Re: [Nmh-workers] mhbuild Content-Disposition header

[David Levine]

> > >             directive    ::=     "#" type "/" subtype
> > >                                      0*(";" attribute "=" value)
> > >                                      [ "(" comment ")" ]
> > >                                      [ "<" id ">" ]
> > >                                      [ "[" description "]" ]
> > >                                      [ filename ]
> > >                                      EOL
> > >                                      [ "#" extension-field ]
> > > 
> > > where extension-field just can't look like a directive.
> > 
> > Like this?
> > 
> >           extension-field    ::=    "Content-" fieldname ":"
> >                                         attribute [ "=" value ]
> >                                         0*(";" attribute [ "=" value ])
> > 
> > #application/pdf; <>[ Adobe Portable Document Format (PDF) v1.2 ] /tmp/foo.
> pd
> > f
> > #Content-Disposition: attachment; filename="foo.pdf"
> 
> Yes for the example, no for the grammar, although I got the grammar I wrote
> wrong anyway. :)

Just a missing EOL at the end?

> Firstly, how does the example look to you? The colon
> isn't really necessary, and keep in mind that the line might be immediately
> followed by another directive.
>
> Regarding your grammar, I think it's wrong as a general RFC2045 grammar
> because the value of the field can be any text, no?

My intent was to allow the value of the field to be
anything, for future expansion.  It seems that RFCs issue at
a faster rate than nmh can support.

It would be up to the user to use sensible field names,
mhbuild would not enforce that.  And that's the spirit
in which I put in the colon, the idea being that whatever is
in the extension field is pretty much going to be the header.
And the plaintext Content-Description: has a colon.

> It's the right grammar
> for Content-Disposition though.

Note that The grammar isn't for an RFC, it's for mhbuild.
But clearly we want it to support any RFC2045
extension-field.

> Another reason I suggested this grammar is that I think the parsing of
> it will be quite easy to fit into the existing mhbuildsbr.c code.

{} would be, too, but at this point I'm leaning towards
extension-field.

David