IPP> Minutes from IPP WG in IETF 47

IPP> Minutes from IPP WG in IETF 47

IPP> Minutes from IPP WG in IETF 47

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Wed May 10 16:32:48 EDT 2000

Please find attached the minutes from the IPP WG meeting in Adelaide

Carl-Uno Manros
Chair of IETF IPP WG

Principal Engineer - Xerox Architecture Center - 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 at cp10.es.xerox.com 

-------------- next part --------------
Minutes from the IPP WG Meeting in IETF 47 - Tuesday March 28, 14:15 - 15:15

Note taker: Lee Farrell

Carl-Uno Manros, Chair, led the Internet Printing Protocol (IPP) WG session. 
Around 30 people attended. 

Carl-Uno listed the IPP/1.1 documents that are still under review by the IESG:
- Model and Semantics
- Encoding and Transport
- Implementer’s Guide

He noted that although there have been some recent updates on these documents, 
the changes have been editorial in nature, the technical content has remained the 
same since the documents were submitted in June 1999.

He also listed the new IPP Notification drafts:
- IPP Event Notification Specification
- The "mailto:" Notification Delivery Method
- The "ipp" Notification Polling Method
- The "INDP" Notification Delivery Method
- IPP Notification Delivery Protocol (INDP protocol)
- Notifications over SNMP

Bob Herriot then presented some slides about issues using HTTP "chunking" with 
regard to notification messages. He first asked the group whether HTTP proxies 
support chunking:
- for POST in requests?
- for POST in responses?

But none of the attendees could provide an answer.

As a brief background, Bob explained that subscriptions for both printer and job 
events contain the notification recipient URL. The event notification is intended 
to be delivered to the specified recipient URL whenever the event occurs. 
Currently, there are four different delivery methods currently under consideration:
- ipp-get:
- indp:
- mailto:
- snmp-notify:

In the ipp-get method, the Printer saves each event for a fixed amount of time. 
The client must poll for event notifications within this time interval. 
When polled, the Printer responds to the client with one or more event notifications 
and a recommended time (lease time) by which the client should next poll.

Bob raised a few issues:
- In order for the client to receive events as they occur, should there be an operation 
with a single HTTP POST, returning event notifications in multiple response-parts spread 
over a long duration of time (e.g., several minutes)?
- Should this operation use HTTP GET instead of POST?

Although there was some discussion of the first two items, several people in the group 
felt that the appropriate experts were not present to adequately address this question. 
Later, Keith Moore suggested, "Try it - it might work." 
However, it was noted that intermediaries on the network might prevent it from being 
a reliable method.

- Should each response-part be a separate message body in MIME multi-part?

Keith Moore suggested that this should not be done. He recommends that the group should 
"avoid the complication."
- Do the lease and server recommended times make this polling mechanism a reasonable 
alternative to Printer-initiated event delivery methods (i.e. mailto, indp, and 

The last question caused Keith Moore to raise a concern that if multiple notification 
delivery methods are used within IPP, it is very likely that a user will experience 
widely differing behavior - depending on the method employed. He recommended that perhaps 
the group should concentrate on a single method of event notification. When asked which 
one, Keith suggested that ippget might have the best chance of working in most 
environments. He also suggested that ippget would require less code (no additional 
protocols), but might require more cache/memory - for storing events. This could be 
lessened by using shorter time intervals, causing fewer events to be saved at one time.

Carl-Uno noted that the group consensus seems to be that support of ipp-get is favored 
as the baseline delivery method. The mailto method might be a secondary increment.

Carl-Uno then referenced the Internet-Draft proposal for an LDAP schema for printer 
services: draft-ietf-ipp-ldap-printer-schema-00.txt. He noted that this document is 
aligned with the SLP printer template: draft-ietf-svrloc-printer-scheme-06.txt

He listed the new Internet-Drafts on additional IPP operations and syntax:
- Job and Printer Set Operations: draft-ietf-ipp-job-printer-set-ops-01.txt
- The 'collection' attribute syntax: draft-ietf-ipp-collection-02.txt

Carl-Uno referenced that at the previous IETF Plenary in November he led a BOF session 
for IPPExt. At that meeting, the group proposed additional future work for the IPP WG. 
As a result of that meeting, a proposed Charter was submitted to the IESG for an IPP 
Extensions Working Group. He said that he has not yet received any response about forming 
a new WG.

The proposed Charter contains two areas of focus for future activity in the IPPExt WG. 
The proposed Milestone deliverables are:
- New Operations - June 2000
- Notifications - September 2000

Before the meeting ended, Carl-Uno expressed his idea of making available 
"open source IPP client(s)" for full support of IPP. He mentioned that Microsoft is 
only supporting the bare minimum of the IPP feature set in their client. He would also 
like to see clients that work on other operating systems besides Windows. If anyone,
or any company, is interested in working on this goal, please contact Carl-Uno.

IPP meeting adjourned.

More information about the Ipp mailing list