RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: Legacy

Errata ID: 485
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Bruce Lilly
Date Reported: 2002-01-05

Section 2 says:

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)

It should say:

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)

Errata ID: 1457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2008-06-20
Verifier Name: Lisa Dusseault
Date Verified: 2008-10-06

Section Boilerplate says:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Updates: 1806                                                  S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

It should say:

Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Obsoletes: 1806                                                S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997

Notes:

RFC 2183 completely replaces RFC 1806, so it should say "obsoletes" instead of "updates".

Errata ID: 3847
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Eric Reitmaier
Date Reported: 2013-12-23
Verifier Name: Barry Leiba
Date Verified: 2013-12-23

Section 3 says:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

It should say:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500"
        Content-Description: a complete map of the human genome

Notes:

In section 2 it states:

disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)

The semicolon should not be at the end of a header field.
And in the example there is a semicolon behind the disposition-parm "modification-date".

Status: Reported (1)

RFC 2183, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", August 1997

Note: This RFC has been updated by RFC 2184, RFC 2231

Source of RFC: Legacy

Errata ID: 5330
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Daniel Beardsmore
Date Reported: 2018-04-20

Section 2 says:

   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
   parameter value containing only non-`tspecials' characters SHOULD be
   represented as a single `token'.  A short parameter value containing
   only ASCII characters, but including `tspecials' characters, SHOULD
   be represented as `quoted-string'.  Parameter values longer than 78
   characters, or which contain non-ASCII characters, MUST be encoded as
   specified in [RFC 2184].

It should say:

   NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
   parameter value formed solely from characters valid for a `token'
   SHOULD be represented as a single `token', and not as a
   `quoted-string'.  Parameter values longer than 78 characters, or
   which contain non-ASCII characters, MUST be encoded as specified in
   [RFC 2184].

Notes:

The RFC seems to assume that token = ASCII - tspecials. Token in fact is defined more strictly: token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials>.

Consequently, a value with spaces (such as "Some file.txt"), which is a value without any tspecials, is expected to be recorded as a token, when in fact this is impossible. The same applies to CTLs.

I've written the corrected text according to the apparent intent, to avoid quotes around the value when they are unnecessary. You may wish to revise the correction for clarity or to better suit the intent of this restriction.

Report New Errata



Advanced Search