Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Keith Moore <[email-masked]>, Lawrence Greenfield <[email-masked]>, [email-masked]
Date: Thu, 31 Jan 2002 20:25:24 -0500
List-Id: <ietf-822.imc.org>

> please supply the list of names that should be reserved.

since the X- convention is already well-established,
I'd suggest that anything that doesn't begin with X- should be
reserved for use by protocol extensions that have been 
approved via an IETF Consensus process.

(maybe if we were starting from scratch we could pick
a less "ugly" convention.  but frankly I don't think we 
could do much better than X-)

Keith

Date: Thu, 31 Jan 2002 17:18:01 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Lawrence Greenfield <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:49 PM 1/31/2002 -0500, Keith Moore wrote:
>all of this sounds fine to me.  I just don't want the registry to
>serve as a means to circumvent the standards process

excellent.  we agree entirely on this.

>or to allocate
>header field names that should be reserved for standards.

please supply the list of names that should be reserved.

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: Thu, 31 Jan 2002 19:49:56 -0500
Sender: [email-masked]

>    what you seem to be wanting is for IETF to bless nonstandard practices
>    for a widely-used, critical service that is sensitive to disruption -
>    or at least, for IETF to make such practices appear "equal" to standards.
>    I think that would counterproductive to IETF's purpose.
> 
> We don't want the IETF to "bless" nonstandard practices.  We just want
> a useful registry that helps people in implementation and prevents
> standardization of fields that have already been used for a different
> meaning.

all of this sounds fine to me.  I just don't want the registry to 
serve as a means to circumvent the standards process or to allocate 
header field names that should be reserved for standards. 

Keith

Date: Thu, 31 Jan 2002 19:27:55 -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]

   Date: Thu, 31 Jan 2002 18:44:58 -0500 (EST)
   From: Keith Moore <[email-masked]>
[...]
   what you seem to be wanting is for IETF to bless nonstandard practices
   for a widely-used, critical service that is sensitive to disruption -
   or at least, for IETF to make such practices appear "equal" to standards.
   I think that would counterproductive to IETF's purpose.

We don't want the IETF to "bless" nonstandard practices.  We just want
a useful registry that helps people in implementation and prevents
standardization of fields that have already been used for a different
meaning.

Larry

Date: Thu, 31 Jan 2002 18:46:36 -0500 (EST)
To: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
cc: [email-masked]
From: Keith Moore <[email-masked]>
Sender: [email-masked]

> >It certainly is an indication that the field is not standardized,
> >that it doesn't have a specification that has received community
> >review and consensus before use.
> 
> It certainly indicates that there is no spec, but it doesn't at all
> mean that the field is not a de-facto standard.

actually, it doesn't indicate that there is no spec (I've seen a
spec for X-Face) but it is a good first-order indication that the
field is not a de facto standard.

