RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

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

Note: This RFC has been obsoleted by RFC 8010

Source of RFC: ipp (app)

Errata ID: 4172

Status: Verified
Type: Editorial

Reported By: Michael Sweet
Date Reported: 2014-11-12
Verifier Name: Barry Leiba
Date Verified: 2014-11-12

Section 3.5 says:

   a value that the parser treats atomically.  Values from 0x00 to
   0x37777777 are reserved for definition in future IETF standard track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

It should say:

   a value that the parser treats atomically.  Values from 0x00 to
   0x3FFFFFFF are reserved for definition in future IETF Standards Track
   documents.  The values 0x40000000 to 0x7FFFFFFF are reserved for
   vendor extensions.

Status: Held for Document Update (1)

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

Note: This RFC has been obsoleted by RFC 8010

Source of RFC: ipp (app)

Errata ID: 4100

Status: Held for Document Update
Type: Technical

Reported By: Michael Sweet
Date Reported: 2014-09-05
Held for Document Update by: Barry Leiba
Date Held: 2014-09-17

Section 8.1.2 says:

   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
   for Server Authentication and Operation Privacy. IPP Printers MAY
   also support TLS for Client Authentication.  If an IPP Printer
   supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   cipher suite as mandated by RFC 2246 [RFC2246].  All other cipher
   suites are OPTIONAL.  An IPP Printer MAY support Basic Authentication
   (described in HTTP/1.1 [RFC2617])  for Client Authentication if the
   channel is secure. TLS with the above mandated cipher suite can
   provide such a secure channel.

   If a IPP client supports TLS, it MUST support the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC
   2246 [RFC2246].  All other cipher suites are OPTIONAL.

It should say:

   IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
   for Server Authentication and Operation Privacy. IPP Printers MAY
   also support TLS for Client Authentication.  An IPP Printer MAY
   support Basic Authentication (described in HTTP/1.1 [RFC2617]) for
   Client Authentication if the channel is secure.

Notes:

Per the PWG IPP WG discussions at the August 2014 F2F, any mention of cipher suites in RFC 2910 is inappropriate. In particular, the cipher suite mentioned is no longer mandatory in TLS/1.2.

----- Verifier notes -----
While the cipher suites listed were correct when RFC 2910 was written, the list of required/recommended cipher suites has changed since then, to the point that some what were required at the time are specifically *not* recommended now. For that reason, RFC 2910 is in need of an update. This errata report will serve to note that, until such time as the update is done and a new RFC is published.

Status: Rejected (1)

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

Note: This RFC has been obsoleted by RFC 8010

Source of RFC: ipp (app)

Errata ID: 4101

Status: Rejected
Type: Editorial

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