Subject: Re: quoted strings within quoted strings
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Thu, 28 Feb 2002 23:40:23 -0800 (PST)
List-Id: <ietf-822.imc.org>

> This reflects a problem that has come up with a proposed feature in
> USEFOR, but it arises out of the syntax of MIME.

Perhaps I'm missing something, but I see no problem here whatsoever.

> Currently, various MIME headers (and some new USEFOR headers) can have
> parameters of the form

> 	attribute = value
> where
> 	attribute = token
> 	value = token / quoted-string

> There is provision for new parameters to be defined in later standards,
> and registered with IANA. Typically, the "values" involved are things like
> charsets and filenames.

Actually, an incredible variety of stuff has been placed in parameter values in
practice. Email addresses. Quoted strings. Extremely long strings. Strings
containing control characters. Strings in different charsets. MIME already
provides complete facilities for all of this.

> Now suppose someone invents a parameter where the "value" is to be a
> mailbox (I don't think that case has arisen yet in MIME, but it well
> might).

It arose years ago. The obvious example is filenames.

>  Perhaps something like:

> 	"sender" "=" mailbox

> Obviously, the mailbox has to be a quoted-string (it contains an '@',
> which is a tspecial). BUT a mailbox can itself contain a quoted-string in
> many situations, so one might want to write

> but, of course, you can't write that because it contains nested
> quoted-strings.

Sure you can. The quoting facility in content type parameters is completely
general.

> So what is the proper way to do it?
> Would it be

> 	sender = "\"John D. Bloggs\" <[email-masked]>"

Yup. And as Cyrus points out, even more complex nestings like 

        sender = "\"John D. \\\"Cool\\\" Bloggs" <[email-masked]>"

are allowed.

> in which case would/should the inner \"John D. Bloggs\" then be
> interpreted as a quoted-string?

It isn't a question of interpretation. The process of extraction of the
parameter value produces the result

   "John  D. Bloggs"

There is no wiggle room here. However, how this result is interpreted or used
is entirely dependent on the semantics of the parameter itself. If those
semantics say that quotes in the value imply a quoted string, such as the case
of a parameter value containing an email address, so be it. But it may be that
the semantics don't imply that, such as in the case of a filename, which is
fine too.

> Or is it the case that there is no proper way to express this sort of
> thing?

Again, the facility is completely general.

				Ned

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Message Header Field Registry - revised proposal 
Date: Thu, 28 Feb 2002 20:19:34 -0500
Sender: [email-masked]

>  Aren't experimental RFCs last-called?

they don't have to be.  IESG can ask for one, but it's not required.

Date: Thu, 28 Feb 2002 21:03:07 +0000
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

At 04:16 PM 2/28/02 +0000, Charles Lindsey wrote:
> >At 10:59 AM 2/27/02 +0000, Charles Lindsey wrote:
> >> >
> >>I would have expected experimental specs to refer to the author(s) just
> >>like the informational ones.
>
> >Maybe ... I was presuming an experimental RFC here, which has IETF
> >consensus for publication.  I don't feel strongly either way.
>
>Does it? I thought publication of an experimental RFC was more or less
>automatic, except that the IESG might insist on a disclaimer or, in
>extreme cases only, block it entirely.

Note I said consensus for _publication_.  Aren't experimental RFCs 
last-called?  (That would be my touchstone here.)

> >>Would this cover the case where, say, USEFOR defines a header that has a
> >>minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
> >>after a '\').  Would the Spec then say USEFOR, but the related say "based
> >>on RFC 2822"?
>
> >That seems to fit the general intent.  I think the primary specification in
> >this case would be USEFOR, but it would be helpful to cite RFC2822 since it
> >contains material incorporated by reference.  Inevitable, there will be
> >some judgement calls here.
>
>An alternative might be to list several specifications, perhaps in some
>prioritized order.

I wondered about that, but was concerned it might create possible confusion 
in other areas.  I think there should always be a single definitive spec, 
even if others documents are included by reference.

> >> > 3.4 Objections to registration
> >> >
> >>I think you need to include conflict with other ongoing work within the
> >>IETF as a valid ground.
>
> >This list was intended to be illustrative rather than
> >exhaustive.  Ultimately, blocking is a matter for IETF consensus, via the
> >IESG, so I'd rather not grow the list unless you feel strongly about
> >mentioning this particular point.
>
>I think it is a case of some practical importance.

OK, I'll take it you feel strongly about it ;-)

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Thu, 28 Feb 2002 12:39:02 -0500
From: Cyrus Daboo <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: quoted strings within quoted strings
Sender: [email-masked]

Hi,

--On Thursday, February 28, 2002 4:33 PM +0000 Charles Lindsey
<[email-masked]> wrote:

| So what is the proper way to do it?
| Would it be
| 
| 	sender = "\"John D. Bloggs\" <[email-masked]>"
| 
| in which case would/should the inner \"John D. Bloggs\" then be
| interpreted as a quoted-string?
| 
| Or is it the case that there is no proper way to express this sort of
| thing?

I think you need a slightly different example to actually express this
problem. If the phrase had instead been 'John D. "Cool" Bloggs', then you
have the problem of a quoted string in a quoted string more clearly
expressed, and I think the simple solution is to reapply the quoting rules
so you end up with something like:

sender = "\"John D. \\\"Cool\\\" Bloggs" <[email-masked]>"

-- 
Cyrus Daboo

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: quoted strings within quoted strings 
Date: Thu, 28 Feb 2002 12:32:36 -0500
Sender: [email-masked]

> So what is the proper way to do it?
> Would it be

        sender = "\"John D. Bloggs\" <[email-masked]>"

IMHO yes.  and the value encded by that sender parameter is

"John D. Bloggs" <[email-masked]>

not

\"John D. Bloggs\" <[email-masked]>

Keith

To: [email-masked]
Xref: clerew local.mime:1122
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message Header Field Registry - revised proposal
Date: Thu, 28 Feb 2002 16:16:18 GMT
Lines: 125
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> writes:

>Charles,

>Thanks for your comments.  I accept most of them and will take them into 
>account for the next revision.  I note below a few responses and small 
>differences of view:

>At 10:59 AM 2/27/02 +0000, Charles Lindsey wrote:
>> >
>>I would have expected experimental specs to refer to the author(s) just
>>like the informational ones.

>Maybe ... I was presuming an experimental RFC here, which has IETF 
>consensus for publication.  I don't feel strongly either way.

Does it? I thought publication of an experimental RFC was more or less
automatic, except that the IESG might insist on a disclaimer or, in
extreme cases only, block it entirely.

>>Would this cover the case where, say, USEFOR defines a header that has a
>>minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
>>after a '\').  Would the Spec then say USEFOR, but the related say "based
>>on RFC 2822"?

>That seems to fit the general intent.  I think the primary specification in 
>this case would be USEFOR, but it would be helpful to cite RFC2822 since it 
>contains material incorporated by reference.  Inevitable, there will be 
>some judgement calls here.

An alternative might be to list several specifications, perhaps in some
prioritized order.

>>I still maintain there MUST always be a discussion forum (whether by mailing
>>list or otherwise).

>There is a forum for discussion of new registrations (see section 3.3. and 
>reference [43]).

But see my remarks about an offical IETF forum further on. The norm should
be to discuss it in a forum pretty specific to the proposal (e.g. an IETF
WG if there is one, or maybe a Usenet newsgroup such as news.software.*,
especially in the case of a proposal for a news header). My original idea
was that if there wasn't a pre-existing forum, then the proponent had
better create one. An IETF-official forum should only be the fallback, or
a place to point people at the real discussion.

>I can imagine some specific cases of registration for which a separate 
>forum does not exist -- e.g. a proprietary design that is widely used in 
>the wild.   How about SHOULD?

Yes, that might work, with the IETF forum as the fallback. The proper
forum would need to be identified in the registry entry.

>Hmmm... tough one.  This is a requirement for the provisional repository, 
>and I was trying to make sure it was easy for IANA to check whether they 
>were authorized to remove an entry (c.f. section 3.5).  I would suggest 
>that a placeholder document that refers to the offline specification would 
>satisfy this criterion.  (In which case, some words here would be appropriate.)

Yes, that would do.

>> > 3.3 Submission of registration
>> >
>>I doubt IETF will want to set up a special discussion list just for these
>>templates, and I doubt many people would subscribe to such a list. Better
>>to use the existing ietf announce mailing list, with discussion on the
>>existing discussion list. Or maybe make use of the ietf-822 list.

>Fine.  I guess that would be a matter for discussion with IESG.

I think you should be sounding out the IETF admin people about this before
proceeding further. As I said, there only seem to be two public IETF lists
in existence at the moment.

>> > 3.4 Objections to registration
>> >
>>I think you need to include conflict with other ongoing work within the
>>IETF as a valid ground.

>This list was intended to be illustrative rather than 
>exhaustive.  Ultimately, blocking is a matter for IETF consensus, via the 
>IESG, so I'd rather not grow the list unless you feel strongly about 
>mentioning this particular point.

I think it is a case of some practical importance.

>> > 4. IANA considerations
>> >
>>I think you should only specify the initial permanent registry. Let people
>>come forward with their own provisional registrations.

>I agree.  Did I say otherwise?

It wasn't clear. No harm to make it explicit.

>Second, these companion documents are intended to contain registration 
>templates as described here.  I think volunteers are ready to do the email 
>and http parts -- would you be prepared to do one for news?

It depends whether USEFOR get approved before the registry - could happen
either way around. If the registry comes first, then I could produce
something pretty brief containing the bare minimum from RFC 1036. If USEFOR
comes first, then I would expect to produce the full works, of course.

>Third, no they don't exist yet, but work has started on them.

Good. I think we should look closely at the mail one before finalizing the
present draft.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1123
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: quoted strings within quoted strings
Date: Thu, 28 Feb 2002 16:33:33 GMT
Lines: 49
Sender: [email-masked]

This reflects a problem that has come up with a proposed feature in
USEFOR, but it arises out of the syntax of MIME.

Currently, various MIME headers (and some new USEFOR headers) can have
parameters of the form

	attribute = value
where
	attribute = token
	value = token / quoted-string

There is provision for new parameters to be defined in later standards,
and registered with IANA. Typically, the "values" involved are things like
charsets and filenames.

Now suppose someone invents a parameter where the "value" is to be a
mailbox (I don't think that case has arisen yet in MIME, but it well
might).  Perhaps something like:

	"sender" "=" mailbox

Obviously, the mailbox has to be a quoted-string (it contains an '@',
which is a tspecial). BUT a mailbox can itself contain a quoted-string in
many situations, so one might want to write

but, of course, you can't write that because it contains nested
quoted-strings.

So what is the proper way to do it?
Would it be

	sender = "\"John D. Bloggs\" <[email-masked]>"

in which case would/should the inner \"John D. Bloggs\" then be
interpreted as a quoted-string?

Or is it the case that there is no proper way to express this sort of
thing?

-- 
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: [email-masked]      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

Date: Wed, 27 Feb 2002 14:08:15 +0000
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

Charles,

Thanks for your comments.  I accept most of them and will take them into 
account for the next revision.  I note below a few responses and small 
differences of view:

At 10:59 AM 2/27/02 +0000, Charles Lindsey wrote:
> >    Author/Change controller:
> >       For internet standards-track or experimental specifications, state
> >       "IETF".  For other open standards, give the name of the publishing
> >       body (e.g.  ANSI, ISO, ITU, W3C, etc.).  For other specifications,
> >       give the name, email address, and organization name of the primary
> >       specification author Postal address, home page URI, telephone and
> >       fax numbers may be included.
> >
>I would have expected experimental specs to refer to the author(s) just
>like the informational ones.

Maybe ... I was presuming an experimental RFC here, which has IETF 
consensus for publication.  I don't feel strongly either way.

> >    Specification document(s):
> >       Reference to document that specifies the header for use with the
> >       indicated protocol, preferably including a URI that can be used to
> >       retrieve a copy of the document.  An indication of the relevant
> >       sections MAY also be included, but is not required.
> >
> >    Related information:
> >       Optionally, citations to additional documents containing further
> >       relevant information.  (This part of the registry may also be used
> >       for IESG comments.)
> >
>Would this cover the case where, say, USEFOR defines a header that has a
>minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
>after a '\').  Would the Spec then say USEFOR, but the related say "based
>on RFC 2822"?

That seems to fit the general intent.  I think the primary specification in 
this case would be USEFOR, but it would be helpful to cite RFC2822 since it 
contains material incorporated by reference.  Inevitable, there will be 
some judgement calls here.

> >    Author/Change controller:
> >       The name, email address, and organization name of the submission
> >       author, who may authorize changes to or retraction of the
> >       repository entry.  Postal address, home page URI, telephone and
> >       fax numbers may be included.
> >       If the proposal comes from a standards body working group, give
> >       the name and home page URI of the working group, and an email
> >       address for discussion of or comments on the specification.
> >
>I still maintain there MUST always be a discussion forum (whether by mailing
>list or otherwise).

There is a forum for discussion of new registrations (see section 3.3. and 
reference [43]).

I can imagine some specific cases of registration for which a separate 
forum does not exist -- e.g. a proprietary design that is widely used in 
the wild.   How about SHOULD?

> >    Specification document(s):
> >       Reference to document that specifies the header for use with the
> >       indicated protocol.  The document MUST be an RFC, a current
> >       Internet-draft or the URL of a publicly accessible document (so
> >       IANA can verify availability of the specification).  An indication
> >       of the relevant sections MAY also be included, but is not
> >       required.
> >
>I think you have got to allow purely paper documents. There may still be
>some standards bodies whose committees meet in oak-panelled rooms and
>write out their minutes on parchment in long hand :-) . Certainly, for
>example, ISO standards are NEVER available via a URL (they still have
>delusions about generating income from selling paper).

Hmmm... tough one.  This is a requirement for the provisional repository, 
and I was trying to make sure it was easy for IANA to check whether they 
were authorized to remove an entry (c.f. section 3.5).  I would suggest 
that a placeholder document that refers to the offline specification would 
satisfy this criterion.  (In which case, some words here would be appropriate.)

> > 3.3 Submission of registration
> >
> >
> >    o  Send a copy of the template to the designated email discussion
> >       list [43].  Allow a reasonable period - at least 2 weeks - for
> >       discussion and comments, then send the template to IANA at the
> >       designated email address [44].  IANA will publish the template
> >       information if the requested name and the specification document
> >       meet the criteria noted, unless the IESG or their designated
> >       expert have requested that it not be published (see next section).
> >
>I doubt IETF will want to set up a special discussion list just for these
>templates, and I doubt many people would subscribe to such a list. Better
>to use the existing ietf announce mailing list, with discussion on the
>existing discussion list. Or maybe make use of the ietf-822 list.

Fine.  I guess that would be a matter for discussion with IESG.

> > 3.4 Objections to registration
> >
> >    Listing of an entry in the provisional repository should not be
> >    lightly refused.  An entry MAY be refused if there is some credible
> >    reason to believe that such registration will be harmful.  In the
> >    absence of such objection, IANA SHOULD allow any registration that
> >    meets the criteria set out above.  Some reasonable grounds for
> >    refusal might be:
> >
> >    o  There is IETF consensus that publication is considered likely to
> >       harm the Internet technical infrastructure in some way.
> >
> >    o  Disreputable or frivolous use of the registration facilities.
> >
> >    o  The proposal is sufficiently lacking in purpose, or misleading
> >       about its purpose, that it can be held to be a waste of time and
> >       effort.
> >
>I think you need to include conflict with other ongoing work within the
>IETF as a valid ground.

This list was intended to be illustrative rather than 
exhaustive.  Ultimately, blocking is a matter for IETF consensus, via the 
IESG, so I'd rather not grow the list unless you feel strongly about 
mentioning this particular point.

> > 3.5 Change control
> >
> >
> >    It is intended that entries in the Permanent Message Header Field
> >    Registry may be used in the construction of URNs (per RFC 2141 [15])
> >    which have particular requirements for uniqueness and persistence
> >    (per RFC 1737 [4]).  Therefore, once an entry is made in the
> >    Permanent Message Header Registry, the combination of the header name
> >    and applicable protcol MUST NOT subsequently be registered for any
> >    other purpose.  (This is not to preclude revision of the applicable
> >    specification(s) within the appropriate IETF Consensus rules, and
> >    corresponding updates to the specification citation in the header
> >    registration.)
> >
>But you need to allow that a future standard may obsolete or reinstate a
>header, or even change its meaning so that it bears no resemblance at all
>to its former self.

If the IETF decides that that's the right thing to do, then I agree the 
registry would track that change.  I would hope that one effect of the 
registry would be to prevent such changes from happening by accident.  It 
seems a sufficiently unlikely case that it can reasonable be covered by the 
guiding principle of IETF consensus for control of this registry.  I think 
the parenthesized comment is enough here.

> >
> > 4. IANA considerations
> >
> >
> >    Initial header registrations are provided by the following companion
> >    documents:
> >
>I think you should only specify the initial permanent registry. Let people
>come forward with their own provisional registrations.

I agree.  Did I say otherwise?

> >    o  For mail message headers: Registration of mail header fields [41]
> >
>It might be better as an appendix to this RFC. In any case, we need to
>have a good look at [41] (does it exist yet?) before finalising this
>present draft. There is nothing like looking at real cases to spot the
>situations you have failed to cover. In fact, perhaps that should be our
>next business.
>
>Also, you need to do something for Netnews. RFC 1036 would do for a start,
>assuming USEFOR is not ready in time.

First, my expectation was that the initial registry documents would be 
brought forward at the same time as this document ... if this goes to RFF 
publication, I'd hope for a consecutive sequence for registry, email, news, 
http.

Second, these companion documents are intended to contain registration 
templates as described here.  I think volunteers are ready to do the email 
and http parts -- would you be prepared to do one for news?

Third, no they don't exist yet, but work has started on them.

>     o  For HTTP message headers: Registration of HTTP header fields [42]
> >
>Isn't RFC 2616 enough?

See above:  the plan is to have registration templates that IANA can 
use.  Also, to demonstrate/check use of the registry procedures.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Wed, 27 Feb 2002 13:39:48 +0000
To: "Jeff Stephenson" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Message Header Field Registry - revised proposal
Cc: <[email-masked]>
Sender: [email-masked]

I acknowledge this is a technical possibility.

As a matter of personal preference, I don't find it very attractive.  Also, 
taking the range opinions expressed here, I sense that there is a general 
preference for some level of community consensus for permanent allocations.

#g
--

At 09:59 AM 2/26/02 -0800, Jeff Stephenson wrote:

> > -----Original Message-----
> > From: Graham Klyne [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 3:40 PM
> >
> > If every hare-brained idea for a new header gets a permanently
> > allocated name to satisfy this condition, then the interesting
> > parts of namespace are potentially liable to to be committed.
> > I think it's helpful if a degree of community consensus is required
> > to obtain a unique, permanent allocation.
>
>The interesting parts of the namespace only get consumed if the URN of
>the field is based only on the name of the field.  Were the URN for
>fields to be a stricly increasing number (like RFC numbers) or the field
>name plus a strictly increasing number (like ID names), the namespace
>for *fields* (as opposed to URNs) would be unaffected by hare-brained
>schemes.
>
>-- jeff

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Wed, 27 Feb 2002 13:33:50 +0000
To: Jacob Palme <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

It's true this isn't stated explicitly.  I thought it was covered by 
section 3.4:

[[[
    The IESG or their designated expert MAY require any change or
    commentary to be attached to any registry entry.
]]]

#g
--

At 06:34 PM 2/26/02 +0100, Jacob Palme wrote:
>At 16.36 +0000 02-02-21, Graham Klyne wrote:
>>>         Filename        : draft-klyne-msghdr-registry-03.txt
>
>There is no mention, in the revised proposal, of the possibillity
>that you record a header-name together with an explicit warning
>against using it, or that you record a controversial header-name
>with two different conflicting descriptions of it, done by different
>people, and, of course, a warning against using such a controversial
>header name.
>--
>Jacob Palme <[email-masked]> (Stockholm University and KTH)
>for more info see URL: http://www.dsv.su.se/jpalme/

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<[email-masked]>

To: [email-masked]
Xref: clerew local.mime:1118
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message Header Field Registry - revised proposal
Date: Wed, 27 Feb 2002 10:59:06 GMT
Lines: 303
Sender: [email-masked]

>            Registration procedures for message header fields
>                      draft-klyne-msghdr-registry-03

I am now reasonably happy with this draft. So it is time to pick some of
the smaller nits. Here goes ...

> 
> 
> Abstract
> 
>    This specification defines registration procedures for the message
>    header fields used by Internet mail, HTTP, news and other
                                                ^^^^
                                                Netnews
>    applications.

> 1. Introduction
> 
>    The primary specification for Internet message header fields in email
>    is the Internet mail message format specification, RFC 2822 [34].
>    HTTP/1.0 [7] and HTTP/1.1 [28] define message header fields
>    (respectively, the HTTP-header and message-header protocol elements)
>    for use with HTTP.  These specifications also define a number of
>    header fields, and and provide for extension through the use of new
>    field-names.
> 
>    There are many other Internet standards track documents that define
>    additional header fieldss for use within the same namespaces, notably
>    MIME [9] and related specifications.  Other Internet applications
>    that use MIME, such as newsgroup feeds (RFC 1036 [1]) may also use
>    many of the same header fields.
> 
I think you need to introduce RFC 1036 on a par with RFC 2822 and the HTTP
specs. Or maybe it will be USEFOR by the time your draft is finalized.
USEFOR defines the syntax of header fields ab initio, though they are
essentially the same as in RFC 2822.

> 2.1 Permanent and provisional header fields
> 
>    o  A Permanent Message Header Field Registry, intended for headers
>       defined in IETF standards-track documents, those that have
>       achieved a comparable level of community review, or are generally
>       recognized to be in widespread use.  The assignment policy for
>       such registration is "Specification required", as defined by RFC
                                            ^^^^^^^^
                                            Required
>       2434 [26], where the specification must be published in an RFC

> 2.2.1 Application-specific message headers
> 
> 
>    Thus, we need to accommodate application-specific fields, while
>    wishing to recognize and promote (where appropriate) commonality of
>    other fields across multiple applications.  Common repositories are
>    used for all applications, and each registered header field specifies
>    the application protocol for which the corresponding definition
>    applies.  A given field name may have multiple registry entries for
>    different protocols; in the Permanent Message Header Field registry,
>    a given header field name may be registered only once for any given
>    protocol.
> 
Not quite. A header field may be extensible (e.g. in MIME where
Content-Type can have extra 'parameters' added by subsequent standards;
USEFOR is also introducing a similar feature). So a given field might
legitimately have several specifications (RFCs) listed against it (the
later ones UPDATING rather than OBSOLETING the earliest one, to use the
usual IETF terminology).

> 
> 3. Registration procedure
> 
> 
> 3.1 Header field specification
> 
>    A registered field name MUST conform at least to the syntax defined
                             ^^^^
                             SHOULD (just to cover yourself :-) )
>    by RFC 2822 [34], section 3.6.8.
> 
Actually, even that is not good enough, because that allows only US-ASCII,
and USEFOR already allows the full 8 bits in ftext. Doubtless there will
be other exceptions in the future for perfectly valid reasons.

> 
>    Further, the "." character is reserved to indicate a naming sub-
>    structure and MUST NOT be included in any registered field name. 
>    Currently, no specific sub-structure is defined; if used, any such
>    structure MUST be defined by a standards track RFC document. 
> 
>    It is further RECOMMENDED that characters in a registered field name
>    are restricted to those that can be used without escaping in a URI
>    [24] or URN [15], namely upper- or lower-case ASCII letters, decimal
>    digits, "(", ")", "+", ",", "-", "=", "@", ";", "$", "_", "!", "*"
>    and "'".  Of course, a field name must also conform to any applicable
>    rules of the protocol(s) with which it is used. 
> 
I would restrict it even further than that (after all, it is only at
SHOULD level). USEFOR restricts it to letters (case-insensitive) digits
and '-' (but SHOULD accept the full RFC2822), and all known headers in all
three protocols already conform to that. I have no doubt that much
software in many places makes that assumption, and we could think of no
good reason to risk extending it further.

> 
>    Some field names may find use in conjunction with XML [39]. In these
>    cases, the name characters SHOULD be further restricted to just
>    letters, digits, hyphen ('-') and underscore ('_') characters, with
>    the first character being a letter or underscore. 
> 
Yes, that would actually be fine as the general RECOMMENDation.

I also think you should exclude any header beginning with 'X-'.

> 
> 3.2 Registration templates
> 
> 
> 3.2.1 Permanent message header field registration template
> 
> 
>    Applicable protocol:
>       Specify "mail" (RFC 2822), "http" (RFC 2616), "news" (RFC 1036),
                                                       ^^^^
                                                       netnews