> In fact, it may have
> received a sufficient level of community review (e.g., X-Mailer and
> X-Face didn't need a whole lot of discussion pre-deployment).

and it's always possible that the designer got the field "right"
the first time without any external review. but it's a rare occurance.

> >And for that reason it really is a fairly good first-order
> >indication about whether it's a good idea to implement the field.
> 
> But of course, that isn't how it's viewed. What implementors instead
> take it to mean is "You'll never find documentation on this field, so
> if it looks useful to you, either examine the field itself or look at
> the source code of some MUA that uses it and then wing it." And that
> is a much more likely recipe for bad things to happen.

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?

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

-----------------------------------------------------------------------
Summary of my position on X- fields:

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.

   (yes, there are a couple of exceptions, but they're rare)

2. it is perfectly reasonable to document X- Fields that are deployed,
   because it's almost always useful to document existing practice.

3. it is unlikely that an X- field is worthy of standardization as-is.

   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. 

Keith

Date: Thu, 31 Jan 2002 18:44:58 -0500 (EST)
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
cc: Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

> >  that
> >it doesn't have a specification that has received community review
> >and consensus before use.
> 
> more importantly, what it does NOT tell you is whether it has received
> community review and consensus AFTER use.

with certainty, no.  with high probability, yes.

what you seem to be wanting is for IETF to bless nonstandard practices
for a widely-used, critical service that is sensitive to disruption -
or at least, for IETF to make such practices appear "equal" to standards.
I think that would counterproductive to IETF's purpose.

nobody should believe that standards are an absolute assurance of
quality, or that protocols that don't enjoy review and feedback are
inherently of poor quality.  but on average, you get better quality
if you get community review before settling on a design - particularly
when the design needs to satisfy the needs of a variety of concerns.

Keith

Date: Thu, 31 Jan 2002 15:20:44 -0800
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 05:54 PM 1/31/2002 -0500, Keith Moore wrote:
>It certainly is an indication that the field is not standardized,

formally, yes.  de facto, no.

>  that
>it doesn't have a specification that has received community review
>and consensus before use.

more importantly, what it does NOT tell you is whether it has received 
community review and consensus AFTER use.

(That is, after all, the difference between de jure and de facto standards.)

d/

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

To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 31 Jan 2002 18:04:37 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> What meaning (in reality now, not some future hoped reality) does X- convey?

Something to do with Files, right?

Date: Thu, 31 Jan 2002 17:03:58 -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]>, Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

On 1/31/02 at 5:54 PM -0500, Keith Moore wrote:

>It certainly is an indication that the field is not standardized, 
>that it doesn't have a specification that has received community 
>review and consensus before use.

It certainly indicates that there is no spec, but it doesn't at all 
mean that the field is not a de-facto standard. In fact, it may have 
received a sufficient level of community review (e.g., X-Mailer and 
X-Face didn't need a whole lot of discussion pre-deployment).

>And for that reason it really is a fairly good first-order 
>indication about whether it's a good idea to implement the field.

But of course, that isn't how it's viewed. What implementors instead 
take it to mean is "You'll never find documentation on this field, so 
if it looks useful to you, either examine the field itself or look at 
the source code of some MUA that uses it and then wing it." And that 
is a much more likely recipe for bad things to happen.

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

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 31 Jan 2002 17:54:26 -0500
Sender: [email-masked]

> And what, pray tell, does it cue? What meaning (in reality now, not
> some future hoped reality) does X- convey? It's certainly not whether
> the field is in short term use. It's certainly not whether a field is
> a good thing to implement or not. For what is it a visual cue?

It certainly is an indication that the field is not standardized, that 
it doesn't have a specification that has received community review 
and consensus before use. And for that reason it really is a fairly 
good first-order indication about whether it's a good idea to implement 
the field.   

Which is not to say that using X- in a field name (and the corresponding
failure to get community review before deployment) inherently makes the
field a Bad Idea To Implement.  But the vast majority of Ideas that people 
come up with for new fields turn out to be Bad Ideas, or at least Ideas 
That Need Improvement Before Deployment.

Keith

Date: Thu, 31 Jan 2002 16:43:18 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

On 1/31/02 at 4:40 PM -0500, Keith Moore wrote:

>X- is just another visual cue.

And what, pray tell, does it cue? What meaning (in reality now, not 
some future hoped reality) does X- convey? It's certainly not whether 
the field is in short term use. It's certainly not whether a field is 
a good thing to implement or not. For what is it a visual cue?

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

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 31 Jan 2002 16:47:06 -0500
Sender: [email-masked]

> I agree; we need an open registry.
> 
> I don't understand Keith's concerns that it would "confer legitimacy
> on nonstandard field names".  We don't have this problem with other
> open registries, say, SASL mechanism names.

different protocols need different constraints on their extension
mechanisms, and I don't think the analogy holds in this case. 

- SASL names are not as visible as email field names. 

- there are not as many SASL implementaitons as there are MUAs.

- offhand, it seems that SASL mechanisms are more-or-less independent
  of the protocol being authenticated (so adding another mechanism doesn't
  change the protocol), 

- and I don't see how different SASL mechanisms can interact with one 
  another, either.  

on the other hand a field like mail-followup-to can change both the
handling of other fields (like reply-to) but also basic UA functionality
(like the reply command).

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: Thu, 31 Jan 2002 16:40:38 -0500
Sender: [email-masked]

> > > this sounds like a variant of the cliche about security through obscurity.
> >
> >that's a lousy analogy.  we're not talking about security here, we're
> >essentially talking about a social convention.
> 
> my point was about the design approach that attempts to control behavior by
> ugliness.

ugliness is your personal judgement.  I think X- is beautiful.

we quite often use visual cues to call attention to special circumstances:

- colored flashing lights on emergency vehicles
- warning signs on top of a student driver's automobile
- yellow tape surrounding a construction area or crime scene
- colored dots on IETF nametags

X- is just another visual cue.  

> it's like the effort to prevent use of tcp header prediction -- which
> permitted a tripling of tcp throughput -- because it would permit ethernet
> users to get an unfair share of the line.

no it's not.  we're not talking about preventing people from doing 
anything here.

Keith 

Date: Thu, 31 Jan 2002 13:07:32 -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:54 PM 1/31/2002 -0500, Keith Moore wrote:
> > this sounds like a variant of the cliche about security through obscurity.
>
>that's a lousy analogy.  we're not talking about security here, we're
>essentially talking about a social convention.

my point was about the design approach that attempts to control behavior by 
ugliness.

it's like the effort to prevent use of tcp header prediction -- which 
permitted a tripling of tcp throughput -- because it would permit ethernet 
users to get an unfair share of the line.

d/

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

Date: Thu, 31 Jan 2002 15:05:57 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

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

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

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.

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

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: Thu, 31 Jan 2002 15:54:37 -0500
Sender: [email-masked]

> >What it does is to encourage people to use ordinary-looking field names
> >for poorly designed fields which don't have the benefit of public review.
> 
> this sounds like a variant of the cliche about security through obscurity.

that's a lousy analogy.  we're not talking about security here, we're 
essentially talking about a social convention.  

nobody is pretending that this convention prevents people from deploying 
code that generates or accepts poorly-designed message headers.  we're
only discussing whether the X- convention is useful.

Keith

Date: Thu, 31 Jan 2002 12:48:23 -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 03:23 PM 1/31/2002 -0500, Keith Moore wrote:
>What it does is to encourage people to use ordinary-looking field names
>for poorly designed fields which don't have the benefit of public review.

this sounds like a variant of the cliche about security through obscurity.

in this case it would be something like "email header protection through 
naming ugliness."

sigh.

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: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 31 Jan 2002 15:23:27 -0500
Sender: [email-masked]

> >X-headers are very useful for experimental features and private agreements -
> 
> in fact, x-headers have been quite a problem.  they are excellent in
> theory, but the header can become popular, thereby becoming a de facto
> standard.  then we are stuck with a defacto standard that uses and x- label.

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

To me this says we should strengthen the X- convention rather than abandon it.

> simply registering headers does not encourage or discourage private or
> public efforts.

What it does is to encourage people to use ordinary-looking field names 
for poorly designed fields which don't have the benefit of public review. 

To the extent that this has already occurred, it's almost universally been
harmful.

Keith

Date: Thu, 31 Jan 2002 15:10:09 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

I agree; we need an open registry.

I don't understand Keith's concerns that it would "confer legitimacy
on nonstandard field names".  We don't have this problem with other
open registries, say, SASL mechanism names.

Larry

   Date: Thu, 31 Jan 2002 11:33:31 -0800
   From: Dave Crocker <[email-masked]>

   >X-headers are very useful for experimental features and private
   >agreements -

   in fact, x-headers have been quite a problem.  they are excellent in 
   theory, but the header can become popular, thereby becoming a de facto 
   standard.  then we are stuck with a defacto standard that uses and x- label.

   the view that we simply re-label the header with a non-x value does not 
   match the last 20 years of history.

   simply registering headers does not encourage or discourage private or 
   public efforts.

   instead it does exactly what it is supposed to do, namely make sure that we 
   have a coherent, public name space and accountability for who is consuming 
   it -- that is, where to go to find out about a particular header.

   d/

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

Date: Thu, 31 Jan 2002 11:33:31 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Sender: [email-masked]

>X-headers are very useful for experimental features and private agreements -

in fact, x-headers have been quite a problem.  they are excellent in 
theory, but the header can become popular, thereby becoming a de facto 
standard.  then we are stuck with a defacto standard that uses and x- label.

the view that we simply re-label the header with a non-x value does not 
match the last 20 years of history.

simply registering headers does not encourage or discourage private or 
public efforts.

instead it does exactly what it is supposed to do, namely make sure that we 
have a coherent, public name space and accountability for who is consuming 
it -- that is, where to go to find out about a particular header.

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: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Thu, 31 Jan 2002 13:13:47 -0500
Sender: [email-masked]

> > Mulling some more, I do see a potential problem that you may be alluding
> >to, and have another thought.  Allowing provisional registration of non X-
> >headers might be seen as tacitly acknowledging that it's OK to use them
> >without standardization, regardless of what the protocol spec may say.
> 
> 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.
> 
> 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. 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.

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. 

IMHO X-headers for read/write fields shouldn't be used in widely deployed 
code.  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.

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.

Keith

To: [email-masked]
Xref: clerew local.mime:872
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, 31 Jan 2002 10:40:29 GMT
Lines: 44
Sender: [email-masked]

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

>Mulling some more, I do see a potential problem that you may be alluding 
>to, and have another thought.  Allowing provisional registration of non X- 
>headers might be seen as tacitly acknowledging that it's OK to use them 
>without standardization, regardless of what the protocol spec may say.

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.

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

>How about changing the rules for provisional registration to allow all 
>comers for header field names beginning with X-, and require IETF consensus 
>or IESG approval for anything else?  (I'd need to check that this has the 
>desired effect for HTTP and News.)

I don't think any X-header should ever be registered. But if you want some
restriction on what gets into any "provisional" classification, then I
think maybe the Area Director (or his nominated expert, as already
provided for in the IANA RFC) should be given some say. And it is clearly
in the nature of any "provisional" register that there should be some
mechanism to take things out of it. Otherwise, it is not "provisional".

-- 
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, 31 Jan 2002 14:58:00 +0000
From: Olafur Osvaldsson <[email-masked]>
To: [email-masked]
Subject: Regarding rfc2821
Sender: [email-masked]

Hi,
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, 31 Jan 2002 16:50:21 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Sender: [email-masked]

It would appear that RFC2822 is the only document that uses a single,
well-defined terminology. Following 2822 ought to be a good idea, then.

--Arnt

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, 31 Jan 2002 10:26:03 -0500
Sender: [email-masked]

> >p.s. I'd also prefer "header fields" to "headers".  The header is the
> >structure at the beginning of an email message (NNTP message,
> >HTTP message, whatever), and it is composed of zero or more fields.
> 
> That is indeed the terminology defined in RFC 2822, but it is NOT the
> terminology used in common parlance throughout Usenet and other places.

Since the usefor draft is being revised, perhaps it affords an
opportunity to migrate toward more uniform terminology?

Keith

Date: Thu, 31 Jan 2002 07:05:49 -0800
To: [email-masked] (Charles Lindsey)
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: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'.

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.

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]
Xref: clerew local.mime:871
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, 31 Jan 2002 10:28:36 GMT
Lines: 24
Sender: [email-masked]

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

>p.s. I'd also prefer "header fields" to "headers".  The header is the
>structure at the beginning of an email message (NNTP message, 
>HTTP message, whatever), and it is composed of zero or more fields.

That is indeed the terminology defined in RFC 2822, but it is NOT the
terminology used in common parlance throughout Usenet and other places.

It is not the terminology used in RFC 1036 (though the actual terminology
there is a random mix of three different conventions :-( ). It is not the
terminology used in Son-of-1036, and it is not the terminology of the
present Usefor 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: Graham Klyne <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Wed, 30 Jan 2002 16:52:22 -0500
Sender: [email-masked]

At 02:07 PM 1/30/02 -0500, Keith Moore wrote:
> > > >  and no Provisional field be added to the registry without
> > > >either IETF consensus or IESG approval.
> > >
> > > ... but folks who have expressed an interest in the provisional registry
> > > aspects have argued that not allowing a reasonably full coverage all
> > > headers, good and bad, would weaken the informative purpose of the
> > > provisional registry.
> >
> >I am assuming that either IESG or a consensus process will approve
> >additions to the registry for the "informative" purpose of documenting
> >pre-existing practice. Jacob Palme's documents would make a good
> >starting point for this.  The trick is to document existing practice
> >without making it too easy to stake a claim for poorly chosen headers
> >that don't exist yet.
> 
> I guess I'm having difficulty buying into your (apparent) premiss here,
> that the existence of a provisional registry will initiate a land-grab for
> header names.

That's not quite what I'm worried about - it's more that the existence
of such a registry would effectively confer legitimacy on nonstandard
field names (even if the document defining the registry specifically
said otherwise) - both by making such field names more visible and by 
establishing a "claim" to particular field names.

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

Once there are deployed implementations that use a header field in 
a particular way, it's usually too late to fix what's wrong with it.

> To emphasize this, I'd be tempted to add something to the provisional
> registry disclaimer, along the lines of:
> [[[
>       Registration as a Provisional Message Header does not imply any kind
>       of endorsement by the IETF, IANA or any other body.
> 
>       The existence of any provisionally registered header name does not
>       represent any kind of claim or priority for a corresponding entry
>       in the normative registry.
> ]]]

I think the disclaimer is appropriate, but I don't think it solves the 
problem.  Visibility of the fields in the registry will have the effect 
of conferring legitimacy even if there is such a disclaimer.

> Mulling some more, I do see a potential problem that you may be alluding
> to, and have another thought.  Allowing provisional registration of non X-
> headers might be seen as tacitly acknowledging that it's OK to use them
> without standardization, regardless of what the protocol spec may say.

That's close to my concern
 
> How about changing the rules for provisional registration to allow all
> comers for header field names beginning with X-, and require IETF consensus
> or IESG approval for anything else?  (I'd need to check that this has the
> desired effect for HTTP and News.)
 
That would be fine with me.  

Keith

Date: Wed, 30 Jan 2002 19:37:47 +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], Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Sender: [email-masked]

At 02:07 PM 1/30/02 -0500, Keith Moore wrote:
> > >  and no Provisional field be added to the registry without
> > >either IETF consensus or IESG approval.
> >
> > ... but folks who have expressed an interest in the provisional registry
> > aspects have argued that not allowing a reasonably full coverage all
> > headers, good and bad, would weaken the informative purpose of the
> > provisional registry.
>
>I am assuming that either IESG or a consensus process will approve
>additions to the registry for the "informative" purpose of documenting
>pre-existing practice. Jacob Palme's documents would make a good
>starting point for this.  The trick is to document existing practice
>without making it too easy to stake a claim for poorly chosen headers
>that don't exist yet.

I guess I'm having difficulty buying into your (apparent) premiss here, 
that the existence of a provisional registry will initiate a land-grab for 
header names.

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?

To emphasize this, I'd be tempted to add something to the provisional 
registry disclaimer, along the lines of:
[[[
      Registration as a Provisional Message Header does not imply any kind
      of endorsement by the IETF, IANA or any other body.

      The existence of any provisionally registered header name does not
      represent any kind of claim or priority for a corresponding entry
      in the normative registry.
]]]

>...  It's much easier to get IESG
>to blanket approve an occasional batch of registrations for the sake
>of documenting existing practice than it is to get IESG to remove
>or warn about individual fields.

OK, I won't push on that.

...

Mulling some more, I do see a potential problem that you may be alluding 
to, and have another thought.  Allowing provisional registration of non X- 
headers might be seen as tacitly acknowledging that it's OK to use them 
without standardization, regardless of what the protocol spec may say.

How about changing the rules for provisional registration to allow all 
comers for header field names beginning with X-, and require IETF consensus 
or IESG approval for anything else?  (I'd need to check that this has the 
desired effect for HTTP and News.)

#g

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

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Wed, 30 Jan 2002 14:07:50 -0500
Sender: [email-masked]

> At 01:05 PM 1/30/02 -0500, Keith Moore wrote:
> >In general, I support the idea of a central (cross-protocol) header
> >field name registry, but I think it's totally unacceptable to confer
> >any more legitimacy on nonstandard header fields, or to define a
> >procedure which would effectively allow parties to bypass the
> >established procedures for extending protocols that use these
> >header fields.
> 
> I accept the concern, and I/we have tried to be sensitive to it.
> 
> There is this disclaimer:
> [[[
> 3.2.2 Provisional header template
> 
>     Registration as a Provisional Message Header does not imply any kind
>     of endorsement by the IETF, IANA or any other body.
> ]]]
> 
> Would you prefer some stronger wording?

that's fine regarding the applicability of a field that has made it
into the registry - my concern is about allowing making it too easy
to introduce new fields into the registry.

> >  and no Provisional field be added to the registry without
> >either IETF consensus or IESG approval.
> 
> ... but folks who have expressed an interest in the provisional registry
> aspects have argued that not allowing a reasonably full coverage all
> headers, good and bad, would weaken the informative purpose of the
> provisional registry.

I am assuming that either IESG or a consensus process will approve 
additions to the registry for the "informative" purpose of documenting 
pre-existing practice. Jacob Palme's documents would make a good
starting point for this.  The trick is to document existing practice
without making it too easy to stake a claim for poorly chosen headers
that don't exist yet.
 
> >That way, we can document existing uses of header fields without
> >creating a mechanism to "stake a claim" for new fields that are
> >ill-advised, poorly designed, or poorly defined.
> 
> Hmm... rather than raising the bar so high for admission, how about
> allowing IESG to require removal of a provisional entry (that's already
> there), OR to require that a "health warning" be added of they feel the
> header to be particularly egregious?

IMHO, that's lowering the bar too much.  It's much easier to get IESG
to blanket approve an occasional batch of registrations for the sake
of documenting existing practice than it is to get IESG to remove
or warn about individual fields.

Keith

Date: Wed, 30 Jan 2002 18:22:56 +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], Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Sender: [email-masked]

