Agenda for IPP Phone Conference 980715
======================================
We will hold our normal weekly conference on Wednesday.
Contrary to our belief that the IPP scheme discussion
might be finished by now, it has turned out it isn't quite.
Keith Moore has come back with his comments on the Monterey
output document on the IPP scheme and wants to have new
feedback from the group if the proposal is now more palatable.
It seems that there is still a disconnect about which
infrastructure services are needed for IPP, and what the
user experience should be for IPP.
For those of you who may not yet have seen the Monterey
document, I have attached that as a text file.
I expect that the discussion will continue on the DL for
the next few days, and we will review any new input on the
subject in the phone conference.
By copy of this message, I am also inviting Keith to
participate. Keith, can you please confirm back to me
whether you can attend?
Here is the dial-in information:
Time: July 15, 10:00 - 12:00 PDT (1:00 - 3:00 EDT)
Phone: 1-800-857 5607
Passcode: cmanros
Carl-Uno
--=====================_900253698==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="ipp_scheme1.txt"
Monterey, July 9, 1998
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.
--=====================_900253698==_
Content-Type: text/plain; charset="us-ascii"
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@cp10.es.xerox.com
--=====================_900253698==_--