IPP> IPP Protocol Meeting Minutes

IPP> IPP Protocol Meeting Minutes

IPP> IPP Protocol Meeting Minutes

Randy Turner rturner at sharplabs.com
Fri Mar 14 21:05:34 EST 1997

This is a multi-part message in MIME format.

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for the delay everyone....these are the minutes that I
collected from the IPP Protocol meeting at Sun last week.


Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com

Content-Type: text/plain; charset=us-ascii; name="ippnotes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ippnotes.txt"

Where do we draw the line between "model" and "protocol".
One of the goals was to make the "model" document
"representation-free", so things like MIME get pushed
into a protocol document.

Larry Masinter mentioned that a statement by Harald &
Keith to NOT use HTTP was advisory, and not a requirement.

Roger brought up the fact that maybe the IPP document should
specify protocol as well as model, potentially for
enhanced interoperability.

A lengthy discussion ensued regarding the usage of
standard HTTP forms to implement the IPP model.

One method for file upload would be to use RFC 1867.
Larry Masinter stated that he knew of 6 HTTP server
implementations of RFC 1867 and that support for this
RFC has been in Netscape Navigator since version 2.0.
He continued by saying that support is also scheduled
for the next version of Microsoft Internet Explorer
(Version 4.0)

Larry Masinter has agreed to isolate the sections of
RFC 1867 and include this information into a separate
IPP-related document. These sections of the RFC 1867
would be only the protocol support for which the
IPP working group deems is necessary for IPP compliance.

<Lunch Break...including discussion of Sharp prototype>

Requirements discussion continued...

Requirements -

1) Protocol doc would be specific enough (in content
   or references) to allow 2 or more independent
   implementations of the specification to interoperate
   for all model operations w/o any other agreements.

2) Nothing in IPP that requires a private agreement
   (something outside the specification) to use.

3) Ways to discover private extensions (protocols?)

4) Protocol will allow future extensions; such 
   extensions will not preclude interoperation with
   prior protocol versions.

5) Client & Server need not have same "locales".

6) There will be a security section that analyzes
   potential threats and specifies how protocol
   treats these threats.

7) Provide mapping of LPR/LPD (as practiced) to IPP.

Some discussion was started on how clients can 
receive asynchronous notification from IPP services.
Larry Masinter suggested that one of the specified
attributes that a client passes on job creation 
would be a URL string that defines a target for
future asynchronous messages. 

A lengthy discussion ensued regarding whether or not
a multiple-post or single-post job submission model
should be required. Steve Zilles suggested that 
servers should probably be support all job submission
models, but clients are free to choose which submission
model they will use to a particular IPP server.

In the multiple-post submission model, there are 
three separate POST operations to submit a job:

		Create-Job, Send-Job-Data, End-Job

The "Create-Job" POST operation would return three
URL strings that define where future accesses to this
job are to be directed:


In the single POST job submission model, the 
Create-Job, Send-Job-Data, and End-job are combined
into a single POST operation.

A foil presentation of protocol models by PWG in
Austin, and for IETF Plenary in Memphis.

Larry should issue a draft of multipart form-data for
RFC1867 by IETF I-D deadline.


More information about the Ipp mailing list