From: Bruce Lilly (blilly@erols.com)
Date: Wed Mar 17 2004 - 07:28:33 CST
Charles Lindsey wrote:
> In <40563DF9.2000406@erols.com> Bruce Lilly <blilly@erols.com> writes:
>>The definition for the Subject field is going to be RFC 2822's definition.
>>The fact is that we will be obliged to use that definition for the Subject
>>field. You have zero chance of changing that fact; your time and effort
>>would be better spent tilting at windmills.
>
>
> It is not at all helpful for you to misrepresent what the intended
> Registry will do. Since I had a considerable part in drawing up that
> proposal, I should know what is in it.
>
> It DOES NOT mandate any particular definitions (because that is not what
> IANA Registries are for), and it DOES make provision for different
> protocols to define a given header differently.
>
From draft-klyne-msghdr-registry-07 (which has passed IESG review):
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and
widely-used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
N.B. "discouraging multiple definitions of a header field name
for different purposes" and "encouraging convergence of header
field name usage across multiple applications".
And from the latest version of the registration draft:
2.1.11 Header field: Subject
Description:
Topic of message
[...]
Status:
standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force.
Specification document(s):
http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.5)
Related information:
Contains a short string identifying the topic of the message.
The chance of registering "multiple definitions of a header field name"
(i.e. Subject) which is "standardized and widely-used", "for different
purposes" in a way which discourages "convergence of header field
name usage across multiple applications" (indeed, in a manner which
*encourages* *divergence* of usage) is either zero or vanishingly small.
And "Subject" will be registered with RFC 2822 section 3.6.5 as its
specification. That is the section of RFC 2822 to which Russ and John
and I have referred you to; the section which clearly states that the
field is unstructured and that it contains "only human-readable content".