At 01:05 PM 1/30/02 -0500, Keith Moore wrote:
>In general, I support the idea of a central (cross-protocol) header
>field name registry, but I think it's totally unacceptable to confer
>any more legitimacy on nonstandard header fields, or to define a
>procedure which would effectively allow parties to bypass the
>established procedures for extending protocols that use these
>header fields.

I accept the concern, and I/we have tried to be sensitive to it.

There is this disclaimer:
[[[
3.2.2 Provisional header template

    Registration as a Provisional Message Header does not imply any kind
    of endorsement by the IETF, IANA or any other body.
]]]

Would you prefer some stronger wording?

>To this end, I strongly recommend that no Normative field be
>added to the registry without an IETF consensus process
>(fields defined in existing IETF standards could be added with IESG
>approval),

Yes, that's the defined intent...

>  and no Provisional field be added to the registry without
>either IETF consensus or IESG approval.

... but folks who have expressed an interest in the provisional registry 
aspects have argued that not allowing a reasonably full coverage all 
headers, good and bad, would weaken the informative purpose of the 
provisional registry.

>That way, we can document existing uses of header fields without
>creating a mechanism to "stake a claim" for new fields that are
>ill-advised, poorly designed, or poorly defined.

Hmm... rather than raising the bar so high for admission, how about 
allowing IESG to require removal of a provisional entry (that's already 
there), OR to require that a "health warning" be added of they feel the 
header to be particularly egregious?

