RFC Errata
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
Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472
Source of RFC: ipp (app)
Errata ID: 4172
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472
Source of RFC: ipp (app)
Errata ID: 4100
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Note: This RFC has been updated by RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472
Source of RFC: ipp (app)
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.