Keith has said that he wants to forward our proposal (that Randy and Larry
sent to
the IPP mailing list on 6/16) for a new IPP scheme to the IESG along with
our documents. Until the following shortcomings with the current proposal
for a new IPP scheme are fixed, we are not all talking about the same thing:
1. There are no MUST verbs.
2. There are 3 SHOULD verbs.
3. There are no MAY or NEED NOT verbs.
4. Only the outbound gateway is considered, not the inbound gateway.
(Isn't Keith Moore worried about filtering by an inbound gateway?).
5. There is no statements MUST or SHOULD or MAY or NEED NOT about the
scheme in the URI attributes in the application/ipp MIME type itself, i.e,
in "printer-uri", "job-uri", "printer-uri-supported", etc..
I suggest that we try to improve our proposal in the above areas, working
with Keith, before sending it to the IESG. If we agree on something at our
Wednesday, IPP meeting, July 8, is there any chance of interacting with
Keith on it at our meeting on Thursday, July 9, by phone?
This is the same proposal that Randy and Larry produced on June 16, 1998
and send to the IPP mailing list. I have only changed the port number from
374 to the one assigned to IPP as the IPP default port by IANA on June 22,
namely, 631. I also capitalized the "shoulds" to make them stand out. - TNH
Proposal for an IPP scheme
This is a proposal for the registration of a new URL scheme "ipp".
The syntax for the new IPP scheme would be identical to the existing
"http" scheme except for the scheme name itself:
ipp://host[:port]/<IPP-specific-abs-path>
Associated with this new IPP scheme would be an IANA-assigned TCP port
number, which would be 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.
When an IPP client obtains an IPP URL, the interpretation of this URL by
the client can take one of three forms, depending on the configuration
and implementation of the client:
------------------------------------------------------
IPP Client Configured with no proxy server -
------------------------------------------------------
When an IPP client (no proxy configured) obtains an IPP-schemed URL such
as "ipp://myhost.com/myprinter/myqueue, it will 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 will 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:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
It is likely that existing proxies will not understand IPP URLs,
so the RequestURI SHOULD use the HTTP form of the URL.
-------------------------------------------------------
IPP Clients with HTTP-only constraints
-------------------------------------------------------
If a particular IPP client implementation uses a pre-packaged HTTP library
or HTTP class that only supports HTTP-schemed URLs, then the following
operation would be required:
- The IPP client obtains the IPP-schemed URL and converts it to the
following form:
"http://myhost.com:631/myprinter/myqueue"
The client then submits this URL to the pre-packaged HTTP library API.
-------------------------------------------------------
Existing HTTP 1.1 clients (and IPP clients) will only contact IPP servers
using a requestURI specified in #1 below. However, RFC 2068 states that
HTTP 1.1
servers SHOULD accept "full" URLs as well, so IPP servers SHOULD also be
able to
accept requestURIs as specified in #2 and #3 as well.
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)
End of Proposal for a new IPP scheme