>       or cite any other standards-track RFC defining the protocol with
>       which the header is intended to be used.
> 
>    Status:
>       Specify "standard", "experimental", "informational" or "historic",
>       according to the type and status of the primary document in which
>       it is defined.
> 
I think you also need "deprecated", "obsoleted", etc if that is how the Spec
defines it (otherwise, you have to premit removal from the registry, which
you don't want).

> 
>    Author/Change controller:
>       For internet standards-track or experimental specifications, state
>       "IETF".  For other open standards, give the name of the publishing
>       body (e.g.  ANSI, ISO, ITU, W3C, etc.).  For other specifications,
>       give the name, email address, and organization name of the primary
>       specification author Postal address, home page URI, telephone and
>       fax numbers may be included.
> 
I would have expected experimental specs to refer to the author(s) just
like the informational ones.

> 
>    Specification document(s):
>       Reference to document that specifies the header for use with the
>       indicated protocol, preferably including a URI that can be used to
>       retrieve a copy of the document.  An indication of the relevant
>       sections MAY also be included, but is not required.
> 
>    Related information:
>       Optionally, citations to additional documents containing further
>       relevant information.  (This part of the registry may also be used
>       for IESG comments.)
> 
Would this cover the case where, say, USEFOR defines a header that has a
minor difference from RFC2822 (e.g. msg-id where we forbid a SP, even
after a '\').  Would the Spec then say USEFOR, but the related say "based
on RFC 2822"?

> 
> 3.2.2 Provisional message header field submission template
> 
> 
>    Applicable protocol:
>       Specify "mail" (RFC 2822), "http" (RFC 2616), "news" (RFC 1036),
                                                       ^^^^
                                                       netnews
>       or cite any other standards-track RFC defining the protocol with
>       which the header is intended to be used.
> 
>    Status:
>       Specify: "provisional".  This will be updated if and when the
>       header registration is subsequently moved to the permanent
>       registry.
> 
>    Author/Change controller:
>       The name, email address, and organization name of the submission
>       author, who may authorize changes to or retraction of the
>       repository entry.  Postal address, home page URI, telephone and
>       fax numbers may be included.
>       If the proposal comes from a standards body working group, give
>       the name and home page URI of the working group, and an email
>       address for discussion of or comments on the specification.
> 
I still maintain there MUST always be a discussion forum (whether by mailing
list or otherwise).

> 
>    Specification document(s):
>       Reference to document that specifies the header for use with the
>       indicated protocol.  The document MUST be an RFC, a current
>       Internet-draft or the URL of a publicly accessible document (so
>       IANA can verify availability of the specification).  An indication
>       of the relevant sections MAY also be included, but is not
>       required.
> 
I think you have got to allow purely paper documents. There may still be
some standards bodies whose committees meet in oak-panelled rooms and
write out their minutes on parchment in long hand :-) . Certainly, for
example, ISO standards are NEVER available via a URL (they still have
delusions about generating income from selling paper).

> 3.3 Submission of registration
> 
> 
>    o  Send a copy of the template to the designated email discussion
>       list [43].  Allow a reasonable period - at least 2 weeks - for
>       discussion and comments, then send the template to IANA at the
>       designated email address [44].  IANA will publish the template
>       information if the requested name and the specification document
>       meet the criteria noted, unless the IESG or their designated
>       expert have requested that it not be published (see next section).
> 
I doubt IETF will want to set up a special discussion list just for these
templates, and I doubt many people would subscribe to such a list. Better
to use the existing ietf announce mailing list, with discussion on the
existing discussion list. Or maybe make use of the ietf-822 list.

> 
> 3.4 Objections to registration
> 
>    Listing of an entry in the provisional repository should not be
>    lightly refused.  An entry MAY be refused if there is some credible
>    reason to believe that such registration will be harmful.  In the
>    absence of such objection, IANA SHOULD allow any registration that
>    meets the criteria set out above.  Some reasonable grounds for
>    refusal might be:
> 
>    o  There is IETF consensus that publication is considered likely to
>       harm the Internet technical infrastructure in some way.
> 
>    o  Disreputable or frivolous use of the registration facilities.
> 
>    o  The proposal is sufficiently lacking in purpose, or misleading
>       about its purpose, that it can be held to be a waste of time and
>       effort.
> 
I think you need to include conflict with other ongoing work within the
IETF as a valid ground.

> 
> 3.5 Change control
> 
> 
>    It is intended that entries in the Permanent Message Header Field
>    Registry may be used in the construction of URNs (per RFC 2141 [15])
>    which have particular requirements for uniqueness and persistence
>    (per RFC 1737 [4]).  Therefore, once an entry is made in the
>    Permanent Message Header Registry, the combination of the header name
>    and applicable protcol MUST NOT subsequently be registered for any
>    other purpose.  (This is not to preclude revision of the applicable
>    specification(s) within the appropriate IETF Consensus rules, and
>    corresponding updates to the specification citation in the header
>    registration.)
> 
But you need to allow that a future standard may obsolete or reinstate a
header, or even change its meaning so that it bears no resemblance at all
to its former self.

> 
> 4. IANA considerations
> 
> 
>    Initial header registrations are provided by the following companion
>    documents:
> 
I think you should only specify the initial permanent registry. Let people
come forward with their own provisional registrations.

>    o  For mail message headers: Registration of mail header fields [41]
> 
It might be better as an appendix to this RFC. In any case, we need to
have a good look at [41] (does it exist yet?) before finalising this
present draft. There is nothing like looking at real cases to spot the
situations you have failed to cover. In fact, perhaps that should be our
next business.

Also, you need to do something for Netnews. RFC 1036 would do for a start,
assuming USEFOR is not ready in time.

> 
>    o  For HTTP message headers: Registration of HTTP header fields [42]
> 
Isn't RFC 2616 enough?

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1117
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message Header Field Registry - revised proposal
Date: Wed, 27 Feb 2002 10:03:38 GMT
Lines: 30
Sender: [email-masked]

In <p05100311b8a176d380bd@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>At 10.00 -0800 02-02-21, Jeff Stephenson wrote:
>>(1) There's only one place to look to see header fields.
>>(2) When a temporary/proprietary field moves to standardized, the
>>maintainers of the registry need only change a status field rather than
>>move the entry between registries.

>Also, two separate registries introduces the risk of the
>same header name occuring by mistake in both registries.

I don't think that is a serious risk.

Clearly, it is no big deal whether we have one registry with provisional
tags, or two seperate ones.

My personal preference is for two, and that has the advantage of keeping
the URN space cleaner (not that I really understand this URN business).

-- 
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: [email-masked]      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

content-class: urn:content-classes:message
Subject: RE: Message Header Field Registry - revised proposal
Date: Tue, 26 Feb 2002 09:59:49 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Graham Klyne [mailto:[email-masked]] 
> Sent: Thursday, February 21, 2002 3:40 PM
> 
> If every hare-brained idea for a new header gets a permanently
> allocated name to satisfy this condition, then the interesting
> parts of namespace are potentially liable to to be committed.
> I think it's helpful if a degree of community consensus is required
> to obtain a unique, permanent allocation.

The interesting parts of the namespace only get consumed if the URN of
the field is based only on the name of the field.  Were the URN for
fields to be a stricly increasing number (like RFC numbers) or the field
name plus a strictly increasing number (like ID names), the namespace
for *fields* (as opposed to URNs) would be unaffected by hare-brained
schemes.

-- jeff

Date: Tue, 26 Feb 2002 18:31:26 +0100
To: "Jeff Stephenson" <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RE: Message Header Field Registry - revised proposal
Cc: <[email-masked]>
Sender: [email-masked]

At 10.00 -0800 02-02-21, Jeff Stephenson wrote:
>(1) There's only one place to look to see header fields.
>(2) When a temporary/proprietary field moves to standardized, the
>maintainers of the registry need only change a status field rather than
>move the entry between registries.

Also, two separate registries introduces the risk of the
same header name occuring by mistake in both registries.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Tue, 26 Feb 2002 18:34:16 +0100
To: Graham Klyne <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

At 16.36 +0000 02-02-21, Graham Klyne wrote:
>>         Filename        : draft-klyne-msghdr-registry-03.txt

There is no mention, in the revised proposal, of the possibillity
that you record a header-name together with an explicit warning
against using it, or that you record a controversial header-name
with two different conflicting descriptions of it, done by different
people, and, of course, a warning against using such a controversial
header name.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:1113
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message Header Field Registry - revised proposal
Date: Fri, 22 Feb 2002 12:11:13 GMT
Lines: 35
Sender: [email-masked]

In <[email-masked]> "Jeff Stephenson" <[email-masked]> writes:

>> So, separate from the fine-grained details, I would like to 
>> propose that the split be between Standardized vs. Proprietary.

>While many (perhaps most) of the entries in the non-standardized
>category will indeed be purely proprietary, to me "proprietary" means
>implemented by only a single MUA.  It seems to me that there will also
>be a significant number of non-standardized fields that are more widely
>implemented and thus aren't strictly proprietary in my sense of that
>word.  I think that Standardized/Non-Standard is perhaps a better
>distinction than Standardized/Proprietary.

I agree. "Proprietary" will be widely misunderstood (whether rightly or
wrongly so does not matter).

OTOH, "Informational" is not quite right either, because headers defined
in Informational RFCs (which are widely and permanently used, but don't
need to be standardised because there is no protocol involved and they
only apply to a limited class of objects, such as FAQs) may well get
promoted to the upper registry (or, at least, we should retain the option
to allow that at some future point, it not in this draft).

"Temporary" would but fine, but I still think "Provisional" is best.

-- 
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: [email-masked]      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

Date: Fri, 22 Feb 2002 00:54:07 +0000
From: Olafur Osvaldsson <[email-masked]>
To: [email-masked]
Subject: Regarding rfc2821
Sender: [email-masked]

Hi,
This is my second and last attempt to send this question to this mailing list,
this I do only because my last one went unanswered.

I found this list address in the last drums archive.

I have been unable to contact the editor of RFC 2821 so I ask you this.
I'm not on the list so please send Cc of any replies to me.

I was going through this rfc and found several references wich point to
section 2.4.1 but this section does not exist.
Can you tell me if this section was left out and why, or if it was forgotten
and then I need to know how this can be corrected.

My understanding is that this section covers the fact that servers should not
edit the body of emails, but I may be wrong.

                                Oli
-- 
Olafur Osvaldsson
Systems Administrator
Internet a Islandi hf.
Tel:   +354 525-5291
Email: [email-masked]

Date: Thu, 21 Feb 2002 23:39:37 +0000
To: "Jeff Stephenson" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Message Header Field Registry - revised proposal
Cc: <[email-masked]>
Sender: [email-masked]

At 11:17 AM 2/21/02 -0800, Jeff Stephenson wrote:

> > -----Original Message-----
> > From: Graham Klyne [mailto:[email-masked]]
> > Sent: Thursday, February 21, 2002 10:34 AM
>
> > Having transient, non-permanent entries would break the RFC
> > 1737 persistence requirements for URNs.
>
>The paragraph you're referring to in RFC 1737 is (I think):
>
>      It is intended that the lifetime of a URN be
>      permanent.  That is, the URN will be globally unique forever, and
>      may well be used as a reference to a resource well beyond the
>      lifetime of the resource it identifies or of any naming authority
>      involved in the assignment of its name.

Yes, and there's also this:

    o Global uniqueness: The same URN will never be assigned to two
      different resources.

If every hare-brained idea for a new header gets a permanently allocated 
name to satisfy this condition, then the interesting parts of namespace are 
potentially liable to to be committed.  I think it's helpful if a degree of 
community consensus is required to obtain a unique, permanent allocation.

>It specifically states that the resource itself needn't be permanent,
>just the URN.  As long as the registry entries are given unique and
>non-repeating URNs, a single registry would satisfy RFC 1737.

I understand the document to be saying something slightly different;  viz 
the other point noted above.  Once a name is allocated permanently in this 
way, then some record must be maintained as a guard against reallocation.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

content-class: urn:content-classes:message
Subject: RE: Message Header Field Registry - revised proposal
Date: Thu, 21 Feb 2002 11:17:57 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Sam [mailto:[email-masked]] 
> Sent: Thursday, February 21, 2002 10:23 AM
> 
> I see the split as between "standardized" and 
> "informational", where I'd like to be able to find 
> information on headers I see in the wild that aren't 
> standardized and likely should be shunned.

I definitely prefer "Informational" to "Proprietary".

-- jeff

content-class: urn:content-classes:message
Subject: RE: Message Header Field Registry - revised proposal
Date: Thu, 21 Feb 2002 11:17:57 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Graham Klyne [mailto:[email-masked]] 
> Sent: Thursday, February 21, 2002 10:34 AM

> Having transient, non-permanent entries would break the RFC 
> 1737 persistence requirements for URNs.

The paragraph you're referring to in RFC 1737 is (I think):

     It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

It specifically states that the resource itself needn't be permanent,
just the URN.  As long as the registry entries are given unique and
non-repeating URNs, a single registry would satisfy RFC 1737.

-- jeff

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: "Jeff Stephenson" <[email-masked]>, [email-masked]
Subject: Re: Message Header Field Registry - revised proposal 
Date: Thu, 21 Feb 2002 14:12:47 -0500
Sender: [email-masked]

> I would like to be able to use the (permanent) registry entries as a basis
> for constructing URNs for use in (say) a generic message archive and
> classification system.  This is my motivation for doing this work.

I don't get it.  Why do you need a header field registry in order to
construct URNs for messages?

Keith

Date: Thu, 21 Feb 2002 18:34:25 +0000
To: "Jeff Stephenson" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Message Header Field Registry - revised proposal
Cc: <[email-masked]>
Sender: [email-masked]

At 10:00 AM 2/21/02 -0800, Jeff Stephenson wrote:
>(1) There's only one place to look to see header fields.
>(2) When a temporary/proprietary field moves to standardized, the
>maintainers of the registry need only change a status field rather than
>move the entry between registries.
>
>Admittedly neither of these is a big deal, but they are IMHO advantages
>to a single registry over a split registry and I see no advantages the
>other way around; maybe someone can enlighten me.

Speaking for myself:

I would like to be able to use the (permanent) registry entries as a basis 
for constructing URNs for use in (say) a generic message archive and 
classification system.  This is my motivation for doing this work.

Having transient, non-permanent entries would break the RFC 1737 
persistence requirements for URNs.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Thu, 21 Feb 2002 13:23:00 -0500
From: Sam <[email-masked]>
To: [email-masked]
Subject: Re: Message Header Field Registry - revised proposal
Sender: [email-masked]

I see the split as between "standardized" and "informational",
where I'd like to be able to find information on headers I see in the
wild that aren't standardized and likely should be shunned.

Sam

On Thu, Feb 21, 2002 at 09:29:17AM -0800, Dave Crocker <[email-masked]> wrote:
> 
> At 04:36 PM 2/21/2002 +0000, Graham Klyne wrote:
> >The main change is a refactoring into a permanent registry and a 
> >provisional repository.
> 
> The split into two categories seems like an especially helpful change, 
> given the concerns that have been expressed.
> 
> I think that consideration of the split can divide into two different 
> levels.  One is the nature of the distinction between the two categories 
> and the other is the detailed rules for each.
> 
> The 'nature' of the proposed distinction is temporal:  -- permanent versus 
> temporary.  Over the course of the IETF's history, I think that the 
> pragmatics of temporariness has tended to prove to be elusive, misleading 
> or wrong.
> 
> My sense of the major focus of concern in the current discussion is between 
> official, formal, standardized reservations, versus those that are outside 
> of such processes.  That is, the focus is about the authority behind 
> specific entries.  The ones that are not part of the public, offical, 
> formal world are private or proprietary.
> 
> So, separate from the fine-grained details, I would like to propose that 
> the split be between Standardized vs. Proprietary.

-- 
Sam Roberts <[email-masked]>

Date: Thu, 21 Feb 2002 18:04:01 +0000
To: Dave Crocker <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

At 09:29 AM 2/21/02 -0800, Dave Crocker wrote:
>So, separate from the fine-grained details, I would like to propose that 
>the split be between Standardized vs. Proprietary.

A question:  what would be the status of a work-in-progress proposal from a 
working group?

#g

------------
Graham Klyne
([email-masked])

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Graham Klyne <[email-masked]>, [email-masked]
Subject: Re: Message Header Field Registry - revised proposal 
Date: Thu, 21 Feb 2002 13:04:39 -0500
Sender: [email-masked]

> My sense of the major focus of concern in the current discussion is between
> official, formal, standardized reservations, versus those that are outside
> of such processes.  That is, the focus is about the authority behind
> specific entries. 

I would characterize this somewhat differently.  It's not so much a
matter of "authority" as whether or not an extension is deployed 
without a specification that has been subjected to community review 
and gained consensus.  I see IETF as more of a mechanism to facilitate
such review and gauge consensus than as an "authority".

Keith

content-class: urn:content-classes:message
Subject: RE: Message Header Field Registry - revised proposal
Date: Thu, 21 Feb 2002 10:00:27 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Thursday, February 21, 2002 9:29 AM
> 
> At 04:36 PM 2/21/2002 +0000, Graham Klyne wrote:
> >The main change is a refactoring into a permanent registry and a 
> >provisional repository.
> 
> The split into two categories seems like an especially 
> helpful change, given the concerns that have been expressed.

I'm afraid I don't see how two registries accomplishes this any better
than a single registry with a status field on each entry that expresses
this distinction.  To me, a single registry has several advantages:

(1) There's only one place to look to see header fields.
(2) When a temporary/proprietary field moves to standardized, the
maintainers of the registry need only change a status field rather than
move the entry between registries.

Admittedly neither of these is a big deal, but they are IMHO advantages
to a single registry over a split registry and I see no advantages the
other way around; maybe someone can enlighten me.

> So, separate from the fine-grained details, I would like to 
> propose that the split be between Standardized vs. Proprietary.

While many (perhaps most) of the entries in the non-standardized
category will indeed be purely proprietary, to me "proprietary" means
implemented by only a single MUA.  It seems to me that there will also
be a significant number of non-standardized fields that are more widely
implemented and thus aren't strictly proprietary in my sense of that
word.  I think that Standardized/Non-Standard is perhaps a better
distinction than Standardized/Proprietary.

-- jeff

Date: Thu, 21 Feb 2002 09:29:17 -0800
To: Graham Klyne <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal
Cc: [email-masked]
Sender: [email-masked]

At 04:36 PM 2/21/2002 +0000, Graham Klyne wrote:
>The main change is a refactoring into a permanent registry and a 
>provisional repository.

The split into two categories seems like an especially helpful change, 
given the concerns that have been expressed.

I think that consideration of the split can divide into two different 
levels.  One is the nature of the distinction between the two categories 
and the other is the detailed rules for each.

The 'nature' of the proposed distinction is temporal:  -- permanent versus 
temporary.  Over the course of the IETF's history, I think that the 
pragmatics of temporariness has tended to prove to be elusive, misleading 
or wrong.

My sense of the major focus of concern in the current discussion is between 
official, formal, standardized reservations, versus those that are outside 
of such processes.  That is, the focus is about the authority behind 
specific entries.  The ones that are not part of the public, offical, 
formal world are private or proprietary.

So, separate from the fine-grained details, I would like to propose that 
the split be between Standardized vs. Proprietary.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Thu, 21 Feb 2002 16:36:20 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Message Header Field Registry - revised proposal
Sender: [email-masked]

You may have noticed a new revision announced:

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Registration procedures for message header fields
>         Author(s)       : G. Klyne et al.
>         Filename        : draft-klyne-msghdr-registry-03.txt
>         Pages           : 19
>         Date            : 20-Feb-02
>
>This specification defines registration procedures for the message
>header fields used by Internet mail, HTTP, news and other
>applications.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-03.txt

We've tried to take account of the various concerns that have been raised, 
though it's clearly  not going to be possible to completely satisfy everybody.

The main change is a refactoring into a permanent registry and a 
provisional repository.

Admission to the permanent registry must satisfy uniqueness criteria, and 
publication of a persistent document by a recognized open standards 
publisher.  This effectively ensures a community review without getting 
into the details of duplicating existing review procedures.

Admission to the provisional repository requires a specification, 
notification to a common mailing list and a review period.  We think this 
is plenty to allow the more egregious  possible abuses to be blocked while 
maintaining what is essentially an open listing.

In this, and numerous smaller changes, we believe that the concerns 
expressed have been addressed or mitigated, while maintaining a lightweight 
process that in normal use will not be a drain on IESG or IANA resources.

#g

------------
Graham Klyne
([email-masked])

Date: Wed, 13 Feb 2002 08:23:57 -0800 (PST)
From: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
To: Keith Moore <[email-masked]>
Cc: Dave Crocker <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Interesting.  I thought my comments were simple and clear, yet they seem to
> > be receiving an impressive degree of mis-hearing.

> there's a lot of that going around.
 
> > Let me try this again, slower and simpler:
> >
> > 1.  ADs are vastly overburdened.
> >
> > 2.  ADs often try to obtain review services from others.
> >
> > 3.  ADs typically have an extremely difficult time obtaining those services.
> >
> > 4.  The problem is bad enough for some ADs to have given up on even trying
> > to get those services.

One of the things they teach you in first aid classes is that a general call to
get someone to "call 911" is rarely effective since everyone will assume
someone else is doing it. What works is tasking one or two specific individuals
to do it.

The same thing applies to reviewers. Having a general review panel with a vague
mission statement doesn't work well at all. Asking specific individuals to
review specific things works pretty. Asking someone to be an official "reviewer
of foo" may or may not work -- finding people with the time to do this sort of
thing is hard.

So the bottom line is that effective review processes end up costing ADs time.
I wish this weren't the case, but it is.

					Ned

Date: Wed, 13 Feb 2002 17:13:53 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> Interesting.  I thought my comments were simple and clear, yet they seem to 
> be receiving an impressive degree of mis-hearing.

Maybe a little bit too short. It often gets to be that way when there's a
great big pile of mail...

I accept what you say in this message. Some of it's fact, some of it's
opinion with which I agree. I don't argue with any of it.

Never the less I would like registrants of new header fields to provide a
specification, wait a couple of weeks and deal with any comments provided
in that period, and only then enter it into the registry.

I'm not an AD or designated expert, I don't have a public responsibility
to review internet-drafts, but I read the ones that are relevant to my
work. When I send in comments, the author has a responsibility to listen.
That responsibility is a good thing.

--Arnt

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Date: Wed, 13 Feb 2002 10:31:54 -0500
Sender: [email-masked]

> Interesting.  I thought my comments were simple and clear, yet they seem to
> be receiving an impressive degree of mis-hearing.

there's a lot of that going around.
 
> Let me try this again, slower and simpler:
> 
> 1.  ADs are vastly overburdened.
> 
> 2.  ADs often try to obtain review services from others.
> 
> 3.  ADs typically have an extremely difficult time obtaining those services.
> 
> 4.  The problem is bad enough for some ADs to have given up on even trying
> to get those services.

all of the above are consistent with my experience.   

Keith

Date: Wed, 13 Feb 2002 07:22:20 -0800
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

Interesting.  I thought my comments were simple and clear, yet they seem to 
be receiving an impressive degree of mis-hearing.

Let me try this again, slower and simpler:

1.  ADs are vastly overburdened.

2.  ADs often try to obtain review services from others.

3.  ADs typically have an extremely difficult time obtaining those services.

4.  The problem is bad enough for some ADs to have given up on even trying 
to get those services.

5.  My sense of this problem is obtained from an intense review of AD work, 
as part of my CURRENT involvement in Nomcom, during which this very problem 
was discussed at length and the seriousness of the problem was noted to be 
pervasive.

So, if folks are going to try to dismiss my observation, please try not to 
do it by claiming the observation is wrong or that it is a different 
observation.

d/

At 04:11 PM 2/13/2002 +0100, Arnt Gulbrandsen wrote:

>Dave Crocker <[email-masked]>
> > No.  I am talking about getting non-AD folks to do review work.  That 
> is, I
> > am talking about exactly the kind of task being discussed here.
>
>Well, non-AD folk do internet-draft reviews, and that doesn't seem to be a
>disaster.
>
>--Arnt

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Date: Wed, 13 Feb 2002 10:15:35 -0500
Sender: [email-masked]

> No.  I am talking about getting non-AD folks to do review work.  That is, I
> am talking about exactly the kind of task being discussed here.

I agree that it is very hard to get people to do good reviews of detailed
proposals.   Sometimes the best solution is to form a working group, but 
WGs take up AD resources also, and good WG chairs are also hard to find.

For the existing registries that come to mind, the review process doesn't 
seem especially burdensome on the person doing the review.  But for those 
registries the effect of adding a new number or name is fairly well-bounded,
and this isn't true for header fields.  IMHO X-Face or X-Priority wouldn't
be terribly difficult to review, because their effects are also well-bounded.
OTOH, something that attempts to fix the problems with reply would be more
difficult to review, because it's harder to understand the effect that
a proposal would have on the mail system.

So I agree that review of new header fields will sometimes be difficult.
This is one reason that I think the reviewer ought to be able to say
"this is something that requires IETF consensus before it is approved"
(even if it appears in the registry in the meantime)

But the very reason that the review is difficult is also the reason that
we need review of such proposals - we need to understand the likely 
impact of the change before we recommend deployment (or not).

In general, it easy to come up with lots of potentially good ideas ,
much more difficult to understand which ones really work in practice.

Keith

Date: Wed, 13 Feb 2002 16:11:26 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> No.  I am talking about getting non-AD folks to do review work.  That is, I 
> am talking about exactly the kind of task being discussed here.

Well, non-AD folk do internet-draft reviews, and that doesn't seem to be a
disaster.

--Arnt

Date: Wed, 13 Feb 2002 06:33:56 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Cc: Keith Moore <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

No.  I am talking about getting non-AD folks to do review work.  That is, I 
am talking about exactly the kind of task being discussed here.

d/

At 06:15 AM 2/13/2002 -0500, Keith Moore wrote:
> > having just about completed a turn on nomcom, let me assure you that their
> > life is not nearly so smooth and those "others" are not nearly so readily
> > available.
>
>if you're talking about the AD job in general, I agree
>but the specific tasks of finding experts for registries
>and making judgements about the suitability of new registrations
>are the least of it.

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Date: Wed, 13 Feb 2002 06:15:00 -0500
Sender: [email-masked]

> having just about completed a turn on nomcom, let me assure you that their
> life is not nearly so smooth and those "others" are not nearly so readily
> available.

if you're talking about the AD job in general, I agree
but the specific tasks of finding experts for registries
and making judgements about the suitability of new registrations
are the least of it. 

Date: Wed, 13 Feb 2002 11:52:11 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Paul Smith <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Paul Smith <[email-masked]>
> Speaking as someone who's probably unqualified to talk here (as I've never 
> tried to write an RFC), the mere thought of writing an RFC fills me with 
> terror ;-)

The draft asks for an RFC in some cases, but merely for a "defining
document" of some sort in the rest. Sounds like a good balance.

--Arnt

Date: Wed, 13 Feb 2002 10:18:02 +0000
To: Barry Leiba <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

>>To me, a suitable spec would be something like:
>>
>>List-Unsubscribe
>>-----------------
>>
>>That's it.
>
>Sure, that's it for that one.
>Now write a spec for the "Sender" header field.

Maybe if we'd had this proposed 'registry' when 'Sender' was being put into 
the standards then it wouldn't have been the same problem it is today... :-)

>And then look at all the cases where it's been done wrong over the years 
>(and understand why X-Sender exists).  Some fields are easy to explain, 
>easy to implement right, and have been a smooth sail.

Most good ideas for message headers are quite easy to specify (Subject, 
Date, From, To, etc :-) ). If they're complicated to write a spec for, 
maybe they need re-thinking. IMHO the current requirements for making an 
RFC or a draft in the 'proper' formal format are quite intimidating for 
most people, and having an easier way of *proposing* a new header would be 
a good idea.

One way of stopping abuse of a registry would be to 'authorise' people to 
be able to add stuff to it (eg, if you want to add a new header you have to 
get a login by proving that you are an email software producer (easy to do, 
just tell someone your website..)). Then, if there's abuse from that 
company, ban them from registering more headers.

I don't see that fear of 'abuse' should be a hindrance to the idea of a 
'registry' as it's quite easy to prevent.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: 13 Feb 2002 07:26:12 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: The Sender header field
Sender: [email-masked]

Dave Crocker writes:
> sender/from/reply-to were major innovations in RFC 733, considerably 
> pre-dating SMTP.

RFC 822 did not predate SMTP. There were many changes from 733 to 822.
Return-Path was added in 822. Why did Return-Path not replace Sender?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Tue, 12 Feb 2002 23:19:51 -0800
To: "D. J. Bernstein" <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

At 8:44 PM +0000 2/12/02, D. J. Bernstein wrote:
>Pine and Eudora use Sender (or X-Sender or X-X-Sender) as a bogus
>security mechanism, putting private login information into it and making
>it difficult for novice users to change. What was Crispin thinking? What
>were the Qualcomm people thinking?

I dare not speak for Mark.

In our case we were trying to placate a determined co-worker 
possessed by a half-baked idea without doing too much damage to the 
rest of the Internet email community.  Some compromises are good 
ones.  Others, you just shrug your shoulders and move on.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

Date: Tue, 12 Feb 2002 23:02:05 -0800
To: Pete Resnick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: The Sender header field
Cc: [email-masked]
Sender: [email-masked]

sender/from/reply-to were major innovations in RFC 733, considerably 
pre-dating SMTP.

d/

At 12:55 AM 2/13/2002 -0600, Pete Resnick wrote:

>>RFC 822 4.4.4 specifies Sender, defaulting to From, as the bounce target.
>>
>>What was Crocker thinking? The envelope/message distinction was already 
>>clear in SMTP. Why is Sender useful in a mail system that supports 
>>envelope senders?
>
>4.4.4 is not clear on whether it means bounces or other sorts of 
>notifications. For instance, a message from a human saying "This person 
>has a new e-mail address" would go back to the Sender since (e.g.) the 
>secretary would be the one interested in this information. Sender would be 
>the only reasonably readable place to find that information since at the 
>time, Return-Path would also have had a bunch of routing information, 
>might have a relatively useless address after the route, and it was rarely 
>generated.

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Wed, 13 Feb 2002 00:55:05 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: The Sender header field
Sender: [email-masked]

On 2/12/02 at 8:44 PM +0000, D. J. Bernstein wrote:

>It would be interesting to understand how people managed to create 
>the current Sender situation.

I'll try to shed what light I can.

>RFC 822 4.4.4 specifies Sender, defaulting to From, as the bounce target.
>
>What was Crocker thinking? The envelope/message distinction was 
>already clear in SMTP. Why is Sender useful in a mail system that 
>supports envelope senders?

4.4.4 is not clear on whether it means bounces or other sorts of 
notifications. For instance, a message from a human saying "This 
person has a new e-mail address" would go back to the Sender since 
(e.g.) the secretary would be the one interested in this information. 
Sender would be the only reasonably readable place to find that 
information since at the time, Return-Path would also have had a 
bunch of routing information, might have a relatively useless address 
after the route, and it was rarely generated.

>Pine and Eudora use Sender (or X-Sender or X-X-Sender) as a bogus 
>security mechanism, putting private login information into it and 
>making it difficult for novice users to change. What was Crispin 
>thinking? What were the Qualcomm people thinking?

Actually, this one I can explain, at least for Eudora. Eudora never 
used Sender because 822 said:

         This field contains the authenticated identity  of  the  AGENT
         (person,  system  or  process)  that sends the message.

and made it quite clear that this had to be a deliverable address. We 
had no way to get any kind of authenticated identity that was 
guaranteed to be deliverable. However, users (read site 
administrators) insisted that we put the POP login information 
somewhere to "prevent forgeries", even when we tried to convince them 
that this was a stupid (and useless) thing to do. Since we couldn't 
legitimately put that in Sender, we made up X-Sender. (In all 
versions of Eudora, any user with two brain cells to rub together 
could have gotten rid of the X-Sender or put just about anything into 
it that they wanted without a great deal of effort.)

We never used X-X-Sender as far as I know.

>The Pine people say that they use X-Sender/X-X-Sender because some 
>unidentified mailing-list programs look at Sender/X-Sender. If this 
>is true, what were the authors of those programs thinking?

The same thing that those site administrators were thinking. (*Sigh*)
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 12 Feb 2002 21:14:25 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:52 PM 2/12/2002 -0500, Keith Moore wrote:
> > area directors are already vastly overburdended.  and the effort to do the
> > task you are assigning is substantial.
>
>area directors routinely designate others to perform such duties.
>and the effort to do these tasks is not generally substantial.

having just about completed a turn on nomcom, let me assure you that their 
life is not nearly so smooth and those "others" are not nearly so readily 
available.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 12 Feb 2002 21:10:07 -0800
Lines: 24
Sender: [email-masked]

D J Bernstein <[email-masked]> writes:

> The Pine people say that they use X-Sender/X-X-Sender because some
> unidentified mailing-list programs look at Sender/X-Sender. If this is
> true, what were the authors of those programs thinking?

It is true.  LISTSERV will use the Sender header in preference to the From
header as the address to perform actions on, to the degree that if you try
to subscribe to a LISTSERV mailing list and your mail has a Sender header,
it will add the contents of that header to the list, not your From header.

I don't know what they were thinking, but from discussions that I've had
with Eric Thomas, it was apparently entirely intentional and not due to
any sort of confusion over what the headers are for, and it's a decision
that he defended with some degree of heat.

I've not used a LISTSERV list again with a Sender header; after that
extremely frustrating and unfruitful exchange with him, I turned off
generation of the Sender header in Gnus (which is similarly using it as a
mostly broken security feature).  I don't know if, despite that exchange,
it was later fixed.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Date: Tue, 12 Feb 2002 22:52:23 -0500
Sender: [email-masked]

> area directors are already vastly overburdended.  and the effort to do the
> task you are assigning is substantial.

area directors routinely designate others to perform such duties.
and the effort to do these tasks is not generally substantial.

Keith

From: Keith Moore <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Keith Moore <[email-masked]>, "D. J. Bernstein" <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Tue, 12 Feb 2002 22:35:57 -0500
Sender: [email-masked]

> >> Let's try an example.
> >>
> >> Mail-Followup-To has found favor with the community. It saves time for
> >> users. There are several independent interoperable implementations.
> >
> > Mail-Followup-To is widely implemented, which I find unfortunate, because
> > it makes the reply problem even worse than it already was.
> 
> What would you suggest instead to improve the situation?

I will try to write an I-D about it before the Minneapolis meeting.

Keith

Date: 12 Feb 2002 20:44:51 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Barry Leiba writes:
> Now write a spec for the "Sender" header field.

http://cr.yp.to/immhf/sender.html covers the 822 syntax and semantics,
the 2822 syntax and semantics, and what programs do in practice. But
people should not have to do this much work before reserving a name.

> Some have capsized, and the Coast Guard is still unable to find any 
> survivors.

It would be interesting to understand how people managed to create the
current Sender situation.

RFC 822 4.4.2 makes Sender sound like the traditional secretary line in
memos. There are several examples of this later in the document. RFC 822
4.4.4 specifies Sender, defaulting to From, as the bounce target.

What was Crocker thinking? The envelope/message distinction was already
clear in SMTP. Why is Sender useful in a mail system that supports
envelope senders?

Pine and Eudora use Sender (or X-Sender or X-X-Sender) as a bogus
security mechanism, putting private login information into it and making
it difficult for novice users to change. What was Crispin thinking? What
were the Qualcomm people thinking?

The Pine people say that they use X-Sender/X-X-Sender because some
unidentified mailing-list programs look at Sender/X-Sender. If this is
true, what were the authors of those programs thinking?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

To: Keith Moore <[email-masked]>
Cc: "D. J. Bernstein" <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Feb 2002 20:33:32 +0100
Lines: 36
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Let's try an example.
>> 
>> Mail-Followup-To has found favor with the community. It saves time for
>> users. There are several independent interoperable implementations.
>
> Mail-Followup-To is widely implemented, which I find unfortunate, because
> it makes the reply problem even worse than it already was.

What would you suggest instead to improve the situation?

The facilities for directing respones to messages in RFC 2822 is not
sufficient for some common uses, and MFT makes a shot at solving this
need.  If there are problems with MFT, they aren't addressed because
there is no standardisation work going on.

>> Am I saying that Mail-Followup-To should be standardized without review?
>> No. I'm simply saying that the name should be reserved, so that there's
>> no risk of the Mail-Followup-To deployment bumping into something else.
>
> I personally think Mail-Followup-To is a Bad Idea.  But I also think 
> that this specific field is worth documenting in a registry - because 
> there are enough implementations that support it that people need to 
> know what it is, and so that nobody else will choose the same name for
> a different purpose.  
>
> I wouldn't object to registering Mail-Followup-To *provided* the 
> registration process required community review.

Documenting current practice (which is in wide use) in a Informational
RFC would be a first step.  The community can review it and either
suggest that it is moved onto the standards track, or if community
review of if specification proves that it is inadequate, the community
should propose a better solution that would go onto the standards
track. IMHO.

Date: Tue, 12 Feb 2002 13:30:12 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Paul Smith says...
> To me, a suitable spec would be something like:
>
> List-Unsubscribe
> -----------------
> Syntax:
>   List-Unsubscribe: "<"URL">"[,"<"URL">"]...
> where URL is the URL to go to to unsubscribe from the mailing list.
>
> Example
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
>
>
> That's it.

Sure, that's it for that one.
Now write a spec for the "Sender" header field.
Be sure to include when an MUA SHOULD include it, when it MUST, whether 
it ever MAY or MUST NOT.  Be sure to cover if and when it's OK for a 
mail submission server to add it on behalf of the MUA.  Be sure to 
include how it relates to the "From" and the "Reply-To" fields.  Be 
sure to relate it to mailing lists, as well as to regular e-mail.  Be 
sure to cover what the field is used for, and when it's appropriate to 
use "Sender" as the recipient of some sort of return message.  Be sure 
to make all this clear enough that no one gets it wrong when they 
implement it.

And then look at all the cases where it's been done wrong over the 
years (and understand why X-Sender exists).  Some fields are easy to 
explain, easy to implement right, and have been a smooth sail.

Some have capsized, and the Coast Guard is still unable to find any 
survivors.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 12 Feb 2002 08:54:10 -0800
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

At 05:09 PM 2/12/2002 +0100, Arnt Gulbrandsen wrote:
>Dave Crocker <[email-masked]>
> > Writing a spec that has one's name on it very much IS a barrier.
>
>Are you saying that you want anonymous specs, or that you want new header
>field names without associated specs?

neither.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Tue, 12 Feb 2002 16:44:32 +0000
To: Arnt Gulbrandsen <[email-masked]>, Dave Crocker <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

>Dave Crocker <[email-masked]>
> > Writing a spec that has one's name on it very much IS a barrier.
>
>Are you saying that you want anonymous specs, or that you want new header
>field names without associated specs?

Speaking as someone who's probably unqualified to talk here (as I've never 
tried to write an RFC), the mere thought of writing an RFC fills me with 
terror ;-)

Maybe that's what he's talking about. If I had the idea for a brand new 
wizzo header field (which I don't..) then I'd be much happier to write a 
'normal' spec, at least at the initial stage. You know, maybe half a page 
or so of 'normal' English to say what the header does, what the syntax is 
etc. This would be a lot less offputting that writing an 'RFC' style spec 
where you seem to need 30 pages of "pointless" stuff around the actual 
"meat" of the document just to put it in the "proper" format, with the fear 
that if you get it wrong you'll get the spec laughed out of court even 
though it might be a good idea, just not formatted properly.

Then, if the consensus is that it's a good idea, maybe either someone else, 
with more experience, will take on the task of writing the RFC style spec, 
or at least help the original person through the initial problems of 
writing the spec in the proper format.

To me, a suitable spec would be something like:

List-Unsubscribe
-----------------
Syntax:
  List-Unsubscribe: "<"URL">"[,"<"URL">"]...
where URL is the URL to go to to unsubscribe from the mailing list.

Example
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

That's it.
Now, maybe this isn't precise enough to please some people, but it'd 
certainly do for a start, and be a lot less frightening than the current 
requirements (see RFC2919 for the similar List-ID spec)

Anyway, that's my 2p.

> > repeat 10 times:  this is a registry, not a standards process.
>
>Yes? The latest draft I see requires that each new registration contains a
>"defining document". Old names seem to be grandfathered in by a host of
>references, although that isn't said explicitly.
>
>--Arnt

Date: Tue, 12 Feb 2002 17:43:32 +0100
To: "Jeff Stephenson" <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RE: Time to act: draft-klyne-msghdr-registry
Cc: <[email-masked]>
Sender: [email-masked]

At 11.08 -0800 02-02-11, Jeff Stephenson wrote:
>3) Merging the "normative" and "provisional" registries - queries based
>on the keyword in (2) would serve the purpose, and with a merged
>registry we have the option of seeing all known field names together.

I agree. Having a single registry, with an attribute on
each entry indicating its status, is easier to manage for
both IANA and the people who are going to look in the
registry. It also reduces the risk of mistakes, such as
putting a header name in the wrong registry or including
the same header name in both registries.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Tue, 12 Feb 2002 17:09:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> Writing a spec that has one's name on it very much IS a barrier.

Are you saying that you want anonymous specs, or that you want new header
field names without associated specs?

> repeat 10 times:  this is a registry, not a standards process.

Yes? The latest draft I see requires that each new registration contains a
"defining document". Old names seem to be grandfathered in by a host of
references, although that isn't said explicitly.

--Arnt

Date: Tue, 12 Feb 2002 07:46:03 -0800
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

At 03:55 PM 2/12/2002 +0100, Arnt Gulbrandsen wrote:
>We've had 30 years where the way to add a new name was to implement
>support for it and release new software, acts which requires quite a bit
>of thought. Certainly not something one tends to do frivolously.
>
>A registry without _any_ threshold might end up like alt.config. Having to
>write a spec, provide a forum for discussion and go through a two-week
>discussion (or wait two weeks for comments) isn't much of a barrier, but
>should be enough.

Writing a spec that has one's name on it very much IS a barrier.

> > It does not make sense to fix a problem that does not exist, and create
> > substantial extra work and delay?
>
>Agreed. But I think "write spec; set up mailing list; deal with comments"
>usually would be less work than "implement feature;

less work, perhaps, but that does not make it insufficient.

repeat 10 times:  this is a registry, not a standards process.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Tue, 12 Feb 2002 15:55:44 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> area directors are already vastly overburdended.  and the effort to do the 
> task you are assigning is substantial.
> 
> The requirement will also, therefore, cause substantial delay.

Good point. And I can't think of anyone else in a suitable role, so I
withdraw that.

> >I think striking the right balance's important: The burden should be big
> >enough to prevent most frivolous additions,
> 
> No.  We have had 30 years of unregulated header name availability.  Has 
> there been a problem with frivolous additions?

We've had 30 years where the way to add a new name was to implement
support for it and release new software, acts which requires quite a bit
of thought. Certainly not something one tends to do frivolously.

A registry without _any_ threshold might end up like alt.config. Having to
write a spec, provide a forum for discussion and go through a two-week
discussion (or wait two weeks for comments) isn't much of a barrier, but
should be enough.

> It does not make sense to fix a problem that does not exist, and create 
> substantial extra work and delay?

Agreed. But I think "write spec; set up mailing list; deal with comments"
usually would be less work than "implement feature; release new version"
was in the past. As long as it's substantially more than "make new
alt.fan.me.me.me newsgroup" I'm happy.

--Arnt

Date: Tue, 12 Feb 2002 06:16:14 -0800
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

At 10:44 AM 2/12/2002 +0100, Arnt Gulbrandsen wrote:

>Dave Crocker <[email-masked]>
> > that requirement imposes considerably more of a burden (and delay) than 
> you
> > appear to appreciate.
>
>Mind explaining?

area directors are already vastly overburdended.  and the effort to do the 
task you are assigning is substantial.

The requirement will also, therefore, cause substantial delay.

>I think striking the right balance's important: The burden should be big
>enough to prevent most frivolous additions,

No.  We have had 30 years of unregulated header name availability.  Has 
there been a problem with frivolous additions?

It does not make sense to fix a problem that does not exist, and create 
substantial extra work and delay?

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Tue, 12 Feb 2002 10:44:36 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> that requirement imposes considerably more of a burden (and delay) than you 
> appear to appreciate.

Mind explaining?

I think striking the right balance's important: The burden should be big
enough to prevent most frivolous additions, but not big enough to prevent
any serious, considered additions.

(And yes, I think that anything for which an implementer writes parsing
and generating code must be said to be serious and considered, whatever
its merits.)

--Arnt

To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 11 Feb 2002 23:57:51 -0800
Lines: 14
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:

> My own sense is that we have only one person with serious objections to
> this draft, but a substantial number of others who are in favor of it.

I've been convinced that I don't particularly care.  My argument has been
that I don't expect such a registry to be particularly useful, since it
occupies a no-man's land between a comprehensive registry and a
well-reviewed registry that I'm not sure will fill anyone's needs.  But I
could well be wrong, and regardless I don't see much harm coming out of it
other than a waste of people's time that they're volunteering.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry 
Date: Mon, 11 Feb 2002 20:48:46 -0500
Sender: [email-masked]

> ISOC/IAB/IESG/IETF/IANA/whatever is blatantly violating these rules when
> it gives authority to someone like Keith to declare that, for example,
> Mail-Followup-To shouldn't be implemented.

I can't imagine that I'd be asked to do the expert review for
message headers.  Even if I were asked, I wouldn't accept.  

So if that's what you're worried about, you can relax now.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 20:24:21 -0500
Sender: [email-masked]

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

that's pretty much what I had in mind.  publishing an I-D is a pretty
low-overhead mechanism, and it serves the purpose of making the draft
proposals accessible, and I don't see why we need a different mechanism.

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

seems like an over-statement.  I don't think it means anything more than
someone has made a proposal, and it's being reviewed.  certainly it's no
indication that the field will be widely deployed or that implementations
should have to deal with it (other than to ignore it, which is normal
behavior).
 
> >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. 

I don't think it's a huge change.  In other cases a WG that's defining
a new item in the reigstry still has to go through the procedure.  
e.g. if a WG defines a new content-type then the content-type still 
has to be reviewed by the normal process for content-types. (often
this is done long before the WG gets consensus on the work as a whole)
The review for the registry typically looks at different things than the 
WG review.  And when one WG does something that impacts another WG's 
work it's not at all unusual for IESG to tell the second WG to review 
the first WG's proposal.

