Search RFCs

RFC Editor

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 byRFC 2184, RFC 2231

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. TroostRequest for Comments: 2183                           New Century SystemsUpdates: 1806                                                  S. DornerCategory: Standards Track                          QUALCOMM Incorporated                                                        K. Moore, Editor                                                 University of Tennessee                                                             August 1997

It should say:

Network Working Group                                          R. TroostRequest for Comments: 2183                           New Century SystemsObsoletes: 1806                                                S. DornerCategory: 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 byRFC 2184, RFC 2231

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