Subject: [Technical Errata Reported] RFC6266 (5383)

From: RFC Errata System <[email-masked]>
Date: Thu, 7 Jun 2018 06:03:07 -0700 (PDT)

The following errata report has been submitted for RFC6266,
"Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5383

--------------------------------------
Type: Technical
Reported by: Parameter names must not allow * <[email-masked]>

Section: 4.1

Original Text
-------------
     disp-ext-parm       = token "=" value
                         | ext-token "=" ext-value
     ext-token           = <the characters in token, followed by "*">

   Defined in [RFC2616]:

     token         = <token, defined in [RFC2616], Section 2.2>
     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token | quoted-string

   Defined in [RFC5987]:

     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

Corrected Text
--------------
     disp-ext-parm       = parmname "=" value
                         | ext-parmname "=" ext-value
     ext-parmname        = <the characters in parmname, followed by "*">

   Defined in [RFC2616]:

     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
     value         = <value, defined in [RFC2616], Section 3.6>
                   ; token | quoted-string

   Defined in [RFC5987]:

     parmname    = <parmname, defined in [RFC5987], Section 3.2>
     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>

Notes
-----
RFC5987 section 3.2.1 modifies the grammar from RFC2616. These modifications should be used in RFC6266. If not, it is impossible to determine whether a parameter should be a value or an ext-value based on the parameter name, since "*" is a valid character in token.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6266 (draft-ietf-httpbis-content-disp-09)
--------------------------------------
Title               : Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
Publication Date    : June 2011
Author(s)           : J. Reschke
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Julian Reschke <[email-masked]>
Date: Thu, 7 Jun 2018 15:11:38 +0200

On 2018-06-07 15:03, RFC Errata System wrote:
> ...

I believe we should reject this erratum.

Reasons:

1) When we'll revise RFC 6266, it'll be based on RFC 8187, not RFC 5987. 
This changes the whole base (of what is defined how in the ABNF).

2) To define new parameters for Content-Disposition, a spec would have 
to update RFC 6266, in which case the WG and/or IESG will need to ensure 
that no parameter name ending in "*" is defined without using the RFC 
8187 encoding.

Best regards, Julian

---

From: Natasha Carroll <[email-masked]>
Date: Thu, 7 Jun 2018 23:56:04 +1000

It's a hacker your helping

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jun 2018 15:52:21 +0200

On 2018-06-12 15:48, Magnar Myrtveit wrote:
> Thanks for your reply, Julian.
> 
> I agree with both of your reasons, but I still don't think the erratum 
> should be rejected. For example when creating a parser for the 
> Content-Disposition header field, it is important to know what one can 
> expect. Currently, one cannot assume an ext-value to follow ext-token 
> "=". It might just as well be a value. My guess is that this is not the 
> intention, and it makes creating future-proof parsers harder. Having a 
> validated erratum clarifying the issue would be nice.

Well, in general you can't assume that. The extended syntax is currently 
defined only for "filename", and any new parameter using the extended 
syntax would need to be defined in a document extending RFC 6266. So 
yes, you can't handle parameters in a generic way which haven't been 
defined yet.

> By the way, you may update the erratum field "Name" to "Magnar Ovedal 
> Myrtveit". I mistook it as erratum title, rather than my own name :)

The RFC-Editor might be able to do that.

Best regards, Julian