> And they have publicly available specifications and
> publicy available mailing lists for those who want to be involved.

WGs tend to be narrowly-focused, but when a WG's work impacts the work
of other WGs, or of parties outside the WG's interest area, there is a
need for that WG's work to be reviewed outside the WG.  Sometimes this
happens because of explicit coordination between WGs, sometimes it 
happens during Last Call, sometimes it happens because IESG directs one
WG to review another's work.  But cross-group review is becoming more and
more important all the time.

Keith

Date: 12 Feb 2002 01:23:02 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Pete Resnick writes:
> In ASME v. Hydrolevel, the court held ASME liable for the FRAUDULENT 
> acts of one of its officers who acted FOR HIS OWN (or in this case, 
> his companies) BENEFIT within the scope of his authority.

It was an antitrust case, not a fraud case. The liability principles
are the same, as the Supreme Court explained in detail, but this doesn't
mean that you have to do something fraudulent to violate antitrust law.
(Price-fixing, for example, doesn't become legal when you do it openly.)

In 1971, the Federal Trade Commission sent a letter to ANSI explaining
the effect of antitrust law on standards organizations. There are
substantive rules: for example, ``construction standards'' must never be
used when ``performance standards'' can be developed. There are also
procedural rules: for example, organizations must provide due process,
including ``timely hearings with prompt decisions.''

In 1998, the FTC chairman publicly emphasized the importance of ``clear,
fair procedures'' to help standards organizations avoid mistakes, to
force ``the presentation of valid reasons for any potentially
anticompetitive activity,'' and to ``provide an antitrust tribunal with
a record.'' In other words, the decisions not only have to be justified,
but also have to be documented so that judges can _see_ that they were
justified.

ISOC/IAB/IESG/IETF/IANA/whatever is blatantly violating these rules when
it gives authority to someone like Keith to declare that, for example,
Mail-Followup-To shouldn't be implemented. In a legitimate standards
organization such as ANSI, _nobody_ has that much power.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

From: Keith Moore <[email-masked]>
To: "Jeff Stephenson" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 20:13:56 -0500
Sender: [email-masked]

> > either personally abusive, or misleading field names that say
> > one thing but mean another (like the titles of bills in the
> > US Congress), or frivolous proposals.
> 
> Personally abusive field names are unlikely to have any interest or
> relevance for other implementers, but that is not the case for field
> names that some of us may find "frivolous" or misleading.  For example,
> the fact that the field name misrepresents the use of the field doesn't
> mean that a deployed instance of that field is not out there; 

If the instance of the field is "out there" (i.e. in wide deployment)
then I agree that it's useful to document it.  However I don't think
many implementors would propagate an abusive or frivolous or misleading 
field anyway.  My reason for the expert being able to exclude 
abusive/misleading/frivolous fields is mostly to keep completely useless 
garbage out of the registry, and to keep people from having to review it.

> IMO, misrepresented fields are even *more*
> important to have in a registry so that the rest of us can know what's
> going on.  

For a field that was widely deployed, I'd agree with you.  But again,
I think there are somewhat conflicting goals here - one being to
document things that are already deployed so that implementors will 
know about them, and the other being to encourage documentation 
and review of new proposals.  For the abusive/frivolous/misleading
field, I'm thinking in terms of the "review new proposals" process, 
not the "document widely-deployed practice" process, and I think these 
are best treated as separate cases.

> Except for personally abusive names, I think that opinions of
> the field should only be noted in the registry and should not enter into
> whether the decision as to whether the field gets registered.

Well, I think the category probably needs to be broader than just 
personally abusive names, but I won't try to nail it down precisely.  
Personally, I'm willing to trust the designated expert to make such 
a determination, with an appeals process to keep the expert honest.

> > well, I've suggested that registrations could be marked with a
> > "waiting for review" placeholder before review, so they would
> > appear in the registry - just as long as we get a prompt review.
> 
> I agree that one of the keyword/status values should be "unreviewed", so
> that the indeterminate usefulness of the field is emphasized.  However I
> think the next step for a bad field idea should be either "in revision"
> or "don't implement", not deregistration of the field.

I think it's perfectly reasonable to "de-register" a field that is proposed
but doesn't get any significant deployment.  Lots of internet-drafts get
written that never amount to anything - because they don't attract enugh
support or people find a better way to do the same thing.  I assume that 
lots of extension header fields will get proposed that don't amount to
anything either.  Why clutter the registry with them?

> > I just think that putting
> > a field in a registry without getting prompt review will do
> > more harm than good.
> 
> I agree that prompt review is a good thing.  I disagree that a
> non-reviewed field is a problem - it should simply be marked as
> non-reviewed.

I don't mind "non-reviewed" status as long as the time during which
it can appear is no more than a few weeks.  After that the status needs
to change to something more meaningful.

Keith

Date: Mon, 11 Feb 2002 14:30:23 -0800
To: Arnt Gulbrandsen <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Cc: [email-masked]
Sender: [email-masked]

At 09:58 PM 2/11/2002 +0100, Arnt Gulbrandsen wrote:
>For example: a two-week delay in registration; if there isn't agreement on
>the wording, a note about that has to go in; the IETF AD or a designated
>expert can add a comment such as "don't implemenent"...

that requirement imposes considerably more of a burden (and delay) than you 
appear to appreciate.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Mon, 11 Feb 2002 16:23:15 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

On 2/11/02 at 9:29 PM +0000, D. J. Bernstein wrote:

>Arnt Gulbrandsen writes:
>>the IETF AD or a designated expert can add a comment such as "don't 
>>implemenent"...
>
>So the AD can say such a thing without community consensus?

No, they ought not, and if they do, they ought to be held accountable 
for it. (They don't have to start a brand new discussion every time 
they need to judge that consensus, but if they don't, they better 
judge correctly.) Failure to get community consensus or to judge it 
wrongly should result in appeal of their decision and eventual 
removal from their position if they do it regularly.

>If ISOC, IAB, IESG, IANA, et al. allow their names to be attached to 
>such statements, they will be held liable under United States 
>antitrust law for anticompetitive effects of those statements. See
>
>    http://caselaw.findlaw.com/cgi-bin/getcase.pl?court=US&vol=456&invol=556
>
>for a Supreme Court decision imposing liability upon an engineering 
>standards organization for giving subcommittee chairs authority to 
>make such statements. The organization ended up paying $4.75 million.

In ASME v. Hydrolevel, the court held ASME liable for the FRAUDULENT 
acts of one of its officers who acted FOR HIS OWN (or in this case, 
his companies) BENEFIT within the scope of his authority. And yes, if 
an ISOC, IAB, IESG, IANA, et. al. member makes a FRAUDULENT statement 
FOR THEIR OWN BENEFIT for an anticompetitive purpose, they (and the 
IETF) might well be held liable for such an action. (Given who was in 
the majority and dissent in that case in that case and the current 
makeup of the court, there might be some question about whether they 
would be held liable, but if they still believe in stare decisis...) 
In any event, I see no reason to believe that the sorts of statements 
we currently see from the IESG and other members of the IETF, 
especially from the likes of Keith, have much of a chance of falling 
under the constraints of the case you cited.

BTW: I am not a lawyer, but you can take the above opinions in light 
of the obscene number of such people in my family and the intro 
constitutional law class I took almost 20 years ago (just about when 
that decision was handed down from the court).
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:1042
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Mon, 11 Feb 2002 21:41:39 GMT
Lines: 75
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> 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: [email-masked]      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

content-class: urn:content-classes:message
Subject: RE: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 13:47:00 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Monday, February 11, 2002 11:42 AM

> either personally abusive, or misleading field names that say 
> one thing but mean another (like the titles of bills in the
> US Congress), or frivolous proposals.

Personally abusive field names are unlikely to have any interest or
relevance for other implementers, but that is not the case for field
names that some of us may find "frivolous" or misleading.  For example,
the fact that the field name misrepresents the use of the field doesn't
mean that a deployed instance of that field is not out there; when
Congress passes a misrepresented bill, it's the law of the land,
misrepresentation or no.  IMO, misrepresented fields are even *more*
important to have in a registry so that the rest of us can know what's
going on.  Except for personally abusive names, I think that opinions of
the field should only be noted in the registry and should not enter into
whether the decision as to whether the field gets registered.

> well, I've suggested that registrations could be marked with a 
> "waiting for review" placeholder before review, so they would 
> appear in the registry - just as long as we get a prompt review.

I agree that one of the keyword/status values should be "unreviewed", so
that the indeterminate usefulness of the field is emphasized.  However I
think the next step for a bad field idea should be either "in revision"
or "don't implement", not deregistration of the field.
 
> I just think that putting 
> a field in a registry without getting prompt review will do 
> more harm than good.

I agree that prompt review is a good thing.  I disagree that a
non-reviewed field is a problem - it should simply be marked as
non-reviewed.

-- jeff

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 16:37:42 -0500
Sender: [email-masked]

> Let's try an example.
> 
> Mail-Followup-To has found favor with the community. It saves time for
> users. There are several independent interoperable implementations.

Mail-Followup-To is widely implemented, which I find unfortunate, because
it makes the reply problem even worse than it already was.
 
> In the IETF, however, publication of an experimental Mail-Followup-To
> spec was blocked by a small group of people who refuse to admit that
> mail clients have separate reply and followup features. 

This is not an accurate characterization of what happened.

> Presumably the
> same people would also be in charge of an IETF field-name registry.

That the same people would be in charge now as then seems unlikely to 
me, because people tend to rotate out of positions of responsibility
in a few years' time.  That doesn't mean the result would be different.

> Am I saying that Mail-Followup-To should be standardized without review?
> No. I'm simply saying that the name should be reserved, so that there's
> no risk of the Mail-Followup-To deployment bumping into something else.

I personally think Mail-Followup-To is a Bad Idea.  But I also think 
that this specific field is worth documenting in a registry - because 
there are enough implementations that support it that people need to 
know what it is, and so that nobody else will choose the same name for
a different purpose.  

I wouldn't object to registering Mail-Followup-To *provided* the 
registration process required community review.

Keith

Date: 11 Feb 2002 21:29:59 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Arnt Gulbrandsen writes:
> the IETF AD or a designated expert can add a comment such as "don't
> implemenent"...

So the AD can say such a thing without community consensus?

If ISOC, IAB, IESG, IANA, et al. allow their names to be attached to
such statements, they will be held liable under United States antitrust
law for anticompetitive effects of those statements. See

   http://caselaw.findlaw.com/cgi-bin/getcase.pl?court=US&vol=456&invol=556

for a Supreme Court decision imposing liability upon an engineering
standards organization for giving subcommittee chairs authority to make
such statements. The organization ended up paying $4.75 million.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: 11 Feb 2002 20:43:03 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> If people don't want their proposals reviewed by the community because
> they are afraid that their ideas won't find favor, I have no sympathy
> with them.

Let's try an example.

Mail-Followup-To has found favor with the community. It saves time for
users. There are several independent interoperable implementations.

In the IETF, however, publication of an experimental Mail-Followup-To
spec was blocked by a small group of people who refuse to admit that
mail clients have separate reply and followup features. Presumably the
same people would also be in charge of an IETF field-name registry.

There are several problems here:

   * The IETF ``leadership'' does a poor job of representing the
     community. IETF doesn't have mechanisms for the community to
     override decisions made by people like Keith.

   * Control is being applied prematurely. Keith doesn't want to allow
     an experiment and then make an informed decision; he wants to kill
     the experiment before it happens.

   * IETF review is painfully slow; it certainly doesn't happen on
     ``Internet time.'' Consider, again, the case of Internet
     telephones, where IETF _still_ hasn't finished SIP.

Am I saying that Mail-Followup-To should be standardized without review?
No. I'm simply saying that the name should be reserved, so that there's
no risk of the Mail-Followup-To deployment bumping into something else.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Mon, 11 Feb 2002 21:58:59 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Dave Crocker <[email-masked]>
> My own sense is that we have only one person with serious objections to 
> this draft, but a substantial number of others who are in favor of it.

Keith has objections in principle, but the eventual wording he can live
with doesn't seem far removed from what the rest of you can.

For example: a two-week delay in registration; if there isn't agreement on
the wording, a note about that has to go in; the IETF AD or a designated
expert can add a comment such as "don't implemenent"...

--Arnt

From: Keith Moore <[email-masked]>
To: "Jeff Stephenson" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 14:41:48 -0500
Sender: [email-masked]

> > -----Original Message-----
> > From: Keith Moore [mailto:[email-masked]]
> > Sent: Monday, February 11, 2002 10:12 AM
> >
> > ... however we may disagree about how "light-weight" the
> > registration should be.
> >  I still want to see a brief review period, with community
> > input, before registration is accepted, and I want to have
> > the possibility for the registration to be deined - especially
> > if it's abusive or misleading.  I think that will work better
> > than automatically accepting whatever extensions are proposed.
> 
> I think the default action should be to register a field, with
> provisions for de-registering abusive ones (assuming you mean personally
> abusive, like "So-and-so-is-a-doofus: Yes").  

either personally abusive, or misleading field names that say one thing 
but mean another (like the titles of bills in the US Congress), or 
frivolous proposals.

> The reality is that
> refusing to register a field does not mean that it won't be deployed, it
> just means that there is no place for me, as an implementer, to find out
> anything about that header when I encounter it.  

well, I've suggested that registrations could be marked with a 
"waiting for review" placeholder before review, so they would 
appear in the registry - just as long as we get a prompt review.

but if the review time is (for most purposes) bounded to 2 to 4 weeks, 
are we really worried about race conditions during that window?

> I don't think a
> registration should ever be revoked just because it's a bad idea - if
> it's out there, it's out there and I want to know that I'd better not
> use the name "FooBar" for a field because there's already some dumb UA
> using that name in a totally stupid manner and who knows what will
> happen to my UA if it ever receives one of its messages.

that much sounds reasonable.  

> The registry is not, IMO, about approval - it is about notifying the
> Internet community of a field and making information about it readily
> available.  That information should include the community's assessment
> of the value/danger of the field, but we should not refuse registration
> just because a field is deemed dangerous.  We should, in fact,
> *encourage* it because the registration provides a forum for the
> community to warn about the dangers of the field (assuming we can't
> influence it to make it non-dangerous).
 
I agree with the above sentiment.  I just think that putting a field in
a registry without getting prompt review will do more harm than good.

Keith

content-class: urn:content-classes:message
Subject: RE: Time to act: draft-klyne-msghdr-registry
Date: Mon, 11 Feb 2002 11:08:58 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]] 
> Sent: Monday, February 11, 2002 10:11 AM
> 
> Can we please obtain a firm sense of whether this is correct, 
> so that we can move the draft on to be implemented?

I'm for moving the draft forward, though I think there are some issues
that should be addressed in it that have been discussed previously:

1) Inclusion of a community assessment note for each field, and the
process by which that note is determined.
2) Inclusion of a community assessment keyword, based on (1), that can
be used in queries against the registry.
3) Merging the "normative" and "provisional" registries - queries based
on the keyword in (2) would serve the purpose, and with a merged
registry we have the option of seeing all known field names together.

-- jeff

content-class: urn:content-classes:message
Subject: RE: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 10:44:11 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Monday, February 11, 2002 10:12 AM
>
> ... however we may disagree about how "light-weight" the 
> registration should be. 
>  I still want to see a brief review period, with community 
> input, before registration is accepted, and I want to have
> the possibility for the registration to be deined - especially
> if it's abusive or misleading.  I think that will work better
> than automatically accepting whatever extensions are proposed.

I think the default action should be to register a field, with
provisions for de-registering abusive ones (assuming you mean personally
abusive, like "So-and-so-is-a-doofus: Yes").  The reality is that
refusing to register a field does not mean that it won't be deployed, it
just means that there is no place for me, as an implementer, to find out
anything about that header when I encounter it.  I don't think a
registration should ever be revoked just because it's a bad idea - if
it's out there, it's out there and I want to know that I'd better not
use the name "FooBar" for a field because there's already some dumb UA
using that name in a totally stupid manner and who knows what will
happen to my UA if it ever receives one of its messages.

The registry is not, IMO, about approval - it is about notifying the
Internet community of a field and making information about it readily
available.  That information should include the community's assessment
of the value/danger of the field, but we should not refuse registration
just because a field is deemed dangerous.  We should, in fact,
*encourage* it because the registration provides a forum for the
community to warn about the dangers of the field (assuming we can't
influence it to make it non-dangerous).

-- jeff

From: Keith Moore <[email-masked]>
To: "Jeff Stephenson" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 13:12:06 -0500
Sender: [email-masked]

> On the other hand, if we allow light-weight registration (requiring a
> minimal spec and a discussion forum), we might find out early on when
> someone is intending to deploy a new field.

this is actually what I have in mind.  however we may disagree about
how "light-weight" the registration should be.  I still want to see
a brief review period, with community input, before registration is 
accepted, and I want to have the possibility for the registration to 
be deined - especially if it's abusive or misleading.  I think that 
will work better than automatically accepting whatever extensions are
proposed.

in other words, I believe "light-weight" is good - up to a point.
but there is also such a thing as "too light-weight".

Keith

Date: Mon, 11 Feb 2002 10:09:16 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:01 PM 2/11/2002 -0500, Keith Moore wrote:
> > 1.  You need to learn a little bit about tradeoffs between individual and
> > group decision making.
>
>I've had quite a lot of opportunity to observe it for myself, thank you.

In that case, you need to learn a bit about asserting behavioral 
generalizations based on individual experience.  The quick summary is that, 
at best, it is nearly useless.

Start with the construct of sampling error.

And, by the way, you appear to be confusing the difference between design 
by committee and review by committee.

> > 2.  Extending your logic means that we take away all individuals
> > rights.  Unless an action is approved by the majority -- and hence the term
> > "tyranny of the majority" -- then it is to be prohibited.
>
>You and I both know that the IETF doesn't work that way.

We are not talking about an IETF standards process.  We are talking about a 
label registration process.  They are different, though you do not want 
them to be.

> > >Yes they do.  But most protocols don't allow arbitrary extensions from
> > >other parties.
> >
> > Yes, I've noted this rather peculiar line of concern from you.  It seems to
> > suggest that cooperation among consenting hosts is not to be permitted
> > unless it has IETF approval.  Hence my term "parental".
>
>Protocols are carefully constructed ...

Keith, many thanks for the tutorial about the nature and requirements for 
protocol construction.

It was, of course, irrelevant to the question of permitting consenting 
hosts to use a public registration venue for mechanisms for that are not 
(yet) standardized.

> > If registration requires citation of a specification, then community review
> > is inherent.
>
>No it's not.  Few people will bother reviewing a specification when it
>is first introduced unless there is some chance that their review will
>do some good.

Keith, you keep inventing new requirements or concerns.  The more 
requirements you add, such as early review, the more it is made 
compellingly clear that you want a full standards process.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Mon, 11 Feb 2002 10:10:47 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Time to act: draft-klyne-msghdr-registry
Sender: [email-masked]

Folks,

My own sense is that we have only one person with serious objections to 
this draft, but a substantial number of others who are in favor of it.

Can we please obtain a firm sense of whether this is correct, so that we 
can move the draft on to be implemented?

Thanks.

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 13:08:39 -0500
Sender: [email-masked]

> >  > Would you accept registration of "no consensus" where a header
> >>  name is registered together with the different views on how this
> >>  header should be used or not used?
> >
> >I think that would be necessary.  It's better to say "no consensus"
> >than to recommend or discourage when no consensus exists.   Ideally
> >in that case there would be some summary of the various positions.
> >But the process needs to encourage consensus, with the statement of
> >differing opinions used only as a last resort.
> 
> Would you agree that "Reply-To" should be registered as
> "no consensus" in the registry?

I presume there was consensus on "reply-to" when 822 was defined.

if we took the trouble to gauge consensus today,
I wouldn't be surprised to find that "no consensus" were the case.

Keith

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 13:01:15 -0500
Sender: [email-masked]

> At 12:32 PM 2/11/2002 -0500, Keith Moore wrote:
> > > it means that there is control being imposed, with the claimed basis that
> > > those imposing the control have superior ability to judge appropriateness.
> >
> >In fact, I do believe that the judgment of the community is usually
> >superior to the judgment of individuals.
> 
> 1.  You need to learn a little bit about tradeoffs between individual and
> group decision making.

I've had quite a lot of opportunity to observe it for myself, thank you.

> 2.  Extending your logic means that we take away all individuals
> rights.  Unless an action is approved by the majority -- and hence the term
> "tyranny of the majority" -- then it is to be prohibited.

You and I both know that the IETF doesn't work that way.  "rough consensus" 
is different than majority rule, and there's usually considerable incentive 
to work toward a consensus.

> > > The problems WITHOUT the control are theoretical and based on fear without
> > > serious empirical foundation.
> >
> >My opinions are based on experience and judgment.  I assume your opinions
> >are based on your experience and judgment.  Neither of us can cite 'serious
> >empirical foundation' for our positions.
> 
> The detrimental effect of prohibiting easy coordination through open
> registration is an essentially mathematical fact.

No it's not, because the applicability of any math that you'd cite
(if you actually cited any) to this case would still be open to question.
 
> The dangers you cite, by contrast, are NOT based on actual experience,
> contrary to your claims.  Their only substance is fear.

I respectfully disagree.  And your opinion of my experience or motivation
is of considerably less value than your opinion about protocol extension
mechanisms that is based on your own experience and judgment.

> > > The IETF's "own protocols" already cite the heck out of work from
> > elsewhere.
> >
> >Yes they do.  But most protocols don't allow arbitrary extensions from
> >other parties.
> 
> Yes, I've noted this rather peculiar line of concern from you.  It seems to
> suggest that cooperation among consenting hosts is not to be permitted
> unless it has IETF approval.  Hence my term "parental".

Protocols are carefully constructed agreements about how to communicate.  
The care that is taken in construction of those protocols reflects a 
widely-held belief that proper functioning of the application requires
attention to a variety of concerns.  The balance that is struck between
these concerns when the protocol is designed can easily be upset. 
For this reason, the designers of a protocol quite often exercise as
much care in choosing an extension mechanism as they exercise in the
rest of that protocol design.  Often the specified mechanism requires
that the proposed extension be reviewed by the community of experts
that defined the initial protocol. 
 
> >p.s. If people don't want their proposals reviewed by the community because
> >they are afraid that their ideas won't find favor,
> 
> If registration requires citation of a specification, then community review
> is inherent.  

No it's not.  Few people will bother reviewing a specification when it
is first introduced unless there is some chance that their review will
do some good.  And without some requirement for review and response
to substantive comments prior to acceptance of a specification, few
submitters will bother to refine their specifications in light of such
review as does occur.

Keith

Date: Mon, 11 Feb 2002 09:44:39 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:32 PM 2/11/2002 -0500, Keith Moore wrote:
> > it means that there is control being imposed, with the claimed basis that
> > those imposing the control have superior ability to judge appropriateness.
>
>In fact, I do believe that the judgement of the community is usually
>superior to the judgement of individuals.

1.  You need to learn a little bit about tradeoffs between individual and 
group decision making.

2.  Extending your logic means that we take away all individuals 
rights.  Unless an action is approved by the majority -- and hence the term 
"tyranny of the majority" -- then it is to be prohibited.

> > The problems WITHOUT the control are theoretical and based on fear without
> > serious empirical foundation.
>
>My opinions are based on experience and judgement.  I assume your opinions
>are based on your experience and judgement.  Neither of us can cite 'serious
>empirical foundation' for our positions.

The detrimental effect of prohibiting easy coordination through open 
registration is an essentially mathematical fact.

The dangers you cite, by contrast, are NOT based on actual experience, 
contrary to your claims.  Their only substance is fear.

> > The IETF's "own protocols" already cite the heck out of work from 
> elsewhere.
>
>Yes they do.  But most protocols don't allow arbitrary extensions from
>other parties.

Yes, I've noted this rather peculiar line of concern from you.  It seems to 
suggest that cooperation among consenting hosts is not to be permitted 
unless it has IETF approval.  Hence my term "parental".

>p.s. If people don't want their proposals reviewed by the community because
>they are afraid that their ideas won't find favor,

If registration requires citation of a specification, then community review 
is inherent.  You are confusing review with approval.  You want to require 
prior community approval.  Both the control and its timing are entirely 
unecessary for this registration mechanism.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

content-class: urn:content-classes:message
Subject: RE: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 09:39:24 -0800
From: "Jeff Stephenson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Monday, February 11, 2002 6:16 AM
> 
> But I don't think a registry is likely to decrease the use
> of bad fields unless review happens before registration
> (else, how do we determine that they are bad?).

I disagree.  If we throw up barriers to registration of a field, people
will simply go off and deploy the field on their own (as is evidenced by
looking at the headers in virtually any message).  If someone else sees
the field, thinks it's useful, and wants to interoperate with that UA,
they'll then try and implement it themselves, perhaps botching the
reverse-engineering of an already ill-advised field.  Nobody has input,
nobody has responsibility, nobody has a spec - what we have is a mess.

On the other hand, if we allow light-weight registration (requiring a
minimal spec and a discussion forum), we might find out early on when
someone is intending to deploy a new field.  We now have input (on the
discussion forum), responsibility (the person who submitted the
registration), and a (perhaps minimal) spec.  The community's power of
persuasion can now be brought to bear, working with the submitter to
either modify or scrap the field.  If the community consensus is that
the field is a bad idea and the submitter cannot be persuaded to either
modify or remove the registration, the headers is marked in the registry
as "discouraged".  In that case, there is at least an explanation of the
field for anyone encountering it and and explanation of why the
community discourages its deployment.

Think of the registry as similar to the "honey-pots" used to detect
hackers - it gives you a heads-up, and the opportunity to deal with the
issue before you're blind-sided.

-- jeff

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 12:32:42 -0500
Sender: [email-masked]

> At 10:55 AM 2/11/2002 -0500, Keith Moore wrote:
> > > Having the "parent" be a group does not change the model or the problems
> > > with it.
> >
> >Your use of the word 'parental' could be misleading, because it imples
> >that the 'parents' are somehow superior to the person submitting the
> >proposal,
> 
> it means that there is control being imposed, with the claimed basis that
> those imposing the control have superior ability to judge appropriateness.

In fact, I do believe that the judgement of the community is usually
superior to the judgement of individuals.  Particularly when the subject
being discussed is a protocol for communication that is used by, and
affects, an extremely diverse set of interests.
 
> >There are problems with any model.  I think there are fewer problems
> >with a model for extensions that requires community review,
> 
> The problems WITHOUT the control are theoretical and based on fear without
> serious empirical foundation.

My opinions are based on experience and judgement.  I assume your opinions 
are based on your experience and judgement.  Neither of us can cite 'serious
empirical foundation' for our positions.  

> The IETF's "own protocols" already cite the heck out of work from elsewhere.

Yes they do.  But most protocols don't allow arbitrary extensions from 
other parties.  The review and the publication of those extensions
is generally expected to happen in IETF.

Keith

p.s. If people don't want their proposals reviewed by the community because
they are afraid that their ideas won't find favor, I have no sympathy with 
them.  But if people don't want to deal with personal attacks and baseless 
accusations, frankly, I wouldn't blame them.  

So if we want to streamline the process by which we can approve new 
protocols or protocol extensions, in my opinion, the most effective 
thing we could do is to curtail those personal attacks.

Date: Mon, 11 Feb 2002 17:27:45 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 09.55 -0500 02-02-11, Keith Moore wrote:
>  > Would you accept registration of "no consensus" where a header
>>  name is registered together with the different views on how this
>>  header should be used or not used?
>
>I think that would be necessary.  It's better to say "no consensus"
>than to recommend or discourage when no consensus exists.   Ideally
>in that case there would be some summary of the various positions. 
>But the process needs to encourage consensus, with the statement of
>differing opinions used only as a last resort.

Would you agree that "Reply-To" should be registered as
"no consensus" in the registry?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 11 Feb 2002 08:09:01 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: [email-masked]
Sender: [email-masked]

At 10:55 AM 2/11/2002 -0500, Keith Moore wrote:
> > Having the "parent" be a group does not change the model or the problems
> > with it.
>
>Your use of the word 'parental' could be misleading, because it imples
>that the 'parents' are somehow superior to the person submitting the
>proposal,

it means that there is control being imposed, with the claimed basis that 
those imposing the control have superior ability to judge appropriateness.

>There are problems with any model.  I think there are fewer problems
>with a model for extensions that requires community review,

The problems WITHOUT the control are theoretical and based on fear without 
serious empirical foundation.

The problem WITH the control is that it hurts innovation.  Internet 
innovation that includes (multi-vendor) interoperability requires easy, 
public registration of interoperability information.  This has been 
explained repeatedly.

> > At 09:55 AM 2/11/2002 -0500, Keith Moore wrote:
> > The world has multiple venues for publication of Internet
> > specifications.  The only concern for publication venue should be
> > reliability of long-term access.
>
>Standards organizations tend to respect one another's wishes about
>extending another organization's protocols.  IETF tends to want to
>control extensions to its own protocols.

Next you will have us all required to be exactly the length of a particular 
bed.

The IETF's "own protocols" already cite the heck out of work from elsewhere.

Keith, let's stop this ethnocentric perspective on things.  It is seriously 
counter-productive.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 10:55:19 -0500
Sender: [email-masked]

> > > To repeat, the real debate here is about parental controls on
> > > registrations,
> >
> >What I had in mind was a consensus model with a designated expert
> >making the final call.
> 
> Having the "parent" be a group does not change the model or the problems
> with it.

Your use of the word 'parental' could be misleading, because it imples
that the 'parents' are somehow superior to the person submitting the
proposal, and that there are a small number of 'parents'.  That's not
what is being proposed.

There are problems with any model.  I think there are fewer problems
with a model for extensions that requires community review, than with
one that doesn't require any review.
 
> At 09:55 AM 2/11/2002 -0500, Keith Moore wrote:
> >I think that specs for new header fields should be published as RFCs.
> 
> The world has multiple venues for publication of Internet
> specifications.  The only concern for publication venue should be
> reliability of long-term access.

Standards organizations tend to respect one another's wishes about
extending another organization's protocols.  IETF tends to want to
control extensions to its own protocols.

Keith

Date: Mon, 11 Feb 2002 07:35:28 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: [email-masked]
Sender: [email-masked]

At 09:21 AM 2/11/2002 -0500, Keith Moore wrote:
> > To repeat, the real debate here is about parental controls on
> > registrations,
>
>What I had in mind was a consensus model with a designated expert
>making the final call.

Having the "parent" be a group does not change the model or the problems 
with it.

At 09:55 AM 2/11/2002 -0500, Keith Moore wrote:
>I think that specs for new header fields should be published as RFCs.

The world has multiple venues for publication of Internet 
specifications.  The only concern for publication venue should be 
reliability of long-term access.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 09:55:25 -0500
Sender: [email-masked]

> >I have also tried to suggest a 'middle ground' which would allow
> >easier and faster registration of extensions while still providing
> >community review.   While I'm not entirely comfortable with this
> >proposal, I do accept that it can take a long time to get an RFC
> >published, and that this can be a barrier to deployment of useful
> >new features.  We've had some success with other 'expedited review'
> >processes for other kinds of protocol extensions (charsets,
> >content-types), and I what I proposed is similar to those mechanisms.
> 
> If no RFC is published, where would the specification of the
> new header name be stored? It should be easily accessible
> to anyone. Can it be stored in the header name registry itself?

I think that specs for new header fields should be published as RFCs.
 
> Would you accept registrations of "warning signs" of header names
> not recommended (with explanation of why)?

Hmmm.  If someone tries to register a field and there is consensus 
that its use should be discouraged, I have no problem with that.  If
someone tries to register a field because he wants to discourage
its use, I think we still need consensus that the use of the field
should be discouraged before we put that in the registry.  I don't 
want the registry to make any recommendations purely on advice of the 
person who submits a registration.
 
> Would you accept registration of "no consensus" where a header
> name is registered together with the different views on how this
> header should be used or not used?

I think that would be necessary.  It's better to say "no consensus" 
than to recommend or discourage when no consensus exists.   Ideally
in that case there would be some summary of the various positions.  
But the process needs to encourage consensus, with the statement of
differing opinions used only as a last resort.

Keith

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 09:21:14 -0500
Sender: [email-masked]

> To repeat, the real debate here is about parental controls on
> registrations, 

What I had in mind was a consensus model with a designated expert 
making the final call.

Keith

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 11 Feb 2002 09:15:32 -0500
Sender: [email-masked]

> You have thus far given no demonstration that a registry would in any
> way increase the number of UAs using bad fields. I have given (IMHO)
> a cogent argument, based on historical practice, that a registry
> would *decrease* such occurrences.

I agree that a registry could serve to decrease use of bad fields.
But I don't think a registry is likely to decrease the use of bad fields 
unless review happens before registration (else, how do we determine
that they are bad?). I don't think that we're likely to get good 
documentation either unless review is a part of the process.

> - When many current UAs get charsets they don't know about, they fall
> flat on their faces and show garbage to the user.
> 
> - When some current UAs get content-types they don't know about
> (especially subtypes), they fall flat on their faces and show garbage
> to the user, or fail to show the user anything.
> 
> - When all of the current UAs that I know of get a header field that
> they don't know about, they ignore it.
> 
> The first two cases are damaging to the current interoperation of
> Internet mail. They deserve the heightened scrutiny that they get.
> The present case is different and cannot in a reasonable way be
> compared to the first two. It deserves a far lower bar.

I'm not concerned about UA behavior in the presence of header fields
that the UA doesn't know about - as you say, the UA will generally
ignore such fields.  I'm far more concerned about UA implementation of
bad header fields because there was no review of those fields before
deployment.

Keith

Date: Mon, 11 Feb 2002 11:20:38 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 15.06 -0500 02-02-10, Keith Moore wrote:
>I have also tried to suggest a 'middle ground' which would allow
>easier and faster registration of extensions while still providing
>community review.   While I'm not entirely comfortable with this
>proposal, I do accept that it can take a long time to get an RFC
>published, and that this can be a barrier to deployment of useful
>new features.  We've had some success with other 'expedited review'
>processes for other kinds of protocol extensions (charsets,
>content-types), and I what I proposed is similar to those mechanisms.

If no RFC is published, where would the specification of the
new header name be stored? It should be easily accessible
to anyone. Can it be stored in the header name registry itself?

Would you accept registrations of "warning signs" of header names
not recommended (with explanation of why)?

Would you accept registration of "no consensus" where a header
name is registered together with the different views on how this
header should be used or not used?

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sun, 10 Feb 2002 19:33:12 -0800
To: Pete Resnick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

At 08:45 PM 2/10/2002 -0600, Pete Resnick wrote:
>You have thus far given no demonstration that a registry would in any way 
>increase the number of UAs using bad fields. I have given (IMHO) a cogent 
>argument, based on historical practice, that a registry would *decrease* 
>such occurrences.

Pete,

To repeat, the real debate here is about parental controls on 
registrations, to protect folks from coordinating on use of mechanisms that 
do not have approval from experts, versus an approach that simply wants to 
permit easy registration.

For those feeling the need to be parental, it does not matter whether the 
danger is real.  All that matters is that the fear is.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Sun, 10 Feb 2002 20:45:29 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

On 2/10/02 at 3:06 PM -0500, Keith Moore wrote:

>Over the past 10+ years I have seen several attempts by individuals 
>to introduce protocol extensions that would fundamentally change 
>some aspect of how the protocol works, compromise security or 
>privacy, or were so poorly done as to degrade interoperability - 
>often with some "success".

