IPP> ADM - Minutes from PWG PP Meeting in Monterey - July 8-9, 1998

IPP> ADM - Minutes from PWG PP Meeting in Monterey - July 8-9, 1998

IPP> ADM - Minutes from PWG PP Meeting in Monterey - July 8-9, 1998

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Tue Jul 21 18:17:33 EDT 1998


1 Internet Printing Protocol - July 8-9, 1998

2 Attendees

David Pond	      Apple
Lee Farrell	      Canon Information Systems
Ron Bergman 	Data Products
Shivaun Albright	Hewlett Packard
Brian Batchelder	Hewlett Packard
Alan Berkema	Hewlett Packard
Sandra Matts	Hewlett Packard
Ken Oakeson	      Hewlett Packard
Kris Schoff	      Hewlett Packard
Harry Lewis 	IBM
Yuji Sasaki	      Japan Computer Industry
Stuart Rowley	Kyocera
Don Wright(4)	Lexmark
Paul Moore	      Microsoft
Hugo Parra	      Novell
William Wagner	Osicom
Charles Quan Kong	Panasonic
Atsushi Uchino	Seiko Epson
Randy Turner	Sharp
Anthony Fung	ST Microelectronics
Tom Hastings	Xerox
Carl-Uno Manros	Xerox
Xavier Riley	Xerox
Rick Yardumian 	Xerox
Pete Zehler	Xerox

3 Administrivia

Don Wright provided details for the next PWG meeting:
· August 17-21
· Toronto Marriott at Eaton Centre
· 525 Bay Street
· Toronto, Ontario, Canada M5G 2L2
· $175CN (about $120 US)
· Deadline is July 24, 1998

Future PWG meeting schedules will have the following structure:
· MIB meetings on Tuesday evenings (if needed)
· PWG Plenary on Wednesday mornings
· IPP meetings on Wednesday afternoon and Thursday morning
· SDP meetings on Thursday afternoon
· UPD meetings on Friday

The PWG meeting calendar for 1999 will be discussed at the next meeting
in Toronto. A first draft of dates and locations will be generated for
review and evaluation.

Carl Uno-Manros opened the IPP meeting. He presented the meeting goals
and proposed agenda topics:
· Discuss Keith Moore's (IETF Application Area Director) comments on IPP
draft documents
· Reactivate us on the registration of Printer MIB document types as
MIME types
· Microsoft's proposal to register IPP extra operations
· Discuss plans for IPP interoperability testing
· Agenda for August IETF Plenary
· Discuss Implementor's Guide activities for IPP
· Discuss a question from the IFAX group: Would the IPP group be
prepared to write a mapping document for IPP to IFAX?
· MIB access over IPP
· IPP Notifications

Carl-Uno noted that it is unlikely that we will be able to address all
the above topics. The first item is the most important (and will
probably occupy most-if not all-of the meeting.)

4 IESG Obstacles on IPP drafts

It was suggested that the PWG group needs to consider their position on
the IPP standards independently of the IETF views and opinions. It was
noted that the PWG members seem to have reached agreement - only the
IETF/IESG has any objections to the latest draft documents. One person
raised the question about whether the group would consider moving
forward with the IPP standard without IETF support. "What does it take
to determine when the IPP v1.0 effort will be completed?"

Someone voiced his frustration with the IETF and strongly suggested that
the PWG group split from IETF control. 

[A lively discussion ensued, accompanied by a free flow of ideas and
opinions.]

During the discussion, Randy Turner said that he has received a private
e-mail that suggests there will be another objection to the IPP
documents with regard to security. He was not willing to provide more
details. He believes that there might be a minimal security requirement
that may be raised.

Shivaun Albright pointed out that the IETF has provided useful technical
guidance. She is concerned about the possible negative press that would
result from the PWG splitting from the IETF.

The group is very concerned that the IETF process (and possible
additional objections by the IESG) may delay the process much more.
Carl-Uno believes that the IESG will formally review the documents in
the next three weeks. As a result of that meeting, he believes that they
will provide a complete list of the outstanding problems.

"Why can't we just get to the stage of Proposed (Draft) Standard, and
choose to implement them as written?" (And not wait for total agreement
from the IETF/IESG.)

How about if we just put the word "SHOULD" for including the ipp://
scheme in the specification, and agree not to implement it?

Carl-Uno suggested that people should write to Keith Moore and explain
that they have implemented the current set of documents. Perhaps this
will help to persuade him (and the IESG) to accept the documents as is.

Three alternatives were identified:
· split with the IETF
· wait for the full IETF process
· implement what we have now, and wait for the process to continue -
decide later to change if necessary

An attempt was made to obtain a consensus opinion on which decision the
group wants to follow. Although a formal vote was not taken, it seemed
that several people feel that we should still abide by the IETF/IESG
decisions.

