ietf-822
[Top] [All Lists]

Re: draft-klyne-msghdr-registry-00.txt

2001-10-05 14:49:41

In 
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20011005111502(_dot_)009d2720(_at_)joy(_dot_)songbird(_dot_)com>
 Graham Klyne <GK-lists(_at_)ninebynine(_dot_)org> writes:


At 03:11 PM 10/4/01 +0000, Charles Lindsey wrote:

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.

I think there are several mechanisms that could be used. Ones menmtioned
so far have included:
        existence of an internet-draft
        Designated Experts
        registry of "bogus" headers
I guess some combination of these may be needed, and there are doubtless
other possibilities. Certainly there seems to be interest in doing
something in this area, but there are dangers too. But there are also
dangers in doing nothing (the fact is that people will just ignore the
registry altogether, and just "use" their new headers like they do now, if
we put too many hurdles in their way).


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

I think it has to be (a).

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.

Certainly one wants ths usages of a given header across a variety of
protocols to be broadly similar. But I think IETF Working Groups are well
abel to look after that, provided the registry is there to alert them to
possible conflicts.

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:

Indeed, but I reckon there are already several RFCs that update 2045 (and
if there aren't, there surely will be :-( ). So it is a tree structure.
Ideally, it should be possible, from the registry, to find everything you
should need to know about a given header, but it will always be the case
that the original (non-obsoleted) primary document is the most
important (2045 in this case).

Another related point, especially with Content-Type, is that there are
umpteen RFCs describing extra types, charsets, etc. Fortunately, there are
already IANA registries for most of those things, so another need for our
registry will be to refer to other IANA registries that deal with specific
parameters of a header.


... the "updates" trail being what I meant by a coherent definition.  But, 
cross application, it looks as if you're right.

Yes, it's a big can of worms - which is exactly why a good registry will
be such a help.

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?

Because if someone is proposing to invent a Foobar: header for Netnews, he
might look in the Netnews registry and find that it did not exist, little
knowing that it already existed in the Mail registry.

But the format I have illustrated above is no more complex than a lot of
other things that IANA already registers (look at the type registry for the
Content-Type header).

-- 
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(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)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