From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Tue May 13 2003 - 05:08:03 CDT
In <3EBFB65B.7040601@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> I allow "From: Joe Q. Public <joe@public.example>" on a MUST accept
>> SHOULD NOT generate yet basis, to bring us in line with RFC 2822
>That is not consistent with 2822, which states that unquoted dot in
>a phrase MUST NOT (not merely "SHOULD NOT") be generated [2822 sections
>3.1 and 4].
Yes, but that is the sort of wording we have used at all other places in
our draft where we have to say "MUST accept, but SHOULD NOT generate yet".
We need to be consistent.
However, you seem to accept (and I think everybody else accepts) that our
draft needs to include the Joe Q. Public phrases at least as a MUST
accept, which is the main principle to be decided.
If you want to bring this up as a general issue, then by all means do so,
though I would prefer to leave that discussion until we come to the final
rearrangement of the bulk of the draft, after we have removed all the I18N
and USEAGE stuff from it (whether or not that rearrangement includes
splitting into #1 and #2).
>> unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS]
>> phrase = 1*( [CFWS] encoded-word [CFWS] / word ) /
>> extended-phrase
>> extended-phrase = ( [CFWS] encoded-word [CFWS] / word )
>> *( [CFWS] encoded-word [CFWS] / word /
>> [CFWS] "." [CFWS] )
>Unfortunately the syntax for encoded words is not nearly that simple.
>Aside from the issue of the allowable characters in the encoded-words
>(which differs for phrases, comments, and unstructured text), there
>must be linear whitespace on both sides of each encoded-word except
>for three cases, viz. an encoded-word immediately following the '(' in
>a comment (which obviously only applies to a subset of structured
>fields), an encoded-word immediately followed by ')' in a comment,
>and an encoded-word at the end of a field (either unstructured or as
>the last word of a phrase at the end of a field body). I have confirmed
>that in correspondence with 2047's author, Keith Moore. The ABNF
>above does not say that; it permits all of the following, which are
>illegal per the intent of RFC 2047:
Yes, but describing the requirement for FWS on both sides of an
encoded-word, except where it isn't, is a pain to do in ABNF which is, no
doubt, the reason why RFC 2047 did not attempt to do so.
This, and the other matters you mention, were supposed to be covered by
the last paragraph of section 2.4.3, but I see I had omitted to mention
the FWS requirement. I have now rewritten the last part of that paragraph
as follows:
The syntax of encoded-text and of encoding can be found in [RFC
2047], and there are restrictions on the characters that may occur
within an encoded-text, depending on its context. There are also
restrictions on the overall length of an encoded-word and of headers
containing encoded-words and requirements for encoded-words to have
FWS on either side of them in most contexts. All these restrictions
and requirements MUST be observed.
>> Msg-ids are redefined [...]
>Actually what is redefined is *not* the msg-id production but
>no-fold-quote and no-fold-literal.
True, but a reasonable exercise of poetic licence.
> In any event, it would be better
>to use different terms for different entities to avoid confusion, e.g.
>usefor-msg-id, usefor-id-left, usefor-id-right, usefor-no-fold-quote,
>usefor-no-fold-literal.
If I did that for msg-id, I would have to do it for other things we have
changed, such as date-time and unstructrured. However, I have been careful
to draw attention, in the principal places where these constructs are
used, to the changes recorded in 2.4.2. I think that should be sufficient.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk 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