At 03:11 PM 10/4/01 +0000, Charles Lindsey wrote:
>The reason I feel that a registry is in order, rather than just an
>informational database, is that I am finding situations where I want to
>leverage the existing set of standards-track definitions in another
>specification; I want to be able to include existing header names and
>semantics by reference. (My immediate application is representation of
>message metadata with URIs used to identify header values.)
I think that is essentially my reason #3.
OK, we're roughly aligned in intent, if using different language sometimes.
>Yes, I was leaving open the choice between "standards action" or "IETF
>consensus"; I tend to favour the latter, as long as it's obvious from a
>published RFC whether or not it represents such consensus. (I wanted the
>IANA assessment to be dead easy: the key registration items are the header
>name and defining RFC, which should be easy to check. Certianly, a
>standards-track RFC definition is.)
There is provision in RFC 2434 for "Designated Experts" appointed by the
Area Director to approve registrations.
Well, we could go that way, but it doesn't require RFC publication of the
specification (IIRC). My preference is to pick one of the stronger conditions.
>Hopefully, there will be just one *defining* RFC.
No, life is not so simple. For example, RFC 2616 defines Content-Type from
the ground up.
If RFC 2045 were to disappear in a puff of smoke, RFC 2616
would not be affected. USEFOR does make more use of RFC 2822 for the
headers that are common to both, at least for the syntax. But even there
the semantics are (re)defined in full.
OUCH! You're right. I hadn't noticed that the HTTP definition doesn't
cite MIME (except for the media type registration).
Options I might consider:
(a) for each header, allow different definitive citations for different uses.
(b) limit the applicability of the registry to email/news (though even that
may be problematic in light of your comment about USEFOR).
(c) limit the applicability of the registry to email. (If required, other
applications might define separate registries that import
It was a presumption of mine that the header names occupied a single
namespace across all uses; there might be some headers with specialized
application uses, but no header would be used for different purposes in
different protocols. Having multiple specifications makes this more
difficult to verify.
>>Even for a single protocol, there may be more than one document (for
>>example a basic definition, plus some later extension that provides
>>additional functionality).
>Good point.
>In this case, the RFC index will show that the original specification is
>updated or obsoleted by subsequent documents, so I think it can be argued
>that the combination of "active" documents provides a single, coherent
>definition.
Not so. To understand everything you are allowed to write in a
Content-Type, even just for Mail, you need RFC 2231 as well as RFC 2045
(because it extends the syntax of 'token'). But RFC 2231 does not
obsolete RFC 2045.
But is *does* update it:
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies. N. Freed, N. Borenstein. November 1996.
(Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations. N. Freed, K. Moore. November 1997.
(Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045,
RFC2047, RFC2183) (Status: PROPOSED STANDARD)
So the extended/refined definitions can be traced from the original
specification...
> I'd better re-phrase the previous question:
> >>> Question: does every standardized header truly have a single coherent
>definition, tracable from a single initial defining RFC?
Still no.
... the "updates" trail being what I meant by a coherent definition. But,
cross application, it looks as if you're right.
I think that mechanism will be essential. Here, for example, is how I
would register Content-Type. Note that for each protocol there is a
primary definition, and possibly several secondary definitions (i.e.
extensions).
Header Field-name: Content-Type
Protocol: Mail
Primary definition: RFC 2045
Secondary definition: RFC 2231
Protocol: Netnews
Primary definition: RFC 2045
Secondary definition: [[[USEFOR]]]
Protocol: HTTP
Primary definition: RFC 2616
Hmmm... this is looking like three registries in one. Why not three
separate registries instead?
#g
------------------------------------------------------------
Graham Klyne Baltimore Technologies
Strategic Research Content Security Group
<Graham(_dot_)Klyne(_at_)Baltimore(_dot_)com> <http://www.mimesweeper.com>
<http://www.baltimore.com>
------------------------------------------------------------