From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Mon Jun 28 2004 - 07:19:52 CDT
In <40DF3167.1090801@erols.com> Bruce Lilly <blilly@erols.com> writes:
>Charles Lindsey wrote:
>> In <40DB7D51.7060006@erols.com> Bruce Lilly <blilly@erols.com> writes:
>>
>>>Attempting to redefine the Subject field is exactly an attempt to infringe
>>>upon RFC 2822 and its cognizant WG. RFC 850 adopted RFC 822 format,
>>>specifically mentioning use of Subject as defined in 822 as a replacement
>>>for the erstwhile "Title", and clearly accepting RFC 822 as authoritative.
>>
>>
>> We have not replaced the Subject field (except that we do not allow the
>> Subject to be empty). There is nothing that we are proposing to write
>> regarding "Re: " that will cause the slightest difficulty to any Mail User
>> Agent.
>There are proposals that require parsing the field as structured, which is
>in direct opposition to the definition of the field as unstructured.
Only to detect that an initial "Re: " is not already present, and then
only if it is intended to prepend a new one. There is also an
acknowledgement that some reading agents currently do find it 'desirable'
to parse the Subject-header (to the extent of detecting an initial
"Re: ").
There is nothing that is proposed that will cause any mail user agent to
break if it encounters one of our "Re: "s. On the contrary, many current
mail user agents will recognize (and ignore) it.
But in any case there is no law of the universe forbidding parsing
unstructured headers. Even RFC 2822 recognizes that it will happen, for it
invites the implementor to avoid prepending a second "Re: ", and why
else does it refer to "undesirable consequences" if other than a single
"Re: " is prepended? If there is no parsing, then there can be no
undesirable consequences.
Moreover, if it is forbidden for a standards-track document to contemplate
parsing an unstructured header, then for sure that IMAP draft that has
been mentioned before will never get past the IESG.
>> The text therein says it 'specifies a [not the] syntax for text messages
>> ... within the framework of "electronic mail" ...'. No mention of its
>> applicability to other frameworks such as Netnews.
>That is specified in RFCs 850 and 1036, which adopted the RFC 822 format
>in preference to A news format.
Which voluntarily *chose* to adopt a subset of the RFC 822 format (as we
have done with the RFC 2822 format). It (and we) was under no obligation
to do so.
>>> Moreover,
>>>we are bound by direction from the WG Chair, and last year our Chair specifically
>>>stated that our work was to be based on RFC 2822 and MIME.
And this year our new Chair specifically stated that all that was required
was a subset of RFC 2822 and MIME.
>>
>>
>> Our work IS based on RFC 2822 and MIME. "Based on" does not mean
>> "identical to".
>Perhaps the Chair needs to make a clarification here...
He already has.
>>>" The primary consideration in choosing a message format is that it
>>> fit in with existing tools as well as possible. Existing tools
>>> include implementations of both mail and news.
>>
>>
>> A high ideal, but in the real world of that time it never worked out like
>> that.
>So in your opinion, common UAs such as Mozilla, Netscape, Outlook Express,
>etc. simply do not exist!?! It is precisely such a class of "Existing tools"
>which "include implementations of both mail and news" that RFCs 850 and 1036
>referred to. Ditto for IMAP.
And apparently, in your opinion, common UAs such as rn, trn, nn, etc do
not exist. The fact is that news agents in general (and that includes many
relaying and serving agents) do not accept the full range of RFC [2]822
messages. That is a fact of life, and screaming "broken agents" will get
you nowhere. Usenet is working very well with its present software, and we
are not about to obsolete it all overnight. Therefore, our draft has taken
great care to ensure that anything that will break current software is
deprecated, at least in the medium term.
Last year, I published a document setting out all the differences between
RFC 2822 and our draft. Maybe I should dust it down and repost it. Maybe
it should even go into an Appendix in USEFOR.
>No, according to RFC 2822 and MIME, the unstructured Subject field is
>meant for human consumption,
primarily, but not exclusively,
> and explicitly permits (and RFC 2277 strongly
>encourages as BCP) use of RFC 2047 encoding to specify the language and
>character set of text contained therein. Explicit provisions in the draft
>for excluding use of RFC 204677 encoding, for treating text as case-sensitive
>keywords as if the field were structured are inconsistent with processing
>according to RFC 2822 and MIME.
ITYM RFC 2047 encoding. Nowhere in the draft is RFC 2047 encoding
excluded. Nowhere in the draft are keywords defined by RFC 2822 or MIME to
be treated as case-sensitive. Again, your lack of ability to read what is
actually in the draft is showing through. Your retraction is awaited.
>The intent and practice seems perfectly clear; A news format has been
>abandoned in preference to RFC 822 format for very good reasons, clearly
>elucidated.
>>>>So forget RFC 1036. It is dead. We are writing its succcessor.
>>
>>
>>>According to the RFC index, it is still in effect.
>>
>>
>> But it is not, and was not intended to be, a standard. And it will be
>> obsoleted by our document.
>Its title says it is a standard, and the first sentence of its text as well
>as the first sentence of its "Introduction" section clearly so states.
Then why does its status section state "It does not specify an Internet
standard". Moreover, its Introduction does not "so state". It says that it
defines the "standard format", which is not the same thing at all.
-- 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