Frank Ellermann wrote:
Filename : draft-reschke-rfc2231-in-http-00.txtGood. What's the plan wrt ABNF ? This memo is harmless enough that it could offer both, a normative STD 68 ABNF, and an informative appendix using an appropriate mix of the 2231 + 2616 BNF.
My plan was to come up with test cases for the current support in user agents first. I want to make sure that the spec actually reflects what UAs support.
As it happens the draft already contains an "appropriate mix", because it doesn't need the advanced feature of the #-rule. The general idea of "HTTP does not need continuations" could boil down to *WSP for all implicit LWS in the BNF. Or in other words replace any "=" by EQU, and specify | EQU = *WSP "=" *WSP Even if we end up with something slightly more obscure, e.g., EQU = [FWS] "=" [FWS], the BNF hides one subtle point in <ext-parameter>: | ext-parameter = attribute "*=" ext-value I _think_ that "*=" actually means "*" EQU in RFC 2231, i.e. there can be LWS between "*" and "=".
Yes, that is probably true. The question is: do we want that in the profile? I assumed that we want to reduce the number of places where WS is allowed.
It can as well mean LWS "*" EQU, i.e. there can be LWS before "*", between "*" and "=", or after "=". I think it does _not_ mean LWS "*=" LWS remotely in the direction of an *= operator.
My hope was to make it exactly that, in order to make parsing simpler.But yes, this is an open issue; I'll do some testing with Content-Disposition as implemented in practice. There's no point in putting it into the ABNF if we have evidence that those UAs that do support RFC2231 do not allow it (remember: the reason for a profile is to cut out the unnecessary stuff).
BR, Julian