IPP Mail Archive: Re: IPP> Re: New IPP Scheme

Re: IPP> Re: New IPP Scheme

Randy Turner (rturner@sharplabs.com)
Wed, 15 Jul 1998 21:38:06 -0700

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=20
scheme it sees.

(?)

Randy

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