ietf-822
[Top] [All Lists]

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt

2002-02-11 14:57:51

In <200202110000(_dot_)g1B00f911635(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu> 
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Agreed on the need to get people to think about the information they're
providing.  I'm not sure what the best mechanism is.  I'd be perfectly
happy if folks had to submit an Internet-Draft and get it published as
an RFC.

I don't think an RFC is needed for provisional registration (an RFC would
normally get it into the "full" register - modulo some careful wording in
the case of non-stanrads RFCs, perhaps).

But if you are saying "no provisional registration without an Internet
Draft", then that is an argument to which I might be persuaded (since I
would regard Internet Drafts as the normal route anyway). Indeed, that is
what I actually suggested way back during Graham's first draft.


IMHO if we put something in the registry without a reasonably final
specification, then the most that the registry should say is "currently
undefined; specification under discussion; deployment discouraged".  
We certainly don't need people implementing and deploying an extension 
for which there's not a stable and publically available specification.

Certainly being in a provisional registry should imply

1. This header is likely to go into experimental use, so expect to see it
in the wild.

2. If you are writing software that recognises it, be aware that its
detailed specification may evolve further (and it may even be withdrawn
entirely), so you need to keep a watch on developments.

3. The latest specification for it can be found here ----->

4. Discussion of the specification takes place there ----->


I could see having a separate list for each of mail, http, and news, but
I disagree that it's a good idea to let each WG be the sole reviewer of its 
own fields.  WGs that are focused on a narrow topic (say, how to do
fax over email, or how to do printing over http) have shown a significant
ability to be naive about the broader implications of their proposals.
Extensions of the email protocol need to be reviewed by a community
of email experts, not just experts in the field for which the extension
is being proposed.  Similarly for http and news.

The you are proposing a huge change to the present IETF procedures.
because current practice is that the IETF appoints WGs to do a job, and
they get on and do it. And they have publicly available specifications and
publicy available mailing lists for those who want to be involved.

And a registry would actually improve things here, because people would
see in the registry that some obscure WG was proposing this new header,
and they could join in at an early stage. Currently, they might not even
be aware of it until last call.

8. T... An exception might be made for headers that were loose in the
wild, but which were to be permanently deprecated.

I like this idea, but I wonder how we could make it stick in practice.

Yes, we must make sure that "permanent deprecation" of bad headers gets
written into our system somewhere. I would suggest that if an RFC
establishes header A, and says that header B is thereby obsoleted, then
both A and B get into the register.

-- 
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

<Prev in Thread] Current Thread [Next in Thread>