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

[David Levine]

>   | 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.
> 
> I think Joel's point was that that wasn't what your grammar achieved,
> it required the value of the field to be a sequence of attribute=value

The "="value portion is optional, and the grammar doesn't
further define attribute.

> tuples, whereas some new field that might want to be added (and whose
> name need not necessarily start with "Content-" I would have thought)

RFC2045 extension-fields are defined as starting with "Content-".

We could support arbitrary field names, but then let's call it
something beside extension-field.

> might have some entirely different syntax, or perhaps no syntax at all.

It admits at least one attribute, which can be any
characters except CRLF, SPACE, and HTAB.  The only syntax it
doesn't admit is simply the header name.  We could allow
that, but I don't think it's necessary.

> ps: Also remember, if you're using RFC ABNF grammars (as opposed to the
> semi-defined thing that was in RFC822) then you also need to be explicit
> about where white space is to be permitted, if anywhere.   Using RFC ABNF,
> the example you gave didn't fit your grammar, as you included (in the
> example) spaces between "Disposition:" and "attachment", and again
> between "attachment;" and "filename=" (and in the actual directive
> line, between "pdf;" and "<>" and between "]" and "/tmp/foo".)

This is mhbuild, not RFC, syntax.  The mhbuild composition file
grammar doesn't explicitly show whitespace.  For example,
directive starts with:  "#" type "/" subtype, but this is supported:

#   text/ plain foo.txt

David