RFC 2910, "Internet Printing Protocol/1.1: Encoding and Transport", September 2000

Note: This RFC has been obsoleted by RFC 8010

Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472

Errata ID: 4101
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2014-09-05
Rejected by: Barry Leiba
Date Rejected: 2014-09-17

Section 5 says:

   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.

It should say:

    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.
--VERIFIER NOTES--
While this consolidation and reference to RFC 3510 makes sense, RFC 3510 was published two and a half years *after* RFC 2910... so this dos not represent an error in RFC 2910. Any update to RFC 2910 will clearly refer to RFC 3510 for this information.

Report New Errata