Keith,
If you can wait a couple of days, we will forward you a *final* version of
this proposal before you forward this to the IESG......(?)
Randy
----------
> From: Tom Hastings <hastings at cp10.es.xerox.com>
> To: Keith Moore <moore at cs.utk.edu>
> Cc: ipp at pwg.org> Subject: IPP> On clarifying the proposal for a new IPP scheme
> Date: Monday, July 06, 1998 12:09 PM
>> At 14:13 07/03/98 PDT, Keith Moore wrote:
> >Tom,
> >
> >The best thing to do at this point would be for me to run this proposal
> >by the entire IESG when it is balloted. So I'll include it in the
> >formal ballot that gets sent to IESG.
> >
> >Keith
>> 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