Re: IPP> On clarifying the proposal for a new IPP scheme

["Randy Turner" <[e-mail]>]

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 <[e-mail]>
> To: Keith Moore <[e-mail]>
> Cc: [e-mail]
> 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