The group agreed that no one should implement the ipp:// scheme until
agreement has been reached within the IETF. 

The group then decided to spend the afternoon drafting a response to
Keith Moore. It was suggested that we develop a document that includes
the requested changes from Keith Moore, but also explains why the PWG
members disagree with them.

5 IPP Scheme

Carl-Uno provided a summary of what he understands that Keith Moore
requires for the use of the ipp scheme. Whenever a URL is viewed or used
by a user, it should be "ipp://" to refer to a printer. Also, the ipp
scheme should be used for the MIME content type. However, Carl-Uno
believes that we can use http:// when communicating to the server.

The group reviewed a proposal from Randy Turner that was sent to the
e-mail list on June 16. Various changes were suggested and will be
included in an updated proposal response to Keith Moore.

There were several comments speculating on exactly what Keith Moore
believes. (Unfortunately, he was not present to explain his position.)
An e-mail excerpt from Keith Moore was referenced to help clarify his
position:

There was much concern about the apparent contradiction of requiring
that servers support "a full IPP URL" even though no client
implementation is allowed to use them. There was repeated discussion
about whether this is a reasonable concern. Two individuals strongly
suggested that this requirement should be removed. As a compromise, it
was left as a SHOULD instead of a MUST.

6 IPP Scheme in the Body

Keith Moore also says that any URL in the body content that references
an IPP Printer should use the ipp:// scheme. 

7 Security

What happens for translating ipp:// to http:// if security is desired?
How does the new scheme for ipp indicate security? How will a process
determine if an IPP URL should be mapped to http:// or https://? If it
is mandated that ipp:// is used, how can an IPP Printer indicate that it
should be contacted using https://? No clear conclusion was reached for
any of these issues.

Randy said that the IETF would be very happy if IPP included SASL.
Carl-Uno said that if we did, it would further delay things by a few
months.

[More heated exchange of opinions.]

--- "Cooling-off" break ---

Paul Moore summarized an informal conversation that was held during the
break:
Several people feel that a "half-way, pseudo-scheme compromise" (as
currently considered in the modified proposal) will encounter many
problems as we dig deeper into the details. We really need to choose to
use a "pure" ipp:// scheme or a "pure" http:// scheme-not the proposed
"compound" scheme. By convincing the IESG that a compound scheme is not
practical, the group believes that the IESG will agree to using http://
rather than forcing us to start all over and develop a completely new
scheme.

The group again agreed that we should continue to develop a document
that addresses the requested changes from Keith Moore, but also explains
why the PWG members believe it will not work. The group believes that
this approach will be useful to prove that we did our "due diligence" in
attempting to meet the suggestions from Keith Moore. However, after
serious consideration, the group has found that the suggestions do not
produce a viable solution for achieving the protocol.

The group generated a list of several problems with the proposal
(included at the end of the modified proposal-see below.)

8 Proposal Update - continued

The next day, the group participated in a review of some modifications
to the proposal that Randy had made the night before. 

There was much debate about Randy's proposal for including a security
parameter in a URL scheme. Several attendees were concerned that the
IESG would not accept a parameterized URL scheme. No one was aware of
any precedent for this concept, and a few people suggested that defining
such a parameterized scheme should be done outside the IPP WG.

Additional modifications to the proposal resulted in the following
document:


IPP Working Group Analysis of Proposed IPP URL Scheme
----------------------------------------------------------------------

Introduction

The IETF Applications Area Director has proposed that the IPP working
group consider creating a new URL scheme, "ipp:", to reference IPP 
objects, as defined in the IPP Model Document. The IPP working group
has created a usage model of how a potential IPP URL would be used,
if implemented and deployed. This usage model is included in this
document analysis, for completeness.

A subsequent analysis of the usage model for this new scheme has
exposed some critical issues and concerns that the IPP working group
has with the proposed "ipp:" scheme. Considering the impact of these
issues, the working group feels that the integration of a new URL 
scheme into the IPP model and protocol specifications is not feasible
at this time.


Usage Model for "ipp" Scheme
-----------------------------------------------------------------------

In its current definition, IPP uses HTTP 1.1 as a transport protocol,
and
hence uses the existing "http:" URL scheme, in which URL path names and 
MIME types are used to multiplex and demultiplex IPP from the HTTP
protocol data stream. 

The conventional model for the introduction of a new protocol scheme
assumes that the URL scheme maps directly to an application protocol,
network transport protocol and default transport "port number".
Typically, this transport protocol includes a
multiplexing/demultiplexing
capability based on the idea of a port number (e.g., TCP, UDP). 

