Frank Ellermann wrote:
Filename : draft-reschke-rfc2231-in-http-00.txt
Good. 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