I've been reading through RFC2822 and have some questions particularly in
regards to how the robustness principle should be applied to some of the
formatting rules when used on multi-purpose messaging systems. More
specifically, I'm looking for confirmation on my interpretations.
1) There does not appear to be a requirement for a space after the colon
in the header field, although I don't think I've ever seen name:data
(without a space) used anywhere. I assume the friendliest behavior is for
messaging systems to use colon-space on messages they send, but to expect
colon-only in messages they receive.
2) Although any printable character from US-ASCII except colon may be used
in header names, I've never seen any headers use anything other than
alphanumerics and hyphen. Moreover, chances are probably pretty good that
the use of chars like open parenthesis and single-quote would be harmful
to some implementations. usefor-05 only allows letter-digit-hyphen chars
and that is a reasonable safe set for new headers to use, although the
full set should be tolerated. Any communal knowledge of experimental field
names which use other chars?
3) There is no explicit length limit on field names. This would seem to
indicate that the maximum allowable field name is 997 chars [(leaving room
for the colon) see related question in #4 below], with a preferred maximum
of 77 chars (again, leaving room for the colon). However, this would also
mean that the field body would start on a continuation line, which may
cause problems, particularly since usefor-05 says that some of the field
body must appear on the same line as the field name. This means that field
names must be short enough to accomodate at least some data from the field
body, but what this number is exactly is undefinable as a universal value.
"should be as long as necessary but no longer"?
4) There is no explicit length limit on an unfolded header field, but
only on the folded parts of the field (since they are the elements which
are parsed as "lines"). However, it is somewhat likely that there exists
at least one implementation which limits operations to 1000 bytes of data.
My assumption is that the friendliest behavior is to endeavor to keep
folded parts at 78 bytes, with the entire unfolded header field within 998
bytes.
5) String length in header bodies is similarly undefined.
Out of curiousity, has anybody ever tested the maximum length conditions?
IE, what happens when a field name is 997 bytes, and is followed by a
field body which is 998 bytes of continuous data? This appears to be
technically valid based on my reading, although it would probably be
self-defeating for the sender.
Thanks for any insights, comments, corrections, etc.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/