The only way this happens with the introduction of *new* header 
fields is when UAs start interpreting the new header field. UAs that 
do nothing with the new field (i.e., the currently installed base) 
can *not* be affected by the new header field. The only way in which 
a existing field would cause such problems is if more UAs start 
interpreting that field. Unlike other protocol extensions, header 
fields only have an effect on protocol operation, security, or 
privacy when UAs actually change.

You have thus far given no demonstration that a registry would in any 
way increase the number of UAs using bad fields. I have given (IMHO) 
a cogent argument, based on historical practice, that a registry 
would *decrease* such occurrences.

>We've had some success with other 'expedited review' processes for 
>other kinds of protocol extensions (charsets, content-types), and I 
>what I proposed is similar to those mechanisms.

Just to be clear:

- When many current UAs get charsets they don't know about, they fall 
flat on their faces and show garbage to the user.

- When some current UAs get content-types they don't know about 
(especially subtypes), they fall flat on their faces and show garbage 
to the user, or fail to show the user anything.

- When all of the current UAs that I know of get a header field that 
they don't know about, they ignore it.

The first two cases are damaging to the current interoperation of 
Internet mail. They deserve the heightened scrutiny that they get. 
The present case is different and cannot in a reasonable way be 
compared to the first two. It deserves a far lower bar.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 10 Feb 2002 20:01:40 -0500
Sender: [email-masked]

> The question here is simple: Can someone reserve and use a field name
> for a protocol extension that Keith doesn't like?
> 
> This is a yes-no question. Describing the two possible answers as
> ``extreme positions'' doesn't contribute to the discussion.

Nor does your attempt to cast the question in those terms.

But fwiw, for at least one other protocol that uses an extension 
mechanism similar to the one I proposed for header fields, there is 
an existence proof that a registration "that Keith doesn't like" 
can be accepted.  

(the specific example is the PIN NID for URNs, but there are probably 
others)

Keith

Date: 11 Feb 2002 00:27:23 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

The question here is simple: Can someone reserve and use a field name
for a protocol extension that Keith doesn't like?

This is a yes-no question. Describing the two possible answers as
``extreme positions'' doesn't contribute to the discussion.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 10 Feb 2002 19:00:41 -0500
Sender: [email-masked]

> In <[email-masked]> Keith Moore <[email-masked]> writes:
> 
> >What I currently have in mind is something like the following:
> 
> >1. have a template to request registration of a message header,
> >   much like the templates for content-types, charsets, or URN NIDs.
> 
> Actually no. People are too used to filling in Web Templates without
> thinking. But yes, there needs to be a clear list of what information needs
> to be provided; we want people to have to think about what they are doing
> (it's one of those "if you need to ask, then you should probably not be
> doing it" sort of things).

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.

> >   the template explains the information that is required in order
> >   to register a header field -  including the field name, the purpose 
> >   of the field, abnf syntax, security and privacy considerations, 
> >   the set of protocols for which the field is intended, etc.
> 
> No, that is the detail for the specification, and it is likely to change
> as the specification is developed. The only technical requirement should
> be a _pointer_ to the latest published spec (ideally an Internet-Draft -
> and they certainly change over time).

Okay, we've had people arguing that we needed to make it easy to register
things so that they would be documented and so that other people could
implement them; now you're saying that we can't expect a specification
to review before we put something in the registry.  

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.

> >2. have a single mailing list for public discussion of all 
> >   proposed message headers
> 
> No, not a single mailing list. A mailing list (or newsgroup or web forum)
> for that particular topic. Remember that we hope the principal customers
> for this facility will be IETF Working Groups, and they will not thank you
> for being forced to discuss the header off their own mailing lists.
> Moreover, I cannot think of a mailing list that would be competent to
> discuss headers for both email and HTTP.

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.

Also, since the header fields tend to leak between protocols, some 
cross-protocol review would also be useful.

I'm also very dubious about using newsgroup or web fora for discussion;
I see this as a good way to limit exposure.  Most people I know don't
read usenet anymore, and not many people are going to check a web page 
every few days for (if charset and content-type registrations are 
any indication) a new header field proposal that might arrive, on 
average, once every few months?

> >3. submission of the form causes an announcement to be sent to that
> >   list, opening discussion of that header field.
> 
> Ietf-822 would be a good place for announcements :-) .

maybe.  or maybe a separate list would be better.  

> >4. initial review takes place for a fixed period of time - say 2 
> >   or 4 weeks.
> 
> No, 2 or 4 days. The review is up to the mailing list (if it hasn't being
> reviewing it already). All we want initially is time for the "expert" to
> stop it, or insist on a disclaimer. or whatever we decide.

2 or 4 days isn't nearly enough.  Experts are busy people, and they can 
easily go for several days without having enough cycles to deal with 
things like this.  IMHO 2 weeks isn't really long enough.
 
> >5. at the end of the review period a designated expert makes one
> >   of a small number of recommendations:
> 
> >   - field is believed to be non-disruptive and okay for
> >     experimental use, or
> >   - field is insufficiently documented, or
> >   - revision based on review feedback is required, or
> >   - IETF consensus is required before this field can be registered
> 
> Essentially he either says 
>     1. this satisfies the requirements of having a specification and a
>        discussion forum
>     2. it does not conflict with other ongoing work
>     3. it has reached the stage where it would be useful to try using it
>        for real
> Or else he says
>     1. this is dumb/conflicts/is write-only or vanity/better left as X-
>     2. it should be stopped/require a disclaimer/be referred to IESG

I think we have very different levels of review in mind.  If the purpose
of registering a header field name is just to keep anyone else from 
using that field, then a level of review like you propose might be sufficient
(provided that a specification were forthcoming and that the registration
would "time out" if the specification were not stable and available within
a few weeks).  But if the purpose is making header specifications available 
so that other people can implement them, I don't think that level of 
review is anywhere nearly sufficient.

> >6. "in the wild" observations are maintained separately, and
> >   perhaps, automatically.  these are submitted via an emailed 
> >   web form. submission of the form causes an automatic reply
> >   to the email address that submitted the form; the sender must
> >   confirm sending the observation before it will be accepted.
> 
> If it exists in the wild without proper discussion/documentation, then
> someone needs to take it in hand, form a group to discuss it (or take it
> to an existing group), prepare a proper spec, and then apply for
> registration. All with a clear intent for an ultimate RFC and promotion to
> the "full" register.

Ideally, everything that is out there would be documented, complete
with an applicability statement (and perhaps a network-accessible 
oracle that could tell software to ignore or delete harmful fields).  

As a practical matter, somebody has to find time to research and document
those things, and for an applicability statement we need to get consensus,
and this is difficult and time consuming.  In my experience, most of the 
time required to do this is in doing the research and writing a clear
specification, not in dealing with the publication process.  A registry
like we're propsing won't help much, I'm afraid.

> >7. there also needs to be a process for commenting on existing 
> >   header fields and their applicability.  this might be as 
> >   simple as writing a BCP about the header field, but the
> >   information in that BCP needs to be reflected in the registry.
> 
> That is the public discussion forum mentioned above.
> 
> I would also add
> 
> 8. There needs to be a clear intent that the thing is to be taken forward
> towards an eventual RFC (standards/experimental/informational according to
> the nature of the beast), at which point it gets promoted to the "full"
> register. 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.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 10 Feb 2002 18:37:35 -0500
Sender: [email-masked]

> >Trying to return to a more polite tone:  notice this email has a Versions:
> >header, used by a set of mail tools I've been using on the Internet since
> >1990.
> 
> Interesting. It seems to be in direct competition with X-Mailer and
> User-Agent. All these are all loose in the "wild", though User-Agent has
> the advantage that is is already standarised for HTTP, and hopefully soon
> will be for Netnews.
> 
> And we are going to have the same problem with the various X-Priority and
> Precedence headers.

Where there are conflicts between current usage, or between current and
standard usages, I think we will need to sort these out via traditional
means of  RFC publication.  I think it will be difficult to sort these
things out with a review/registration process like we've been describing.

I also think it will be difficult for a "registry" (that is, any list 
of header fields) to explain how such a conflict is sorted out; particularly
if each of the different field names has a different syntax.  At most it 
can say "discouraged/deprecated in favor of XXXX; see RFC YYYY". 

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 10 Feb 2002 18:33:07 -0500
Sender: [email-masked]

> >I'm not ignoring it.  I'm categorically stating that:
> 
> Indeed you are.
> 
> And other people are categorically stating the exact opposite :-( .

Well, I'm not accusing them of ignoring me :)
 
> >No, correct syntax alone isn't sufficient.  The proposal must at least
> >appear to be sound and not harmful, and failure to address
> >security/privacy considerations is a frequent source of harm.
> >(cookies in HTTP, various frobs to request an automatic response in email)
> 
> Yes, but a registry is not the place to specify syntax or other technical
> details. That is what the indicated specification or the ongoing
> discussion is for. 

It seems to me that we're discussing a mechanism for defining extensions 
for certain protocols, for reserving the names used for those extensions,
and for making information about those names and extensions generally
available.  But because extensions can be disruptive or otherwise
harmful, in order to minimize the potential for harm it needs to have 
some degree of public review and oversight.   And a certain degree of
specification is needed for such review to be effective.

The fact that we've been using the word "registry" to refer to this 
extension mechanism doesn't change that; and the fact that we've been
using that word shouldn't compel us to choose an extension mechanism
that doesn't provide sufficient information with which to review
a proposal.

> Agreed that, at the time of registration, some degree
> of soundness and lack of harmfulness is needed. But that is just a matter
> of insisting that the initial specification is clear enough to permit
> experimental use in the wild, and that the forum proposed for its
> discussion is the most appropriate one (e.g. that there is not already
> another forum tackling the exact same problem).

I strongly disagree.  A clear specification does not prevent harm, and
potentially having a separate forum for each new header field will 
just diminish the effectiveness of community review.  At most there
should be one forum for each protocol (e.g. mail, news, and http),
and the proposal should be reviewed by the forum corresponding to the
protocol for which the extension is proposed.  But since header fields
tend to leak between protocols, I'd far prefer a single forum for 
discussion of all new proposals.

Keith

To: [email-masked]
Xref: clerew local.mime:1029
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 10 Feb 2002 16:14:33 GMT
Lines: 101
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>What I currently have in mind is something like the following:

>1. have a template to request registration of a message header,
>   much like the templates for content-types, charsets, or URN NIDs.

Actually no. People are too used to filling in Web Templates without
thinking. But yes, there needs to be a clear list of what information needs
to be provided; we want people to have to think about what they are doing
(it's one of those "if you need to ask, then you should probably not be
doing it" sort of things).

>   the template explains the information that is required in order
>   to register a header field -  including the field name, the purpose 
>   of the field, abnf syntax, security and privacy considerations, 
>   the set of protocols for which the field is intended, etc.

No, that is the detail for the specification, and it is likely to change
as the specification is developed. The only technical requirement should
be a _pointer_ to the latest published spec (ideally an Internet-Draft -
and they certainly change over time).

>2. have a single mailing list for public discussion of all 
>   proposed message headers

No, not a single mailing list. A mailing list (or newsgroup or web forum)
for that particular topic. Remember that we hope the principal customers
for this facility will be IETF Working Groups, and they will not thank you
for being forced to discuss the header off their own mailing lists.
Moreover, I cannot think of a mailing list that would be competent to
discuss headers for both email and HTTP.

>3. submission of the form causes an announcement to be sent to that
>   list, opening discussion of that header field.

Ietf-822 would be a good place for announcements :-) .

>4. initial review takes place for a fixed period of time - say 2 
>   or 4 weeks.

No, 2 or 4 days. The review is up to the mailing list (if it hasn't being
reviewing it already). All we want initially is time for the "expert" to
stop it, or insist on a disclaimer. or whatever we decide.

>5. at the end of the review period a designated expert makes one
>   of a small number of recommendations:

>   - field is believed to be non-disruptive and okay for
>     experimental use, or
>   - field is insufficiently documented, or
>   - revision based on review feedback is required, or
>   - IETF consensus is required before this field can be registered

Essentially he either says 
    1. this satisfies the requirements of having a specification and a
       discussion forum
    2. it does not conflict with other ongoing work
    3. it has reached the stage where it would be useful to try using it
       for real
Or else he says
    1. this is dumb/conflicts/is write-only or vanity/better left as X-
    2. it should be stopped/require a disclaimer/be referred to IESG

>6. "in the wild" observations are maintained separately, and
>   perhaps, automatically.  these are submitted via an emailed 
>   web form. submission of the form causes an automatic reply
>   to the email address that submitted the form; the sender must
>   confirm sending the observation before it will be accepted.

If it exists in the wild without proper discussion/documentation, then
someone needs to take it in hand, form a group to discuss it (or take it
to an existing group), prepare a proper spec, and then apply for
registration. All with a clear intent for an ultimate RFC and promotion to
the "full" register.

>7. there also needs to be a process for commenting on existing 
>   header fields and their applicability.  this might be as 
>   simple as writing a BCP about the header field, but the
>   information in that BCP needs to be reflected in the registry.

That is the public discussion forum mentioned above.

I would also add

8. There needs to be a clear intent that the thing is to be taken forward
towards an eventual RFC (standards/experimental/informational according to
the nature of the beast), at which point it gets promoted to the "full"
register. An exception might be made for headers that were loose in the
wild, but which were to be permanently deprecated.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1032
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 10 Feb 2002 16:39:46 GMT
Lines: 49
Sender: [email-masked]

In <[email-masked]> Dan Grillo <[email-masked]> writes:

>Trying to return to a more polite tone:  notice this email has a Versions:
>header, used by a set of mail tools I've been using on the Internet since
>1990.

Interesting. It seems to be in direct competition with X-Mailer and
User-Agent. All these are all loose in the "wild", though User-Agent has
the advantage that is is already standarised for HTTP, and hopefully soon
will be for Netnews.

And we are going to have the same problem with the various X-Priority and
Precedence headers.

>As an email implementor, I'd like to see a list that says:

>What's standard (ie, defined in an RFC, like Subject)
>What's non-standard but exists (like my Versions header)

Yes, the register needs to recognise that there are some headers out in
the wild (even widely used, some of them) which are nevertheless to be
deprecated on the grounds that some other, more-or-less equivalent, header
is going to be the one standardised. Do these headers remain in the
"provisional" register for ever? Or do they get entered in the "full"
register with a deprecated flag against them?

Ideally, I suppose, the RFC that standardizes the "official" version
should, at the same time, deprecate the others. Perhaps Graham could make
provision for such a flag in the "full" register.

In fact, we have a situation of this sort in Usefor. There are currently a
variety of NNTP-Posting-[Host,Date,Account] headers and other tracing
headers such as X-Trace. We plan to create one single Injector-Info header
(and I have already seen that in the wild too) to encompass the lot. So
the old ones (which were never documented anywhere anyway) will be
deprecated and, hopefully, will fade away (though I still expect to see
them in the wild for quite some time yet).

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1031
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 10 Feb 2002 16:26:12 GMT
Lines: 53
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I'm not ignoring it.  I'm categorically stating that:

Indeed you are.

And other people are categorically stating the exact opposite :-( .

>No, correct syntax alone isn't sufficient.  The proposal must at least
>appear to be sound and not harmful, and failure to address 
>security/privacy considerations is a frequent source of harm.
>(cookies in HTTP, various frobs to request an automatic response in email)

Yes, but a registry is not the place to specify syntax or other technical
details. That is what the indicated specification or the ongoing
discussion is for. Agreed that, at the time of registration, some degree
of soundness and lack of harmfulness is needed. But that is just a matter
of insisting that the initial specification is clear enough to permit
experimental use in the wild, and that the forum proposed for its
discussion is the most appropriate one (e.g. that there is not already
another forum tackling the exact same problem).

>Fine.  Give the submitter of the proposal two options in response
>to an unfavorable review by the expert:

>1. withdraw the proposal
>2. list the field in the registry, along with the review

Yes, that is OK.

>And still give the expert reviewer the right to categorically reject 
>applications for fields that are misleading, vanity fields, etc.
>Give the submitter the right of appeal to IESG, IAB, etc. if necessary. 

Agreed.

>The main point is, that things don't go into the registry at all without
>some documentation and without being accompanied by some community review. 

Agreed. 

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1030
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 10 Feb 2002 16:17:24 GMT
Lines: 26
Sender: [email-masked]

In <a05100301b889b7fe37f6@[216.43.25.67]> Pete Resnick <[email-masked]> writes:

>And if 3 or 4 sites want to use Counter-Argument-To amongst 
>themselves for a very special purpose and make it 
>X-Counter-Argument-To, and then it does catch on worldwide because 
>slowly 500 sites and 10 MUA writers all implement it, we are again 
>stuck with a non-standardizable field name because they decided to 
>start it with an X. What is the HARM of not just calling it 
>Counter-Argument-To from the get-go?????

We are stuck in that situation at the moment. The whole idea of this
proposal is to get us out of that situation. However, it may sometimes
fail (something that was originally intended to be kept under tight
control escapes into the wild). That should be rare, but will be
unavoidable; it will still be an improvement on the present situation.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 10 Feb 2002 15:06:09 -0500
Sender: [email-masked]

> We would be making much more progress on this argument if people stopped
> taking extreme positions, and instead started to look for the middle
> ground. There has been much suggested for the middle ground, but it is
> getting ignored as the artillery continues to fly overhead.

I don't believe my position is extreme at all.  Over the past 10+ 
years I have seen several attempts by individuals to introduce protocol 
extensions that would fundamentally change some aspect of how 
the protocol works, compromise security or privacy, or were so 
poorly done as to degrade interoperability - often with some 
"success".  It's precisely because I've seen so many examples of 
this, and I've seen the harm that it has done, that I've adopted 
my position.

I have also tried to suggest a 'middle ground' which would allow
easier and faster registration of extensions while still providing 
community review.   While I'm not entirely comfortable with this 
proposal, I do accept that it can take a long time to get an RFC 
published, and that this can be a barrier to deployment of useful
new features.  We've had some success with other 'expedited review'
processes for other kinds of protocol extensions (charsets, 
content-types), and I what I proposed is similar to those mechanisms.

Keith

To: [email-masked]
Xref: clerew local.mime:1028
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 10 Feb 2002 15:33:04 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> "D. J. Bernstein" <[email-masked]> writes:

>Keith Moore writes:
>> it's even more absurd that widely used protocols should be
>> subject to arbitrary modification by any random individual 
>> who thinks he understands what is going on better than
>> anybody else.

>The past decade of Internet progress happened _despite_ IETF control,
>not because of it. IETF is too big, too slow, and too far out of touch
>with the users. I am confident that fast, responsive, decentralized
>protocol development, taking advantage of open extension mechanisms,
>will continue to fuel Internet progress.

And there we have the two extreme positions; the pot arguing with the
kettle as to which one of them is "true black".

We would be making much more progress on this argument if people stopped
taking extreme positions, and instead started to look for the middle
ground. There has been much suggested for the middle ground, but it is
getting ignored as the artillery continues to fly overhead.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: "John R. LoVerso" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sat, 09 Feb 2002 08:43:09 -0500
Sender: [email-masked]

> > You might notice that it's considerably more difficult to get approval
> > for new IP and TCP options than it is to get a port assignment.
> 
> No it's not.  When I needed one 2 years ago, I asked for and was assigned one.
> TCP Option Number 24, "SNAP".

Here's the current policy:

>From RFC 2780, "IANA Allocation Guidelines For Values In the Internet Protocol 
and Related Headers", published March 2000:

for IP options:

] 4.5 IPv4 Option Type field
] 
]    The IANA allocates values from the IPv4 Option Type name space
]    following an IESG Approval, IETF Consensus or Standards Action
]    process.

for TCP options:

] 9.3 TCP Option Kind field
]
]  Values in the Option Kind field are assigned following an IESG
]  Approval or Standards Action process.

for ports: 

] 8. IANA Considerations for fields in the UDP header
] 
]    The UDP header [UDP] contains the following fields that carry values
]    assigned from IANA-managed name spaces: Source and Destination Port.
] 
]    Both the Source and Destination Port fields use the same namespace.
]    Values in this namespace are assigned following a Specification
]    Required, Expert Review, IESG Approval, IETF Consensus, or Standards
]    Action process.  Note that some assignments may involve non-
]    disclosure information.
] 
] 
] 9.1 TCP Source and Destination Port fields
] 
]    Both the Source and Destination Port fields use the same namespace.
]    Values in this namespace are assigned following a Specification
]    Required, Expert Review, IESG Approval, IETF Consensus, or Standards
]    Action process.  Note that some assignments may involve non-
]    disclosure information.

So I stand by my statement.   Ports can be allocated using Specification
Required, while Options require at least IESG approval.

Keith

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sat, 09 Feb 2002 08:33:20 -0500
Sender: [email-masked]

> > No it's not.  When I needed one 2 years ago, I asked for and was assigned one.
> > TCP Option Number 24, "SNAP".
> 
> Thanks for the data point. Did you request and obtain Keith's approval
> of the merits of your protocol extension before you started using it?

Or was Dan's blanket assurance that OPTIONAL protocol extensions are 
completely harmless sufficient for IANA?

Keith

p.s. and yes, thanks for the data point.  I'm going to investigate whether
this is current policy.  I'm curious, did you submit a specification for
your extension when requesting the option number?

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sat, 09 Feb 2002 08:29:04 -0500
Sender: [email-masked]

> > Dan, you're simply wrong.  Header fields have been designed that
> > modify essentially every aspect of email operation
> 
> No. New header fields are OPTIONAL protocol extensions.

Even "OPTIONAL" protocol extensions cause the implementations that
support those extensions to behave differently.  In many cases,
such extensions have been harmful to recipients, or to operation
of the mail service.  

In general, the more extensions that are in use, the more behavior 
differs from one UA to another, and the less predictable and 
interoperable the mail system becomes.

Keith

Date: 9 Feb 2002 07:38:16 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> You might notice that it's considerably more difficult to get approval
> for new IP and TCP options than it is to get a port assignment.

John R. LoVerso responds:
> No it's not.  When I needed one 2 years ago, I asked for and was assigned one.
> TCP Option Number 24, "SNAP".

Thanks for the data point. Did you request and obtain Keith's approval
of the merits of your protocol extension before you started using it?

---Dan

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sat, 09 Feb 2002 00:24:21 -0500
From: "John R. LoVerso" <[email-masked]>
Sender: [email-masked]

> You might notice that it's considerably more difficult to get approval
> for new IP and TCP options than it is to get a port assignment.

No it's not.  When I needed one 2 years ago, I asked for and was assigned one.
TCP Option Number 24, "SNAP".

John

Date: 9 Feb 2002 05:09:50 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> Dan, you're simply wrong.  Header fields have been designed that 
> modify essentially every aspect of email operation

No. New header fields are OPTIONAL protocol extensions. Unrecognized
fields are, as a rule, skipped, so programs using the unextended
protocol are not affected by the header fields.

Is it possible to create a message that simultaneously (1) uses new
fields and (2) causes failures in programs unaware of the new fields?
Of course. But this failure is _not_ caused by the presence of the new
fields; it is caused by the misuse of the old fields.

When you mischaracterize extensions as ``arbitrary modifications,'' you
are ignoring the simple fact that extensions preserve interoperability,
while ``arbitrary modifications'' can break interoperability.

You say that HTTP caused ``headaches'' for network operators. You say
that new header fields deployed without your infinitely wise guidance
often ``disrupt'' the email system. I bet it horrifies you that millions
of users are chatting on Internet telephones without waiting for the
IETF to finish coming to ``consensus'' on the monster known as SIP.

---Dan

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 21:59:24 -0500
Sender: [email-masked]

> > Since nothing limits the semantics of header fields, adding a header
> > field can cause an arbitrary modification to the protocol.
> 
> No. Extensions are not arbitrary modifications. 

Dan, you're simply wrong.  Header fields have been designed that 
modify essentially every aspect of email operation - presentation,
user interface, message retention, MTA handling, automatic responses,
etc.  While they do not generally affect UAs or MTAs that don't
look for them, they do affect the operation of the email system - 
often in disruptive ways.

> > TCP and UDP ports are just a demultiplexing mechanism.
> 
> False. 

You're wrong about this also.  But then again, if I said the sky
was blue, you'd argue that it was green.

Keith

Date: 9 Feb 2002 01:50:54 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> Since nothing limits the semantics of header fields, adding a header
> field can cause an arbitrary modification to the protocol.  

No. Extensions are not arbitrary modifications. Extensions are designed
so that extended software interoperates with unextended software. X-Loop
software, for example, talks to non-X-Loop software without trouble,
because the non-X-Loop software simply ignores X-Loop.

It's a much more serious matter when you modify a protocol in a way that
breaks interoperability. But this has nothing to do with how you use
_new_ header fields. The issue is that you aren't using the _old_ header
fields according to the existing protocol.

If, for example, someone says ``Put the sender information into this new
Sender-Information field, and omit the From field,'' then there will be
interoperability problems. Those problems come from the omission of the
>From field. They do _not_ come from the addition of the new field.

> TCP and UDP ports are just a demultiplexing mechanism.

False. Thousands of ports have special meanings. Port 22, for example,
is assigned to ssh. This assignment extended the Internet protocol
suite. It allowed Tatu Ylonen to define part of the format of the data
communicated through the Internet---and to do so without ``consensus''
from control freaks like you.

> They don't change the semantics of IP,

New header fields don't change the RFC 822 Appendix B parsing mechanism.

Your naive notion of ``protocol'' as ``port'' is inadequate to explain
FTP, TCPMUX, the World Wide Web, tunnels, etc. Do you really have this
much trouble seeing the entire Internet data flow as a single object?
Yes, there's a difference in scale between a typical new port and a
typical new header field, but the same extension principles apply.

> You might notice that it's considerably more difficult to get approval
> for new IP and TCP options than it is to get a port assignment.

Evidence? I've never asked for a new IP option, but a glance at the
IP-options list reveals several assignments to protocol extensions that
aren't documented in RFCs.

Anyway, I can understand setting a barrier for a namespace that has a
small set of possible values. But header fields don't have that problem.

---Dan

From: Dan Grillo <[email-masked]>
Organization: President, Grillo Networking, Inc.
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 8 Feb 2002 10:59:42 -0800
Versions: dmail (bsd44) 2.3/makemail 2.9b
Sender: [email-masked]

Dan Bernstein writes:
 |The past decade of Internet progress happened _despite_ IETF control,
 |not because of it. 

Keith Moore writes:
 |I could make an equally valid statement about Dan Bernstein.  

Ok.  Sounds like that thread has hit the wall.

Trying to return to a more polite tone:  notice this email has a Versions:
header, used by a set of mail tools I've been using on the Internet since
1990.

Other mail software, at various times, has noticed, filtered, and/or
used per my "spec" this header.  (NeXT's Mail.app is one example)

It seems like it would be nice to be able to publically
document that header's use.

At the same time my mail software knows about all kinds of other
"random" headers.  It uses some magic MS Outlook headers to 
parse outlook meeting invitations.  It would have been nice to
know about those, also.

As an email implementor, I'd like to see a list that says:

What's standard (ie, defined in an RFC, like Subject)
What's non-standard but exists (like my Versions header)

If there are conflicts the list should call this out.
Clearly the default winner in a conflict is the standard, and it's
OK if the list stresses that fact. 

If there's a conflict between 2 non-standard items, well, highlight
that, and email implementers will know these are great headers
to never display to users :-)

			--Dan

--
  Dan Grillo   [email-masked]  (650) 917-0685  fax (209)315-7970

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 13:36:27 -0500
Sender: [email-masked]

> And if 3 or 4 sites want to use Counter-Argument-To amongst
> themselves for a very special purpose and make it
> X-Counter-Argument-To, and then it does catch on worldwide because
> slowly 500 sites and 10 MUA writers all implement it, we are again
> stuck with a non-standardizable field name because they decided to
> start it with an X. 

let's get over that.  if someone creates an X- field that is
really worthy of standardization as-is, let's standardize it.

but let's not deprecate X- just for the rare case that this actually
happens.

Keith

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 13:34:18 -0500
Sender: [email-masked]

> Keith Moore writes:
> > it's even more absurd that widely used protocols should be
> > subject to arbitrary modification by any random individual
> > who thinks he understands what is going on better than
> > anybody else.
> 
> We aren't talking about ``arbitrary modification.'' We are talking about
> _extensions_ to the Internet protocol suite, through mechanisms designed
> to support these extensions: TCP ports, header fields, etc.

Since nothing limits the semantics of header fields, adding a header
field can cause an arbitrary modification to the protocol.  

TCP and UDP ports are just a demultiplexing mechanism.  They don't 
change the semantics of IP, and different port assignments don't 
interfere with one another.  

You might notice that it's considerably more difficult to get approval
for new IP and TCP options than it is to get a port assignment.
 
> Some ``random individual'' at CERN developed and deployed the World Wide
> Web without approval from anyone other than his boss. 

Sure, but he didn't change an existing protocol to do that.   As it 
happened, HTTP's poor design created tremendous headaches for network 
operators.  But at least the introduction of HTTP didn't disrupt other 
network services (much).

> Imagine going back to 1990 and demanding that he write protocol specs, 
> deal with people like Keith Moore, and build ``consensus,'' before 
> being allowed to use a TCP port!

And imagine if random vendors had been allowed to make arbitrary modifications 
to HTTP without getting consent from anyone.  Of course that's exactly what
happened, and the current version of HTTP is the mess that resulted.  (more 
precisely, HTTP 1.1 was a long and very expensive and only somewhat successful 
attempt to clean up the mess that resulted)

Now you're arguing that IETF should endorse the practice of making 
random modifications to protocols.  

> The past decade of Internet progress happened _despite_ IETF control,
> not because of it. 

I could make an equally valid statement about Dan Bernstein.  

Keith

Date: Fri, 8 Feb 2002 18:49:59 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 11.21 +0000 02-02-08, Charles Lindsey wrote:
>There are problems with that too. The header as proposed may be dumb. But
>later someone else may want to revive the same header for a different
>purpose, or even revive it for the same purpose, but with a less dumb
>syntax and semantics.

I do not think there is any need to ever reuse a header which
is already used in dumb ways. It is not difficult to invent
a new header for a slightly revised task, to avoid the
problem of collission with the existing header name.
Language is rich!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 13:11:11 -0500
Sender: [email-masked]

> >...if the approval process is too onerous then more people will try 
> >to bypass the approval process than otherwise.
> >...if the approval process is too easy then the bad mechanisms *get 
> >approved*, and there's less to discourage other vendors from 
> >implementing them.
> [My emphasis added above]
> 
> There's a third choice which you continue to ignore: There is *NO* 
> approval process. 

I'm not ignoring it.  I'm categorically stating that:

- I think it will do harm to the interoperability of Internet 
  mail, by making it too easy to legitimize bad ideas and effectively
  bypassing the standards process,

- I think it optimizes for the extremely rare case of a header field
  that really is worthy of widely deployment despite not having been
  reviewed by the community and revised on the basis of that review
  before deployment 

> >I also think we should be able to document header fields that are 
> >observed "in the wild" absent approval - but they should be listed 
> >separately, or in such a way that it's very clear that no approval 
> >was obtained.
> 
> Why separately? Why not just have one list with a marking on each 
> entry which says "Approved", "Not approved", "Actively discouraged", 
> etc.?

Because observing a header field in use and documenting the specification
for a header field along with its applicability are fundamentally 
different things, and I think it's too confusing to try to combine them.

> >What I currently have in mind is something like the following:
> >
> >1. have a template to request registration of a message header, much 
> >like the templates for content-types, charsets, or URN NIDs.
> 
> Fine. Heck, put it on the IANA web site as a web form.
> 
> >the template explains the information that is required in order to 
> >register a header field -  including the field name, the purpose of 
> >the field, abnf syntax, security and privacy considerations, the set 
> >of protocols for which the field is intended, etc.
> 
> Fine, although putting in "No security considerations" is not a bar 
> to registration, though it may be a bar to the approval process. 
> Registration happens after step one is completed in a syntactically 
> correct way.

No, correct syntax alone isn't sufficient.  The proposal must at least
appear to be sound and not harmful, and failure to address 
security/privacy considerations is a frequent source of harm.
(cookies in HTTP, various frobs to request an automatic response in email)

I can see not requiring security/privacy considerations as part of
the form - let other people fill that in.  But those things need to
be considered before the field is registered.

> >2. have a single mailing list for public discussion of all proposed 
> >message headers
> >
> >3. submission of the form causes an announcement to be sent to that 
> >list, opening discussion of that header field.
> 
> Peachy.
> 
> >4. initial review takes place for a fixed period of time - say 2 or 4 weeks.
> >
> >5. at the end of the review period a designated expert makes one of 
> >a small number of recommendations:
> >
> >    - field is believed to be non-disruptive and okay for experimental use, or
> >    - field is insufficiently documented, or
> >    - revision based on review feedback is required, or
> >    - IETF consensus is required before this field can be registered
> 
> Nonsense. This makes it so that bad mechanisms will not appear in the 
> registry for months. This will cause damage to the net. For an 
> approval mechanism, this is fine; for a registration mechanism, it is 
> wrong.

Fine.  Give the submitter of the proposal two options in response
to an unfavorable review by the expert:

1. withdraw the proposal
2. list the field in the registry, along with the review

But also make it explicit in the registry that implementation of a proposal 
that gets an unfavorable review is not recommended - or if the field is 
believed to cause harm, the registry can contain an indication that the 
field should be ignored or even deleted by message handling software.

And still give the expert reviewer the right to categorically reject 
applications for fields that are misleading, vanity fields, etc.
Give the submitter the right of appeal to IESG, IAB, etc. if necessary. 

The main point is, that things don't go into the registry at all without
some documentation and without being accompanied by some community review.  

Keith

Date: Fri, 08 Feb 2002 09:58:41 -0800
To: Pete Resnick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

At 11:39 AM 2/8/2002 -0600, Pete Resnick wrote:
>Now, we may wish to add a process after registration that calls for 
>approval (or disapproval), and the results of that process can attach to 
>any registration. And I don't care how onerous that approval process is. 
>Heck, make it require a standards track RFC for all I care. What I want is 
>for approval to be a completely separate act from registration.

exactly.

the core of this debate is a failure to distinguish the act of registration 
from the act of review (and approval.)

sometimes, some people DO take a registration to imply some sort of 
approval.  however there are always some people, somewhere, who do things 
wrong.

basing an entire system on that possibility is a good way to ensure that 
nothing productive gets done.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Fri, 8 Feb 2002 11:39:22 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

On 2/8/02 at 9:46 AM -0500, Keith Moore wrote:

>...if the approval process is too onerous then more people will try 
>to bypass the approval process than otherwise.
>...if the approval process is too easy then the bad mechanisms *get 
>approved*, and there's less to discourage other vendors from 
>implementing them.
[My emphasis added above]

There's a third choice which you continue to ignore: There is *NO* 
approval process. Bad mechanisms don't "get approved". They get 
*registered*.

Now, we may wish to add a process after registration that calls for 
approval (or disapproval), and the results of that process can attach 
to any registration. And I don't care how onerous that approval 
process is. Heck, make it require a standards track RFC for all I 
care. What I want is for approval to be a completely separate act 
from registration.

>I also think we should be able to document header fields that are 
>observed "in the wild" absent approval - but they should be listed 
>separately, or in such a way that it's very clear that no approval 
>was obtained.

Why separately? Why not just have one list with a marking on each 
entry which says "Approved", "Not approved", "Actively discouraged", 
etc.?

>What I currently have in mind is something like the following:
>
>1. have a template to request registration of a message header, much 
>like the templates for content-types, charsets, or URN NIDs.

