On Wed, 18 Dec 2002, Keith Moore wrote:
One can recognise a comment from lexical analysis alone.
comments are only valid in structured fields. so in order to
recognize a comment you have to know the set of structured fields.
Yes, that's true (both in RFC 822 section 3.1.3 and RFC 2822 section
2.2.1).
Does anybody claim that that RFC 2912 "Content-Encoding" is an
unstructured field?
and it is (perhaps unfortunately) the cases that some fields have
a syntax that uses parenthesis as other than comment delimiters.
if I'm not mistaken this has been the case ever since rfc 987,
which used constructs like (a) to order to encode things like @ in
PrintableString fields.
By my reading of RFC 987, if a PrintableString is used in a context
where something like unquoted "(a)" could be misinterpreted as a
comment, then the entire PrintableString must be further encoded in an
RFC 822 quoted-string. See the second paragraph on page 58 of RFC 987,
where it says "word may be encoded as 822.atom (which has a restricted
character set) or as 822.quoted-string, which can handle all ASCII
characters."
I submit that the RFC 2822 section 3.2.3 definition of a comment was
intended to apply to all header fields
I don't think so - that would break too many things already in
existence.
OK, all structured header fields. The entire lexical analyser described
in RFC 822 section 3.1.4, and RFC 2822 section 3.2 (read in conjunction
with section 2.2.2), seems to be intended to apply to all structured
header fields. I have always assumed that this included any structured
fields that might be defined in the future.
Apart from RFC 2912 Content-Encoding, what else violates this assumption?
--apb (Alan Barrett)