Re: IPP> Re: New IPP Scheme

[Randy Turner <[e-mail]>]

I read the action items below and it appears very close to our previous usage
model. Except below, this
version says the IPP server "SHOULD" accept "ipp:" URLs wherein I would think
this would be a "MUST",
since later on it mentions that this document does not discuss what a server
does with any other URL 
scheme it sees.

(?)

Randy




At 06:41 PM 7/15/98 -0700, Robert Herriot wrote: 
>
> Action item from Robert Herriot and Tom Hastings:
>
> The IPP working group reached an agreement with Keith Moore in this 
> morning's teleconference. This document is our best understanding of the 
> details of this agreement.
>
> Summary:
>
> The quick summary is that IPP should support a new scheme 'ipp', which 
> clients and servers use in IPP attributes. Such attributes are in a message 
> body whose Content-Type is application/ipp.  A client maps 'ipp' URLs to 
> 'http' URLs, and then follows the HTTP/1.1 rules for constructing a 
> Request-Line and HTTP headers. The IPP document will not prohibit 
> implementations from supporting other schemes in IPP attributes, but such 
> support is not defined by this document.  
>
> Now for the details.
>
> A client and an IPP object (i.e. the server) SHOULD support the 'ipp'
scheme 
> in the following IPP attributes.  Each of these attributes identifies a 
> printer or job object. The 'ipp' scheme is not intended for use in 'uri' 
> valued attributes not in this list.
>
>      job attributes - 
>  job-uri 
>  job-printer-uri
>     printer attributes - 
>  printer-uri-supported
>     operation attributes - 
>  job-uri 
>  printer-uri
>
> If the scheme of the target URL in a request (i.e. the value of  
> "printer-uri" or "job-uri" operation attribute) is some scheme 'x', other 
> than 'ipp', the behavior of the IPP object is not defined by this
document.  
> However, it is RECOMMENDED that if an operation on an IPP object creates a 
> new value for any of the above attributes, that attribute has the same 
> scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the 
> seven attributes above in the response, that the IPP object returns those 
> URL values as is, regardless of the scheme of the target URL.
>
> If the client obtains a target URL from a directory service, the scheme of 
> the target URL SHOULD be 'ipp'.  If the scheme is not 'ipp', the behavior
of 
> the client is not defined by this document, but it is RECOMMENDED that the 
> client use the URL as is as the target URL.
>
> Although user interfaces are beyond the scope of this document, it is 
> RECOMMENDED that if software exposes the URL values of any of the above 
> seven attributes to a human user, that the human see the URL as is.  
>
> When a client sends a request, it MUST convert an 'ipp' target URL to an 
> 'http' target URL for use in the HTTP Request-Line and HTTP headers as 
> specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the 
> value of the "printer-uri" or "job-uri" attribute in the message body.  If 
> the scheme of the target URL is not 'ipp', the behavior of the client is
not 
> defined by this document, but it is RECOMMENDED that the client use the 
> target URL as is in the Request-Line and HTTP headers.
>
> A client converts an 'ipp' URL to an 'http' URL by 
>     1) replacing the 'ipp' scheme by 'http' 
>     2) adding an explicit port 631 if the URL does not contain an explicit 
> port.
>
> When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL 
> such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection 
> to some port (this example uses the IPP default port 631) on some host 
> (“myhost.com” in this example) with the following headers:
>
> POST /myprinter/myqueue HTTP/1.1 
> Host: myhost.com:631 
> Content-type: application/ipp 
> Transfer-Encoding: chunked 
> ...
> "printer-uri" "ipp://myhost.com/myprinter/myqueue"  
> (encoded in application/ipp message body) 
> ...
>
> When an IPP client sends a request via a proxy, such as “myproxy.com”, to
an 
> ‘ipp’  URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a
TCP 
> connection to some port (8080 in this example) on some proxy (“myproxy.com” 
> in this example) with the following headers:
>
>
> POST
> <http://myhost.com:631/myprinter/myqueue>http://myhost.com:631/myprinter/m
> yqueue   HTTP/1.1 
> Host: myproxy.com:8080 
> Content-type: application/ipp 
> Transfer-Encoding: chunked 
> ...
> "printer-uri" "ipp://myhost.com/myprinter/myqueue"  
> (encoded in application/ipp message body) 
> ...
>
> The proxy then connects to the IPP origin server with headers that are the 
> same as the "no-proxy" example above.
>
>