This is a multi-part message in MIME format.
--------------7DA9308557A7
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
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com
--------------7DA9308557A7
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:
Printer-Assigned-URL
Query-Status-URL
Modify-Job-URL
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.
--------------7DA9308557A7--