ftp://ftp.pwg.org/pub/pwg/ipp/minutes/IETF38-IPP-WG-Meeting.txt
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/IETF38-IPP-WG-Meeting.pdf
Don
-----------------------------------
Internet Printing Protocol Working Group
at the 38th IETF
These minutes were recorded by Don Wright.
The meeting was called to order by Carl-Uno Manros at 9:03
AM CST on April 8th at the Peabody Hotel in Memphis
Tennessee.
Planned agenda:
1) Introduction of WG Charter and Internet-drafts
2) Protocol
3) Security
4) Requirements
5) Model and Semantics
CHARTER:
Carl-Uno reviewed the WG charter including the lists of:
- Advisor, Chairs, Editors
- Current Drafts
The goals and background information of the charter were
then reviewed. (Carl-Uno's charts will be available as a
part of the proceedings) A question was asked as to what
directory methods would be used. The current plan is to
define the directory schema so as to be directory neutral
and to be optional. Since the original IPP BOF at the last
IETF meeting, significant security requirements have been
added to the charter. A question was raised as to how the
directory information would keep up to date when used in a
cached environment. Since IPP is not defining the directory
access method only the schema, IPP will not be addressing
the area of caching of directory information. Many people
felt that the directory work should be a milestone after the
protocol is done; however there were others concerned that
while the actual document could be done later, it needed to
be considered while working on the model. The WG will
produce recommendations for inter-operation between IPP
clients/servers and LPD clients/servers.
Charter Milestones:
March 97: Internet Drafts: requirements, model, protocol,
and directory schema
May 97: Several implemented prototypes
August: Requirements I-D to IESG as informational RFC
Mapping IPP/LPR mapping as informational RFC
Other documents submitted as RFCs
Contact Information:
Discussion list is ipp@pwg.org.
To subscribe: ipp-request@pwg.org
Archive is ftp://ftp.pwg.org/pub/pwg/ipp
Web Server is http://www.pwg.org/ipp/
A long discussion on what should be covered within the
directory schema. One of the major potential problems
identified was how to include access control as a part of
the information available through the directory. The scope
of IPP at this time does not cover administrative functions
like job accounting.
PROTOCOL:
Steve Zilles presented an outline of the general direction
the group is going in the area of "protocol." (Steve's
charts will be a part of the proceedings.) A concern was
raised that if multiple, alternative ways are defined to do
something, we will fail. This comment was directed at the
current direction to perhaps support Application/IPP and
Multipart/FormData as well as support both HTPP/1.1 and some
new IPP TBD. The current protocol issues Steve identified
are:
1) Status inquiries during data transmission
- posting all the data at once
--- versus---
- create job, send data
2) What must the server implement?
- full HTTP/1.1
- IPP subset of HTTP/1.1 (non-caching, origin server)
- TBD protocol
Questions:
- Can we really subset HTTP/1.1?
- Work level difference between creating a new protocol
versus subsetting?
- Harald Alvestrand. presented a concept of layering
and a HTTP/HTML presentation of data to be send via
or received from an IPP protocol.
Interoperability issues with potentially two protocols and
syntaxes are:
1) One protocol, two syntaxes
- server must implement both
2) Two separate protocol
- formdata over HTTP
- application/ipp over tbd
- server may implement either
3) Does the request format determine the response format?
4) How are the operations coded?
- in the formatted data
- in the protocol header
- in the URL that is the target.
SECURITY:
Carl-Uno presented the work being done on security for IPP.
(These charts will be available in the proceedings.) The
type of attacks that could be deployed against IPP were
described including masquerading, eavesdropping, tampering,
replaying, denial of service, document malicious content
code (embedded programs in the print job), liability and
provability of service. All these were mapped against
security services like client authentication, server
authentication, data confidentiality, data integrity, non-
repudiation and timestamping/nonces. There were some areas
of the chart that need to be updated with additional
"yes"es. "Signing" was identified as something that has
been very useful as a combination of authentication and
integrity.
The group has looked at a number of security services being
investigated including HTTP/1.1 (Digest Authentication --
RFC 2069), SSL(V2), SSL(V3) and LDAP. Additional security
service suggested to be examined include sHTTP, SMIME and
PGP.
Simple security service (like LPD user name) would probably
not be appropriate for a standards track document (Keith
Moore.) Adequate security must be defined but the security
level may be negotiated between the client and the server.
Harald A: Decisions on security should be made by the
working group not by the Area Directors but having no
security will probably be a problem.
MODEL DOCUMENT:
Harald A. expressed his opinion that while the model
document is very large, it seems incomplete. He had a
several comments and will document them in detail to the
distribution list.
Due to a lack of time, the Requirements document was not
discussed.
The meeting was adjourned at 11:35AM CST.
-----------------------------------
*************************************************************
* Don Wright (don@lexmark.com) Lexmark International *
* Manager Strategic Alliances *
* 740 New Circle Rd Phone: 606-232-4808 *
* Lexington, KY 40511 Fax: 606-232-6740 *
*************************************************************