Moderator: Carl-Uno Manros
Note taker: Scott I.
Attendees:
Scott Isaacson, Steve Zilles, Roger deBry, Lee Farrell, Ron Bergman, Peter
Zehler, Randy Turner, Harry Lewis, Bob Herriot, Tom Hastings, Ira McDonald,
David Kellerman
Start 2:05 PM Mountain
Agenda:
1. Review Munich
- Carl-Uno with edit and produce the minutes
- Break up of the Security Doc: Roger, Scott, and Bob to get together an
editors meetings early the week of 8/9/97.
- New Issues There was talk that IPP must start in a secure mode and
negotiate down to a unsecure mode
- Keith suggested mandatory use of TLS, but TLS is not deployed yet
- Should we include security attributes in IPP itself since TLS is not
deployed.
- Is it possible to force TLS framing with NULL parameters for all IPP
implementations? Not practically given that TLS is still not deployed on
the first round of HTTP/1.1 servers.
- Use of TLS under HTTP is an HTTP problem. Keith might say that a
statement such as "we will do whatever HTTP does" however a statement such
as "we will do something different than HTTP" is also unacceptable.
- SEC action item to see if TLS backward compatibility for SSL3. Xerox
people are working on this.
- Randy will contact TLS working group about SSL backwards compatibility and
proposed use with HTTP.
- Carl-Uno will contact Larry Masinter
- Carl-Uno will set up a security call
2. Editing Issues
- Re-edit requirements document. Don will do this. Peter Z will email a
reminder to Don.
- Scott will reissue Model document by 9/3/97
- Bob will reissue Protocol document by 9/5/97
- Directory should be standards track. Hopefully Scott can get to this by
the end of September
- Steve will update rationale document
- Bob will put LPD mapping document on lower priority as an informational
RFC
3. Review outstanding Issue
3.a MIME types
- IPP will use MIME. Who will register? PWG or the vendor? There is huge
pain in having two systems. We ought to update IANA registry for Printer
Document Format Enums to point to the MIME type.
- Don or Lloyd should add the issue of Printer MIB support for MIME types to
the PMP working group. Suggest: keep the same Printer MIB registry, do not
deprecate it, add a new optional, printerLangMIMEType
- MIME types can optionally contain the language and char set
- Harold and Keith need to be advised as to the problem with char set
registry (the registry has more than 1 for each char set) Steve Z will do
this.
- Job MIB allows for both MIME type and Printer ENUM
- IANA has a double registry right now (MIME and Printer MIB) If we don't
add a new MIME type object to the Printer MIB, we will not be able to
transition very easily.
3b. URI for Jobs or ID for Jobs
- Point of order: final discussion on the mailing list
- Reading of the minutes from Redmond about Job URI
- Deciding on Job URI or Job ID there are issues with 1) APIs for exiting
practice and 2) Gateways If the Printer or the Gateway which generates the
Job URI choose to do <printer URI>/<jobnumber>, that is ok. However, what
if the client side expects IDs not URIs and the Printer or Gateway only
generates URIs? This is true for most APIs. Even in most DPA
implementations, they implemented 32bit integer rather than OCTET STRING.
- What about redirect (DPA resubmit). If the ID is just a Job ID, it is
always in context of a Printer URI and so if you redirect Job requests you
also have to redirect the Printer requests which is not desired.
- Scalability issues: Central IPP Printer for security , access control,
validation etc., but then multiple back end IPP Printers for Job processing
and Job status.
- Can we explore a way to do both (Job URI and Job ID)?
- There might be mapping being done already with Job Handles for writing vs
Job IDs at the client anyway
- Bob to write down reasons for Job ID
- Randy to reformat reasons for Job URL
4. Other issues:
a. Semantics of time out
b. Semantics of walk-up user vs network users
c. Why protocols shouldn't have version numbers?
d. Why is "printer-up-time" MANDATORY?
e. What is the value of "Get-Jobs" without order?
5. Waltham Review
- It went reasonably well
- Some people are actually beginning to write stuff (mostly positive about
the direction, a little weak on details)
- Wait and see if we need another one
- Perhaps a west coast version around December IETF.
6. Agenda items for Atlanta
a. Dictionary Syntax
b. Fax number
c. Interoperability Testing
End: 4:10 PM Mountain