The working group considered using the "ipp:" URL scheme using the 
conventional model, but the current HTTP infrastructure 
(existing HTTP 1.1 servers and proxies) does not understand "ipp:" URLs,
and would not reliably transport HTTP messages containing headers that
reference "ipp:" URLs.

We finally considered a "compound" URL scheme, wherein a translation
from
"ipp:" to "http:" URL schemes is performed.

The syntax for the new IPP scheme is identical to the existing
"http" scheme except for the scheme name itself. The similarity is
maintained to ease the IPP-to-HTTP translation burden:

ipp://host[:port]/<IPP-specific-abs-path>

Associated with this new IPP scheme is an IANA-assigned TCP port
number, 631, which is the default port number used by clients to
contact IPP servers that are represented by IPP URLs.

The IPP scheme implies all of the same protocol semantics as that of
the HTTP scheme, except that, by default, the port number used by
clients
to connect to the server is port 631. The semantics for clients 
configured for proxy access is different as described below.

The implementation impact of using the new scheme on the existing 
specifications is divided into two key areas: HTTP headers and the
application/ipp MIME body part.

------------------------------------------------------
HTTP Header Usage
------------------------------------------------------

When an IPP client obtains an IPP URL, the interpretation (translation)
of this URL by the client can take one of two forms, depending upon
whether
the client is configured to use an HTTP 1.1 proxy server.


IPP Client Configured with no proxy server 
------------------------------------------------------

When an IPP client (no proxy configured) obtains an "ipp:" URL such 
as "ipp://myhost.com/myprinter/myqueue", it MUST open an TCP connection
to 
port 631 on myhost.com, with the following example headers:

POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...

IPP Client Configured for Proxy Service
------------------------------------------------------

When an IPP client that uses a proxy named "myproxy.com" obtains the URL

"ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to
myproxy.com with the following example headers:

POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:8080
Content-type: application/ipp
Transfer-Encoding: chunked
...

Existing proxies will not understand IPP URLs, so the RequestURI MUST
use the HTTP form of the URL.

After proxy processing, the proxy would connect to the IPP origin server
with
headers that are the same as the "no-proxy" example above.

IPP/HTTP Server Implications
-------------------------------------------------------------------

Existing HTTP 1.1 clients (and IPP clients) will only contact IPP origin
servers using a requestURI specified in #1 below. However, RFC 2068
states
that HTTP 1.1 servers MUST accept "full" URLs as well, so IPP servers
MUST also be able to accept a requestURI as specified in #2 as well.
Also,
IPP servers SHOULD be able to accept a full requestURI as specified in
#3
below. Servers MUST interpret all of the forms below as equivalent.


          1. A "abs_path" URL (e.g., /myprinter/myqueue)
          2. A full HTTP URL (e.g
http://myhost.com:631/myprinter/myqueue)
          3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue)

NOTE: Example #3 is included to support the possible future deployment
of 
IPP services that utilize full IPP requestURIs. Currently, this 
specification does not allow clients to generate full IPP requestURIs.

In all forms of "ipp" URL translation, if an explicit port number is
specified
then this port number MUST be used by the clients and proxies to
initiate 
connections to IPP/HTTP origin servers.


-------------------------------------------------
application/ipp MIME body
-------------------------------------------------

Printer and job URI attributes in the protocol MUST utilize the "ipp"
scheme. The application/ipp body part contains the following URI
components that are affected:

job attributes -
   job-uri
   job-printer-uri

printer attributes -
   printer-uri-supported

operation attributes -
   job-uri
   printer-uri


Other URI attributes in the protocol can contain any number of different
URL schemes, e.g., document-uri, printer-more-info, and are not 
affected by the "ipp" scheme.

-------------------------------------------------------------------
Summary Conclusions
-------------------------------------------------------------------

The IPP working group has serious concerns regarding integrating a new
"ipp:" URL into our specifications. The following issues have been
raised with regards to usage of the "ipp:" scheme.

1. There is currently no defined way for a single "ipp:" URL to
   indicate whether or not a particular IPP server offers "secure"
   connections. Throughout the IPP model document, numerous 
   assumptions are made with regards to our usage of the "http:" URL
   to reference IPP objects, chief among these assumptions is that
   IPP clients treat URL syntax beyond the "host" part of an HTTP URL
   as opaque.

   The IPP working group feels that any specification for security 
   parameters within URL syntax should be a "standard" solution and not
   specifically a "one-off" or one-time only solution for IPP. 
   The effort required to put together a group or effort to accomplish
   this is out-of-scope for our current charter.

2. There is no straightforward way to configure HTTP client proxy
   capability for "proxying" IPP. Currently, there are specific proxy
   configuration options for HTTP clients, such as FTP, GOPHER, HTTP,
   WAIS, etc. There is no option for proxying "ipp:" URLs and this
   deficiency could lead to confusion for the end user. Also, to
