Carl-Uno
Minutes from PWG IPP Meeting in Portland, OR - April 8-9, 1998
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Minutes taken by Jay Martin on April 8.
The meeting started at approximately 8:30 am.
Job openings
Need a permanent, full-time secretary (not Jay!)
Scott will chair the next PWG IPP meeting as Carl-Uno will be unable to
attend.
IETF
Editing and maintenance
Keith Moore wants to see a short document describing the minimal mandator=
y
aspects and components of IPP, from the perspective of the server side
implementation.
No commitment made by any PWG participant to write such a document.
Carl-Uno requested a volunteer to write the document. Peter reminded the
group that the IPP testing document provides much of that kind of info. T=
om
suggested that he, Carl-Uno & Peter will review the testing document and
perhaps deriving a document for Keith Moore=92s use. Carl-Uno stated that=
IPP
V1.0 will formally wrap up its effort by the August 98 IETF plenary.
Carl-Uno announced that Steve Zilles will be asking to be relieved of his
IETF WG co-chairperson position due to other commitments with the W3C.
Scott brought up the fact that the WG has had several proposals for
changes, yet no action has been taken to officially incorporate (or rejec=
t)
those proposals into the formal documents, including:
- Charset and natural language should always be the first and second
attribute in every message in the operations group (affects the Model
document)
- All attributes should be lowercase only, including the values for
language keywords; the document examples need to be updated
- Tom raised the issue of mapping uppercase to lowercase to provide a mor=
e
"forgiving" implementation; the group decided that this was not necessar=
y,
that specifying "always lowercase" is sufficient
- Need to explain the table of attributes with respect to MANDATORY vs.
"required" (section 15 of the Model document)
- Changing URI to URL with respect to references to external IETF
documents, since there is no IETF standards document for URI
Decision: leave it as is (URI). Scott will look into adding some simple
clarifying text in the Model document.
IPP Notifications
What can the IPP group do to satisfy its charter requirements wrt
notifications?
Randy reminded Roger that one of the published requirements was supposed =
to
be removed: the ability for a client to specify which attributes should b=
e
returned in a notification. Rabid discussion followed, resulting in a
decision to make this specific requirement optional rather mandatory. Wh=
at
will be mandatory is support for a fixed list of attributes in a
notification message.
Dictionary proposal
Tom reviewed the recent proposal (v0.92, 3/31/98)
Several people mentioned they have a problem with the term "dictionary", =
so
the term was officially changed to "collection".
The group did not wholeheartedly buy into this data typing and structurin=
g
approach due to its complexity and the lack of understanding of the
requirements
Review of "Notifications for the IPP print protocol" (ipp-job-proposal.do=
c
by Hastings/Lewis)
Consensus was to not provide "ala carte" specification for job event
registrations; instead, events will be gathered into groups, and the clie=
nt
registers for one or more groups.
As a result, job-notify-additional-attributes was removed.
Accessing MIB data through IPP
How to map and access Printer and Job MIB objects using IPP attributes
Scott lead the discussion
Rabid discussion followed resulting in the consensus that the concept and
discussion should be deferred until we conduct more discussion on the
host-to-device issue.
Testing
Peter will draw up and publish a list of the "Top 25" (or so) list of tes=
t
scenarios.=20
Harry pointed out that unless the group schedules a date for a bake-off,
testing will languish.
Carl-Uno is attempting to emancipate a test case generator/analyzer from
the Xerox effort for public use.
The meeting ended at approximately 5:30pm.
--Notes from April 9 taken by Harry Lewis
The meeting started saty 8:30 am =20 Host-to-Device protocol
Carl-Uno tries to set the stage. Trying to get decision on general direction. Concerns. What=92s happening with IPP? Not using HTTP? Drop IP= P into TIPSI? Funny to run this discussion of Host-to-Device protocol on th= e IPP list. Worried about sabotaging peoples confidence in IPPv1.
Change the name of this to Server to printer Review issues - from Paul.
1. IPP asymmetrical. No way to send asych alerts. We=92re working on notification.=20 2. No peer conflict resolution. How does a non-spooling IPP printer resol= ve being asked to print by two clients. Like ticket number that tells you where you are in line. Randy - there are resources at every level of the protocol stack so you really can=92t solve. Randy added two statuses in h= is paper to address this.=20 3. No way for printer to solicit data from the client (to throttle data transfers).=20 All transport layers have a flow control mechanism underneath it. One connection for data and another for control. IPP doesn=92t require this. Maybe we should require this? TCP can do this but IPP is not just TCP 4. Current security too complex? Would security to server and no security from server to device satisfy? Argued that basic authentication is not to= o complex. TLS is optional.=20 5. IPP is not transport neutral. Encoding is HTTP independent except for chinking. From a server standpoint, I want to be able to talk to my printers in whatever way they are connected using one protocol.=20 6. HTTP is heavy duty 7. No way to move data backward (scan, fax...). Embed IPP client in MFP? 8. No separate channel for control. We don=92t make any statements right = now but there should be no reason why we couldn=92t allow or require two connections. Open channel for data, another channel for control. Print jo= b sends status immediately otherwise can=92t query. If IPP CREATE JOB was mandatory, then the job ID would be known early enough to allow queries over separate channel. Maybe in the v2 thing we=92re talking about PrintJ= ob isn=92t even there and createJob is mandatory! 9. Detailed configuration and status not available. =20
We kept discussing the scope, purpose etc. Need to start another project. Decided to start over. Actual proposals for TIPSI and IPP over TCP not reviewed in any organized manner.
Implementers Guide. =20 No one volunteered.
Server to Device PWG meeting Lot=92s of discussion about whether or not we need another protocol.
What are the needs for a server to printer protocol? What are the compelling reasons for doing this. Does it deliver more to the customer? Does it deliver it cheaper? Is there competitive pressure?=20
1. Advantage of single protocol for driver like functions vs. a suite of protocols. - Keeping IP address and URL=92s in synch 2. Advantage of multiple protocols. - Asymmetry maps better to actual communications needs.=20
NEW LIST OF REQUIREMENTS
1. Need a protocol which delivers unsolicited real time status informatio= n (alerts). 2. Flexible security model 3. Transport independent 4. Need way to send FAX or SCAN data from device to server (for MFPs only= ) 5. Control channel can=92t be blocked by data. Server can query and contr= ol with quick response. 6. Need configuration and status info like what=92s provided in the print= er MIB. 7. Ability to recover job accounting information=20 8. Device can retrieve resources like fonts and forms 9. Server to Device protocol must not significantly limit the function of any major existing client to server protocols and must accommodate IPP without any loss.=20 10. Must Cover the case of spooling both in the server and the device or other multiple levels. The user should get the same functionality (CANCEL= , MODIFY etc.). =20 11. What layer are we at? - Application layer. 12. Submit Cancel and list jobs (end-user and administrator) =20
Naming the new project SDP - Server device protocol. Jay is tentative Cha= ir.
SNMP v3 Traps and Informs
Job MIB traps work is ongoing. Looked like a match with IPP notifications requirements. Notification MIB and Trap MIB as part of SNMPv3 introduced = by Randy. Utility and applicability of SNMPv3 MIBs to what we are trying to do. Joe F. and Ira McD. put together proposal for registration.
SNMPv3 128 octet OID string.=20 Trap types or groups are given OIDs.=20 "TargetSpinLock" keeps one agent from overwriting another agent=92s entri= es.=20 Randy recommends use the SNMPv3 target and notification MIBs, augmented, = if necessary with additional function (i.e. Time to Live group indexed to th= e target). JAM MIB supports automatic trap de-registration. Keep alive etc.=20 Is there stuff in the v3 MIBs that we don=92t need? Should we create a hy= brid? Basically, there is a lot of overlap with Xerox MIB and v3 MIB's so use v= 3 and augment. Thru IPP you can register on a per-job basis, but not with SNMP. There, only per time-out (all jobs).=20 No disagreement regarding adoption of this approach.=20 We should use Informs... not traps. For v1 it=92s a trap. For v2-3 use in= form.=20 Need proposal to fit this together. Tom, Harry, Ron. Keep this at tail end of IPP for the next few meetings.=20
Administrator register with time to live. Clients register with job.=20 Need a way to manage reg table itself. Next highest index.=20 Need to define trap informs (informational) Need to write augments for target and notification MIB's (stds track or experimental - might ultimately be subsumed by IETF cause they like this idea).
The meeting closed at 5:30 pm.
Carl-Uno Manros Principal Engineer - Advanced Printing Standards - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com