| 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers