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>
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy