[IPP] Fwd: [Editorial Errata Reported] RFC2910 (4101)

[Michael Sweet <[e-mail]>]

Begin forwarded message:

> From: RFC Errata System <[e-mail]>
> Subject: [Editorial Errata Reported] RFC2910 (4101)
> Date: September 5, 2014 at 11:49:16 AM EDT
> To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> Cc: [e-mail], [e-mail]
> 
> 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 <[e-mail]>
> 
> 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

_______________________________________________
ipp mailing list
[e-mail]
https://www.pwg.org/mailman/listinfo/ipp