>p.s. I'd also prefer "header fields" to "headers".  The header is the
>structure at the beginning of an email message (NNTP message,
>HTTP message, whatever), and it is composed of zero or more fields.

Yup ... my mistake.  It has been pointed out but I've failed to fix all 
occurrences so far.

#g

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

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: [email-masked], Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Subject: Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt 
Date: Wed, 30 Jan 2002 13:05:01 -0500
Sender: [email-masked]

In general, I support the idea of a central (cross-protocol) header
field name registry, but I think it's totally unacceptable to confer 
any more legitimacy on nonstandard header fields, or to define a
procedure which would effectively allow parties to bypass the
established procedures for extending protocols that use these 
header fields. 

To this end, I strongly recommend that no Normative field be 
added to the registry without an IETF consensus process
(fields defined in existing IETF standards could be added with IESG
approval), and no Provisional field be added to the registry without
either IETF consensus or IESG approval.  

That way, we can document existing uses of header fields without 
creating a mechanism to "stake a claim" for new fields that are 
ill-advised, poorly designed, or poorly defined.

Keith

p.s. I'd also prefer "header fields" to "headers".  The header is the
structure at the beginning of an email message (NNTP message, 
HTTP message, whatever), and it is composed of zero or more fields.

Date: Wed, 30 Jan 2002 16:23:19 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
Cc: Mark Nottingham <[email-masked]>, Jeffrey Mogul <[email-masked]>
Sender: [email-masked]

Further to discussions here on IETF-822 last year, and some continuing 
offline discussions with interested parties, I've joined forces with Mark 
Nottingham and Jeffrey Mogul who had similar ideas for HTTP (see 
http://search.ietf.org/internet-drafts/draft-nottingham-http-header-reg-00.txt).

The result is an updated registry proposal, per the announcement below...

In summary, the proposal is for a pair of cross-protocol registries:  one 
for normative (standardized) message headers, and another for provisional 
(non-standardized) message headers.

#g
--

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Registration procedures for message headers
>         Author(s)       : G. Klyne et al.
>         Filename        : draft-klyne-msghdr-registry-02.txt
>         Pages           : 16
>         Date            : 29-Jan-02
>
>This specification defines registration procedures for the message
>headers 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-02.txt

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