Fine. Heck, put it on the IANA web site as a web form.

>the template explains the information that is required in order to 
>register a header field -  including the field name, the purpose of 
>the field, abnf syntax, security and privacy considerations, the set 
>of protocols for which the field is intended, etc.

Fine, although putting in "No security considerations" is not a bar 
to registration, though it may be a bar to the approval process. 
Registration happens after step one is completed in a syntactically 
correct way.

>2. have a single mailing list for public discussion of all proposed 
>message headers
>
>3. submission of the form causes an announcement to be sent to that 
>list, opening discussion of that header field.

Peachy.

>4. initial review takes place for a fixed period of time - say 2 or 4 weeks.
>
>5. at the end of the review period a designated expert makes one of 
>a small number of recommendations:
>
>    - field is believed to be non-disruptive and okay for experimental use, or
>    - field is insufficiently documented, or
>    - revision based on review feedback is required, or
>    - IETF consensus is required before this field can be registered

Nonsense. This makes it so that bad mechanisms will not appear in the 
registry for months. This will cause damage to the net. For an 
approval mechanism, this is fine; for a registration mechanism, it is 
wrong.

>6. "in the wild" observations are maintained separately, and 
>perhaps, automatically.  these are submitted via an emailed web 
>form. submission of the form causes an automatic reply to the email 
>address that submitted the form; the sender must confirm sending the 
>observation before it will be accepted.

Fine, but again, why separately?

>7. there also needs to be a process for commenting on existing 
>header fields and their applicability.  this might be as simple as 
>writing a BCP about the header field, but the information in that 
>BCP needs to be reflected in the registry.

Peachy.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 8 Feb 2002 11:17:23 -0600
To: [email-masked] (Charles Lindsey)
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked]
Sender: [email-masked]

On 2/8/02 at 11:27 AM +0000, Charles Lindsey wrote:

>If 3 or 4 sites want to use Counter-Argument-To amongst thjemselves for a
>very special purpose, then it should be X-Counter-Argument-To.
>
>If 3 or 4 sites say "let us try this out strictly between ourselves", then
>it should be X-Counter-Argument-To.
>
>But if they say "this seems a neat idea; let us try it out to see if it
>works and if it does then maybe it will catch on worldwide", than they have
>"anticipated" a wide deployment, and they should use Counter-Argument-To,
>having first got it into our proposed register (which implies passing our
>modest hurdles, of course).

And if 3 or 4 sites want to use Counter-Argument-To amongst 
themselves for a very special purpose and make it 
X-Counter-Argument-To, and then it does catch on worldwide because 
slowly 500 sites and 10 MUA writers all implement it, we are again 
stuck with a non-standardizable field name because they decided to 
start it with an X. What is the HARM of not just calling it 
Counter-Argument-To from the get-go?????

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 8 Feb 2002 17:54:04 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 09.46 -0500 02-02-08, Keith Moore wrote:
>5. at the end of the review period a designated expert makes one
>    of a small number of recommendations:
>
>    - field is believed to be non-disruptive and okay for
>      experimental use, or
>    - field is insufficiently documented, or
>    - revision based on review feedback is required, or
>    - IETF consensus is required before this field can be registered
>
>6. "in the wild" observations are maintained separately, and
>    perhaps, automatically.  these are submitted via an emailed
>    web form. submission of the form causes an automatic reply
>    to the email address that submitted the form; the sender must
>    confirm sending the observation before it will be accepted.

A user should be able to search for items in both data bases
with a single search request, or there should be a list
of all the header names in both data bases in a single
alphabetical listing.

How should synonyms be handled? An example is "Obsoletes",
"Supersedes" and "Revision-Of". Note that they are not
exactly synonyms. "Supersedes" as presently mostly implemented
causes a deletion of the previous message and replacement
with the new text. "Obsoletes" is just a link between
old and new versions, technically similar to "In-Reply-To".

It should at least be able to store links between such
partial synonyms, a registration of "Supersedes" could
contain a field "See also: Obsoletes, Revision-Of".
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:1004
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 8 Feb 2002 11:27:00 GMT
Lines: 45
Sender: [email-masked]

In <p0510030fb8888960ce0a@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>At 10.49 +0000 02-02-07, Charles Lindsey wrote:
>>So you need a requirement that things only go into the registry if it is
>>anticipated that widely deployed software will want to parse and
>>understand them (and which it would be a pain to rewrite if it had to be
>>changed from X- to non-X- later on).

>That is too strict. If an experimental system wants to try
>out a new facility, like "Counter-Argument-To", this should
>be allowed even if we do not know if it will be widely
>used. The importance with the registry is (a) that it stops
>someone else from using the same header name with a
>different usage (b) someone who wants to implement a new
>header can find out and learn from, and make its
>implementation compatible, with what others have done (c)
>it can warn against dangerous header names. None of these
>advantages with a registry will work if we only register
>widely deployed headers.

No, you missed my use of the word "anticipated".

If 3 or 4 sites want to use Counter-Argument-To amongst thjemselves for a
very special purpose, then it should be X-Counter-Argument-To.

If 3 or 4 sites say "let us try this out strictly between ourselves", then
it should be X-Counter-Argument-To.

But if they say "this seems a neat idea; let us try it out to see if it
works and if it does then maybe it will catch on worldwide", than they have
"anticipated" a wide deployment, and they should use Counter-Argument-To,
having first got it into our proposed register (which implies passing our
modest hurdles, of course).

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1003
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 8 Feb 2002 11:21:21 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> So you need a requirement that things only go into the registry if it is
>> anticipated that widely deployed software will want to parse and
>> understand them 

