Begin forwarded message:
> From: RFC Errata System <rfc-editor at rfc-editor.org>
> Subject: [Editorial Errata Reported] RFC2910 (4101)
> Date: September 5, 2014 at 11:49:16 AM EDT
> To: robert.herriot at pahv.xerox.com, sbutler at boi.hp.com, pmoore at peerless.com, jwenn at cp10.es.xerox.com, tom.hastings at alum.mit.edu, robert.herriot at pahv.xerox.com, barryleiba at computer.org, presnick at qti.qualcomm.com, carl at manros.com> Cc: msweet at apple.com, rfc-editor at rfc-editor.org>> The following errata report has been submitted for RFC2910,
> "Internet Printing Protocol/1.1: Encoding and Transport".
>> --------------------------------------
> You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=2910&eid=4101>> --------------------------------------
> Type: Editorial
> Reported by: Michael Sweet <msweet at apple.com>
>> Section: 5
>> Original Text
> -------------
> The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
> that identifies either an IPP printer object or an IPP job object.
> The IPP attributes using the 'ipp' scheme are specified below.
> Because the HTTP layer does not support the 'ipp' scheme, a client
> MUST map 'ipp' URLs to 'http' URLs, and then follows the HTTP
> [RFC2616][RFC2617] rules for constructing a Request-Line and HTTP
> headers. The mapping is simple because the 'ipp' scheme implies all
> of the same protocol semantics as that of the 'http' scheme
> [RFC2616], except that it represents a print service and the implicit
> (default) port number that clients use to connect to a server is port
> 631.
>> In the remainder of this section the term 'ipp-URL' means a URL whose
> scheme is 'ipp' and whose implicit (default) port is 631. The term
> 'http-URL' means a URL whose scheme is 'http', and the term 'https-
> URL' means a URL whose scheme is 'https',
>> A client and an IPP object (i.e. the server) MUST support the ipp-URL
> value in the following IPP attributes.
> job attributes:
> job-uri
> job-printer-uri
> printer attributes:
> printer-uri-supported
> operation attributes:
> job-uri
> printer-uri
> Each of the above attributes identifies a printer or job object. The
> ipp-URL is intended as the value of the attributes in this list, and
> for no other attributes. All of these attributes have a syntax type
> of 'uri', but there are attributes with a syntax type of 'uri' that
> do not use the 'ipp' scheme, e.g. 'job-more-info'.
>> If a printer registers its URL with a directory service, the printer
> MUST register an ipp-URL.
>> User interfaces are beyond the scope of this document. But if
> software exposes the ipp-URL values of any of the above five
> attributes to a human user, it is REQUIRED that the human see the
> ipp-URL as is.
>> When a client sends a request, it MUST convert a target ipp-URL to a
> target http-URL for the HTTP layer according to the following rules:
>> 1. change the 'ipp' scheme to 'http'
> 2. add an explicit port 631 if the URL does not contain an
> explicit port. Note: port 631 is the IANA assigned Well Known
> Port for the 'ipp' scheme.
>> The client MUST use the target http-URL in both the HTTP Request-
> Line and HTTP headers, as specified by HTTP [RFC2616] [RFC2617] .
> However, the client MUST use the target ipp-URL for the value of the
> "printer-uri" or "job-uri" operation attribute within the
> application/ipp body of the request. The server MUST use the ipp-URL
> for the value of the "printer-uri", "job-uri" or "printer-uri-
> supported" attributes within the application/ipp body of the
> response.
>> For example, when an IPP client sends a request directly (i.e. no
> proxy) to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a
> TCP connection to port 631 (the ipp implicit port) on the host
> "myhost.com" and sends the following data:
>> 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)
> ...
>> As another example, when an IPP client sends the same request as
> above via a proxy "myproxy.com", it opens a TCP connection to the
> proxy port 8080 on the proxy host "myproxy.com" and sends the
> following data:
>> POST http://myhost.com:631/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)
> ...
>> The proxy then connects to the IPP origin server with headers that
> are the same as the "no-proxy" example above.
>>> Corrected Text
> --------------
> The IPP URL scheme is defined in [RFC3510].
>> A client and an IPP object (i.e. the server) MUST support the ipp-URL
> value in the following IPP attributes.
> job attributes:
> job-uri
> job-printer-uri
> printer attributes:
> printer-uri-supported
> operation attributes:
> job-uri
> printer-uri
> Each of the above attributes identifies a printer or job object. The
> ipp-URL is intended as the value of the attributes in this list, and
> for no other attributes. All of these attributes have a syntax type
> of 'uri', but there are attributes with a syntax type of 'uri' that
> do not use the 'ipp' scheme, e.g. 'job-more-info'.
>> If a printer registers its URL with a directory service, the printer
> MUST register an ipp-URL.
>> User interfaces are beyond the scope of this document. But if
> software exposes the ipp-URL values of any of the above five
> attributes to a human user, it is REQUIRED that the human see the
> ipp-URL as is.
>>>> Notes
> -----
> Change inline text to a reference to the document that actually defines and registers it.
>> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>> --------------------------------------
> RFC2910 (draft-ietf-ipp-protocol-v11-06)
> --------------------------------------
> Title : Internet Printing Protocol/1.1: Encoding and Transport
> Publication Date : September 2000
> Author(s) : R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn
> Category : PROPOSED STANDARD
> Source : Internet Printing Protocol
> Area : Applications
> Stream : IETF
> Verifying Party : IESG
>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140905/d34d47e9/attachment.p7s>