Re: Content-Disposition next steps

On 04.12.2010 11:18, Adam Barth wrote:
> On Fri, Dec 3, 2010 at 3:56 PM, Adam Barth<ietf@adambarth.com>  wrote:
>> On Thu, Dec 2, 2010 at 4:26 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>>> I'm not totally sure what exactly to test; please elaborate.
>>
>> Content-Disposition: xfilename=foo.txt
>
> Note: I've removed support for this syntax on the wiki.  It seemed
> particularly goofy.

It is. Thanks.

> I've taken a stab at writing this requirement with a grammatical
> presentation.  I'd appreciate some help with the grammar as it's not
> my strong suit.  Here's what I've got (also on the wiki):
>
> [[
> unparsed-string = unbalanced-block / block * ( ";" block ) [ ";"
> unbalanced-block ]
> block = *run
> unbalanced-block = *run unbalanced-run
> run = unquoted-run / quoted-run
> unquoted-run = non-quote *boring-octet
> quoted-run =<">  *non-quote<">
> unbalanced-run =<">  *non-quote
> non-quote =<OCTET, except<">  >
> boring-octet =<OCTET, except<">  and ";">
> ]]
>
> I'm not overly confident in the first grammar.  What I'm trying to
> encode is a parser with two states: initial and in-quote, together
> with the following transition rules:
>
> == State: initial ==
> <">  =>  Buffer the current character, switch to the in-quote state, and
> proceed to the next character.
> ";" =>  Emit the buffered characters, if any, and proceed to the next character.
> EOF =>  Emit the buffered characters, if any, and terminate.
> OTHER =>  Buffer the current character and proceed to the next character.
>
> == State: in-quote ==
> <">  =>  Buffer the current character, switch to the initial state, and
> proceed to the next character.
> EOF =>Emit the buffered characters, if any, and terminate.
> OTHER =>  Buffer the current character and proceed to the next character.
>
> My inclination is to write the state machine into the wiki, but I'm
> hesitating because my understanding is that you all would prefer a
> grammatical presentation.

Before we invest too much time into this: do you have evidence that 
using a grammar other than the one already defines is really needed?

Maybe you could list certain invalid header instances you want to 
handle, and what the result should be?

If we want to keep handling valid header fields properly, we *probably* 
better start from the base grammar, and relax certain constructs.

Best regards, Julian

Received on Saturday, 4 December 2010 11:26:17 UTC