IPP WG - IETF 50th Plenary
Carl-Uno Manros led the Internet Printing Protocol (IPP) WG session. Around
20 people attended.
He explained that because there was no meeting at the last Plenary, some of
his presentation spanned several months.
Agenda:
- Overview of all current IPP Internet-Drafts and where they are in
the IETF process
- Review and comments on IPP Internet-Drafts, currently in IPP WG
Last Call
- Report from the IPP interoperability testing event Autumn 2000
- Future plans for IPP
1. Document Status
[IPP Project Time Line diagram]
1996: PWG Start
1997: IETF Start
1998: First bake-off
1999: IETF IPP/1.0, bake-off 2
2000: IETF IPP/1.1, bake-off 3
2001: IETF IPP/1.1 extensions
1999: RFCs 2565-69, 2639 - IETF Experimental:
- Rationale for the Structure of the Model and Protocol for the
Internet Printing Protocol
- Mapping between LPD and IPP Protocols
- IPP/1.0: Model and Semantics
- IPP/1.0: Encoding and Transport
- IPP/1.0: Implementers Guide
- Design Goals for an Internet Printing Protocol
2000: IETF Standards Track:
- IPP/1.1: Model and Semantics - RFC 2911
- IPP/1.1: Encoding and Transport - RFC 2910
- IPP/1.1: Implementer's Guide [not Standards Track] - in IESG
- IPP: Requirements for Job, Printer and Device Operations [not
Standards Track] - in IESG
- IPP: Job and Printer Set Operations - in IESG
- IPP: The 'collection' attribute syntax - in IESG
- IPP: Job and Printer Administrative Operations - in IESG
- IPP: LDAP Schema for Printer Services - in IESG
- IPP: Requirements for IPP Notifications [not Standards Track] - in
IESG
- IPP: Event Notification Specification - in IESG
- IPP: Job Progress Attributes - in IESG
-
-
- IPP: The 'mailto' Notification Delivery Method - in IESG
- IPP: The INDP Notification Delivery Method and Protocol/1.0
- IPP: The 'ippget' Notification Delivery Method - in IESG
Ned Freed commented that most documents have gone thru IESG. IANA is having
some confusion about how to handle some of the registries. Ned will
coordinate with IANA to determine next steps. He also indicated that
"things are fine."
Ned reported that Patrik Fältström is still working on the LDAP document-
and he hopes that Patrik will finish his review soon.
IETF drafts currently in Last Call
- IPP URL Scheme
<draft-ietf-ipp-url-scheme-02.txt>
- The 'indp' Delivery Method for Event Notifications and
Protocol/1.0
<draft-ietf-ipp-indp-method-04.txt>
- The 'ippget' Notification Delivery Method for Event Notifications
<draft-ietf-ipp-notify-get-02.txt>
- Printer Installation Extension
<draft-ietf-ipp-install-02.txt>
- IPP URL Scheme
- The 'indp' Delivery Method for Event Notifications and
Protocol/1.0
- The 'ippget' Notification Delivery Method for Event Notifications
- Printer Installation Extension
Carl-Uno asked for any comments about the above drafts.
Ned commented that a clear security section would be necessary.
There were no other comments on the drafts.
IPP Specifications that are PWG documents:
- IPP: Override Attributes for Documents and Pages
IEEE-ISTO 5010.4
- IPP: Production Printing - Set 1
IEEE-ISTO 5010.3
- IPP: 'finishings" attribute values extension
IEEE-ISTO 5010.1
- IPP: 'output-bin" attribute extension
IEEE-ISTO 5010.2
Carl-Uno mentioned that some of these documents also generate additional
IANA registration needs.
2. Report from the IPP Interoperability Testing Event Autumn 2000
Fifteen printer vendors participated in the IPP bake-off. Four firewall and
proxy server vendors participated:
- 17 companies total
- 9 IPP client side implementations
- 16 IPP printer side implementations
- 96% IPP/1.1 client/printer success rate for interworking
- Firewalls and proxies worked fine
- A few issues:
* HTTP stack
* IPP/1.0 and IPP/1.1 interworking
Carl-Uno mentioned one problem experienced was that a 100 Continue was
unexpectedly received. A few people, including Larry Masinter, agreed that
no response should be sent until a request is received.
3. Market Activity with IPP
Carl-Uno gave some status on IPP products.
Canon, Ricoh, and Xerox have all introduced Multifunction products with IPP
support.
New IPP Products in Japan from the following companies:
- Canon - printers, multifunction systems
- Epson - printers, small print servers
- Fuji Xerox - printers, multi-function systems
- HP - small print servers, network cards
- JCI - network cards
- Minolta - printers
- Ricoh - printers, multi-function systems
Europe:
- Axis, Sweden
- I-data, Denmark
- SEH Computertechnik, Germany
New IPP products - Linux
- Several vendors are now offering IPP Open Source code for Linux:
* Easy Software Products - CUPS
* Astart Technologies - LPRng
* VA Linux - GNUlpr
- Expect to see IPP code in most Linux distributions in 2001
New IPP products - Applications
- Easy Software Products
* IPP as transport for miniMAX international
miniMax services competes with Kinko's and other printing shops
* IPP as printing service in the US Department of Defense
- From PrinterOn
* IPP for PrinterOn Internet Printing Services among Seybold
Editors' Hot Picks in San Francisco 2000
IPP impact in other printing standards
- Universal Plug 'n' Play (UPnP) - Microsoft led consortium
- Wireless Printing in Bluetooth - Telecom consortium
- Job Definition Format (JDF) - CIP4 consortium on Production
Printing
- IPP Fax - Printer Working Group project
- PPML - PODi (Print on Demand Initiative) consortium
4. Future plans for IPP
Remaining Work in the IETF IPP WG:
- Get the 4 WG Last Call drafts edited with any final comments and
sent to the IESG
- Make one more revision of the IPP/1.1 Implementer's Guide to
incorporate resolutions to a few issues from the latest bake-off
and send to IESG
- Fix any issues brought up by the IESG or the RFC Editor
- Finish some IANA registrations for document types, etc.
Ned said that it is not necessary to create any RFCs for registering MIME
types. It is especially easy if it is a vendor type.
Carl-Uno suggested to Ned that when the remaining documents can
successfully be pushed through the IESG, he believes that the IPP WG will
be ready to close.
5. HTTP Authentication
Scott Lawrence briefly referenced HTTP Authentication (RFC 2617) and
Upgrading to TLS within HTTP/1.1 (RFC 2817).
After reviewing past IPP e-mail on security, Scott wanted to clarify some
HTTP Digest Authentication Misconceptions.
Purposes of the Client Nonce (cnonce)
- Prevent chosen-plaintext attack
* Attacker spoofing server cannot choose all of the inputs to the
authentication hash
* Incidentally protects against sloppy nonce choices by server
- Mutual authentication
* The client can check the response digest to verify that the
server also knew the shared secret
Message Body Integrity Protection
- NOT algorithm=MD5-sess
* MD5-sess modifications shared secret usage to permit third
party authentication services;
has no effect on body integrity
- qop=auth-int
* Provides body integrity protection by incorporating body hash
into authentication hash calculations
* Note that you don't know the authentication status until the
end
Other
- A server can challenge any time it wants to
- For any reason it wants
- How can a server distinguish protection domains?
* Modify the realm name?
Carl-Uno requested that Scott should send his comments to the IPP e-mail
list, given that many of the IPP participants were not at the Plenary.
Scott also mentioned that the HTTP reflector-although not very active-is
still operating. He recommends that any HTTP questions should be directed
to that list.
6. Fragmenting/Chunking XHTML/XML
Carl-Uno raised a last topic on Fragmenting/Chunking XHTML/XML to help deal
with receivers that have limited resources. He mentioned that a few groups
have been struggling with this issue recently. Two Internet-Drafts will be
published in the near future:
- The MIME Multipart/Interleaved and application/chunk Content-types
* draft-herriot-multipart-interleaved-00
- The MIME Application/BatchBeep Content-type
* draft-herriot-application-batchbeep-00
Larry said that the problem really can't be solved-in general. He feels
that neither of the above methods avoids the potential need to buffer at
the receiver's end. If the receiver doesn't do the buffering, the sender
must do the buffering at the receiver's request/control.
Predicting the optimal buffering order is a very difficult effort-even if
it is within a single page.
The fundamental issue is not an encoding problem. It is related to the
incremental rendering of a compound document by a device that cannot buffer
all the components. This is very similar to the problem(s) being faced by
mobile devices.
Ned: Have you considered "pull" instead of "push"?
Perhaps an IPP client could act as a server to pull the data when it is
ready? There's nothing to stop you from having a reverse HTTP connection.
If MIME types are used for this approach, it would be appropriate to
identify them for limited use only. For example, these types would not be
appropriate for web browser support.
Larry referenced a W3C requirements document that discussed "packaging"
components. It includes the concept of a manifest and several other
features. He recommends examining this document as part of the effort to
generate a possible solution.
Carl-Uno indicated that the group will need to consider whether it makes
sense to try to solve this as an "object" problem, or if it is more
appropriate to examine as a communication problem.
He also said that he does not think that he will be able to get travel
authorization to attend the August IETF Plenary, but hopes to attend in
December.
Meeting adjourned.