correctly 
   configure a proxy service for IPP, the user will have to "know" 
   that IPP actually uses HTTP, and that for IPP proxy service the user
   must configure an HTTP proxy. 

3. Similar to the end-user configuration problem in #2 above, there is
   currently no proxy configuration option for IPP proxy in existing
   proxy server software. IPP will be a "special case" wherein the
   administrator will have to know the special relationship between
   IPP URLs and HTTP URLs.

4. Future use of the "ipp" scheme is compromised by using the new "ipp"
   scheme in the translated form implied by the proposed "ipp:" scheme. 
   The IPP working group would like to reserve use of the "ipp" scheme
   for a pure IPP client/server protocol implementation in the future
   (one that does not require utilization of an existing HTTP 
   infrastructure). In this environment, it seems appropriate to attach
   the "ipp" URL to this future protocol, rather than the initial IPP
   protocol that is just carried in a MIME type within HTTP.

   For example, in a future implementation of an IPP scheme that does
   not utilize HTTP, existing IPP clients would still attempt to 
   translate the "ipp:" scheme into an "http:" scheme, and would do so
   incorrectly, since the future "ipp:" scheme protocol might not use
   HTTP as a transport.

5. The proposal introduces "compound" spoofing by using an "ipp:" scheme
   and transparently translating it to an "http:" scheme An initial
   concern was the fact that there was no way to tell that IPP was
   actually being used by looking at an HTTP URL. However, publishing
   and using only IPP URLs to the user and administrator community might
   hide the fact that IPP is actually using HTTP. 

6. Compound schemes is a new idea and not well understood in its'
   ramifications. In the current IANA registry for URL schemes, there
   are no examples that indicate that scheme "translation" to another
   scheme is required. 

7. All applications that include URI/URL recognition features will have 
   to be updated to include support for the new "ipp:" URL.

8. Existing network infrastructure tools and utilities would need to
   be modified in order to understand the "special" relationship
   between IPP and HTTP URLs.

The working group considers IPP printing an "HTTP application", and
therefore the usage of an "ipp:" URL scheme must maintain a special
relationship with "http:" URLs. The definition of such a "compound"
URL scheme, wherein an "ipp:" scheme is layered or translated to an
"http:" scheme, is somewhat unusual, and the impact of such a definition
on the protocol design and deployment is not generally well understood.
This analysis document has identified a partial list of issues regarding
the integration of the new "ipp:" scheme. It is anticipated that other
unforeseen issues exist, since this technique has not been prototyped.

If the usage model described herein were adopted, these issues raised in
this analysis pose a significant negative impact on the implementation
and deployment of current IPP specifications, as well as potential
interoperability with future revisions of the protocol.

This document will be forwarded to the IESG.

9 Interoperability Testing

Pete Zehler announced that 13 companies (of 35 companies contacted) have
said they are willing to make an announcement about their current status
with regard IPP development. The other companies either have not
responded, or prefer to keep their status private. 

Connectivity issues and bugs in implementations seem to be the major
activity being addressed in the pair-wise testing that is currently
occurring. More testing has occurred, but the participants continue to
guard their activity results.

Pete believes that an interoperability "bake-off" might be achievable
some time in September, or later in the year. A major concern is having
sufficient test tools to support such an effort.

It was suggested that a poll should be taken to see which vendors are
ready (or would be willing) to participate in an interoperability test
within the next several weeks.

Xerox, IBM, Microsoft, and Lexmark all said that they are willing and
able to participate in a bake-off on September 15.

Pete will send out a list of company status and contact points. He will
also send out a request for additional participants for a September 15
bake-off. All implementations will be based on the June 30 specification
documents.

It was estimated that the bake-off would last three days.

10 IETF Plenary Meeting Agenda

Carl-Uno asked what should be planned for the IPP session during the
next IETF Plenary in August. After a short discussion, the following
topics were suggested:
· Status review
· Implementation progress
· Discussion of open issues based on IESG feedback

11 Implementers Guide

Several participants agreed that we should document clarifications and
"lessons learned" from IPP implementation efforts. Carl-Uno volunteered
to collect material for this document. He also said that he would update
the FAQ document.

12 A Mapping Document for IPP to IFAX

Carl-Uno asked if anyone would be willing to write a mapping document
from IPP to IFAX. One suggestion was that Larry Masinter (who made the
request) should provide more information on what he envisions. Harry
Lewis said that he would be interested in talking with Larry about this.

IPP Meeting adjourned

---

My cincere thanks to Lee Farrell for taking the notes.

Please note that later discussion with Keith Moore seems to make it
quite clear that there is an ipp:// scheme in IPP's future.

Further feedback expected from the IESG after their July 30 meeting.

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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 



More information about the Ipp mailing list