In <01JBEAGYFIR48WXW2O(_at_)INNOSOFT(_dot_)COM> Ned Freed
<Ned(_dot_)Freed(_at_)innosoft(_dot_)com> writes:
A brief review of RFC822 and RFC2045 leaves me slightly uncertain whether
or not a MIME content-type field follows the whitespace insertion rules for
an RFC822 structured header field.
Well, I'd call the section you quoted such a statement. But I'll make a note
to clarify this point even further the next time we update the specification.
The specific issue as stake here is whether the following is acceptable:
Content-type: image/tiff; boundary=
"longboundarystringwrappedtonextlinetolimitlinelength"
It is completely legal.
Fine, but that still does not establish _exactly_ where folding may occur.
This is currently of concern to me because I am writing the syntax for the
new USEFOR draft (RFC1036bis) and we need to spell it all out in the
syntax in DRUMS style.
So far I have got:
header-content = USENET-header-content *( ";" header-parameter ) /
other-header-content
header-parameter = USENET-header-parameter /
attribute "=" value
attribute = iana-token / x-token
value = token / quoted-string
iana-token = <A token defined in an experimental or
standards-track RFC and registered with IANA>
x-token = <the two characters "X-" or "x-" followed, with
no intervening white space, by any token>
token = 1*<any (US-ASCII) CHAR except SP, CTLs
or tspecials>
But now that needs to be decorated with [CFWS] in all the right places
([CFWS] means optional whitespace, folding, or comments as in DRUMS).
So to go the "whole hog" I would have:
token = [CFWS]
1*<any (US-ASCII) CHAR except SP, CTLs
or tspecials>
[CFWS]
{note that quoted string already has [CFWS] before and after.}
Essentially, a 'token' is treated like an 'atom'. So that would now allow,
for the example given:
Content-type: image/
tiff
;
boundary
=
"longboundarystr
ingwrappedtonextli
netolimitlinelength"
which then MUST be accepted by all DRUMS-compliant software (though I
grant you that such usage is deprecated by DRUMS which says that CFWS
SHOULD be limited to "higher-level syntactic breaks").
Indeed, one could argue that
Content-type: image
/
tiff
...
is also legal, because
Content-type: xfoobar
/
tiff
...
certainly is.
Please could Ned and Pete comment on these interpretations.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5