Subject: References, and also dtext

From: Charles Lindsey <[email-masked]>
Date: Sun, 16 Jan 2000 20:04:22 +0000 (GMT)

1. I see there has been recent discussion of trimming References when
they get too long. Here is the paragraph that will be appearing in the
next draft of the Usenet-Format document:

   Followup agents SHOULD NOT trim message identifiers out of a 
   References header unless the number of message identifiers exceeds
   21, at which time trimming SHOULD be done by removing sufficient
   identifiers starting with the second so as to bring the total down
   to 21. However, it would be wrong to assume that References headers
   containing more than 21 message identifiers will not occur.

2. There is a serious discrepancy in the current draft for References
between the syntax as proposed for mail, and that used in Netnews (as
mandated by RFC 1036). In news, the references is a sequence of msg-ids
separated by at least one space, as in "References: <[email-masked]>
<[email-masked]>". Apparently many newsreaders barf if that space is
absent. MESSFOR, OTOH, asks for [CFWS] at that point, which allows no
space at all. May I suggest it needs to be CFWS. AIUI the References
header is an import into mail from news (AIUI), so it really ought to
follow the news precedent. The current text in preparation for the next
USEFOR draft contains:
      References-content  = msg-id *( CFWS msg-id )
I did mention this problem to Pete some while back, but I don't know
whether he has fixed it or not.

3. I just spotted a possible bug/misfeature in the syntax of dtext
(as used in domain-literals in addr-specs and in no-fold-literals in
msg-ids). It allows a dtext to include a naked, unescaped DQUOTE, even
though a quoted-pair is always allowed as an alternative, so that an
unescaped DQUOTE is never required. In any case, wny ever should anyone
ever want a DQUOTE in a domain-literal in the first place?

The problem, of course, is that it makes parsing a nightmare. Currently,
you can have a quoted-string (which can contain naked, unmatched '(' and
')'), and you can have a comment (which can contain naked, unescpaed
DQUOTES). So to parse a structured field (to identify the comments, for
example) you proceed until you see a DQUOTE, at which point you hurry
on to the next unescaped DQUOTE paying no special attention to any '('.
Alternatively, if you see a '(' you hurry on to the matching ')' paying
no special attention to any DQUOTE. But you can't do that if DQUOTE is
allowed in dtext - you than have to watch out for matching '[' and ']'
as well.

Was RFC 822 like that? And if so, could that facility perhaps be demoted
to obsolete syntax. I am sure noone evers uses it.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  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