>actually I'd argue that sometimes we want to put things in the "registry"
>(I'd like to find a better term) for the purpose of saying you should not 
>implement them.

There are problems with that too. The header as proposed may be dumb. But
later someone else may want to revive the same header for a different
purpose, or even revive it for the same purpose, but with a less dumb
syntax and semantics.

So I don't think negative entries should be automatic, though I don't
oppose the idea althogether.

Maybe the mechanism is that the Area Director/Expert gets to see the
entries before they are registered. Either he says "put it in", or he says
"if this goes in, it must have the following disclaimer attached to it".
Much what the IESG does if the drafts editor wants to publish something
they are not happy about.

Appeal to the full IESG against the expert's decision if necessary, as per
usual practice.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:1002
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 8 Feb 2002 11:16:17 GMT
Lines: 21
Sender: [email-masked]

In <p0510030cb8881704efb1@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>Here is an attempt to summarize what might be a consensus of
>this discussion:

[Various suggestions snipped.]

Yes, as a set of principles I think many of us agree with that list. But
the devil will be in the details.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 11:29:48 -0500
Sender: [email-masked]

> It's clear that those opposed are more interested in being entrenched in
> their view than they are in considering whether their fears have a serious
> foundation.

once again, you're misstating other people's views,
and using ridicule in an attempt to discredit them.
this doesn't add anything to the discussion.

basically, you're out of line.  and you need to stop.

Keith

Date: Fri, 08 Feb 2002 08:07:25 -0800
To: Pete Resnick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

At 11:33 PM 2/7/2002 -0600, Pete Resnick wrote:
>I gave a long argument as to why this accomplishes exactly the opposite of 
>what you say you want.

Indeed you did.  In fact at this point, the nature and benefits of this 
registration mechanism has been explained many times.

It's clear that those opposed are more interested in being entrenched in 
their view than they are in considering whether their fears have a serious 
foundation.

The model that Somebody Somewhere Might do Something Bad (sm) is a good way 
to ensure that nothing useful ever gets done.

So, continuing this debate only lends credibility to their paranoia.  It 
implies that we should take that paranoia seriously.

We shouldn't.  And the first step in not taking it seriously is to stop 
responding to it.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 09:46:29 -0500
Sender: [email-masked]

> >again, I don't think pulling the plug is the right mechanism.
> >
> >nothing should go in the registry without public comment and
> >explicit approval.
> 
> I gave a long argument as to why this accomplishes exactly the
> opposite of what you say you want.  Prior approval *causes*
> deployment of bad mechanisms without ever documenting them. 

I think that's an exaggeration.  It's true that if the approval 
process is too onerous then more people will try to bypass the 
approval process than otherwise.  But that doesn't inherently 
cause the wide deployment of bad mechanisms. OTOH, if the 
approval process is too easy then the bad mechanisms get approved, 
and there's less to discourage other vendors from implementing them.  
Some bad mechanisms are going to get deployed no matter what we do.

I think it should be easy to apply for approval of a header field, 
in the sense that the process is visible and that the considerations
for approval are also visible and well-documented.  

I think it should be easy to get approval for a header field that 
is well-defined and not disruptive.  

I don't think it should be easy to get approval for a header field
that is disruptive.

I also think we should be able to document header fields that are 
observed "in the wild" absent approval - but they should be listed
separately, or in such a way that it's very clear that no approval 
was obtained.  Another reason for documenting these separately is to
get a sense of the degree of deployment of standard header fields.

What I currently have in mind is something like the following:

1. have a template to request registration of a message header,
   much like the templates for content-types, charsets, or URN NIDs.

   the template explains the information that is required in order
   to register a header field -  including the field name, the purpose 
   of the field, abnf syntax, security and privacy considerations, 
   the set of protocols for which the field is intended, etc.

2. have a single mailing list for public discussion of all 
   proposed message headers

3. submission of the form causes an announcement to be sent to that
   list, opening discussion of that header field.

4. initial review takes place for a fixed period of time - say 2 
   or 4 weeks.

5. at the end of the review period a designated expert makes one
   of a small number of recommendations:

   - field is believed to be non-disruptive and okay for
     experimental use, or
   - field is insufficiently documented, or
   - revision based on review feedback is required, or
   - IETF consensus is required before this field can be registered

6. "in the wild" observations are maintained separately, and
   perhaps, automatically.  these are submitted via an emailed 
   web form. submission of the form causes an automatic reply
   to the email address that submitted the form; the sender must
   confirm sending the observation before it will be accepted.

7. there also needs to be a process for commenting on existing 
   header fields and their applicability.  this might be as 
   simple as writing a BCP about the header field, but the
   information in that BCP needs to be reflected in the registry.

Keith

Date: 8 Feb 2002 07:52:06 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> it's even more absurd that widely used protocols should be
> subject to arbitrary modification by any random individual 
> who thinks he understands what is going on better than
> anybody else.

We aren't talking about ``arbitrary modification.'' We are talking about
_extensions_ to the Internet protocol suite, through mechanisms designed
to support these extensions: TCP ports, header fields, etc.

Some ``random individual'' at CERN developed and deployed the World Wide
Web without approval from anyone other than his boss. Imagine going back
to 1990 and demanding that he write protocol specs, deal with people
like Keith Moore, and build ``consensus,'' before being allowed to use a
TCP port!

The past decade of Internet progress happened _despite_ IETF control,
not because of it. IETF is too big, too slow, and too far out of touch
with the users. I am confident that fast, responsive, decentralized
protocol development, taking advantage of open extension mechanisms,
will continue to fuel Internet progress.

---Dan

Date: Thu, 7 Feb 2002 23:33:20 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

On 2/7/02 at 8:21 AM -0500, Keith Moore wrote:

>again, I don't think pulling the plug is the right mechanism.
>
>nothing should go in the registry without public comment and 
>explicit approval.

I gave a long argument as to why this accomplishes exactly the 
opposite of what you say you want.  Prior approval *causes* 
deployment of bad mechanisms without ever documenting them. Easy 
registration (with later comments or plug pulling) *prevents* 
widespread deployment of bad mechanisms. Would you care to comment on 
that argument instead of simply restating your opinion that there 
should be prior approval?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 08 Feb 2002 00:19:29 -0500
Sender: [email-masked]

> The idea that new interfaces should wait for approval from a
> standardization committee is patently absurd.

it's even more absurd that widely used protocols should be
subject to arbitrary modification by any random individual 
who thinks he understands what is going on better than
anybody else.

Keith

Date: 7 Feb 2002 23:55:43 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes, sarcastically:
> But heaven forbid that someone should actually try to understand those 
> problems, and get consensus on a solution, before deploying something 
> which might make the problem worse.

The idea that new interfaces should wait for approval from a
standardization committee is patently absurd.

I already gave the examples of C, the original Internet protocols, IRC,
HTTP, Java, Internet telephones, and (on a much smaller scale) X-Loop.
All of these advances were deployed without approval from control freaks
like Keith.

Should people understand what they're doing? Of course. Should people
avoid creating interoperability problems? Of course. But the Internet
has all sorts of protocol extension mechanisms: TCP ports, header
fields, etc. The value of those mechanisms would be practically
destroyed if every new extension required IETF approval.

---Dan

Date: Thu, 7 Feb 2002 20:47:04 +0100
To: [email-masked] (Charles Lindsey)
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 10.49 +0000 02-02-07, Charles Lindsey wrote:
>So you need a requirement that things only go into the registry if it is
>anticipated that widely deployed software will want to parse and
>understand them (and which it would be a pain to rewrite if it had to be
>changed from X- to non-X- later on).

That is too strict. If an experimental system wants to try
out a new facility, like "Counter-Argument-To", this should
be allowed even if we do not know if it will be widely
used. The importance with the registry is (a) that it stops
someone else from using the same header name with a
different usage (b) someone who wants to implement a new
header can find out and learn from, and make its
implementation compatible, with what others have done (c)
it can warn against dangerous header names. None of these
advantages with a registry will work if we only register
widely deployed headers.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 07 Feb 2002 14:14:19 -0500
Sender: [email-masked]

> > > should someone be allowed to register a header and state in the
> > > description that this is meant to deprecate an IETF standard header?
> > Mail-Reply-To seems like the ideal example for that question.
> 
> Actually, if you read the Mail-Reply-To spec, you'll see that it's meant
> to fix the (problematic) de-facto standard use of Reply-To, which is
> very different from the (even more problematic) IETF use of Reply-To.

Granted that Reply-To has significant problems.  

But heaven forbid that someone should actually try to understand those 
problems, and get consensus on a solution, before deploying something 
which might make the problem worse.

Keith

To: [email-masked]
Xref: clerew local.mime:992
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Thu, 7 Feb 2002 10:53:49 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> "D. J. Bernstein" <[email-masked]> writes:

>Keith Moore writes:
>> The risk I'm more concerned about is the guy who 
>> does something that substantially changes the way that mail works,
>> and this creates a rift in the installed base and degrades 
>> interoperability for everyone. 

>One example that leaps to mind is multipart/alternative.

Which shows that even the IESG-established mechanisms can be boneheaded on
occasion :-( .

-- 
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: [email-masked]      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

Date: 7 Feb 2002 16:58:14 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

> > should someone be allowed to register a header and state in the
> > description that this is meant to deprecate an IETF standard header?
> Mail-Reply-To seems like the ideal example for that question.

Actually, if you read the Mail-Reply-To spec, you'll see that it's meant
to fix the (problematic) de-facto standard use of Reply-To, which is
very different from the (even more problematic) IETF use of Reply-To.

My web pages distinguish (1) the behavior of real implementations, (2)
the IETF specifications, and (3) my recommendations. In contrast, IETF
authors often explicitly refuse to document the behavior of real
implementations, because they claim that implementors can't handle the
truth. You can see the same paternalism from Keith in this discussion.

---Dan

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 07 Feb 2002 08:21:06 -0500
Sender: [email-masked]

> It certainly shows that there needs to be a mechanism in place for the
> IESG (area director/expert) to pull the plug smartly.

again, I don't think pulling the plug is the right mechanism.  

nothing should go in the registry without public comment and explicit approval.  

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 07 Feb 2002 08:18:28 -0500
Sender: [email-masked]

> So you need a requirement that things only go into the registry if it is
> anticipated that widely deployed software will want to parse and
> understand them 

actually I'd argue that sometimes we want to put things in the "registry"
(I'd like to find a better term) for the purpose of saying you should not 
implement them.

To: [email-masked]
Xref: clerew local.mime:990
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Thu, 7 Feb 2002 10:49:23 GMT
Lines: 29
Sender: [email-masked]

In <p0510033cb88738c8fab2@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>Say that someone wanted to register "Best-Porn-Website"
>or "Days-Before-Judgement-Day" as e-mail headers in
>a completely open registry!

Well those look like "vanity" or "write-only" headers to me, which should
be left as X-headers outside of the registry.

So you need a requirement that things only go into the registry if it is
anticipated that widely deployed software will want to parse and
understand them (and which it would be a pain to rewrite if it had to be
changed from X- to non-X- later on).

Of course, anything in the provisional registry should come with a health
warning to the effect that it MAY change before it gets finalised, though
if it is backed up by an identified discussion forum there is some chance
of keeping the development of the idea on a reasonable track.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:991
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Thu, 7 Feb 2002 10:51:54 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> Cyrus Daboo <[email-masked]> writes:

>Yes indeed! I've already seen instances of a client that emits
>'Thread-Topic' and 'Thread-Index' headers that I can't find described
>anywhere. These are clearly meant to be an attempt to do some form of smart
>message threading, which is fine except that it doesn't use In-Reply-To or
>References, which is what rfc2822 suggests. So is this an attempt to
>deprecate the use of In-Reply-To and References? This illustrates Keith's
>point: should someone be allowed to register a header and state in the
>description that this is meant to deprecate an IETF standard header?

It certainly shows that there needs to be a mechanism in place for the
IESG (area director/expert) to pull the plug smartly.

Whilst such a power is clearly necessary, I doubt it would actually need
to be used all that often.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:989
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Thu, 7 Feb 2002 10:41:22 GMT
Lines: 19
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Which is why it makes me a little uncomfortable to see it proposed as an
>IANA function, mostly because I expect a bit more editorial control than
>that to go into an IANA registry.

Which is exactly why we should be discussing (indeed we are discussing)
the nature of the editorial control that should be put in place.

-- 
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: [email-masked]      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

Date: Thu, 7 Feb 2002 12:43:10 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Here is an attempt to summarize what might be a consensus of
this discussion:

- A mail header name registry is useful.

- The registry should not only contain headers from
   standards, but it should clearly separate header
   names from standards and non-standard header names.

- Some kind of community vetting of new entries should
   be done.

- This community vetting need not be as thorough as
   for a new standard, and it need not always result in
   consensus. If no consensus is reached, the result may
   be to store two alternative views in the registry.

- The community vetting could result in a warning against
   the use of the proposed header, or it could result
   in refusal to accept the new header name in the
   registry.

- Each item in the registry should clarify the status of
   that entry, whether it is from a standard, or otherwise
   whether the community view is a warning or a specification
   of a possible conflict orh problem with the new header
   name.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 7 Feb 2002 12:33:46 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Torgny Tholerus  <[email-masked]>, Lars Enderin <[email-masked]>
Sender: [email-masked]

At 17.03 -0600 02-02-06, Pete Resnick wrote:
>  This gives us an opportunity to quickly try to convince 
>the bonehead that he is in fact a bonehead and get him to 
>instead use In-Reply-To/References and, if that fails, 
>quickly come to a consensus that this *is* a stupid idea 
>and quickly get "This is stupid; don't do it" put into the 
>registry.

Very good idea! There should be some way for the community,
perhaps even qualified single experts, to register
criticism of an entry in the registry.

We have been developing a software with a similar facility.
Our system has an index of terms, a definition of each
term, and other people can comment on this definition. In
practice, our system works like a forum system, where every
term has its own separate forum. However, a normal forum
system might generate too much comment, one would not want
an implementor of "Reply-To" to read through all the
thousand messages on that topic in the drums working group.
Such a person would best be aided by reading a short
summary of each of the conflicting views on this header
name.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 7 Feb 2002 10:44:32 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> Yes indeed! I've already seen instances of a client that emits
> 'Thread-Topic' and 'Thread-Index' headers that I can't find described
> anywhere. These are clearly meant to be an attempt to do some form of smart
> message threading, which is fine except that it doesn't use In-Reply-To or
> References, which is what rfc2822 suggests. So is this an attempt to
> deprecate the use of In-Reply-To and References? This illustrates Keith's
> point: should someone be allowed to register a header and state in the
> description that this is meant to deprecate an IETF standard header?

Mail-Reply-To seems like the ideal example for that question.

--Arnt

Date: 7 Feb 2002 02:14:29 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Charles Lindsey writes:
> That is why I have suggested that no entry
> should be made to the provisional register (or whatever it gets called)
> unless there is an identified forum where it is to be discussed.

http://cr.yp.to/lists.html#imis is open for discussion of anything of
interest to Internet mail implementors.

---Dan

Date: 7 Feb 2002 02:13:17 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> The risk I'm more concerned about is the guy who 
> does something that substantially changes the way that mail works,
> and this creates a rift in the installed base and degrades 
> interoperability for everyone. 

One example that leaps to mind is multipart/alternative.

---Dan

Date: Wed, 6 Feb 2002 17:03:29 -0600
To: Cyrus Daboo <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2/6/02 at 5:36 PM -0500, Cyrus Daboo wrote:

>Yes indeed! I've already seen instances of a client that emits 
>'Thread-Topic' and 'Thread-Index' headers that I can't find 
>described anywhere. These are clearly meant to be an attempt to do 
>some form of smart message threading, which is fine except that it 
>doesn't use In-Reply-To or References, which is what rfc2822 
>suggests. So is this an attempt to deprecate the use of In-Reply-To 
>and References? This illustrates Keith's point: should someone be 
>allowed to register a header and state in the description that this 
>is meant to deprecate an IETF standard header?

Actually, I think this is a fine example. Let's assume for the sake 
of argument that your evaluation is correct and this is an attempt to 
do smart threading which could otherwise be done with 
In-Reply-To/References. Whoever the bonehead was who came up with 
Thread-Topic and Thread-Index, they are most certainly *not* going to 
even attempt to write an Internet Draft documenting it: People of 
this brain capacity can't imagine it's worth the time. And so off 
this bonehead went and implemented it without comment. Guess what 
follows: Other boneheads are going to go off and, having found no 
documentation, figure out how to use it and are going to implement it 
too. The net result of this little exercise is that over time we will 
end up with a deployed stupid idea.

What's the alternative? Make a registry available for the bonehead to 
register Thread-Topic and Thread-Index. Let it point to a web page of 
his making that explains what a brilliant and intelligent person he 
is for coming up with this wonderful mechanism: People of this brain 
capacity think that reserving a name in a registry, thus 
immortalizing themselves and publicly pointing out their brilliance 
are fine things to do, especially if it takes no time at all. So the 
fields get registered. Now, before this stupidity has a chance to 
spread too far, those of us who are only mildly clueful see the new 
registration. This gives us an opportunity to quickly try to convince 
the bonehead that he is in fact a bonehead and get him to instead use 
In-Reply-To/References and, if that fails, quickly come to a 
consensus that this *is* a stupid idea and quickly get "This is 
stupid; don't do it" put into the registry.

Giving folks a quick path to register field names and therefore a 
quick way to look up field names gives the IETF community a chance to 
communicate with people who would not otherwise hear from us before 
they do damage. (Something like Dan's web page, though of high 
utility, takes someone like Dan (who has a job other than 
registrations) to go and post the new entries and is not easy to find 
in the way that an IANA web page would be.) Giving folks a high bar 
for registration does exactly the opposite of what you want: It makes 
people ignore us, go off and do their own thing out of expedience, 
and ends up doing just the kind of damage to the e-mail system you're 
trying to prevent.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 06 Feb 2002 17:36:05 -0500
From: Cyrus Daboo <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

Hi,

--On Wednesday, February 6, 2002 4:14 PM -0500 Keith Moore
<[email-masked]> wrote:

>> The risk with a completely open registry is that any
>> fool might want to register headers related to his
>> favourite religious fanatism, or spammers might want
>> to register headers favoring their web sites.
> 
> That's one risk.  The risk I'm more concerned about is the guy who 
> does something that substantially changes the way that mail works,
> and this creates a rift in the installed base and degrades 
> interoperability for everyone. 
> 
> ( And no, I don't subscribe to the theory that the market will 
>   select the optimal result in the long run. )

Yes indeed! I've already seen instances of a client that emits
'Thread-Topic' and 'Thread-Index' headers that I can't find described
anywhere. These are clearly meant to be an attempt to do some form of smart
message threading, which is fine except that it doesn't use In-Reply-To or
References, which is what rfc2822 suggests. So is this an attempt to
deprecate the use of In-Reply-To and References? This illustrates Keith's
point: should someone be allowed to register a header and state in the
description that this is meant to deprecate an IETF standard header?

-- 
Cyrus Daboo

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Wed, 06 Feb 2002 16:14:24 -0500
Sender: [email-masked]

> The risk with a completely open registry is that any
> fool might want to register headers related to his
> favourite religious fanatism, or spammers might want
> to register headers favoring their web sites.

That's one risk.  The risk I'm more concerned about is the guy who 
does something that substantially changes the way that mail works,
and this creates a rift in the installed base and degrades 
interoperability for everyone. 

( And no, I don't subscribe to the theory that the market will 
  select the optimal result in the long run. )

Date: Wed, 6 Feb 2002 20:55:18 +0100
To: [email-masked] (Charles Lindsey)
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked]
Sender: [email-masked]

>In <[email-masked]> Keith 
>Moore <[email-masked]> writes:
>
>>But I can't help but wonder if there aren't other, more
>>controversial proposals that people want to deploy without
>>community review, and that's why they're trying to get IETF
>>to say that we don't need review of mail protocol extensions
>>before deploying them.

To some extent yes. I would like to register speech act
terminology like "Speech act" with values like "promise",
"request", "offer", "delivery", etc. and pro-contra-
analysis headers like "Pros", "Cons", "Cause-of",
"Effect-of", "Cost-of", "Risk-with", etc.

The risk with a completely open registry is that any
fool might want to register headers related to his
favourite religious fanatism, or spammers might want
to register headers favoring their web sites.

Say that someone wanted to register "Best-Porn-Website"
or "Days-Before-Judgement-Day" as e-mail headers in
a completely open registry!

So I do agree that some kind of control of what we
allow is needed. In general, I have a feeling that
the discussion is nearing consensus.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Wed, 06 Feb 2002 13:43:34 -0500
Sender: [email-masked]

> >But I can't help but wonder if there aren't other, more
> >controversial proposals that people want to deploy without
> >community review, and that's why they're trying to get IETF
> >to say that we don't need review of mail protocol extensions
> >before deploying them.
> 
> No, we are not trying to deploy without community review, but rather in
> parallel with community review. 

either way, I don't think it's something that IETF should encourage -
especially not for critical services like email.

Keith

To: [email-masked]
Xref: clerew local.mime:980
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Wed, 6 Feb 2002 10:02:29 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>But I can't help but wonder if there aren't other, more 
>controversial proposals that people want to deploy without
>community review, and that's why they're trying to get IETF
>to say that we don't need review of mail protocol extensions
>before deploying them.

No, we are not trying to deploy without community review, but rather in
parallel with community review. That is why I have suggested that no entry
should be made to the provisional register (or whatever it gets called)
unless there is an identified forum where it is to be discussed.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:979
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Newsgroups
Date: Wed, 6 Feb 2002 09:58:29 GMT
Lines: 46
Sender: [email-masked]

In <p05100318b885d5bd8ff0@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>At 19.21 +0000 02-02-04, Charles Lindsey wrote:
>>Well Usefor is addressing the "Newsgroups" in e-mail problem. But
>>basically you are right. A header is usually invented first of all for one
>>particular protocol. When it comes to be adopted into another, it usually
>>will be found to be not a perfect fit (though one should try to use as
>>much or the original as possible). So we have adopted MIME (written for
>>email) into Usefor, but we have had to flesh out a few corners,
>>discourages certain usages, and so on (but not half the amount of change
>>that HTTP had to make to it).

>The problem was that "Newsgroups" in e-mail had two different
>meanings:

>(a) The same as in news, indicating which newsgroup this message
>     has been sent to.

>(b) In personal answers to news articles, indicating in which
>     newsgroup the message appeared which this is a personal
>     answer to.

Usefor blesses the first usage (it MAY be used) and deprecates the second
(SHOULD NOT).

It also provides the Posted-And-Mailed header, which can be used in
conjunction with (a).

BTW, Posted-And-Mailed is a good example of a header that has crept into
common usage in spite of the lack of any standard. As far as I can tell,
it arose from discussion on one of the news.software.* newsgroups, at
about the same time as the Mail-Copies-To header (both these are now
fairly widely deployed). It is a good example of a header that would have
gone into a provisional register, if such had existed at the time.

-- 
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: [email-masked]      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

To: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 05 Feb 2002 22:10:08 -0800
Lines: 19
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> well, a wild bird sighting report is not a bad thing.  and I could also
> make analogies with similar kinds of reports that are even more useful -
> reports of the Ebola virus, for example.

*nod*  And I think that's a reasonable summary description of the list
that Dan is currently maintaining.  It's just a list of the headers that
people are using.

> if that's what people want, fine, but I don't like calling it a
> registry.

Which is why it makes me a little uncomfortable to see it proposed as an
IANA function, mostly because I expect a bit more editorial control than
that to go into an IANA registry.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: 6 Feb 2002 00:44:18 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Charles Lindsey writes:
> And (AIUI) it contains just whatever Dan thinks it ought, or ought
> not, to contain.

The point of http://cr.yp.to/immhf.html, http://cr.yp.to/smtp.html, etc.
is interoperability. An accidental conflict of header field names is an
interoperability problem. An open list, properly used, eliminates this
problem.

If you actually look at the list, you'll see more than 100 field names,
not counting all the different Resent-* names, which are described as a
single syntactic rule. You'll see X-X-Sender even though Pine's use of
that field is a truly horrible idea.

---Dan

Date: Tue, 5 Feb 2002 19:35:56 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Newsgroups
Cc: [email-masked]
Sender: [email-masked]

At 19.21 +0000 02-02-04, Charles Lindsey wrote:
>Well Usefor is addressing the "Newsgroups" in e-mail problem. But
>basically you are right. A header is usually invented first of all for one
>particular protocol. When it comes to be adopted into another, it usually
>will be found to be not a perfect fit (though one should try to use as
>much or the original as possible). So we have adopted MIME (written for
>email) into Usefor, but we have had to flesh out a few corners,
>discourages certain usages, and so on (but not half the amount of change
>that HTTP had to make to it).

The problem was that "Newsgroups" in e-mail had two different
meanings:

(a) The same as in news, indicating which newsgroup this message
     has been sent to.

(b) In personal answers to news articles, indicating in which
     newsgroup the message appeared which this is a personal
     answer to.

Since there are many much used UAs which produce "Newsgroups"
in e-mail in both these ways, the solution which was agreed
when I discussed this several years ago, was to say that if
"Newsgroups" appears in e-mail, the recipient should disregard
it, and if you want to indicate in e-mail that a particular
message has also been published in a newsgroup, you should
instead use "Posted-To".

Is this the solution which usefor has arrived at, or have
you some other solution to the problem?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Tue, 5 Feb 2002 12:41:58 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 18.10 +0000 02-02-04, Charles Lindsey wrote:
>Dan's registry is unofficial, and not everybody knows where to find it.
>And (AIUI) it contains just whatever Dan thinks it ought, or ought not, to
>contain. An IANA registry would be findable, authoritative, and would have
>defined rules (the purpose of this discussion is to see what those rules
>should look like, of course).

In the case of RFC 2076, I have tried to not only
present my opinion, but also that of other people.
Whenever I get a comment on it, I try to rewrite
it. Before publication, Ned Freed reviewed the
whole text and I made a number of changes based
on his suggestions. The present version, however,
at http://www.dsv.su.se/jpalme/ietf/mail-headers/,
contains however more than twice the number of
headers of the RFC, and no one has made any
complete review of the text.

We might ask one or two specialists read the
latest version, and then re-publish it as a
new RFC, outdating the previous RFC.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:972
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Tue, 5 Feb 2002 10:38:07 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> Dave Crocker <[email-masked]> writes:

>hence, rather than "provisional" i suggest using the term "proprietary".

No, I don't think "proprietary" is right, because these things don't
always (or even usually) come from "vendors".

For example, if this provisional/whatever registry has been in existence
at the present time, then various header in the current Usefor draft would
have been in it, but I don't think Usefor would regard itself as a
"proprietor".

BTW, there is one Usefor header ("Replaces") that would have been placed
in the registry, and later removed (because we decided not to proceed with
it in the present draft).

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Tue, 05 Feb 2002 10:00:15 -0500
Sender: [email-masked]

> But, at the end of the day,
> what the people out there are looking for is something that gets their
> headers into use, at least on a trial basis.

I've generally found that when someone produces a well-written 
proposal to do something that is obviously useful, and they've
taken the time to clearly address the potential negative 
consequences of their proposal, that it's not too difficult to
get that proposal published as some kind of RFC - either 
Experimental, Informational, or Proposed Standard can generally
be produced in a matter of weeks.  A working group is generally
not needed for these cases (of course, that's up to the ADs to
decide).

The process generally bogs down either because the proposal isn't 
complete or well-written, or when the proposal fails to address 
valid (and usually predictable) concerns.   Sometimes these are
inherently difficult to address, and sometimes addressing these 
concerns involves resolving a conflict between the valid interests 
of multiple constituencies.  But when the process bogs down
it is generally a good indication that the proposed protocol or
extension should *not* be widely deployed in its current form.

People do sometimes argue endlessly about minutiae, but that's 
usually because there are more fundamental issues at stake.
Once the fundamental conflicts are addressed, the minutiae can be
sorted out. 

For two specific headers that have been mentioned here: X-Priority 
and X-Face, I don't see any problem with publishing their definitions 
as at least Informational RFCs.  There are certainly other precedents for 
documenting protocol extensions in RFCs even when those extensions
violated the rules in effect at the time - e.g. unapproved use of TCP
port numbers has been documented, as has unapproved use of PPP 
extensions, and variant/incorrect use of ASN.1 tags.

But I can't help but wonder if there aren't other, more 
controversial proposals that people want to deploy without
community review, and that's why they're trying to get IETF
to say that we don't need review of mail protocol extensions
before deploying them.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Tue, 05 Feb 2002 09:23:16 -0500
Sender: [email-masked]

> >I don't see any reason at all that IESG should be spending much
> >time debating ideas that don't have a supporting constituency
> >larger than the set of authors of the document just in order to
> >keep it from looking like IETF is supporting their boneheaded ideas.
> 
> In that case you let the Area Director, or his nominated expert, be the
> first line of defence. Then the IESG only needs to get involved if the
> expert's ruling is appealed.

well, I was talking specifically about the I-D review process.

of course, for many kinds of protocol extensions, the review process 
works just this way - the designated expert serves to offload the IESG.  
but different protocols vary in the kinds of harm that extensions can do. 
the use of a designated expert in some cases doesn't mean it's 
applicable to all protocol extension mechanisms.

Keith

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Tue, 05 Feb 2002 09:20:18 -0500
Sender: [email-masked]

> > p.s. this is starting to sound more like a wild bird sighting report
> > than the traditional IANA registry.
> 
> Heh.  Yes, that's a much more succinct way of making the point that I was
> trying and not really succeeding at making.

well, a wild bird sighting report is not a bad thing.  and I could also
make analogies with similar kinds of reports that are even more useful -
reports of the Ebola virus, for example.

if that's what people want, fine, but I don't like calling it a registry.

the fact that some things occur frequently in the wild does not 
necessarily make it desirable to propagate them further.   in some
cases it is an indication that they need to be suppressed or eradicated.

Keith

To: [email-masked]
Xref: clerew local.mime:971
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Tue, 5 Feb 2002 10:32:20 GMT
Lines: 21
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I don't see any reason at all that IESG should be spending much
>time debating ideas that don't have a supporting constituency
>larger than the set of authors of the document just in order to
>keep it from looking like IETF is supporting their boneheaded ideas.

In that case you let the Area Director, or his nominated expert, be the
first line of defence. Then the IESG only needs to get involved if the
expert's ruling is appealed.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:957
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Mon, 4 Feb 2002 19:06:32 GMT
Lines: 54
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I'm arguing that any document series is only valuable if it has
>some editorial standards, and that trying to be "too open" with
>that series just wastes our time and resources and invites
>confusion - even if you and I both know that not all RFCs are
>standards, and not all standards are worth implementing.

Quite so. I have proposed two features of such an editorial standard:

(1) Existence of an accessible specification.

(2) Existence of a forum for discussion.

I think I would add two more:

(3) Automatic removal as soon as (1) or (2) ceases to hold.

(4) Machinery to remove entries that are plain "bad".

Of course, we need to put more flesh on those bare bones. Under (1), we
might say "Internet Drafts only", though I feel that is too restrictive.

Under (4), Graham's draft says that the IESG can insist on removal of an
entry (or, in practice, probably an Area Director or his nominated
"expert"). That would be the minimum requirement - you could perhaps
invent further hurdles. And perhaps the IESG should be able to appoint a
different "proponent" (for example, if a header is proposed, and the IESG
decides to set up a working group to move it forward to a standard, then
the working group chair automatically takes control of the registry
entry).

But the chief problem is this. You can make the hurdles higher (insist on
all sorts of tests for whether a header is "suitable") or you can make
them lower (accept every proposal regardless). But, at the end of the day,
what the people out there are looking for is something that gets their
headers into use, at least on a trial basis. The full IESG standards-track
mechanism is seen as too slow (though for sure it remains the final
arbiter). If you make the hurdles too high, people will just ignore them
and carry on regardless (much what happens at the moment). The art of the
matter is to set them at a level which gives us (TINU) more control over
the process than we have at present, which means we have to persuade the
people out there that using our machinery is worth their while.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:960
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Mon, 4 Feb 2002 19:31:41 GMT
Lines: 55
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>If we can come up with a review process to assign such a rating,
>I'd be willing to have the registry accept almost everything.  
>But I still think there would be a need for the review process 
>to be able to refuse a registration - for instance

>- because the person was registering the name in an attempt to 
>  prevent someone else from using it, 
>- because the field name was misleading, performing a different
>  function than it claimed,
>- because the proposer wanted a header name registered for 
>  no other purpose than to say he had one (vanity names),
>- because the proposer was using the process for the sole purpose 
>  of wasting people's time,

Yes, these are the Trolls. In uk.*, we are currently battling against
trolls in our config group, and having to deal with troll RFDs which have
nothing to do with the creation of wanted newsgroups.

Yes, there must be a mechanism for dealing with these. Graham's present
draft allows the IESG to require an entry to be removed from the
provisional register. Maybe we need more than that.

>It might sound silly that people would do such things, but I've 
>seen all of these things done or attempted with other registries.

>There's a second class of things that are bad technically -
>for instance

>- things that belong in the envelope rather than the header,
>- things that would cause security or privacy violations,
>- things that would impair the functionality of the mail system,
>- things that would cause mail loops or sorcerer's apprentice
>  syndrome

I think those things would be rather easier to deal with than pure trolls,
especially if we insist on the existence of a discussion forum associated
with each entry. Moreover, there is time for the forum to discuss the pros
and cons and it will likely resolve the issue before ther IESG needs to
step in. But in the case of the trolls, you want them out fast (OTOH, it
would take a really eager troll to take the trouble to create a spec AND
set up a forum).

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:959
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Mon, 4 Feb 2002 19:21:38 GMT
Lines: 38
Sender: [email-masked]

In <p05100301b882bc546fb2@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>At 22.23 -0800 02-02-02, Dave Crocker wrote:

>>Registering header names that have different associated 
>>specifications, depending upon which protocol service is 
>>being used, is highly counterproductive.  (I'd say 
>>"silly", but the role of inflammatory contributor to this 
>>thread is well and truly taken, already.)

>But when this is (unfortunately) already the case, such as
>with "Newsgroups" in e-mail versus news, and "Date" in
>e-mail versus HTTP, the registry should reflect this
>reality, even if we do not like it. The registry can
>then either warn against some or all use of this header
>name, or just describe the different usage in different
>standards.

Well Usefor is addressing the "Newsgroups" in e-mail problem. But
basically you are right. A header is usually invented first of all for one
particular protocol. When it comes to be adopted into another, it usually
will be found to be not a perfect fit (though one should try to use as
much or the original as possible). So we have adopted MIME (written for
email) into Usefor, but we have had to flesh out a few corners,
discourages certain usages, and so on (but not half the amount of change
that HTTP had to make to it).

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:958
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Mon, 4 Feb 2002 19:11:36 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Graham Klyne <[email-masked]> writes:

>There is no requirement for uniqueness in the provisional registry.  In 
>theory, the original registrant can change their provisional registration 
>and if that no longer corresponds to a wideley followed practice of the 
>original registration then someone else may reinstate the original 
>registration as a new entry.

Well it has to be unique to the extent that there can only be one
outstanding proposal for a given header within a given protocol at one
point in time.

>The problem I do see is that the change of registration details may occur 
>silently.  But if the cited document is not an RFC, then there is no 
>(IETF-ish) control over changes to the specification document cited by the 
>registration.

Yes, the IESG must have some ultimate control. Your present draft gives
them power to remove an entry - maybe the details of that need fleshing
out some more. For example, one of the powers they may need is to replace
a registrant by a different registrant.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:956
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Mon, 4 Feb 2002 18:10:40 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> (1) A specification published in an accessible place. That might be a
>> web site, an Internet Draft, or even an experimental RFC.

>An Internet Draft is clearly not sufficient to register a header for
>standardization because it expires and the registry entry doesn't.

Yes it does. You build in a rule that if the published spec ceases to
exist/expires/whatever, then the entry in the registry automatically goes.
That is why it is called "provisional" (or whatever we decide). Only the
"full" registry of standardized headers is permanent.

>I don't see any point in putting details that may change or be dropped
>entirely into an IETF header registry.  If that's what you want, just use
>Dan's registry.

Dan's registry is unofficial, and not everybody knows where to find it.
And (AIUI) it contains just whatever Dan thinks it ought, or ought not, to
contain. An IANA registry would be findable, authoritative, and would have
defined rules (the purpose of this discussion is to see what those rules
should look like, of course).

-- 
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: [email-masked]      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

To: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 04 Feb 2002 17:57:56 -0800
Lines: 10
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> p.s. this is starting to sound more like a wild bird sighting report
> than the traditional IANA registry.

Heh.  Yes, that's a much more succinct way of making the point that I was
trying and not really succeeding at making.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Mon, 04 Feb 2002 20:08:59 -0500
Sender: [email-masked]

> >There is no requirement for uniqueness in the provisional
> >registry.  In theory, the original registrant can change
> >their provisional registration and if that no longer
> >corresponds to a wideley followed practice of the original
> >registration then someone else may reinstate the original
> >registration as a new entry.
> 
> Good idea! That is rather similar to my idea that in some
> cases where consensus could not be reached, the registry
> should list the different alternative views/definitions.

I agree that it's useful to be able to list multiple 
registrations for non-standard fields - and perhaps 
also to describe variant practices for standard fields.

Keith

p.s. this is starting to sound more like a wild bird
sighting report than the traditional IANA registry.

Date: Mon, 4 Feb 2002 17:15:56 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Sender: [email-masked]

At 20.06 +0000 02-02-03, Graham Klyne wrote:
>There is no requirement for uniqueness in the provisional 
>registry.  In theory, the original registrant can change 
>their provisional registration and if that no longer 
>corresponds to a wideley followed practice of the original 
>registration then someone else may reinstate the original 
>registration as a new entry.

Good idea! That is rather similar to my idea that in some
cases where consensus could not be reached, the registry
should list the different alternative views/definitions.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 04 Feb 2002 09:46:56 -0800 (PST)
From: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
To: Keith Moore <[email-masked]>
Cc: Dave Crocker <[email-masked]>, Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

> > > > Basic RFC rule:  informational specs are published.
> > >
> > >In fact, that's not the rule.  The rule is closer to:
> > >The RFC Editor decides, unless the document is approved by IESG.
> > >Because the RFC Editor has always exercised some degree of
> > >editorial control, and has never published any random document
> > >that someone submitted.
> >
> > oh?  that contradicts actual history, Keith, as well as the premise behind
> > the RFC series.

> This is what Jon told both me personally and IESG, and I heard him
> say it on multiple occasions.  I don't believe the current policy is
> significantly different.  And the RFC series today isn't quite the
> same as originally envisioned.

I suspect the relevance of this to the header registry discussion is getting
rather tenuous at this point, but in hopes of putting this to rest...

The current informational RFC publication policy is pretty much what Keith said
it was. Someone asks the RFC Editor for publication. Then the RFC Editor asks
the IESG to review and comment. If nobody objects it is then back in the RFC
Editor's court. If the IESG has a problem with publication it drafts a note
explaining why. The RFC Editor evaluates the IESG's position. If the RFC Editor
agreees the author is told the document will not be published in its present
form. If the RFC Editor does not agree it informs the IESG of its decision to
publish anyway and the IESG then has the option of writing an IESG note to be
included in the RFC explaining why it is a bad idea or whatever.

The RFC Editor, usually in consultation with the IESG, does reevaluate and
change its editorial policies from time to time. (A policy change regarding
documents with excessive numbers of authors is forthcoming, for example.) But
this usually leads to document revisions, not outright document rejections.

In practice most informational submissions end up getting published. In the
relatively uncommon cases where the IESG has a problem with pulication the RFC
Editor has in my experience gone along with that assessment most of the time.

I've been on the IESG for almost two years now, and before that I was the IAB's
liason to the IESG for a year, and this is how it has always worked during that
time. I can recall only one case where I strongly disagreed with the RFC
Editor's decision to publish something the IESG objected to.

I've been involved in the IETF since late 1989, and I know of cases where the
RFC Editor declined to publish as early as 1992-1993. However, I don't
know what the process was back then.

Does this take IESG time? Sure. I've written several "do not publish" notes in
my time on the IESG (and if memory serves I believe the RFC Editor has gone
along in every case) and they aren't particularly easy to write. But I don't
find the time they take to be overwhelming. And while I find the argument that
the Web makes it possible for anyone to publish things without the bother
associated with the RFC series pretty compelling, I see real value in having an
independent RFC Editor function. Checks and balances are good things even when
you don't agree with the outcome in specific cases. I therefore view any shift
in policy in this area less in terms of "faster/better rejection of boneheaded
ideas" and more in terms of how it would impact organizational independence.

				Ned

Date: Sun, 03 Feb 2002 22:16:28 -0800 (PST)
From: [email-masked]
Subject: LMTP extension (was: I-D ACTION:draft-klyne-msghdr-registry-02.txt)
To: Keith Moore <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

> > At 02:48 PM 2/2/2002 -0500, Keith Moore wrote:
> > >My concern is for interoperability and reliability of Internet mail.
> > >I'm not as concerned with labelling something "right" or
> > >"wrong" as with encouraging behavior that makes email work better.
> >
> > Indeed, that was exactly Larry's concern, too.  He wanted to be able to
> > publish a specification but there was no venue for doing that.

> It's hard for me to believe that neither the IESG nor the RFC Editor
> was willing to publish a spec for an LMTP extension.  Granted, a
> registry might be even better, but if other registries are any
> indication, we'll probably still publish specifications as RFCs
> and just put pointers to the RFCs in the registry.  I think it's a
> stretch to say "there was no venue".
 
I assume this refers to draft-murchison-lmtp-ignorequota-01.txt. If so, I see
no problem with getting it published as an RFC. All you need to do is submit it
to the RFC Editor for publication as informational. 

				Ned

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 04 Feb 2002 11:56:21 -0500
Sender: [email-masked]

> > > Basic RFC rule:  informational specs are published.
> >
> >In fact, that's not the rule.  The rule is closer to:
> >The RFC Editor decides, unless the document is approved by IESG.
> >Because the RFC Editor has always exercised some degree of
> >editorial control, and has never published any random document
> >that someone submitted.
> 
> oh?  that contradicts actual history, Keith, as well as the premise behind
> the RFC series.

This is what Jon told both me personally and IESG, and I heard him
say it on multiple occasions.  I don't believe the current policy is 
significantly different.  And the RFC series today isn't quite the 
same as originally envisioned.

> > > And, by the way, there is no empirical basis for claiming that all that
> > > IETF review produces a useful effect.
> >
> >No, there's not - because you can't do a controlled experiment.
> 
> "empirical" does not require a controlled experiment.  however your
> response does demonstrate the problem with our making strong statements
> about human behavior.  namely it demonstrates that we do not have the tools
> for making such statements about future occurrences involving subtleties of
> human choice.

We cannot make absolutely accurate predictions.  We can, however,
exercise judgement based on experience.  

> >But the IETF's role (for better or worse) is to try to determine
> >the sense of a broad community about which proposals are good
> 
> Again you are confusing IETF review and approval with IANA registration.

IANA registration of message header fields would essentially be an extension 
mechanism for IETF protocols that use 822-style headers. IANA follows IETF 
policy for registration of protocol extensions.  Such policies vary from one
protocol to another.  In particular, the ease of creating extensions varies 
according to the a judgement of the benefit vs. harm that will ensue from
making extensions easy or difficult.  

Keith

Date: Mon, 04 Feb 2002 08:35:49 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

At 11:08 AM 2/4/2002 -0500, Keith Moore wrote:
> > Basic RFC rule:  informational specs are published.
>
>In fact, that's not the rule.  The rule is closer to:
>The RFC Editor decides, unless the document is approved by IESG.
>Because the RFC Editor has always exercised some degree of
>editorial control, and has never published any random document
>that someone submitted.

oh?  that contradicts actual history, Keith, as well as the premise behind 
the RFC series.

> > And, by the way, there is no empirical basis for claiming that all that
> > IETF review produces a useful effect.
>
>No, there's not - because you can't do a controlled experiment.

"empirical" does not require a controlled experiment.  however your 
response does demonstrate the problem with our making strong statements 
about human behavior.  namely it demonstrates that we do not have the tools 
for making such statements about future occurrences involving subtleties of 
human choice.

>But the IETF's role (for better or worse) is to try to determine
>the sense of a broad community about which proposals are good

Again you are confusing IETF review and approval with IANA registration.

Different goals, different criteria.  Please keep them separate.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 04 Feb 2002 11:08:55 -0500
Sender: [email-masked]

> >The time spent doing such reviews was time taken away from other,
> >far more useful activities.  If the IESG had the option of saying
> >"don't publish this as an RFC"  and having it stick, then it
> >wouldn't have been necessary to take up so much time explaining
> >why bad ideas are bad.
> 
> 
> Basic RFC rule:  informational specs are published.  

In fact, that's not the rule.  The rule is closer to:
The RFC Editor decides, unless the document is approved by IESG.
Because the RFC Editor has always exercised some degree of
editorial control, and has never published any random document
that someone submitted.

> And, by the way, there is no empirical basis for claiming that all that
> IETF review produces a useful effect.

No, there's not - because you can't do a controlled experiment.

But the IETF's role (for better or worse) is to try to determine
the sense of a broad community about which proposals are good
and which aren't.  you seem to want to have the IETF rubber stamp
proposals without any review.  that would be diluting the value
of IETF's work, and there's simply no need for IETF to be doing that.

Keith

Date: Mon, 04 Feb 2002 07:57:53 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

At 09:12 AM 2/4/2002 -0500, Keith Moore wrote:
>The time spent doing such reviews was time taken away from other,
>far more useful activities.  If the IESG had the option of saying
>"don't publish this as an RFC"  and having it stick, then it
>wouldn't have been necessary to take up so much time explaining
>why bad ideas are bad.

Basic RFC rule:  informational specs are published.  You want to change 
that to:  informational specs are published if someone approves.

The rest of the details are minor, compared with this considerable change 
that you want to impose.

And, by the way, there is no empirical basis for claiming that all that 
IETF review produces a useful effect.

(fyi, i was on the iesg when the rule for that review and comment was 
created.  seemed like a good idea at the time.  these days, i think that 
simply making clear the thing is not a standard is sufficient.

hence, rather than "provisional" i suggest using the term "proprietary".

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 04 Feb 2002 09:12:08 -0500
Sender: [email-masked]

> >Right. In this case, however, I think what we do is shift the "burden of
> >proof": If you want to register a header field in the "non-standard"
> >registry, that's all well and good, but the IETF may, by some consensus
> >process, put a note on your registration that says, "This is boneheaded;
> >don't use". What we want to do is get the bar lowered enough so that some
> >benign and widely deployed header field can be registered and documented
> >without having to wait for consensus on "the best way to do this".
> 
> Good idea.  This matches what is done for non-standards track RFCs.

What happens is this: when someone wants to publish a non-standards 
track RFC, the IESG is asked to look at it.  The IESG can in principle 
ask to put a note on the RFC that says "this is boneheaded; don't use".  
In practice (at least while I was on IESG) the IESG spent a tremendous 
time reviewing such documents and trying to craft language that explained 
*why* a particular idea was boneheaded. because although the IESG 
could also recommend "don't publish", the RFC Editor might publish it 
anyway, and because many people don't bother looking at the status 
of an RFC before implementing it.  So the IESG occasionally spent time 
crafting detailed explanations, but the RFC Editor wouldn't always 
publish these intact, so there ensued a debate between IESG members
and the RFC Editor about it.

The time spent doing such reviews was time taken away from other,
far more useful activities.  If the IESG had the option of saying
"don't publish this as an RFC"  and having it stick, then it 
wouldn't have been necessary to take up so much time explaining 
why bad ideas are bad.

I don't see any reason at all that IESG should be spending much
time debating ideas that don't have a supporting constituency
larger than the set of authors of the document just in order to
keep it from looking like IETF is supporting their boneheaded ideas.

Similarly, I don't see why IETF should create a header registry
that makes it easier to legitimize boneheaded ideas than it is
to legitimize good ideas.  That's exactly opposite of IETF's mission.

Header fields that are worthy of wide deployment will nearly always 
take more time to develop than a boneheaded or naive approach - because
in order to make an idea worthy of wide deployment it is necessary
to consider a wider range of interests, and that takes time and effort.

Keith

Date: Mon, 04 Feb 2002 10:11:02 +0000
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

In the spirit of pointing out possible misunderstandings...

At 09:42 PM 2/3/02 -0500, Keith Moore wrote:
>- because the person was registering the name in an attempt to
>   prevent someone else from using it,

The current proposal places no uniqueness requirement on non-standard 
header registrations, so pre-emption should not be a concern.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Mon, 04 Feb 2002 09:25:27 +0000
To: Keith Moore <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Russ Allbery <[email-masked]>, [email-masked]
Sender: [email-masked]

At 21:54 03/02/2002 -0500, Keith Moore wrote:
> > Also, IMHO, it would be useful if, as well as people being able to submit
> > header entries, email software authors could say which headers their
> > software uses (ie. reads and/or writes). That way, it would give an
> > indication of whether a header is actually useful or not, and whether a
> > non-standard header may be worth making into a standard one.
>
>It might be interesting information, but it shouldn't be taken to indicate
>whether deployment of the header is useful or desirable.

No, but it could give an indication about whether it might be a good idea 
to take the header specification further. ie if 'x-myheader: useful info' 
is used by 90% of email software, maybe it should be looked at and have a 
formal RFC made for it, but if it's only used by one package, then it's 
probably OK being left as a custom 'x-' header.

(Arguments about HOW to change an 'x-' header to a 'standard' header aren't 
really part of the registry discussion IMHO)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Sun, 03 Feb 2002 21:18:08 -0800
To: Pete Resnick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

At 10:47 PM 2/3/2002 -0600, Pete Resnick wrote:
>Right. In this case, however, I think what we do is shift the "burden of 
>proof": If you want to register a header field in the "non-standard" 
>registry, that's all well and good, but the IETF may, by some consensus 
>process, put a note on your registration that says, "This is boneheaded; 
>don't use". What we want to do is get the bar lowered enough so that some 
>benign and widely deployed header field can be registered and documented 
>without having to wait for consensus on "the best way to do this".

Good idea.  This matches what is done for non-standards track RFCs.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Mon, 04 Feb 2002 00:24:36 -0500
Sender: [email-masked]

> On 2/3/02 at 9:42 PM -0500, Keith Moore wrote:
> 
> >If we can come up with a review process to assign such a rating, I'd 
> >be willing to have the registry accept almost everything. But I 
> >still think there would be a need for the review process to be able 
> >to refuse a registration - for instance...
> [Abuses listed]
> 
> OK, maybe we can close in on an answer here. The current document states:
> 
>     The IESG MAY appoint a domain expert to control registration if it is
>     judged that the facility is being abused.
> 
> Now, personally I think that most of the abuses you cite won't 
> actually happen and that there is certainly utility in having easy 
> registration. However, I certainly accept that such abuses 
> theoretically possible. Would it be enough if the expert was able to 
> unregister such fields if they were deemed of this sort? I take it 
> that having a stupid registration of this sort in the registry for 
> 24-48 hours has limited potential for widespread damage.

I think the expert (if that is the method chosen) should have to 
explicitly approve entries.  If there were a 24-48 hour deadline,
it would be too easy to miss it.  I also think that the document
needs to make clear that the expert has the power to refuse entries
that are considered abusive.

> (For the record, I really couldn't care less about the "vanity" 
> folks. If people want a "vanity" field name, we can deal with that in 
> the "technically bad" category below.)

I don't care much about this either - unless people flood the 
registry with vanity field names.

> >There's a second class of things that are bad technically -
> [...]
> >In those cases it might be better to document what's bad about the 
> >idea than to just refuse to register it.
> 
> Right. In this case, however, I think what we do is shift the "burden 
> of proof": If you want to register a header field in the 
> "non-standard" registry, that's all well and good, but the IETF may, 
> by some consensus process, put a note on your registration that says, 
> "This is boneheaded; don't use". What we want to do is get the bar 
> lowered enough so that some benign and widely deployed header field 
> can be registered and documented without having to wait for consensus 
> on "the best way to do this".

no, I don't think these things should go in the registry until 
there's some consensus on whether it's a good idea.  

Just to be clear - I accept that it's useful to have deployed header 
fields documented, and that it's useful to have a place where one can 
go to find out the syntax and semantics and standardization level and 
applicability of a header field.  But I don't think it's at all 
desirable for new folks to be implementing header fields just because
other folks are implementing them, without a shared understanding of 
whether it's a good idea.

The idea that we should make it easier for some (supposedly) "benign 
and widely deployed header field" to be even more widely implemented 
"without having to wait for consensus" on how to do this strikes
me as essentially a means to bypass the consensus process.  
And it's the same process that made such a mess out of HTTP.
  
> >But I would still not want for such registrations to automatically 
> >preempt other uses of the same field name.
> 
> I don't see any big problem if field names get taken; there are 
> plenty of words (and combinations thereof) that can be used for a 
> field name and I find it hard to imagine us running out of ways to 
> express a particular concept in a field name. However, if there 
> really is such a problem, would the above unregistration mechanism 
> solve this?

maybe.  But I don't like the idea that the nonstandard field should
get the "obvious" name and the standard field has to get a name
that seems less obvious and more strained.  You and I both know
that too many implementors don't read the specifications enough 
even when the protocol is standardized and  well-documented.
It's too easy for a naive implementor to think that the obvious name
is the one that should be implemented.  That doesn't improve
the reliability of Internet mail, and it doesn't make other implementors
work any easier.

> >Also, I view the idea that anybody can define whatever header fields 
> >they wish, as similar to the idea that anybody can define whatever 
> >top-level domains he wishes.
> 
> I don't find the comparison at all apt, and actually I think you are 
> being hyperbolic. Operationally and socially, large numbers of TLDs 
> would have a serious effect on the behaviors of lots of people. I 
> don't see an equivalence in header fields.

I don't think that header fields are as "attractive" a target for
abuse as TLDs.  However I do think that making it too easy for people
to define their own header fields also threatens to introduce a 
kind of semantic drift.  Controlled vocabularies don't work well 
without controls.

> 
> In any case, what I really want to know is:
> 
> - Is it enough to have the IESG set up a policeman only if it turns 
> out that there are abuses?
> - Is it OK that new registrations are "innocent until proven guilty"?
> 
> My personal take is "yes" on both.

my personal take is "no" on both.

Keith 

Date: Sun, 3 Feb 2002 22:47:55 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

On 2/3/02 at 9:42 PM -0500, Keith Moore wrote:

>If we can come up with a review process to assign such a rating, I'd 
>be willing to have the registry accept almost everything. But I 
>still think there would be a need for the review process to be able 
>to refuse a registration - for instance...
[Abuses listed]

OK, maybe we can close in on an answer here. The current document states:

    The IESG MAY appoint a domain expert to control registration if it is
    judged that the facility is being abused.

Now, personally I think that most of the abuses you cite won't 
actually happen and that there is certainly utility in having easy 
registration. However, I certainly accept that such abuses 
theoretically possible. Would it be enough if the expert was able to 
unregister such fields if they were deemed of this sort? I take it 
that having a stupid registration of this sort in the registry for 
24-48 hours has limited potential for widespread damage.

(For the record, I really couldn't care less about the "vanity" 
folks. If people want a "vanity" field name, we can deal with that in 
the "technically bad" category below.)

>There's a second class of things that are bad technically -
[...]
>In those cases it might be better to document what's bad about the 
>idea than to just refuse to register it.

Right. In this case, however, I think what we do is shift the "burden 
of proof": If you want to register a header field in the 
"non-standard" registry, that's all well and good, but the IETF may, 
by some consensus process, put a note on your registration that says, 
"This is boneheaded; don't use". What we want to do is get the bar 
lowered enough so that some benign and widely deployed header field 
can be registered and documented without having to wait for consensus 
on "the best way to do this".

>But I would still not want for such registrations to automatically 
>preempt other uses of the same field name.

I don't see any big problem if field names get taken; there are 
plenty of words (and combinations thereof) that can be used for a 
field name and I find it hard to imagine us running out of ways to 
express a particular concept in a field name. However, if there 
really is such a problem, would the above unregistration mechanism 
solve this?

>Also, I view the idea that anybody can define whatever header fields 
>they wish, as similar to the idea that anybody can define whatever 
>top-level domains he wishes.

I don't find the comparison at all apt, and actually I think you are 
being hyperbolic. Operationally and socially, large numbers of TLDs 
would have a serious effect on the behaviors of lots of people. I 
don't see an equivalence in header fields.

In any case, what I really want to know is:

- Is it enough to have the IESG set up a policeman only if it turns 
out that there are abuses?
- Is it OK that new registrations are "innocent until proven guilty"?

My personal take is "yes" on both.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Paul Smith <[email-masked]>
cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 21:54:13 -0500
Sender: [email-masked]

> Also, IMHO, it would be useful if, as well as people being able to submit
> header entries, email software authors could say which headers their
> software uses (ie. reads and/or writes). That way, it would give an
> indication of whether a header is actually useful or not, and whether a
> non-standard header may be worth making into a standard one. 

It might be interesting information, but it shouldn't be taken to indicate
whether deployment of the header is useful or desirable.

Keith

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 21:42:39 -0500
Sender: [email-masked]

> >>Would it not be better to register everything, but to tag each
> >>entry with its degree of support.
> >
> >no, I don't think so.   I think we should tag each entry with its
> >degree of support, but that doesn't mean we should register
> >everything.
> 
> What is the harm in registering everything so long as it is labeled
> as "Came from God's mouth" or "Stupidest idea since square wheels; do
> not implement" or "No current consensus on what the heck this thing
> is"? 

If we can come up with a review process to assign such a rating,
I'd be willing to have the registry accept almost everything.  
But I still think there would be a need for the review process 
to be able to refuse a registration - for instance

- because the person was registering the name in an attempt to 
  prevent someone else from using it, 
- because the field name was misleading, performing a different
  function than it claimed,
- because the proposer wanted a header name registered for 
  no other purpose than to say he had one (vanity names),
- because the proposer was using the process for the sole purpose 
  of wasting people's time,

It might sound silly that people would do such things, but I've 
seen all of these things done or attempted with other registries.

There's a second class of things that are bad technically -
for instance

- things that belong in the envelope rather than the header,
- things that would cause security or privacy violations,
- things that would impair the functionality of the mail system,
- things that would cause mail loops or sorcerer's apprentice
  syndrome

In those cases it might be better to document what's bad about 
the idea than to just refuse to register it.   A lot depends
on the nature of the review process and the way that the 
information is presented to those who look for it.  But I would 
still not want for such registrations to automatically 
preempt other uses of the same field name.

> I've seen repeated historical harm in not doing so (i.e.,
> headers which are widely used for which no one has the token). Is
> there any evidence of harm in the future?

When we first set up the charset registry, someone registered a huge
number of charsets without any review.  Some of those definitions were 
wrong, and I seem to recall it being argued that having that many 
charsets registered was confusing - people didn't know which ones to use,
and it degraded interoperabliity.  So now we have a review process
in place for charset definitions.

Also, I view the idea that anybody can define whatever header fields
they wish, as similar to the idea that anybody can define whatever
top-level domains he wishes.  A few extra fields (or TLDs) that nobody
uses might not cause much problem, but if there is too much variation
in UA behavior (or the behavior of pseudo-root servers) then mail 
(or DNS) doesn't work well anymore.  I think it would be beneficial 
for everyone if there were more uniformity in behavior of mail 
processing software.  Since more options means less uniformity, I want 
to discourage the header-field-of-the-month club.

I do recognize that some of the existing fields are useful, that
UA vendors compete on features, and that customers demand 
features (sometimes whether they make sense or not).  But I think
we'll get both better functionality and a more manageable mail
system if we define new features by getting consensus on them than 
if we define new features by letting one vendor register a feature
and having everyone else implement it (with or without documentation).  
That's essentially how HTTP got to be such a mess.

Keith

Date: Sun, 03 Feb 2002 15:56:23 -0800
To: Jacob Palme <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: IETF mailing list on MIME and e-mail  <[email-masked]>
Sender: [email-masked]

At 09:37 PM 2/3/2002 +0100, Jacob Palme wrote:
>Would it not be better to register everything, but to tag
>each entry with its degree of support. The tag could
>have for example one of the following values:

yes,  but it's a good idea for a registry to try to avoid maintain 
redundant information.

so the field probably just needs to point to a Status Authority (IETF, ITU, 
etc.) with a URL as appropriate.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 21:07:05 -0500
Sender: [email-masked]

> Can you give an example of something dangerous?

- a field that doesn't belong in the mesage header,
  because it's intended for the message transport system
  rather than the recipient's user agent.  

- a field that would degrade the security or privacy
  of a user whose MUA implemented it - for instance,
  a field that provided automatic confirmation to the
  sender when a message were read.

Keith

Date: Sun, 3 Feb 2002 07:47:27 -0500
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

People often say header, but my assumption was "header" was
meant as the short form of "header field".

As for fields being horizontal in some sense, maybe in databases, but
not in protocols. An IP header has a number of fields, and an RFC2822
header has a number of fields. Pretty clear and conistent, IMHO. I'd
vote for the rfc2822 vocabularly, colloquial usage is too vague.

Sam

Quoting Philip Hazel <[email-masked]>, who wrote:
> On Thu, 31 Jan 2002, Dave Crocker wrote:
> > At 10:28 AM 1/31/2002 +0000, Charles Lindsey wrote:
> > >That is indeed the terminology defined in RFC 2822, but it is NOT the
> > >terminology used in common parlance throughout Usenet and other places.
> >
> > other places includes common conversation around the net.  an individual
> > "slot" is typically called a 'header'.  The set of them is typically called
> > 'headers'.
> 
> That's certainly true. ("What were the contents of the Received:
> header?" is a common kind of utterance.)
> 
> > it would be very nice to have a better distinction than that one character,
> > but we are not likely to change standard language at this juncture.
> 
> I have been trying, in the documents I write, to use "header line" for
> an individual "slot" because this is a phrase which I hope the majority
> of non-expert readers will understand. I rather suspect that "header
> field" will not be correctly understood, because in many people's minds,
> a "field" suggests *part* of a line (or record).
> 
> Colloquially, "lines" suggests a vertical collection of things whereas
> "fields" suggests a horizontal collection of things. Also, an RFC 2822
> message is already defined in terms of lines.
> 
> However, even "header line" is a bit of a mouthful. People always
> abbreviate where they can. I don't think there's any hope of eradicating
> the usage of "header" to mean a single "slot". A radical approach would
> be to recognize this, and redefine the terminology thus:
> 
> . A "header" is a single (logical) line with the following syntax....
> 
> . A message consists of a set of headers (called the "header section"),
> followed by a blank line, followed by a body.
> 
> Philip
> 
> -- 
> Philip Hazel            University of Cambridge Computing Service,
> [email-masked]      Cambridge, England. Phone: +44 1223 334714.
> 

-- 
Sam Roberts <[email-masked]> (Vivez sans temps mort!)

Date: Sun, 3 Feb 2002 16:55:26 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Sender: [email-masked]

On 2/3/02 at 4:28 PM -0500, Keith Moore wrote:

>>Would it not be better to register everything, but to tag each 
>>entry with its degree of support.
>
>no, I don't think so.   I think we should tag each entry with its 
>degree of support, but that doesn't mean we should register 
>everything.

What is the harm in registering everything so long as it is labeled 
as "Came from God's mouth" or "Stupidest idea since square wheels; do 
not implement" or "No current consensus on what the heck this thing 
is"? I've seen repeated historical harm in not doing so (i.e., 
headers which are widely used for which no one has the token). Is 
there any evidence of harm in the future?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sun, 03 Feb 2002 22:50:31 +0000
To: Russ Allbery <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

> >> I don't see any point in putting details that may change or be dropped
> >> entirely into an IETF header registry.  If that's what you want, just
> >> use Dan's registry.
>
> > There is a difference between a casual, personal activity, versus a
> > formal one operated by an organization.
>
>Yes, there is, but that's beside the point.
>
>I don't see any useful purpose served by a half-way registry that doesn't
>contain just standardized, documented, and reviewed headers, but
>simultaneously doesn't contain all the headers being used.  I do see a
>useful purpose served by both a registry that contains everything and a
>registry that contains only well-documented and reviewed headers.

I agree, I think it should contain EVERYTHING, with an indication of the 
'status' of headers - whether standard or non-standard etc.

Also, IMHO, it would be useful if, as well as people being able to submit 
header entries, email software authors could say which headers their 
software uses (ie. reads and/or writes). That way, it would give an 
indication of whether a header is actually useful or not, and whether a 
non-standard header may be worth making into a standard one. OK, I know 
this won't be perfect, since lots of people write email software and don't 
read standards etc, but it'd be interesting and useful.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Sun, 3 Feb 2002 16:47:02 -0500
From: Lawrence Greenfield <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

   From: Keith Moore <[email-masked]>
   Date: Sun, 03 Feb 2002 10:35:04 -0500
[...]
   But regardless, registering anything with a spec is simply too dangerous.

Sorry, I guess I'm not imaginative enough.  Can you give an example of
something dangerous?

Larry

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 03 Feb 2002 13:36:24 -0800
Lines: 18
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:

> the value judgement of the phrase 'half-way' can apply to what you
> prefer, too.

> If one is interested in interoperability, then publishing only
> specifications that are standardized, while excluding specifications
> that are not, is certainly no better than half-way.

By that argument, Dan's doing exactly the right thing, and anything less
than what Dan's doing is "half-way".

Personally, I think there's a clear utility at the other end of the
spectrum just because of the plethora of header-related RFCs that make it
hard to keep track of everything that's been standardized.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 16:28:05 -0500
Sender: [email-masked]

> Would it not be better to register everything, but to tag
> each entry with its degree of support. 

no, I don't think so.   I think we should tag each entry with
its degree of support, but that doesn't mean we should 
register everything.

Keith

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 15:55:59 -0500
Sender: [email-masked]

> At 03:04 PM 2/3/2002 -0500, Keith Moore wrote:
> >No, I've said on multiple occasions that it's reasonable and useful to
> >register extensions that have consensus but don't meet the 2026 requirements
> >for standards track.
> 
> please cite existing specifications for such a process that are used 
> elsewhere in the IETF community.

I've already done so - the SMTP extensions mechanism.
 
> > > it seems clear that you do not want to discuss a registry.  rather, you
> > > want to impose a standards process on all header name publications.
> >
> >It seems clear that you want to persuade others by misrepresenting my
> >views, and resorting to ridicule,
> 
> Keith, over the years you have seen me do ridicule more than once.  This 
> exchange isn't even a close approximation to that.
> 
> Presumably you do not wish to claim that a participant has no right to 
> attempt to summarize your views.  So if you do not agree with a particular 
> summary, feel free to provide a detailed correction.

The problem with that line of argument is that it forces me to defend my
own views against your mischaracterization - and in doing so, to move 
the discussion away from what the registry should look like to whether 
I said such-and-such.  I don't consider that an appropriate or useful 
direction.  (as it is, I'm still spending too much bandwidth arguing
about tangents like X- headers and RFC publication criteria.) 

> >Perhaps we simply disagree.  I don't think that documenting stupid
> >ideas that have no community support is a useful exercise of either
> >IETF's or the RFC Editor's time, energy, or network bandwidth.
> 
> We do it all the time.  

Yes, I know.  And it eats up a lot of our resources.  
 
> CMOT was stupid.  So was MIME.

At least MIME had community support.  
(CMOT was before my time, so I won't comment on it.)

> Perhaps we should to hold off on that kind of assessment and simply 
> distinguish between standard and non-standard.

I fully agree we should hold off on that kind of assessment.  That's
why I want decisions about whether to list a header field deferred 
until an assessment can be made about that particular header field.

As for standard vs. non-standard, I don't think that's the best place
to draw the line.  I'd far prefer "standards-track, consensus, or 
widely deployed" on one hand and everything else on the other.

> >Doing so just serves to degrade the value of the RFC document series
> >and confuses the marketplace.
> 
> Keith, I do encourage you to review the RFC document series.  

I see you haven't abandoned ridicule as an argument strategy.

> You are trying to treat the RFC series as a quality assurance process.  It 
> isn't.  The IETF standards process is.

I'm arguing that any document series is only valuable if it has
some editorial standards, and that trying to be "too open" with
that series just wastes our time and resources and invites
confusion - even if you and I both know that not all RFCs are
standards, and not all standards are worth implementing.

Now that we have the web, there's no longer a need to provide any 
random person with a venue for publication.  Folks who can't get 
their documents through our editorial process, or don't want to 
deal with it, can just publish documents on the web.  It's worked 
well for Dan - it lets him say whatever he wants without having 
to get agreement on it, and the fact that he can do that is a 
Good Thing.  That doesn't mean that IETF should publish whatever
Dan wants, or whatever you want, or whatever I want.  

Similarly, the registry should not automatically include whatever
Dan or you or I want.

> On the other hand, I want to use an existing model and you seem to want to 
> invent a new one.

I am happy to consider existing models. But it's not yet clear to me
that an existing model, without modification, is suitable for this case.

Keith

Date: Sun, 03 Feb 2002 20:12:12 +0000
To: Jacob Palme <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Cc: IETF mailing list on MIME and e-mail  <[email-masked]>
Sender: [email-masked]

At 06:28 PM 2/2/02 +0100, Jacob Palme wrote:
>At 19.00 +0100 01-10-03, Graham Klyne wrote:
>>>OTOH, this does not prevent some other protocol from reusing the same
>>>name, possibly with modified syntax, parameters, etc, but hopefully for
>>>some related purpose. For example, RFC 2616 does some markedly different
>>>things with its Content-Type header (but well within the spirit of MIME).
>>
>>Hopefully, there will be just one *defining* RFC.
>
>You have a counterexample yourself, "Date:" which has
>different syntax in mail and http.

Yes, indeed.  Since I wrote that I have been persuaded to a different 
viewpoint, which is reflected in the current draft.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Sun, 03 Feb 2002 20:06:28 +0000
To: Jacob Palme <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Cc: IETF mailing list on MIME and e-mail  <[email-masked]>
Sender: [email-masked]

At 06:28 PM 2/2/02 +0100, Jacob Palme wrote:

>>  3.4 Change control
>>
>>     Change control of a header registration is subject to the same
>>     condition as the initial registration; i.e.  publication of an IESG-
>>     approved RFC for a Normative Message Header, or on request of the
>>     indicated author/change controller for a Provisional Message Header.
>
>I can see problems with this. If a certain header is at the
>same time non-standard, and widely used, you cannot allow
>the person who happpens to register it first to have change
>control. After it has been put into the registry, IETF (or
>some other standards organisation) must in some way have
>change control, to stop people changing the definition of
>widely used, non-standard headers in ways which are not
>good and not in accordance with existing use.

Interesting point.  I do see a possible related problem, but not exactly 
the one you describe.

There is no requirement for uniqueness in the provisional registry.  In 
theory, the original registrant can change their provisional registration 
and if that no longer corresponds to a wideley followed practice of the 
original registration then someone else may reinstate the original 
registration as a new entry.

The problem I do see is that the change of registration details may occur 
silently.  But if the cited document is not an RFC, then there is no 
(IETF-ish) control over changes to the specification document cited by the 
registration.

I have some thoughts about this but, for now, I'm just observing.

Thanks,

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Date: Sun, 3 Feb 2002 21:37:17 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 10.35 -0500 02-02-03, Keith Moore wrote:
>There needs to be some way of determining whether putting that field name
>in the registry will benefit the community.  It could be IESG approval,
>it could be a consensus process,  or it could be something else. 
>Ideally the process would encourage people to not only publish their
>specifications but also to get review on them and to revise them
>(or discard them) in light of such review.
>
>But regardless, registering anything with a spec is simply too dangerous.

Would it not be better to register everything, but to tag
each entry with its degree of support. The tag could
have for example one of the following values:
- IETF standard
- IETF draft standard
- IETF proposed standard
- IETF experimental standard
- IETF historical standard
- ITU standard
- ISO standard
- Agreed in a consensus in a consensus forum
- Non-consensus, each alternative view is described in the registry
   (example: "Newsgorups" in e-mail)
- Use discouraged according to consensus in a consensus forum
- Vendor-specific
- Commonly used, but no consensus on specification
- Experimental, may become standard in the future

At 14.16 -0500 02-02-03, Keith Moore wrote:
>A registry introduces a third possibility - documenting practice that
>isn't either existing or desirable.

Or even explicitly undesirable!

At 15.04 -0500 02-02-03, Keith Moore wrote:
>No, I've said on multiple occasions that it's reasonable and useful to
>register extensions that have consensus but don't meet the 2026 requirements
>for standards track.  I believe I've also said that it's generally useful
>to document existing practice.   It's the "register any old random
>extension" idea that I have a problem with.

If the registry clarifies the non-support of the header, it is
still useful to have it there, so that people looking for
a particular header can get information about it.

Compare to dictionaries: They usually do not document only
"correct language" but also "existing language usage".
Like the word "gotten" which many people claim is slang,
even though it was standard English five hundred years ago.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sun, 03 Feb 2002 12:14:51 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 03:04 PM 2/3/2002 -0500, Keith Moore wrote:
>No, I've said on multiple occasions that it's reasonable and useful to
>register extensions that have consensus but don't meet the 2026 requirements
>for standards track.

please cite existing specifications for such a process that are used 
elsewhere in the IETF community.

> > it seems clear that you do not want to discuss a registry.  rather, you
> > want to impose a standards process on all header name publications.
>
>It seems clear that you want to persuade others by misrepresenting my
>views, and resorting to ridicule,

Keith, over the years you have seen me do ridicule more than once.  This 
exchange isn't even a close approximation to that.

Presumably you do not wish to claim that a participant has no right to 
attempt to summarize your views.  So if you do not agree with a particular 
summary, feel free to provide a detailed correction.

However jumping into ad hominems guarantees a process that is 
counterproductive or unpleasant.  Usually both.

>Perhaps we simply disagree.  I don't think that documenting stupid
>ideas that have no community support is a useful exercise of either
>IETF's or the RFC Editor's time, energy, or network bandwidth.

We do it all the time.  The fact that some are more theatrical stupid than 
others is quite secondary.

CMOT was stupid.  So was MIME.

Oops.  Perhaps stupid is in the eye of the reader.

Perhaps we should to hold off on that kind of assessment and simply 
distinguish between standard and non-standard.

>Doing so just serves to degrade the value of the RFC document series
>and confuses the marketplace.

Keith, I do encourage you to review the RFC document series.  It really 
does have quite a lot of crap in it.

You are trying to treat the RFC series as a quality assurance process.  It 
isn't.  The IETF standards process is.

The same for a simple IANA registration service.  It is not for quality 
assurance.  It is for registration.  The IETF does the Q/A part and imparts 
a special imprimatur for it.

Let's not confuse functions.

>You seem to forget that different protocols have different extension
>mechanisms, and different registries have different criteria - for
>good reasons.  I'm arguing about the criteria for *this* registry.

son of a gun.  I thought I was too.

On the other hand, I want to use an existing model and you seem to want to 
invent a new one.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Sun, 03 Feb 2002 12:06:44 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: msghdr-registry model consensus query
Sender: [email-masked]

>Hence I believe that draft-klyne-msghdr-registry should provide for 1. 
>standards-track headers, and 2. non-standards track headers for which 
>specifications are provided.

A tiny number of us seem to be engaged in the debate about the message 
header registration model.

I would like to request explicit feedback from others.

If the above model is acceptable, please say so.  If it is not, please say 
so (and why).

Thanks.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 15:04:19 -0500
Sender: [email-masked]

> At 02:44 PM 2/3/2002 -0500, Keith Moore wrote:
> > > >A registry introduces a third possibility - documenting practice that
> > > >isn't either existing or desirable.
> > >
> > > if someone wants to document it and share it, then it is desireable to
> > > somebody.
> >
> >the fact that somebody desires that a protocol extension be documented and
> >shared does not imply that it benefits the internet community for IETF
> >to help them.
> 
> it helps to stay with specific, stable criteria.
> 
> you previously said "desireable".
> 
> now you want to move to using the same criteria that are used for IETF
> standards.

No, I've said on multiple occasions that it's reasonable and useful to
register extensions that have consensus but don't meet the 2026 requirements 
for standards track.  I believe I've also said that it's generally useful 
to document existing practice.   It's the "register any old random 
extension" idea that I have a problem with.

> it seems clear that you do not want to discuss a registry.  rather, you
> want to impose a standards process on all header name publications.

It seems clear that you want to persuade others by misrepresenting my
views, and resorting to ridicule, rather than by explaining why your 
approach will improve reliability of Internet applications that use 
header fields.  Frankly, I expect better from you.
 
> >should IETF help "document and share" Fleming's IPv16 proposal?
> 
> yes.

Perhaps we simply disagree.  I don't think that documenting stupid
ideas that have no community support is a useful exercise of either
IETF's or the RFC Editor's time, energy, or network bandwidth.
Doing so just serves to degrade the value of the RFC document series 
and confuses the marketplace.

> you seem to be forgetting the difference between the IETF openness to
> sharing ideas with the IETF approval process for a subset of those ideas.
>
> you also seem to be forgetting that the model in the msg header registry
> proposal is already in use by IANA, so we are not inventing some high-risk
> thing here.

You seem to forget that different protocols have different extension
mechanisms, and different registries have different criteria - for
good reasons.  I'm arguing about the criteria for *this* registry.

Keith

Date: Sun, 03 Feb 2002 11:49:14 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:44 PM 2/3/2002 -0500, Keith Moore wrote:
> > >A registry introduces a third possibility - documenting practice that
> > >isn't either existing or desirable.
> >
> > if someone wants to document it and share it, then it is desireable to
> > somebody.
>
>the fact that somebody desires that a protocol extension be documented and
>shared does not imply that it benefits the internet community for IETF
>to help them.

it helps to stay with specific, stable criteria.

you previously said "desireable".

now you want to move to using the same criteria that are used for IETF 
standards.

it seems clear that you do not want to discuss a registry.  rather, you 
want to impose a standards process on all header name publications.

that's redundant with the existing standards prcess.

>should IETF help "document and share" Fleming's IPv16 proposal?

yes.

you seem to be forgetting the difference between the IETF openness to 
sharing ideas with the IETF approval process for a subset of those ideas.

you also seem to be forgetting that the model in the msg header registry 
proposal is already in use by IANA, so we are not inventing some high-risk 
thing here.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 14:44:49 -0500
Sender: [email-masked]

> >A registry introduces a third possibility - documenting practice that
> >isn't either existing or desirable.
> 
> if someone wants to document it and share it, then it is desireable to
> somebody.

the fact that somebody desires that a protocol extension be documented and 
shared does not imply that it benefits the internet community for IETF 
to help them.

should IETF help "document and share" Fleming's IPv16 proposal?

Keith

Date: Sun, 03 Feb 2002 11:32:40 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: [email-masked]
Sender: [email-masked]

At 02:16 PM 2/3/2002 -0500, Keith Moore wrote:
>A registry introduces a third possibility - documenting practice that
>isn't either existing or desirable.

if someone wants to document it and share it, then it is desireable to 
somebody.

the next level of determining desireability is the standards process.

we need to be careful that a registry process does not endeavor to be more 
than a registry.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 14:16:43 -0500
Sender: [email-masked]

> Among other things, having a standards body
> maintain an explicitly unstandardized list seems like a conflict of goals.

IETF groups often get in conflicts between documenting existing practice 
and describing desirable practice.  An IETF group can do either one
of these competently as long as it only tries to do one of them, and it
clearly understands which one it's doing.  But trying to do both is a 
recipe for disaster.

A registry introduces a third possibility - documenting practice that
isn't either existing or desirable.

Date: Sun, 03 Feb 2002 10:55:24 -0800
To: Russ Allbery <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 10:27 AM 2/3/2002 -0800, Russ Allbery wrote:
>Dave Crocker <[email-masked]> writes:
> > There is a difference between a casual, personal activity, versus a
> > formal one operated by an organization.
>
>Yes, there is, but that's beside the point.

actually, it is pretty much the entire point.

>I don't see any useful purpose served by a half-way registry that doesn't
>contain just standardized, documented, and reviewed headers,

the value judgement of the phrase 'half-way' can apply to what you prefer, too.

If one is interested in interoperability, then publishing only 
specifications that are standardized, while excluding specifications that 
are not, is certainly no better than half-way.

>The IETF is quite well-qualified to set up and establish the rules for
>maintaining the latter.

This is an IANA activity.  IANA already runs some registry services of the 
model proposed in msghdr-registry.

So if we are going to make assertions about appropriateness, we need to be 
sure to consider the full range of actual history and operation of IANA.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 03 Feb 2002 10:27:09 -0800
Lines: 29
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:
> At 10:11 AM 2/3/2002 -0800, Russ Allbery wrote:

>> I don't see any point in putting details that may change or be dropped
>> entirely into an IETF header registry.  If that's what you want, just
>> use Dan's registry.

> There is a difference between a casual, personal activity, versus a
> formal one operated by an organization.

Yes, there is, but that's beside the point.

I don't see any useful purpose served by a half-way registry that doesn't
contain just standardized, documented, and reviewed headers, but
simultaneously doesn't contain all the headers being used.  I do see a
useful purpose served by both a registry that contains everything and a
registry that contains only well-documented and reviewed headers.

The IETF is quite well-qualified to set up and establish the rules for
maintaining the latter.  I think it's poorly qualified to maintain the
former, and I don't think that it should try.

If some organization wants to pick up Dan's registry, that could arguably
make it more stable and useful, but I don't think the IETF is the right
organization to do that.  Among other things, having a standards body
maintain an explicitly unstandardized list seems like a conflict of goals.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 13:21:59 -0500
Sender: [email-masked]

> Well, for a header to get included in the Provisional Register you should
> need two things:
> 
> (1) A specification published in an accessible place. That might be a web
> site, an Internet Draft, or even an experimental RFC.
> 
> (2) A forum in which to discuss it. Which could be a mailing list or a
> Usenet newsgroup.

I think this would be a good start.  Though I'd strongly prefer that the
specification be published as an I-D (rather than say, an MS word document
on a web page somewhere), and that there be a permanent mailing list
for discussion of new header fields.

The other thing I'd like to see is some way of pushing back on dubious 
extensions.

Keith

Date: Sun, 03 Feb 2002 10:19:25 -0800
To: Russ Allbery <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked]
Sender: [email-masked]

At 10:11 AM 2/3/2002 -0800, Russ Allbery wrote:
>I don't see any point in putting details that may change or be dropped
>entirely into an IETF header registry.  If that's what you want, just use
>Dan's registry.

There is a difference between a casual, personal activity, versus a formal 
one operated by an organization.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 03 Feb 2002 10:11:00 -0800
Lines: 28
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> (1) A specification published in an accessible place. That might be a
> web site, an Internet Draft, or even an experimental RFC.

An Internet Draft is clearly not sufficient to register a header for
standardization because it expires and the registry entry doesn't.

> We could even go further and say that it was the ONLY route (that seems
> to be the position Russ is taking)

No, it's not.

> But if principles (1) and (2) were built into the system, many of
> Keith's objections would be satisfied. People would know what the
> current specification was. If they thought it was a dumb idea, or needed
> improvement, there is a place to make their concerns heard. And, because
> it is clearly provisional, they have ample warning that the details may
> change, or even that the idea might be dropped altogether (BTW, expiry
> of a draft without a durther draft should be automatic grounds for
> removal from the Provisional Registry).

I don't see any point in putting details that may change or be dropped
entirely into an IETF header registry.  If that's what you want, just use
Dan's registry.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.mime:921
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Sun, 3 Feb 2002 13:02:20 GMT
Lines: 70
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> And the recommendation for someone devising some experimental protocol
>> that is expected to require code in widely-deployed software is to use a
>> non-X header, whatever any standards might say. There are dangers in
>> this, but it is regarded as the lesser of the two evils.

>I think that's an (unintentionally) misleading way of putting it.  The
>recommendation is that when someone gets ready to *deploy* a protocol over
>e-mail outside of the originating organization or test base, they should
>use a non-X name; in other words, as soon as people start putting
>recognition of that name into normal software on a non-test basis, use of
>the X name is inappropriate since it then creates unnecessary work in
>future standardization.

>But by the time the protocol extension reaches that point, it should
>*already* be an I-D and the IETF consensus process can begin.

Well, for a header to get included in the Provisional Register you should
need two things:

(1) A specification published in an accessible place. That might be a web
site, an Internet Draft, or even an experimental RFC.

(2) A forum in which to discuss it. Which could be a mailing list or a
Usenet newsgroup.

Graham's present draft make provision for (1), but not for (2), but that
could easily be fixed.

An Internet Draft has the great advantage that it generally (always?) has a
mailing list attached to it (or even an IETF Working Group), so it
automatically provides (1) and (2). Indeed, an Internet Draft should be
regarded as the normal route to Provisional Registration (and it should
certainly be mentioned as such in Graham's draft). We could even go further
and say that it was the ONLY route (that seems to be the position Russ is
taking) but I am not so sure about that - it needs to be discussed.

But if principles (1) and (2) were built into the system, many of Keith's
objections would be satisfied. People would know what the current
specification was. If they thought it was a dumb idea, or needed
improvement, there is a place to make their concerns heard. And, because
it is clearly provisional, they have ample warning that the details may
change, or even that the idea might be dropped altogether (BTW, expiry of
a draft without a durther draft should be automatic grounds for removal
from the Provisional Registry).

>Exceptions of headers that reach widespread use without ever going through
>IETF standardization can be dealt with separately.  Encouraging people to
>take that route rather than properly documenting their extension in an
>IETF document strikes me as counter-productive.

>I see no purpose served by the provisional registry.

On the contrary, I think it could do pretty well exactly what you are
after.

-- 
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: [email-masked]      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

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sun, 03 Feb 2002 10:35:04 -0500
Sender: [email-masked]

> At 02:48 PM 2/2/2002 -0500, Keith Moore wrote:
> >My concern is for interoperability and reliability of Internet mail.
> >I'm not as concerned with labelling something "right" or
> >"wrong" as with encouraging behavior that makes email work better.
> 
> Indeed, that was exactly Larry's concern, too.  He wanted to be able to 
> publish a specification but there was no venue for doing that.

It's hard for me to believe that neither the IESG nor the RFC Editor
was willing to publish a spec for an LMTP extension.  Granted, a
registry might be even better, but if other registries are any
indication, we'll probably still publish specifications as RFCs 
and just put pointers to the RFCs in the registry.  I think it's a
stretch to say "there was no venue".
 
> >If we're arguing about what the rules for extensions should be, I'll
> >recommend a set of rules that I think will help promote interoperability
> >and reliability.
> 
> Here are some thoughts on the matter:
> 
> 
> Possible Goal(s)
> ----------------
> A registry effort like the one under discussion can step through a 
> hierarchy of purposes.  I believe the relevant levels are:
> 
> 1.  List standards for entries in the name space.
> 
> 2.  Associate a protocol specification with a unique entry in the name space.
> 
> 3.  Reserve a unique entry in the header name space.
> 
> #1 and #2 pertain to interoperability.  #3 probably permits users to avoid 
> stepping on each other's independent activities, but it does not rise to 
> the level of facilitating interoperability.
> 
> I have never fully understood the view that only "standards" should listed 
> in an IANA registry effort.  It seems to me that, in fact, interoperability 
> is the entire goal of the IANA registry, rather than the stricter political 
> correctness of only recognizing standards.  Note that such a rigorous 
> criterion is not the requirement for becoming an RFC, for example.

I would agree that "standards only" raises the bar too high.  But 
"anything that has a specification" sets the bar too low.

There needs to be some way of determining whether putting that field name
in the registry will benefit the community.  It could be IESG approval,
it could be a consensus process,  or it could be something else.  
Ideally the process would encourage people to not only publish their
specifications but also to get review on them and to revise them 
(or discard them) in light of such review.

But regardless, registering anything with a spec is simply too dangerous.

> Header Name/Semantics Uniqueness
> --------------------------------
> 
> TCP and UDP have independent port numbering spaces.  Theoretically, port 25 
> could have a different service, depending upon whether it is for UDP or for 
> TCP.  Fortunately, folks were clever enough to combine assignments.  I 
> suggest we do the same.

It's too late - there are already too many variations in use between
different protocols.  Furthermore it seems inevitable that when one
protocol uses another protocol's fields that the semantics of that
field are likely to change slightly - simply because the context in
which the field is used is different than before.  

> Content is content.  A header of a given name should have the same 
> semantics and, where possible, the same syntax no matter what content 
> service it appears in.

Header fields don't just describe content.

Keith

Date: Sun, 3 Feb 2002 16:21:37 +0100
To: IETF mailing list on e-mail headers <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 22.23 -0800 02-02-02, Dave Crocker wrote:
>I'm not thrilled with the vocabulary choice of 
>"provisional" for the description of something registered 
>under #2, since it implies a tentativeness in the 
>allocation and an eventual evaluation by the assignment 
>authority.    But quibbling about specific vocabulary is, 
>well, quibbling.

I agree! I suggest "non-standard" instead. But we have to
define a way for amending non-standard header name
descriptions. I think that some kind of IETF consideration
is wanted also for them. The result of the IETF
consideration may be:

- Use of this name is discouraged
- The creator can have change control (might be automatic
   for names beginning with "vnd-" followed by vendor acronym?)
- Some kind of IETF consensus is needed, even if the name
   is not a standard

>Registering header names that have different associated 
>specifications, depending upon which protocol service is 
>being used, is highly counterproductive.  (I'd say 
>"silly", but the role of inflammatory contributor to this 
>thread is well and truly taken, already.)

But when this is (unfortunately) already the case, such as
with "Newsgroups" in e-mail versus news, and "Date" in
e-mail versus HTTP, the registry should reflect this
reality, even if we do not like it. The registry can
then either warn against some or all use of this header
name, or just describe the different usage in different
standards.

---

A related issue: When a registry is started, it should at
the start have a content something like what I have in RFC
2076 (latest version: draft-palme-mailext-headers-06.txt).
I would suggest that we ask a few experts (Ned? Pete?
Keith?) to read throught it and check that the description
of each header is agreeable and can be moved to the
registry. Headers where these experts disagree could be
discussed in the [email-masked] mailing list. To avoid
the risk of 1000-message flame wars, we could say that
if the discussion in ietf-822 does not seem to lead to
consensus, the registry could just present the different
opinions (example: "Reply-To"), possibly, if we can agree
on that, with a warning.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 02 Feb 2002 22:23:56 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

At 02:48 PM 2/2/2002 -0500, Keith Moore wrote:
>My concern is for interoperability and reliability of Internet mail.
>I'm not as concerned with labelling something "right" or
>"wrong" as with encouraging behavior that makes email work better.

Indeed, that was exactly Larry's concern, too.  He wanted to be able to 
publish a specification but there was no venue for doing that.

>If we're arguing about what the rules for extensions should be, I'll
>recommend a set of rules that I think will help promote interoperability
>and reliability.

Here are some thoughts on the matter:

Possible Goal(s)
----------------
A registry effort like the one under discussion can step through a 
hierarchy of purposes.  I believe the relevant levels are:

1.  List standards for entries in the name space.

2.  Associate a protocol specification with a unique entry in the name space.

3.  Reserve a unique entry in the header name space.

#1 and #2 pertain to interoperability.  #3 probably permits users to avoid 
stepping on each other's independent activities, but it does not rise to 
the level of facilitating interoperability.

I have never fully understood the view that only "standards" should listed 
in an IANA registry effort.  It seems to me that, in fact, interoperability 
is the entire goal of the IANA registry, rather than the stricter political 
correctness of only recognizing standards.  Note that such a rigorous 
criterion is not the requirement for becoming an RFC, for example.

draft-klyne-msghdr-registry
---------------------------

Hence I believe that draft-klyne-msghdr-registry should provide for 1. 
standards-track headers, and 2. non-standards track headers for which 
specifications are provided.

Oh.  Gosh.  That's what it does.

I'm not thrilled with the vocabulary choice of "provisional" for the 
description of something registered under #2, since it implies a 
tentativeness in the allocation and an eventual evaluation by the 
assignment authority.    But quibbling about specific vocabulary is, well, 
quibbling.

Header Name/Semantics Uniqueness
--------------------------------

TCP and UDP have independent port numbering spaces.  Theoretically, port 25 
could have a different service, depending upon whether it is for UDP or for 
TCP.  Fortunately, folks were clever enough to combine assignments.  I 
suggest we do the same.

Registering header names that have different associated specifications, 
depending upon which protocol service is being used, is highly 
counterproductive.  (I'd say "silly", but the role of inflammatory 
contributor to this thread is well and truly taken, already.)

Content is content.  A header of a given name should have the same 
semantics and, where possible, the same syntax no matter what content 
service it appears in.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Sun, 3 Feb 2002 00:45:13 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

At 14.06 -0500 02-02-02, Lawrence Greenfield wrote:
>Ok, so Cyrus IMAP uses LMTP extensively, which uses SMTP extensions.
>Our LMTP server advertises "IGNOREQUOTA".  There's even an
>internet-draft about it (which hasn't expired, but it will in March).

The fact that Internet drafts expire, mean that the description
of a header field should either be documentet in an RFC,
which might be experimental, or in some text which is part
of the header registrty.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 2 Feb 2002 19:14:46 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Sender: [email-masked]

At 13.02 -0500 02-02-02, Keith Moore wrote:
>First,  I said we should "encourage" people to get 
>consensus before deployment,
>not that we should "force" people.  I agree that it's not possible to force
>people to get consensus before deploying code.  But practices that encourage
>review and consensus can still be useful.
>
>Second, there's a difference between gettting consensus and standardization.
>It's possible to get consensus on a proposal without meeting the 2026
>requirements for standards-track, and this happens frequently.
>
>Third, though IETF often does "implement first, make a standard afterwards"
>it's not often the case that the protocol that is first implemented becomes
>a standard without any changes.  And the protocols for which this does
>happen are usually those that had rough consensus (or at least some
>review and changes based on feedback) before deployment.

I have no disagreement with what you write above.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Russ Allbery <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Sat, 02 Feb 2002 14:48:12 -0500
Sender: [email-masked]

>    From: Keith Moore <[email-masked]>
>    Date: Fri, 01 Feb 2002 21:42:56 -0500
> [...]
>    We had a similar discussion regarding SMTP extension names, and I
>    like the compromise we came up with - SMTP extension names can be
>    reserved with either a standards-track document, or an experimental
>    document with IESG approval.  That allows extension names to be
>    reserved for proposals that are publicly documented and have had
>    a basic sanity check even if they're not deemed ready for prime time -
>    but if the extension proves worthy of standardization without
>    incompatible change, the same extension name can be used.
> 
> Ok, so Cyrus IMAP uses LMTP extensively, which uses SMTP extensions.
> Our LMTP server advertises "IGNOREQUOTA".  There's even an
> internet-draft about it (which hasn't expired, but it will in March).
> 
> Did we do the right thing?  We don't have a "standards-track document"
> nor IESG approval.  

My concern is for interoperability and reliability of Internet mail.
I'm not as concerned with labelling something "right" or
"wrong" as with encouraging behavior that makes email work better.

If we're arguing about what the rules for extensions should be, I'll
recommend a set of rules that I think will help promote interoperability
and reliability.  

If you ask me whether you should document a protocol extension and/or 
get review before deploying it, I'll recommend that you do so because 
I think that will promote interoperability and reliability (unless 
I'm firmly of the opinion that your extension is a Bad Idea, in which 
case I'll recommend that you don't deploy it at all and/or try to suggest
something that I think will work better.)

If you ask me what to do when you've already deployed a protocol extension, 
I'll recommend whatever actions I think will help promote interoperability 
and reliability.  

(Note that interoperability and reliability includes having email work
unsurprisingly and predictably across a wide range of user agents - 
and there is a general tendency for new extensions to any protocol
to introduce surprising behavior.)

What's the danger that someone else will use the same keyword (in either 
SMTP or LMTP) to mean something different?  What's the danger that someone 
else will try to implement your extension but do so in a way that harms 
interoperability or reliability of ail delivery?  What can you do to 
minimize such danger?

Even if the LMTP spec says it uses SMTP extensions, that doesn't mean 
that using a non-SMTP extension in LMTP is violating the SMTP standard,
nor does it mean that the rules for extending SMTP should inherently apply 
to LMTP.  

Still, it would be good to publish the spec for the extension as
an Informational or Experimental RFC, so that if others want to
implement something like this they'll have your spec to go by.

Keith

Date: Sat, 2 Feb 2002 14:06:38 -0500
From: Lawrence Greenfield <[email-masked]>
To: Russ Allbery <[email-masked]>, Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

   From: Keith Moore <[email-masked]>
   Date: Fri, 01 Feb 2002 21:42:56 -0500
[...]
   We had a similar discussion regarding SMTP extension names, and I 
   like the compromise we came up with - SMTP extension names can be
   reserved with either a standards-track document, or an experimental
   document with IESG approval.  That allows extension names to be 
   reserved for proposals that are publicly documented and have had 
   a basic sanity check even if they're not deemed ready for prime time -
   but if the extension proves worthy of standardization without 
   incompatible change, the same extension name can be used.

Ok, so Cyrus IMAP uses LMTP extensively, which uses SMTP extensions.
Our LMTP server advertises "IGNOREQUOTA".  There's even an
internet-draft about it (which hasn't expired, but it will in March).

Did we do the right thing?  We don't have a "standards-track document"
nor IESG approval.  Currently the only client/servers that recognize
the keyword are ours.  From my understanding of your previous
paragraph, if we were playing by the rules we should've never deployed
software like this.

If there was an open registry for such keywords, we would've
registered it, given a URL for a stable document (not an ID) that
explains what's going on, and maybe even said why we are or aren't
pursuing standardization.

Note that it's even more confusing: LMTP is an informational document
(it's not used over the internet) but extensions to it really consume
ESMTP extension space.

Larry

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: IETF mailing list on MIME and e-mail <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Sat, 02 Feb 2002 13:02:34 -0500
Sender: [email-masked]

> At 16.52 -0500 02-01-30, Keith Moore wrote:
> >  > I really should back off and see what other people think, but there's one
> >>  more viewpoint I'd like to offer:  it could be argued that the existence of
> >>  an open registry would have the opposite effect;  i.e. it could encourage
> >>  developers with half-baked ideas to come together, pool their thoughts and
> >>  come up with something more fully-baked?
> >
> >If the registry did have that effect, it would be a Good Thing.  But the
> >only way that I can see to have this effect is to encourage people to
> >get consensus on specifications for new fields before they are defined,
> >and especially, before they are widely deployed.
> 
> I do not think that is possible. If people feel the need
> for a header, they will implement it, even if there is no
> consensus. Take for example my suggestions for translation
> headers. You did yourself recommend, if I remember rightly,
> that we should implement it and get experience with it
> before asking to have it made into a standard. This is
> closely related to "experimental" standards and is the way
> IETF often work: Implement first, make a standard
> afterwards. Pros: The standard will be based on practical
> experience. Cons: A badly designed header may inadvertently
> get wide implementation.

First,  I said we should "encourage" people to get consensus before deployment,
not that we should "force" people.  I agree that it's not possible to force
people to get consensus before deploying code.  But practices that encourage
review and consensus can still be useful.

Second, there's a difference between gettting consensus and standardization.
It's possible to get consensus on a proposal without meeting the 2026 
requirements for standards-track, and this happens frequently.

Third, though IETF often does "implement first, make a standard afterwards"
it's not often the case that the protocol that is first implemented becomes 
a standard without any changes.  And the protocols for which this does 
happen are usually those that had rough consensus (or at least some
review and changes based on feedback) before deployment.

Keith

Date: Sat, 2 Feb 2002 18:28:35 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Sender: [email-masked]

>  3.4 Change control
>
>     Change control of a header registration is subject to the same
>     condition as the initial registration; i.e.  publication of an IESG-
>     approved RFC for a Normative Message Header, or on request of the
>     indicated author/change controller for a Provisional Message Header.

I can see problems with this. If a certain header is at the
same time non-standard, and widely used, you cannot allow
the person who happpens to register it first to have change
control. After it has been put into the registry, IETF (or
some other standards organisation) must in some way have
change control, to stop people changing the definition of
widely used, non-standard headers in ways which are not
good and not in accordance with existing use.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sat, 2 Feb 2002 18:28:42 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Sender: [email-masked]

At 12.02 +0000 01-10-03, Charles Lindsey wrote:
>I think the intention of this registry should be to supersede the function
>of RFC 2076 and its extensions.

I agree! I would not like to have to continue to
maintain RFC 2076 if a header registry exists.

At 12.52 -0400 01-10-03, Keith Moore wrote:
>It would be nice if there were a  standards-track document that clearly
>said: header "FOO" is bogus and you should neither generate it nor use it.

RFC2076 today specifically says that certain headers
are discouraged, mainly because of several existing
incompatible uses. If the new registry is to replace
RFC2076, it must cater also for specifically
non-recommended headers.

At 19.00 +0100 01-10-03, Graham Klyne wrote:
>>OTOH, this does not prevent some other protocol from reusing the same
>>name, possibly with modified syntax, parameters, etc, but hopefully for
>>some related purpose. For example, RFC 2616 does some markedly different
>>things with its Content-Type header (but well within the spirit of MIME).
>
>Hopefully, there will be just one *defining* RFC.

You have a counterexample yourself, "Date:" which has
different syntax in mail and http.

At 20.28 +0000 01-10-05, Charles Lindsey wrote:
>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.

A user of the registry would certainly get most help if one
search of the registry will suffice to find all information
about a particular header name. This means that there
should be one search point from which you can find them
all. Possibly, this search point could have
checkboxes to indicate that you only want to search for
standardised or only for HTTP or only for discouraged
headers. But in that case, the default should be that all
these checkboxes are checked.

At 16.52 -0500 02-01-30, Keith Moore wrote:
>  > I really should back off and see what other people think, but there's one
>>  more viewpoint I'd like to offer:  it could be argued that the existence of
>>  an open registry would have the opposite effect;  i.e. it could encourage
>>  developers with half-baked ideas to come together, pool their thoughts and
>>  come up with something more fully-baked?
>
>If the registry did have that effect, it would be a Good Thing.  But the
>only way that I can see to have this effect is to encourage people to
>get consensus on specifications for new fields before they are defined,
>and especially, before they are widely deployed.

I do not think that is possible. If people feel the need
for a header, they will implement it, even if there is no
consensus. Take for example my suggestions for translation
headers. You did yourself recommend, if I remember rightly,
that we should implement it and get experience with it
before asking to have it made into a standard. This is
closely related to "experimental" standards and is the way
IETF often work: Implement first, make a standard
afterwards. Pros: The standard will be based on practical
experience. Cons: A badly designed header may inadvertently
get wide implementation.

At 10.40 +0000 02-01-31, Charles Lindsey wrote:
>This matter has recently been discussed extensively on the USEFOR WG. The
>opinion seems to be that X-headers are more trouble than they are worth
>(especially if they come into widespread use and widely deployed software
>contains code that recognises them). It is also noted that RFC 2822 no
>longer distinguishes them as a special case.

i agree! X-headers cause more problems than they solve.

At 15.23 -0500 02-01-31, Keith Moore wrote:
>Offhand I cannot think of a single read/write X- field that has become a
>de facto standard, but I can think of several X- fields that are really
>bad ideas and which should never have been deployed even in a single
>implementation.  But at least they're easily distinguished from other fields.
>OTOH, most of the poorly designed fields that have gained wide deployment
>don't start with X-.

X-priority is widely used and has become a de-facto standard.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 01 Feb 2002 21:42:56 -0500
Sender: [email-masked]

> I think that's an (unintentionally) misleding way of putting it.  The
> recommendation is that when someone gets ready to *deploy* a protocol over
> e-mail outside of the originating organization or test base, they should
> use a non-X name; in other words, as soon as people start putting
> recognition of that name into normal software on a non-test basis, use of
> the X name is inappropriate since it then creates unnecessary work in
> future standardization.

I guess I wonder - is the burden of "unnecessary work in future 
standardization" consistently worse than the burden of dealing with
poorly-designed features that are widely deployed?  Certainly the
latter cases *me* more pain, and I know of a lot more of the latter
than the former.  But I'm thinking about email, not netnews or HTTP.
By being more concerned about "future standardization", than 
poorly-designed features, I think we'd be optimizing the rare case.

We had a similar discussion regarding SMTP extension names, and I 
like the compromise we came up with - SMTP extension names can be
reserved with either a standards-track document, or an experimental
document with IESG approval.  That allows extension names to be 
reserved for proposals that are publicly documented and have had 
a basic sanity check even if they're not deemed ready for prime time -
but if the extension proves worthy of standardization without 
incompatible change, the same extension name can be used.

> But by the time the protocol extension reaches that point, it should
> *already* be an I-D and the IETF consensus process can begin.

I'm not terribly concerned about proposals for which there is 
documentation and some consensus - even if it's not considered 
to meet 2026 requirements for proposed.  I'm much more concerned
about ad hoc extensions that some random person thought was a 
good idea but didn't bother to publish and/or get review.

Keith

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 01 Feb 2002 20:28:59 -0500
Sender: [email-masked]

> Whoa!  The current proposal on the table is pretty concrete, if not
> necessarily final.

sorry about that.  I was referring to the use of X- fields.

Keith

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 01 Feb 2002 17:02:30 -0800
Lines: 40
Sender: [email-masked]

Russ Allbery <[email-masked]> writes:

> But by the time the protocol extension reaches that point, it should
> *already* be an I-D and the IETF consensus process can begin.

> Exceptions of headers that reach widespread use without ever going
> through IETF standardization can be dealt with separately.  Encouraging
> people to take that route rather than properly documenting their
> extension in an IETF document strikes me as counter-productive.

> I see no purpose served by the provisional registry.

That wasn't sufficiently clear, or rather the above is from a particular
perspective that's not clearly noted.

I see no purpose served by a provisional registry under the aegis of the
IETF.  If you want a registry of every header that someone's claimed,
Dan's already running a perfectly usable one.  If you have no intention of
ever writing an IETF standards document for your header, I don't see why
you'd use an IETF header registry either.

In other words, an IETF registry is going to serve a particular body of
users, and for that use the above-quoted arguments apply.  If you don't
actually want to cooperate with the IETF, then the existence of an IETF
registry is going to be irrelevant to you, and you may as well just use
Dan's list.

It seems to me that one of the goals for a provisional header registry is
to actually provide some sort of "fast-track" process to register a header
with the IETF without actually going to the work of writing a formal
description of its semantics and subjecting it to group review.  I can
appreciate that sentiment; however, I don't think that's what the IETF
does.  If you want something quick and dirty, you can use the existing
lists of headers that don't guarantee anything beyond "someone's using
this."  If you want the process of writing an IETF standards document to
be easier, well, adding an end-run around the process isn't solving that
problem in the most direct or straightforward manner.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 02 Feb 2002 00:15:57 +0000
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: [email-masked]
Sender: [email-masked]

At 01:58 PM 2/1/02 -0500, Keith Moore wrote:
> > In any event, in this discussion, we've had 5 people talking in
> > addition to one of the 3 authors. I'd like to hear from anyone else
> > who supports Keith's view here, because if there's noone else, it's
> > starting to seem like we have rough consensus.
>
>... But I can't see how we have rough consensus
>when we don't even have a concrete proposal yet, and when it's not
>even clear what question is being asked.

Whoa!  The current proposal on the table is pretty concrete, if not 
necessarily final.

And I'm following the debate, looking for ways to satisfy all concerns if 
possible.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 01 Feb 2002 15:59:30 -0800
Lines: 9
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> Offhand I cannot think of a single read/write X- field that has become a 
> de facto standard,

X-Face.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 01 Feb 2002 15:57:12 -0800
Lines: 42
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> This matter has recently been discussed extensively on the USEFOR
> WG. The opinion seems to be that X-headers are more trouble than they
> are worth (especially if they come into widespread use and widely
> deployed software contains code that recognises them). It is also noted
> that RFC 2822 no longer distinguishes them as a special case.

I agree with this part.

> Current thinking on Usefor (as reflected in the current draft) is that
> X-headers are appropriate for informative headers that are intended only
> for human consumption (or for 'vanity' headers, and the like). There is
> a blanket ban on standardizing them.

I agree with this part too.

> And the recommendation for someone devising some experimental protocol
> that is expected to require code in widely-deployed software is to use a
> non-X header, whatever any standards might say. There are dangers in
> this, but it is regarded as the lesser of the two evils.

I think that's an (unintentionally) misleading way of putting it.  The
recommendation is that when someone gets ready to *deploy* a protocol over
e-mail outside of the originating organization or test base, they should
use a non-X name; in other words, as soon as people start putting
recognition of that name into normal software on a non-test basis, use of
the X name is inappropriate since it then creates unnecessary work in
future standardization.

But by the time the protocol extension reaches that point, it should
*already* be an I-D and the IETF consensus process can begin.

Exceptions of headers that reach widespread use without ever going through
IETF standardization can be dealt with separately.  Encouraging people to
take that route rather than properly documenting their extension in an
IETF document strikes me as counter-productive.

I see no purpose served by the provisional registry.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: 1 Feb 2002 21:28:36 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

Keith Moore writes:
> I've expressed some concerns about potential for misuse of the registry,
> specifically the need to keep it from being used as a way to "stake a 
> claim" on a header name or the meaning thereof,

Absolutely! Header field names such as Mail-Followup-To have economic
value, damn it. We can't let someone ``stake a claim'' to them on the
basis of some lame excuse such as ``preventing accidental conflicts.''

(How dare anyone deploy Mail-Followup-To software in the first place,
without written permission from the Internet Engineering Steering Group?
Tomorrow I bet they'll try to steal mail.com from the rightful owners!)

> or as a way to create "vanity" header fields

``Knoxville - A man was arrested today under the new federal laws
against headersquatting. The man, Keith Moore, had reserved all header
field names shorter than 8 characters at the Grand Unified Registry of
Fields (GURF), making those field names unusable to legitimate users.
Complaints from IBM and Microsoft, who wanted to use IBM-COM: and MSOFT:
respectively, triggered the federal action.''

> need to get those fields reviewed (and when applicable, their 
> definitions published) before widely deploying them.
  [ ... ]
> I can't think of a single example of a protocol that was standardized
> in the same form that it was initially deployed, and usually for good
> reasons.

Absolutely! We should never have deployed non-standard interfaces such
as C, and the original Internet protocols, and IRC, and HTTP, and Java,
and Internet telephones, and even something as simple as X-Loop. Look at
how many changes have been made to these interfaces!

We should have sat down in a big room and spent years hashing out
interfaces such as Ada and OSI and SIP and, of course, Quoted-Printable.
These interfaces, unlike C and the Internet and so on, were all designed
perfectly from the start---as you'd expect from a committee. That's why
they've been wildly successful!

> And I would far rather we reach consensus by respecting and understanding
> each other's concerns than by just trying to isolate me.

We're not trying to isolate you, Keith. We love your leadership! It's so
damnably difficult to design a working protocol without your input.
Anything that keeps you in the loop is good.

---Dan

To: [email-masked]
Xref: clerew local.mime:899
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 1 Feb 2002 12:12:29 GMT
Lines: 79
Sender: [email-masked]

In <a05100300b87f5ac633de@[216.43.25.67]> Pete Resnick <[email-masked]> writes:

>On 1/31/02 at 3:23 PM -0500, Keith Moore wrote:

>>I don't know where you get the idea that x-headers have been quite a 
>>problem.  As far as I can tell, they've been quite successful.
>>
>>Offhand I cannot think of a single read/write X- field that has 
>>become a de facto standard...

>X-Priority immediately comes to mind. X-Face is another. And these 
>are perfect examples of the problem: They define perfectly useful or 
>interesting pieces of data, they are in widespread use, but the 
>format of the fields cannot be documented because some bozo chose to 
>name them with an X-.

X-No-Archive: ...

 But even write-only fields are a problem: I 
>can't document for someone what exactly to put in X-Mailer because it 
>starts with an X-. That's a terrible state of affairs and a serious 
>problem.

Actually that's not so bad, since nobody cares what you actually put
inside it. But it is badly named (it only applies to mailers), which is
why Usefor is proposing to standardize User-Agent (which it borrowed brom
HTTP).

>But that's the point: You can't distinguish useful/good fields from 
>bogus/bad fields just by seeing if they start with an X-. And in 
>fact, if people would just register a field that they are about to 
>deploy, they would likely get some immediate feedback of its 
>boneheadedness when they go to document it.

Exactly. We provide machinery with enough hoops for them to jump through
that someone gets to look at it and provide the feedback, but not so many
hoops that they say "What the Heck!" and just go ahead without us.

Now here's a fine example for you all to look at. And it was generated by
widely deployed software (ezmlm). Perhaps someone can tell me which of
these headers are "official" in any sense:

Mailing-List: contact [email-masked]; run by ezmlm
Reply-To: [email-masked]
Date: Tue, 29 Jan 2002 22:47:25 +0000
From: Usenet Control <[email-masked]>
To: [email-masked]
Subject: Progress at Gradwell
Content-Length: 805

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:900
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 1 Feb 2002 12:20:31 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>I don't know how much we can control how X- fields are 'viewed' by
>people who don't read the RFCs to see what X- was intended to mean.
>The most we could do is write new RFCs that alter or clarify the
>meaning of X-.  But if people didn't read the old RFCs, will they
>read the new one?

But which RFCs actually tell you what X-fields are intended to mean? RFC
2822 is silent on the matter. Usefor currently mentions them for
essentially the "write-only" applications. Graham Klyne's draft provides
suitable discouragement (and that is probably the best place to say
whatever needs to be said).

-- 
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: [email-masked]      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

Delivery-Date: Fri Feb  1 13:58:53 2002
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 01 Feb 2002 13:58:50 -0500
Sender: [email-masked]

> >actually, it doesn't indicate that there is no spec (I've seen a 
> >spec for X-Face)
> 
> Where might I find this spec? Certainly not in any registry at IANA 
> that I know about.

No, I'm sure it's not there, and it's been probably 15 years since
I've seen it.  But I did see something of a specification one time
for the format and how to encode it in a header, included with
some software libraries that could generate faces from other 
images and patch exisiting mail programs to display the things.

If you want to find the spec I saw my best guess was that it was
in the faces package in comp.sources.unix - you might find it
in google's usenet archive.

> >but it is a good first-order indication that the field is not a de 
> >facto standard.
> 
> Later on, you write:
> 
> >2. it is perfectly reasonable to document X- Fields that are 
> >deployed, because it's almost always useful to document existing 
> >practice.
> 
> We're talking about protocol here. A "first-order indication" is the 
> equivalent of an educated guess. 

I could quibble about that, but let me take another direction:

Anytime an X- field is widely used, there's inherently a fair amount of 
guessing going on.  The guy who came up with the field is guessing
that it will work well in a wide variety of environments - most of
which he cannot be experienced with - and that it won't cause harm.
He's also guessing that the same field name isn't used by others.
Other folks who use it are guessing about how the field works and what 
it contains, whether there are varying implementations, etc.

I suspect you and I would agree that such guesswork can be dangerous 
and detrimental to interoperability.  I believe that such guesswork
should be discouraged, and that folks who are generating new header
fields need to get those fields reviewed (and when applicable, their 
definitions published) before widely deploying them.  Of course if 
they do that, then they don't need to use X- fields.

Also, sometimes the designer of the new field specifically intends
the field for private use only - because it's inherently specific
to a particular kind of software or because he/she *knows* it's not 
suitable or ready for general use.  X- is a useful way to indicate this.

> It should not take any guessing: 
> Let's say that down the road an X- field gets used for something 
> that, at the time, seems very unimportant. In the future, it turns 
> out that the field is vitally important to interoperation because 
> bunches of people start using it. 

But those folks are *already* guessing because they're using an X-
field - usually without *any* documentation about what it contains 
or how it works.  When we've got something that is "important to 
interoperation" and undocumented, that's a serious problem, because 
there will almost certainly be variation in the way that it's implemented.  

> Now, the current state of affairs 
> is that it *cannot* be a standard, by definition. We could, of 
> course, document it in an Informational RFC. However, an implementor 
> who comes along and sees this important X- field, having the 
> "first-order indication" takes an educated guess that this *isn't* a 
> de facto standard, tries to wing it in his implementation, gets it 
> wrong, and screws it up royally. (This does occasionally happen with 
> things that are standards too, but you're pretty much encouraging it 
> in this case.)

Again, I have no problem with a registry documenting X- fields.
So if the registry existed the implementor could check to see if there
were any documentation on the X- field before trying to "wing it".
In other words, the decision to stop searching for the spec and to 
"wing it" wouldn't be based on the presence of "X-", it would be based 
on the fact that it wasn't listed in the registry.

But even with the registry documenting the field, the fact that a 
field is an X- field should still give the implementor a clue that 
the field might have been been widely deployed before it was 
documented, that such documentation as is available might not fully 
describe variations found in practice, and that the original implementor 
might have screwed it up royally, and that perhaps it shouldn't be 
propagated at all.  Because trying to retroactively document a protocol 
is at least as dangerous as trying to "wing" the implementation - 
perhaps moreso, since the bugs in the document may propagate more 
widely than those in a single protocol implementation.

(I know of at least one attempt to document a protocol in an Informational
RFC that botched the description of that protocol in several ways, 
and as a result, has significatly degraded interoperability of that
protocol.  (RFC 1179 - LPD))

Now you might argue that the registry could contain bits that say:
"this field was widely deployed without review" or "this field was 
widely deployed before it was publicly documented" or "this field 
was documented by observing how it worked, not by the guy who 
designed it".  And those might be good things.  

But X- would still be useful, because it's sometimes a good thing
to clearly indicate in the field name  "you probably shouldn't be 
using this!"  And I'd argue that such indication is appropriate
for any field which is deployed without prior review.   The guy
who designed the field can't reliably determine by himself whether 
his field is going to be good for other people to use, so the 
default assumption needs to be that it shouldn't be used by other people.

> Wouldn't it have been better for all involved to not make any 
> assumptions about the relative worth of a header field just by 
> looking at its name, but rather to have a registry which every 
> implementor can simply look at, check the references for the field, 
> see what it's syntax and semantics are supposed to be, look at its 
> relative worth ("most important field since To:" vs. "stupidest idea 
> anyone ever came up with"), and have a good chance of doing the right 
> thing?

Is it any better to make assumptions about the "relative worth" of the
field based on how frequently it appears?   As far as I can tell,
X- is indeed a better indicator of "relative worth" than frequency
of appearance. I know of several widely used nonstandard fields that 
are either garbage or brain-damaged, but I know of only one or two
X-fields that are even useful for general implementation, and none of
them are of vital importance.

I think it will be difficult for the registry to contain much 
information about relative worth.   At best we could say one
of three things:

"no consensus" on relative worth
"consensus that it's so bad it should be deleted"
"consensus that it shouldn't be used"
"consensus that it's good"

but there would probably often need to be some caveats even on "good"

> >I think there is too much tendency on the part of many implementors 
> >to try to implement any field that 'looks useful'.  We used to call 
> >this creeping featurism, but I've also heard it called 'header 
> >disease'.
> 
> If we had a registry, an implementor could quickly and easily look up 
> a field and see if it really is useful.

It's not clear - because people will not necessarily agree on the 
utility of a field, and getting a clear indication of "usefulness" 
would essentially require getting consensus on that - and this
assumes we know how the header is supposed to work.  And without
a requirement to reach a consensus on "usefulness", the registry
would provide a means of circumventing the standards process.

> >If there's a need for a Priority header field perhaps we should 
> >define one (or use the RFC 1327/X.400 one as it seems to be 
> >reasonable) rather than trying to promote an existing field that 
> >seems to have been used differently by different MUAs.
> 
> 1. If we had a registry at the time, we would have noticed that there 
> was already an "Importance" field in 1327 and used that. In fact, now 
> most MUAs send both (because older versions still depend on 
> X-Priority).
> 
> 2. Most MUAs get X-Priority correct. If we had the ability to 
> standardize it, less folks would have screwed it up. If there wasn't 
> this idea that X- fields were a good thing, we wouldn't have used 
> X-Priority in the first place and it likely would have been 
> standardized.

I think we're getting too hung up on "X- is good / X- is bad".
We're focusing on what's bad about X- and ignoring the things that
are good about it.  I think we can partially fix your problem 
with "X-" by allowing those fields to be documented in a registry.

But the only way to fix the real problem - which is that people
deploy protocol extensions without documenting them or getting
review on them - is to get people to document and get review on
protocol extensions *before* they get deployed.  I fail to see how
abolishing X- will encourage that.
 
> >1. we're better off having a visual convention that indicates that a 
> >field wasn't reviewed and/or standardized before use, than not 
> >having such a convention - because this separates the experimental 
> >and private-use fields from standard fields, and in practice the 
> >presence of X- tends to mean that the field isn't well thought-out.
> 
> A registry alone would serve the same purpose without causing 
> implementors to try to guess using the "first-order indications".

Again, I think it will be very difficult for the registry to provide 
a fair indication of quality.

> >however, there's nothing wrong with standardizing a new field and 
> >having that standard recommend UA behavior regarding generating the 
> >X- field that preceeded it.
> 
> Maybe we don't belong to the same standards organization:
> 
> - In the IETF, deployment traditionally *precedes* standardization. 

That is a myth.  Offhand, I can't think of a single example of a protocol 
that was standardized in the same form that it was initially deployed, 
and usually for good reasons.  There are nearly always serious 
problems with the first version of a protocol, because the folks who
designed that version were doing so in a vacuum, and didn't think about
some important aspect of deploying the protocol in the full diversity
of the Internet.

Now a well-designed protocol - especially one designed to be extensible -
might be able to be standardized with very few changes, and/or in a way
such that the standardized protocol interoperates with the pre-standard
version.  But this varies a lot from one protocol to another, and it's
hard to predict in advance whether you can do it with any particular
protocol.  In general, it's completely unrealistic to design and deploy a 
protocol and expect it to be standardized by IETF as-is.  That doesn't 
stop vendors from trying, but it doesn't work very often.

> First we see if something works in the world, then we write down what 
> does work. Only in more drastic cases (like IPv6) do we reverse that 
> process. That's what separates us from the ISO and the like.

That's simply not true.  Yes, we benefit from prototypes or experience 
with an existing protocol whenever we can.  And we often use an existing
protocol as a starting point for a standards-track protocol.  But the
vast majority of the time we don't standardize the protocol that was
previously deployed - we standardize some variant of it that we think
will work better for the entire Internet than the deployed version.

> - In the IETF, we have repeatedly learned that once something is 
> widely deployed, you are forced to retain backward compatibility in 
> order to retain interoperability. Standardizing a new field that 
> obsoletes an X- field fails that test miserably.

The compatibility issues are different for every protocol and every
protocol extension.  Sometimes you can get good backward compatibility,
sometiems you can't.  But whether the field name begins with an "X-"
or not is pretty much irrelevant to whether you can implement a protocol
extension that is worthy of standardization (meeting the 2026 requirements) 
while still retaining compatibility with pre-standard implementations.

> In any event, in this discussion, we've had 5 people talking in
> addition to one of the 3 authors. I'd like to hear from anyone else
> who supports Keith's view here, because if there's noone else, it's
> starting to seem like we have rough consensus.

I didn't see any CC's to the list on this message, so I've sent this
reply to you personally.  But I can't see how we have rough consensus
when we don't even have a concrete proposal yet, and when it's not 
even clear what question is being asked.

And I would far rather we reach consensus by respecting and understanding
each other's concerns than by just trying to isolate me.

If we're just talking about the desirability of a registry, I suspect 
we do have rough consensus - I haven't seen anybody say that a 
registry is inherently a bad idea or that it shouldn't accept X- fields.

I've expressed some concerns about potential for misuse of the registry,
specifically the need to keep it from being used as a way to "stake a 
claim" on a header name or the meaning thereof, or as a way to create
"vanity" header fields.  That doesn't preclude having a registry at all, 
but it does indicate the need for some care.

As for the desirability of X- fields, we might not have to reach 
consensus on this in order to decide what should go into a registry. 

Keith

Date: Fri, 1 Feb 2002 13:08:05 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 1/31/02 at 6:46 PM -0500, Keith Moore wrote:

>actually, it doesn't indicate that there is no spec (I've seen a 
>spec for X-Face)

Where might I find this spec? Certainly not in any registry at IANA 
that I know about.

>but it is a good first-order indication that the field is not a de 
>facto standard.

Later on, you write:

>2. it is perfectly reasonable to document X- Fields that are 
>deployed, because it's almost always useful to document existing 
>practice.

We're talking about protocol here. A "first-order indication" is the 
equivalent of an educated guess. It should not take any guessing: 
Let's say that down the road an X- field gets used for something 
that, at the time, seems very unimportant. In the future, it turns 
out that the field is vitally important to interoperation because 
bunches of people start using it. Now, the current state of affairs 
is that it *cannot* be a standard, by definition. We could, of 
course, document it in an Informational RFC. However, an implementor 
who comes along and sees this important X- field, having the 
"first-order indication" takes an educated guess that this *isn't* a 
de facto standard, tries to wing it in his implementation, gets it 
wrong, and screws it up royally. (This does occasionally happen with 
things that are standards too, but you're pretty much encouraging it 
in this case.)

Wouldn't it have been better for all involved to not make any 
assumptions about the relative worth of a header field just by 
looking at its name, but rather to have a registry which every 
implementor can simply look at, check the references for the field, 
see what it's syntax and semantics are supposed to be, look at its 
relative worth ("most important field since To:" vs. "stupidest idea 
anyone ever came up with"), and have a good chance of doing the right 
thing?

>I think there is too much tendency on the part of many implementors 
>to try to implement any field that 'looks useful'.  We used to call 
>this creeping featurism, but I've also heard it called 'header 
>disease'.

If we had a registry, an implementor could quickly and easily look up 
a field and see if it really is useful.

>If there's a need for a Priority header field perhaps we should 
>define one (or use the RFC 1327/X.400 one as it seems to be 
>reasonable) rather than trying to promote an existing field that 
>seems to have been used differently by different MUAs.

1. If we had a registry at the time, we would have noticed that there 
was already an "Importance" field in 1327 and used that. In fact, now 
most MUAs send both (because older versions still depend on 
X-Priority).

2. Most MUAs get X-Priority correct. If we had the ability to 
standardize it, less folks would have screwed it up. If there wasn't 
this idea that X- fields were a good thing, we wouldn't have used 
X-Priority in the first place and it likely would have been 
standardized.

>1. we're better off having a visual convention that indicates that a 
>field wasn't reviewed and/or standardized before use, than not 
>having such a convention - because this separates the experimental 
>and private-use fields from standard fields, and in practice the 
>presence of X- tends to mean that the field isn't well thought-out.

A registry alone would serve the same purpose without causing 
implementors to try to guess using the "first-order indications".

>however, there's nothing wrong with standardizing a new field and 
>having that standard recommend UA behavior regarding generating the 
>X- field that preceeded it.

Maybe we don't belong to the same standards organization:

- In the IETF, deployment traditionally *precedes* standardization. 
First we see if something works in the world, then we write down what 
does work. Only in more drastic cases (like IPv6) do we reverse that 
process. That's what separates us from the ISO and the like.

- In the IETF, we have repeatedly learned that once something is 
widely deployed, you are forced to retain backward compatibility in 
order to retain interoperability. Standardizing a new field that 
obsoletes an X- field fails that test miserably.

In any event, in this discussion, we've had 5 people talking in 
addition to one of the 3 authors. I'd like to hear from anyone else 
who supports Keith's view here, because if there's noone else, it's 
starting to seem like we have rough consensus.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Fri, 01 Feb 2002 13:45:13 -0500
Sender: [email-masked]

> So what am I saying?  I'm saying that I think we should do everything we
> can to (1) document what's out there (not "bless" it, but "document" it),
> and (2) make it easier to document it in the future, and to avoid
> collisions of conflicting usages.  And if that means having
> "X-Stupid-Field" in that list, then that's what it means. 

I don't think there's any disagreement on those things.  But I think
some of us have digressed from a conversation about the desirability
of the registry, to a conversation about the desirability of X-
fields.  

But I don't think we need to have consensus on the desirability of 
X- Fields in order to decide what should go into the registry.

Keith

Date: 1 Feb 2002 16:18:27 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

I have a mailing list, http://cr.yp.to/lists.html#imis, for Internet
mail implementors. You can report interoperability problems there.

Barry Leiba writes:
> More importantly, we see inconsistent usage of the "References" and 
> "In-Reply-To" fields in three different MUAs (two of which are even made by 
> the same company, the Windows and Mac versions of Eudora), and we see this 
> inconsistent usage's effect on a fourth MUA.

I wrote http://cr.yp.to/immhf.html to document what actually goes on in
the real world. In particular, http://cr.yp.to/immhf/thread.html covers
the interoperability problems you're talking about. It recommends a fix
in the message writer, and another fix in the message reader.

Similarly, http://cr.yp.to/immhf/index.html is the most comprehensive
published list of field names. It has several pointers to additional
information. If you have a new name, let me know; I'll add it to the
list. You don't need approval from control freaks like Keith.

---Dan

Date: Fri, 01 Feb 2002 08:47:58 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

In response to no item here in particular, I have .02331 Euro (at today's 
exchange rate) to stick in.

As Larry said, in response to Keith's
> what you seem to be wanting is for IETF to bless nonstandard practices
...we don't want the IETF to do anything but ask the IANA to maintain a 
list of explanations, describing what fields are, in fact, being used, and 
in what ways.

This is much like the argument about whether a dictionary should be 
descriptive or prescriptive -- whether it should tell how words *are* used, 
or how they *should be* used.  Look up "comprise", for instance.  The 
correct usage is "the U.S. comprises 50 states," but most of the time 
you're more likely to hear "the U.S. is comprised of 50 states."  And so 
most dictionaries will tell you that.  But when William Safire writes an 
articles in the NY Times on Sunday, about the word "comprise", he'll tell 
you that the former is right and the latter is wrong.  The dictionary is 
taking the role of IANA, registering "usage", so that when you hear/see it, 
and you look it up, you can see what's going on.  The RFCs are William 
Safire, telling you what you SHOULD do, what you MUST do, and what you MAY 
NOT do.

Let me give a real, practical example of why we need this, from my viewing 
of this very mailing list.  I have a server accumulating these messages and 
presenting them to me through NNTP, and I'm using MS OE to view them. 
Here's a subset of headers from four messages, which I'll refer to in the 
order below as K1, P1, K2, and D1:

> From: Keith Moore <[email-masked]>
> Message-Id: <[email-masked]>
> In-reply-to: Your message of "Thu, 31 Jan 2002 13:07:32 PST."
>    <[email-masked]>
>
> From: Pete Resnick <[email-masked]>
> Message-Id: <a05100301b87f78662990@[216.43.25.67]>
> In-Reply-To: <[email-masked]>
> References: <[email-masked]>
> X-Mailer: Eudora [Macintosh version 5.1fc3]
>
> From: Keith Moore <[email-masked]>
> Message-Id: <[email-masked]>
> In-reply-to: Your message of "Thu, 31 Jan 2002 16:43:18 CST."
>    <a05100301b87f78662990@[216.43.25.67]>
>
> From: Dave Crocker <[email-masked]>
> Message-Id: <[email-masked]>
> In-Reply-To: <[email-masked]>
> References: <Your message of "Thu, 31 Jan 2002 16:43:18 CST."
>    <a05100301b87f78662990@[216.43.25.67]>
> X-Mailer: QUALCOMM Windows Eudora Version 5.1

These message should have been shown, threaded, this way:
  K1 -> P1 -> K2 -> D1
but OE showed them this way:
  K1 -> P1 -> D1
  K2
(which, by the way, makes it hard to follow the discussion sometimes, 
because Keith's mail, lacking any "References" header field, is always 
shown at the top level of the thread).

What do we see from the above?  Well, that some mailers use X-Mailer, and 
some don't (so I don't know what Keith is using -- presumably it eschews 
"X-Mailer" because it (the header field, not the MUA) begins with an "X"). 
More importantly, we see inconsistent usage of the "References" and 
"In-Reply-To" fields in three different MUAs (two of which are even made by 
the same company, the Windows and Mac versions of Eudora), and we see this 
inconsistent usage's effect on a fourth MUA.
[I'm actually quite puzzled at what the Windows Eudora is doing, why 
message D1 says "in reply to K2", but "references P1"... but that's not a 
subject for this discussion.]

It would Really Be Nice if there were a place implementers could go to see 
how these, and other, fields are meant to be used, both by those MUAs 
generating them, and by those consuming them.

So what am I saying?  I'm saying that I think we should do everything we 
can to (1) document what's out there (not "bless" it, but "document" it), 
and (2) make it easier to document it in the future, and to avoid 
collisions of conflicting usages.  And if that means having 
"X-Stupid-Field" in that list, then that's what it means.  Perhaps there 
can be a clause that allows the IESG to put its comments on any registry 
entry, so that the IESG can label something with "This is a Bad Idea," when 
it finds that appropriate.  It's still better to know than not to.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

To: [email-masked]
Xref: clerew local.mime:898
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 1 Feb 2002 12:01:52 GMT
Lines: 43
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>X-headers are very useful for experimental features and private agreements -
>i.e. for the kinds of things where you need a new field -  but because it
>isn't going to affect many people, there's no need to go through the review
>process.  For similar reasons, they're okay for write-only fields even if
>they are widely deployed. 

True.

>IMHO X-headers for read/write fields shouldn't be used in widely deployed 
>code.

True. But sadly there already exists much widely deployed code that uses them.

>  If you need a new read/write header field for code that is going 
>to be in widely deployed you need to get consensus on that field name
>before you deploy it.

True in theory, but in the real world people do invent and deploy them
without such consensus. Indeed, this sometimes leads to poor names (such
as Mail-Copies-To which was a good idea which has been taken into Usefor,
but not the name we would have preferred).

>However for a vendor that refuses to get consensus, using a X- field for a 
>proprietary extension is less of a crime than using a field name that 
>doesn't begin with X- for a proprietary extension.

It's a hard call, but the view on Usefor seems to be that it is more of a
crime (though for sure you could point to actual examples to illustrate
either argument). Moreover, it is not necessarily "vendors" that are to
blame.

-- 
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: [email-masked]      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

To: [email-masked]
Xref: clerew local.mime:897
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Date: Fri, 1 Feb 2002 09:49:42 GMT
Lines: 20
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>Since the usefor draft is being revised, perhaps it affords an
>opportunity to migrate toward more uniform terminology?

It depends what you mean by "uniform". We took the view that the
terminology used, and widely understood, in common speech throughout the
Net, and as already used (with more or less consistency) in previous
documents regarding Netnews, should be regarded as "uniform".

-- 
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: [email-masked]      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

Date: Fri, 1 Feb 2002 09:13:32 +0000 (GMT)
From: Philip Hazel <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Charles Lindsey <[email-masked]>, <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

On Thu, 31 Jan 2002, Dave Crocker wrote:

>
> At 10:28 AM 1/31/2002 +0000, Charles Lindsey wrote:
> >That is indeed the terminology defined in RFC 2822, but it is NOT the
> >terminology used in common parlance throughout Usenet and other places.
>
> other places includes common conversation around the net.  an individual
> "slot" is typically called a 'header'.  The set of them is typically called
> 'headers'.

That's certainly true. ("What were the contents of the Received:
header?" is a common kind of utterance.)

> it would be very nice to have a better distinction than that one character,
> but we are not likely to change standard language at this juncture.

I have been trying, in the documents I write, to use "header line" for
an individual "slot" because this is a phrase which I hope the majority
of non-expert readers will understand. I rather suspect that "header
field" will not be correctly understood, because in many people's minds,
a "field" suggests *part* of a line (or record).

Colloquially, "lines" suggests a vertical collection of things whereas
"fields" suggests a horizontal collection of things. Also, an RFC 2822
message is already defined in terms of lines.

However, even "header line" is a bit of a mouthful. People always
abbreviate where they can. I don't think there's any hope of eradicating
the usage of "header" to mean a single "slot". A radical approach would
be to recognize this, and redefine the terminology thus:

. A "header" is a single (logical) line with the following syntax....

. A message consists of a set of headers (called the "header section"),
followed by a blank line, followed by a body.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.