Subject: Re: ipv6-smtp-requirement comments?
From: Eric Allman <[email-masked]>
To: Bob Fink <[email-masked]>
Cc: [email-masked], [email-masked], NGtrans List <[email-masked]>
Date: Mon, 29 Oct 2001 16:27:14 -0800
List-Id: <ietf-822.imc.org>

I think there is some ambiguity in section 3.  In particular, the
numbering seems to combine looping and gotos in a confusing way.
For example, consider the case of doing an A (or AAAA) lookup that
returns multiple IP addresses.  Step (6) says to loop from (7) to
(8) on each address returned, but step (8) says to to back to step
(3).  Which one is it?  This is doubly confusing because step (8)
can never be executed more than once in the innermost loop [(7)-(8)],
so really you are looping on step (7) only -- assuming that the goto
(3) takes precedence over the loop (7)-(8).

Now, _I_ know what they are trying to say, but the language could
be cleaned up -- making this either a loop model or a goto model
should fix it.

Also in section 3, step (5) doesn't say what to do if the resulting
list is empty.  The example at the top of the section lists a host
mx10.example.org that is IPv6 only.  If the source MTA is IPv4 only,
then the lookup of mx10.example.org is going to fail with NO_DATA.
Step (5) should address this.

eric

To: [email-masked]
Cc: [email-masked], [email-masked], NGtrans List <[email-masked]>
Subject: Re: (ngtrans) Re: ipv6-smtp-requirement comments? 
From: [email-masked]
Date: Mon, 29 Oct 2001 09:49:20 +0900
Sender: [email-masked]

>In section 5, there is a discussion of SERVFAIL returns from broken DNS
>servers (which I've seen myself in production).  That could use a one-sentence
>clarification that the problem is the DNS server only having A records for
>an address, and returning SERVFAIL rather than "no data" when asked for AAAA
>records.  
>
>We all know who the offender is, and those of us who use Sendmail already
>know why 'WorkAroundBrokenAAAA' exists.  I'll let somebody with more RFC-writing
>experience than I decide if package-specific "If you run the XYZ MTA, do THIS
>to work around it, if you run the ABC DNS server, upgrade to patch 1.15" info
>should be included in an "operational requirements" RFC.  RFC1912 mentions
>specific releases of BIND, RFC2010 doesn't.

	i don't think it necessary/required to list the broken implementation.
	i know of a couple of products that behave badly (which is an IP load
	balancing box product), but i don't think i can cover every broken
	implementations.

itojun

To: [email-masked], [email-masked], NGtrans List <[email-masked]>
Subject: Re: ipv6-smtp-requirement comments? 
From: [email-masked]
Date: Fri, 26 Oct 2001 08:54:29 -0400
Sender: [email-masked]

--==_Exmh_-1742651564P
Content-Type: text/plain; charset=us-ascii

On Thu, 25 Oct 2001 17:16:50 PDT, Bob Fink said:

> <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt>
> 
> So, please let the ngtrans list now if you have any problems with 
> forwarding this draft, preferably by 1 November.

Technically, I see no major issues - there are a few places where I don't
think we *know* the "best current practice" yet, but those are all carefully
worded with "implementation dependent".

In section 5, there is a discussion of SERVFAIL returns from broken DNS
servers (which I've seen myself in production).  That could use a one-sentence
clarification that the problem is the DNS server only having A records for
an address, and returning SERVFAIL rather than "no data" when asked for AAAA
records.  

We all know who the offender is, and those of us who use Sendmail already
know why 'WorkAroundBrokenAAAA' exists.  I'll let somebody with more RFC-writing
experience than I decide if package-specific "If you run the XYZ MTA, do THIS
to work around it, if you run the ABC DNS server, upgrade to patch 1.15" info
should be included in an "operational requirements" RFC.  RFC1912 mentions
specific releases of BIND, RFC2010 doesn't.

Although Motonori's English is vastly superior to my Japanese,  I still saw
a few places where phrasing was awkward, or verbs had case/tense issues. I'd
consider them not a show-stopper, but if a volunteer from the audience were
to go through and clean them up, the document would benefit (I'll be happy
to do so if nobody else wants to, but consensus calls for a clean-up - but if
nobody else cares, I'll let it slide).

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_-1742651564P
Content-Type: application/pgp-signature

--==_Exmh_-1742651564P--

Date: Thu, 25 Oct 2001 17:16:50 -0700
To: [email-masked], [email-masked]
From: Bob Fink <[email-masked]>
Subject: ipv6-smtp-requirement comments?
Cc: NGtrans List <[email-masked]>
Sender: [email-masked]

ietf-822 & ietf-smtp folk,

The following IETF NGTRANS ipv6-smtp-requirement I-D has just finished WG 
last call for forwarding as an Informational RFC. Randy Bush (our AD) 
suggested that we also circulate it to various groups that might have 
comments otherwise uncovered in ngtrans as it also covers practice.

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt>

So, please let the ngtrans list now if you have any problems with 
forwarding this draft, preferably by 1 November.

	NGtrans List <[email-masked]>

Thanks,

Bob Fink
ngtrans co-chair

Date: Mon,  8 Oct 2001 14:27:14 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: Re: Loop control
Sender: [email-masked]

Excerpts from transarc.system.ietf-822: 6-Oct-01 Re: Loop control James
M [email-masked] (1136*)

>     >(2) Store, in the MTA, the Message-IDs of messages passing.
>     
>     here, to, the problem is that the message can legitimately transit
>     the same site more than one time.

Right.  My old MTA stores the Message-ID and the (canonicalized)
destination address for each delivered message, for a few days. 
Including the destination address means that the message will be
forwarded as often as necessary, as long as it's to different recipients
each time.

The only intrusiveness this method requires is that if the MTA forwards
a message to some other MTA--that is, not doing final delivery
itself--it must ensure that there is some Message-ID on the message
rather than none.

It would be a little more bulletproof if it also recorded and matched
something resulting about the message body, like perhaps its size.  I've
seen this method reject duplicates that had severely-truncated bodies.

		Craig

To: [email-masked]
Subject: Re: Loop control
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 08 Oct 2001 10:49:56 -0700
Lines: 36
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> I would prefer USENET to work in the following way:

> If an article arrives, with the same Message-ID as an already existing
> articles, but with different content of the Newsgroup header, then the
> article is posted to a join of the old and the new set of Newsgroups.

A few points:

First, Usenet has never worked this way, and in fact was required not to
work this way, so that assumption has been written into a lot of software.
One needs a *really* good reason to change that because it requires
upgrading all deployed server software; catering to mail to news gateways
that don't change the message ID like they generally should isn't likely
to be persuasive.

Second, this would do odd things around local policy for things like the
maximum crossposting level that the server is willing to propagate.  I can
see a few ways where this sort of feature would allow people to bypass
crossposting limits that otherwise would be imposed.

Third, this requires rewriting articles in the news spool, which has
significant and possibly prohibitive performance implications for a news
server.

It's not that bad of an idea, but it has rather wide-ranging implications
for the internal design of news server software and for various filters
and administrative controls.  News gets a *lot* of mileage out of knowing
that articles do not change in transit and are never changed after being
written into the news spool, only later deleted.  Breaking that assumption
pulls significant structural support out of the foundation, so to speak,
and the implications are more wide-ranging than I can easily work through.

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

To: [email-masked]
Xref: clerew local.mime:804
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Mon, 8 Oct 2001 11:02:48 GMT
Lines: 45
Sender: [email-masked]

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

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

>For an IANA registry, the criteria for IANA to apply have to be very clear 
>and straightforward.  To my mind, that means limiting the conditions to one 
>stated in RFC 2434 unless there is a really compelling reason to do 
>something else.

Indeed, we want to work within RFC 2434 if we possibly can. But the
mechanisms provided there already provide quite a lot of flexibility.

For example, one might define a "status" field for a header (or perhaps a
header/protocol pair) with values such as:
	standards track
	experimental
	provisional
	deprecated

Inclusion of "standards track" in the register would be automatic, upon
publication of the RFC. Possibly "experimental also".

The other two would be on the authority of the "Designated Expert" (with
the appeals mechanism set out in RFC 2434). The designated expert would
have some rules to work to, for example that "provisional" would only
remain so long as a current internet-draft existed, and possibly only one
proposed by an established IETF Working Group. Not sure what rules would
apply to "deprecated", but several people have been saying we need such
entries for plainly "bogus" headers.

-- 
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: Mon, 8 Oct 2001 11:48:33 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Loop control
Sender: [email-masked]

At 20.34 -0700 01-10-05, Russ Allbery wrote:
>This is correct; however, I wouldn't call it a bug.  It is an absolute
>requirement of the Usenet article format that the message ID be globally
>unique; it is not permissable to have two articles with the same message
>ID, ever.  If two articles have different Newsgroups headers, they're
>different articles, and they are not permitted to have the same message
>ID.

I would prefer USENET to work in the following way:

If an article arrives, with the same Message-ID as an already
existing articles, but with different content of the Newsgroup
header, then the article is posted to a join of the old and
the new set of Newsgroups.

The advantage with this is that a message is sent to two
e-mail mailing lists, which both are gatewayed to two
different newsgroups, the article will occur in both
newsgroups, and not only in the newsgroup used when the
first mailing list was gatewayed.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Sun, 07 Oct 2001 12:26:21 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: Loop control
To: [email-masked]
Sender: [email-masked]

On Sat, 6 Oct 2001, D. J. Bernstein wrote:
    
    James M Galvin writes:
      [ someone else's MX records pointing to one of our IP addresses ]
    > Any ideas on how to deal with that?
    
    The MTA has to check for its own IP addresses in the MX list. See
    http://cr.yp.to/proto/mailloops.txt.

A better reference is RFC2821, which obsoletes RFC974, the original MX
specification.

In particular, RFC974 only ever said that a host evaluating MX records
should remove MX records that match its own name (and all others of
equal or greater preference).  RFC2821 adds the requirement of checking
for your own address.

Jim

--
James M. Galvin <[email-masked]>

Date: 6 Oct 2001 20:08:20 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Loop control
Sender: [email-masked]

James M Galvin writes:
  [ someone else's MX records pointing to one of our IP addresses ]
> Any ideas on how to deal with that?

The MTA has to check for its own IP addresses in the MX list. See
http://cr.yp.to/proto/mailloops.txt.

---Dan

Date: Sat, 6 Oct 2001 15:47:08 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: James M Galvin <[email-masked]>
cc: <[email-masked]>
Subject: Re: Loop control
Sender: [email-masked]

On Sat, 6 Oct 2001, James M Galvin wrote:

> Also, although I do maintain a Message-ID: database for recent messages
> for loop control, the most common looping problem I encounter is sites
> that set their address or their MX to 127.0.0.1.
>
> Any ideas on how to deal with that?

I added a feature to Exim that lets you specify that any A records you
look up in the DNS whose rhs is 127.0.0.1 should be ignored. You then
get "unknown domain" errors for those sites. (In fact it's more general.
You can set it to 127.0.0.0/8 for example.)

Even if you don't set that option, an A record pointing to 127.0.0.1
does not cause loops in Exim. It notices it is trying to send to itself,
and stops trying to deliver the message. (There is an option to
override, but that's the default action.)

I am trying to promote an RFC that says "Thou shalt not put records in
the public DNS that point to private addresses". I don't know how far it
will get. See

  draft-ietf-dnsop-dontpublish-unreachable-01.txt

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Sat, 06 Oct 2001 10:13:45 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: Loop control
To: Dave Crocker <[email-masked]>
Cc: Jacob Palme <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 5 Oct 2001, Dave Crocker wrote:

    >(2) Store, in the MTA, the Message-IDs of messages passing.
    
    here, to, the problem is that the message can legitimately transit
    the same site more than one time.
    
    My own sense is that counting the number of Received headers citing the 
    local system's domain name, and then bouncing messages that have more than 
    N such headers.  Offhand, 3 seems safe, though 4 is probably just as 
    effective and more safe.

This depends entirely on the system in use and current architecture.

Although I agree that 3 or 4 is probably fine for Sendmail-based
systems I, for example, use 12.  This is because for each step through
my system a message gets another Received: line, which of course has the
local system name in it.  This is an architectural choice, the principal
benefit of which is simplicity of configuration and change.

Also, although I do maintain a Message-ID: database for recent messages
for loop control, the most common looping problem I encounter is sites
that set their address or their MX to 127.0.0.1.

Any ideas on how to deal with that?

Jim

Date: Sat, 06 Oct 2001 08:28:17 +0100
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 08:28 PM 10/5/01 +0000, Charles Lindsey wrote:
> >>There is provision in RFC 2434 for "Designated Experts" appointed by the
> >>Area Director to approve registrations.
>
> >Well, we could go that way, but it doesn't require RFC publication of the
> >specification (IIRC).  My preference is to pick one of the stronger 
> conditions.
>
>I think there are several mechanisms that could be used. Ones menmtioned
>so far have included:
>         existence of an internet-draft
>         Designated Experts
>         registry of "bogus" headers
[...]

For an IANA registry, the criteria for IANA to apply have to be very clear 
and straightforward.  To my mind, that means limiting the conditions to one 
stated in RFC 2434 unless there is a really compelling reason to do 
something else.

> >Options I might consider:
> >(a) for each header, allow different definitive citations for different 
> uses.
> >(b) limit the applicability of the registry to email/news (though even that
> >may be problematic in light of your comment about USEFOR).
> >(c) limit the applicability of the registry to email.  (If required, other
> >applications might define separate registries that import
>
>I think it has to be (a).

[...]

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

[...]

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

You make a good case for a single registry;  in particular that it would 
probably help to avoid re-use of headers for different purposes.

#g

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

Date: Fri, 05 Oct 2001 20:37:37 -0700
To: Jacob Palme <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Loop control
Cc: [email-masked]
Sender: [email-masked]

At 12:00 PM 10/5/2001, Jacob Palme wrote:
I do not think IETF has any standard for loop control in e-mail,
>except the priority value in MX records.

mx priorities do not provide loop control

>Common methods for loop control:
>
>(1) Trace list on the message. We have this, in the
>     "Received:" header, but no spec how it should be used for
>     loop control. This is not as easy as it can seem, since a
>     message can legitimately come and go several times to the
>     same MTA, for example after mailing list expansion.

Your "this is not as easy" sentence is extremely important.

>(2) Store, in the MTA, the Message-IDs of messages passing.

here, to, the problem is that the message can legitimately transit the same 
site more than one time.

My own sense is that counting the number of Received headers citing the 
local system's domain name, and then bouncing messages that have more than 
N such headers.  Offhand, 3 seems safe, though 4 is probably just as 
effective and more safe.

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: Loop control
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 05 Oct 2001 20:34:36 -0700
Lines: 29
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> (2) Store, in the MTA, the Message-IDs of messages passing.
>      Can also be combined with checksums of message content.
>      This is the main method of loop control in Usenet News, but
>      is not used very much outside Usenet News. In Usenet News,
>      it has a bug - the same article is *not* accepted twice,
>      even if it is received a second time to a different
>      newsgroup.

This is correct; however, I wouldn't call it a bug.  It is an absolute
requirement of the Usenet article format that the message ID be globally
unique; it is not permissable to have two articles with the same message
ID, ever.  If two articles have different Newsgroups headers, they're
different articles, and they are not permitted to have the same message
ID.

>      This can only handle for messages entering News from e-mail.

If the articles aren't given different message IDs, I'd there's a bug in
the mail to news gateway because it isn't following the requirements of
the Usenet protocol.

The Usenet protocol was not designed for ease of gatewaying in mind, and
this could arguably be called a flaw, but since this behavior is an
intentional implication of the protocol I think "bug" is the wrong term.

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

Date: Fri, 5 Oct 2001 21:00:07 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Loop control
Sender: [email-masked]

At 16.23 +0000 01-10-04, D. J. Bernstein wrote:
>One obvious counterexample is the very widely used Delivered-To field,
>which provides much more effective loop control than any IETF field.

I do not think IETF has any standard for loop control in e-mail,
except the priority value in MX records.

Common methods for loop control:

(1) Trace list on the message. We have this, in the
     "Received:" header, but no spec how it should be used for
     loop control. This is not as easy as it can seem, since a
     message can legitimately come and go several times to the
     same MTA, for example after mailing list expansion.

(2) Store, in the MTA, the Message-IDs of messages passing.
     Can also be combined with checksums of message content.
     This is the main method of loop control in Usenet News, but
     is not used very much outside Usenet News. In Usenet News,
     it has a bug - the same article is *not* accepted twice,
     even if it is received a second time to a different
     newsgroup. This can only handle for messages entering News
     from e-mail.

Listserv has a very good capability of recognizing
duplicates of the same message, even if the Message-ID has
become corrupted by non-standard software like First Class
(First Class puts a new Message-ID on a message which comes
into First Class and is then sent out again). I am not sure
exactly how this is done.
-- 
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:794
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Fri, 5 Oct 2001 20:28:58 GMT
Lines: 109
Sender: [email-masked]

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

>At 03:11 PM 10/4/01 +0000, Charles Lindsey wrote:
>>
>>There is provision in RFC 2434 for "Designated Experts" appointed by the
>>Area Director to approve registrations.

>Well, we could go that way, but it doesn't require RFC publication of the 
>specification (IIRC).  My preference is to pick one of the stronger conditions.

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

>Options I might consider:
>(a) for each header, allow different definitive citations for different uses.
>(b) limit the applicability of the registry to email/news (though even that 
>may be problematic in light of your comment about USEFOR).
>(c) limit the applicability of the registry to email.  (If required, other 
>applications might define separate registries that import

I think it has to be (a).

>It was a presumption of mine that the header names occupied a single 
>namespace across all uses;  there might be some headers with specialized 
>application uses, but no header would be used for different purposes in 
>different protocols.  Having multiple specifications makes this more 
>difficult to verify.

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

>>Not so. To understand everything you are allowed to write in a
>>Content-Type, even just for Mail, you need RFC 2231 as well as RFC 2045
>>(because it extends the syntax of 'token'). But RFC 2231 does not
>>obsolete RFC 2045.

>But is *does* update it:

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

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

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

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

>>I think that mechanism will be essential. Here, for example, is how I
>>would register Content-Type. Note that for each protocol there is a
>>primary definition, and possibly several secondary definitions (i.e.
>>extensions).
>>
>>Header Field-name:      Content-Type
>>Protocol:       Mail
>>         Primary definition:     RFC 2045
>>         Secondary definition:   RFC 2231
>>
>>Protocol:       Netnews
>>         Primary definition:     RFC 2045
>>         Secondary definition:   [[[USEFOR]]]
>>
>>Protocol:       HTTP
>>         Primary definition:     RFC 2616

>Hmmm... this is looking like three registries in one.  Why not three 
>separate registries instead?

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

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

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [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:793
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Fri, 5 Oct 2001 20:05:06 GMT
Lines: 29
Sender: [email-masked]

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

>> > But an RFC that defined Precedence properly, set out the approved usages
>> > and deprecated the rest as obsolete might solve the problem.

>And in the case of precedence, even if you eliminate the usage that doesn't
>belong in a header field (control over delay notifications), you still have two
>different camps with incompatible views of how the field should be used
>(in X.400 terms, priority versus importance). 

Each case on its merits. It may be that thje Precedence header is too far
gone to be recoverable (I haven't studied the gory details). But there
will certainly be some headers which are recoverable in that way. For
example, the Mail-Copies-To header has some redundant usages. IN Usefor,
we have chosen one and deprecated the others (but at least the bad ones do
no actual harm in that case, so they will just hopefully fade away over
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

Date: 05 Oct 2001 23:25:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked]  wrote on 05.10.01 in <[email-masked]>:

> >          "This use of this is not standardized.
> >          There is no formal specification for using this.
> >          People use this in different ways."

> This is basically what Jacob Palme's list of headers has already done. And
> FWIW, I've noticed neither an increase nor a decrease in usage of such
> fields as a result of its publication. Of course it is hard to extrapolate
> from this to the effect a registry would have.

Do an explicit negative (BCP, probably) RFC instead, maybe titled  
"Problematic Headers" or somesuch. (Though it might be better to do this  
per-protocol - what's bad for one might be good for another.)

List bad headers, and explain why they're bad.

I expect at least some people would react differently to that than to the  
Palme RFC. How many, I have no clue, of course; but *if* you can get that  
at BCP level (and it certainly sounds like BCP material), that has more  
force than just any odd informational RFC.

MfG Kai

Date: Fri, 05 Oct 2001 07:55:18 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > And in the case of precedence, even if you eliminate the usage that doesn't
> > belong in a header field (control over delay notifications), you still
> > have two different camps with incompatible views of how the field should
> > be used (in X.400 terms, priority versus importance).

> hmmm.  perhaps this suggests an approach that registers headers known to be
> in common use, but lacking in a formal specification, giving all of them a
> single generic specification pointer to a document that says:

>          "This use of this is not standardized.
>          There is no formal specification for using this.
>          People use this in different ways."

> We do not need to go into value judgements, but simply provide people with
> the facts.

This is basically what Jacob Palme's list of headers has already done. And
FWIW, I've noticed neither an increase nor a decrease in usage of such fields
as a result of its publication. Of course it is hard to extrapolate from this
to the effect a registry would have.

				Ned

Date: Fri, 05 Oct 2001 11:32:44 +0100
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 03:11 PM 10/4/01 +0000, Charles Lindsey wrote:
> >The reason I feel that a registry is in order, rather than just an
> >informational database, is that I am finding situations where I want to
> >leverage the existing set of standards-track definitions in another
> >specification;  I want to be able to include existing header names and
> >semantics by reference.  (My immediate application is representation of
> >message metadata with URIs used to identify header values.)
>
>I think that is essentially my reason #3.

OK, we're roughly aligned in intent, if using different language sometimes.

> >Yes, I was leaving open the choice between "standards action" or "IETF
> >consensus";  I tend to favour the latter, as long as it's obvious from a
> >published RFC whether or not it represents such consensus.  (I wanted the
> >IANA assessment to be dead easy:  the key registration items are the header
> >name and defining RFC, which should be easy to check.  Certianly, a
> >standards-track RFC definition is.)
>
>There is provision in RFC 2434 for "Designated Experts" appointed by the
>Area Director to approve registrations.

Well, we could go that way, but it doesn't require RFC publication of the 
specification (IIRC).  My preference is to pick one of the stronger conditions.

> >Hopefully, there will be just one *defining* RFC.
>
>No, life is not so simple. For example, RFC 2616 defines Content-Type from
>the ground up.

>  If RFC 2045 were to disappear in a puff of smoke, RFC 2616
>would not be affected. USEFOR does make more use of RFC 2822 for the
>headers that are common to both, at least for the syntax. But even there
>the semantics are (re)defined in full.

OUCH!  You're right.  I hadn't noticed that the HTTP definition doesn't 
cite MIME (except for the media type registration).

Options I might consider:
(a) for each header, allow different definitive citations for different uses.
(b) limit the applicability of the registry to email/news (though even that 
may be problematic in light of your comment about USEFOR).
(c) limit the applicability of the registry to email.  (If required, other 
applications might define separate registries that import

It was a presumption of mine that the header names occupied a single 
namespace across all uses;  there might be some headers with specialized 
application uses, but no header would be used for different purposes in 
different protocols.  Having multiple specifications makes this more 
difficult to verify.

> >>Even for a single protocol, there may be more than one document (for
> >>example a basic definition, plus some later extension that provides
> >>additional functionality).
>
> >Good point.
>
> >In this case, the RFC index will show that the original specification is
> >updated or obsoleted by subsequent documents, so I think it can be argued
> >that the combination of "active" documents provides a single, coherent
> >definition.
>
>Not so. To understand everything you are allowed to write in a
>Content-Type, even just for Mail, you need RFC 2231 as well as RFC 2045
>(because it extends the syntax of 'token'). But RFC 2231 does not
>obsolete RFC 2045.

But is *does* update it:

2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
      Internet Message Bodies. N. Freed, N. Borenstein. November 1996.
      (Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
      (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)

2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,
      Languages, and Continuations. N. Freed, K. Moore. November 1997.
      (Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045,
      RFC2047, RFC2183) (Status: PROPOSED STANDARD)

So the extended/refined definitions can be traced from the original 
specification...

> >  I'd better re-phrase the previous question:
>
> > >>> Question:  does every standardized header truly have a single coherent
> >definition, tracable from a single initial defining RFC?
>
>Still no.

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

>I think that mechanism will be essential. Here, for example, is how I
>would register Content-Type. Note that for each protocol there is a
>primary definition, and possibly several secondary definitions (i.e.
>extensions).
>
>Header Field-name:      Content-Type
>Protocol:       Mail
>         Primary definition:     RFC 2045
>         Secondary definition:   RFC 2231
>
>Protocol:       Netnews
>         Primary definition:     RFC 2045
>         Secondary definition:   [[[USEFOR]]]
>
>Protocol:       HTTP
>         Primary definition:     RFC 2616

Hmmm... this is looking like three registries in one.  Why not three 
separate registries instead?

#g

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

To: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 04 Oct 2001 18:36:03 -0700
Lines: 10
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> But an RFC that defined Precedence properly, set out the approved usages
> and deprecated the rest as obsolete might solve the problem.

I think you're considerably too optimistic about people modifying their
existing practice to match a standard just because it's a standard.

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

Date: Thu, 04 Oct 2001 18:21:26 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Sender: [email-masked]

At 05:51 PM 10/4/2001, [email-masked] wrote:
>And in the case of precedence, even if you eliminate the usage that doesn't
>belong in a header field (control over delay notifications), you still 
>have two
>different camps with incompatible views of how the field should be used
>(in X.400 terms, priority versus importance).

hmmm.  perhaps this suggests an approach that registers headers known to be 
in common use, but lacking in a formal specification, giving all of them a 
single generic specification pointer to a document that says:

         "This use of this is not standardized.
         There is no formal specification for using this.
         People use this in different ways."

We do not need to go into value judgements, but simply provide people with 
the facts.

d/

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

Date: Thu, 04 Oct 2001 17:51:31 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > But an RFC that defined Precedence properly, set out the approved usages
> > and deprecated the rest as obsolete might solve the problem.

> not if the "bad" usages were too widespread. especially given that
> most of the uses of precedence are MTA functions and do not belong
> in the message header.

And in the case of precedence, even if you eliminate the usage that doesn't
belong in a header field (control over delay notifications), you still have two
different camps with incompatible views of how the field should be used
(in X.400 terms, priority versus importance). 

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Thu, 04 Oct 2001 19:24:05 -0400
Sender: [email-masked]

> But an RFC that defined Precedence properly, set out the approved usages
> and deprecated the rest as obsolete might solve the problem. 

not if the "bad" usages were too widespread. especially given that
most of the uses of precedence are MTA functions and do not belong
in the message header.

Keith

To: [email-masked]
Xref: clerew local.mime:781
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Thu, 4 Oct 2001 15:43:30 GMT
Lines: 38
Sender: [email-masked]

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

>At 12:52 PM 10/3/01 -0400, Keith Moore wrote:

>>What I'd like this document to do is to discourage pollution of the
>>message header by unscrupulous vendors trying to degrade interoperability
>>with their competitors' products.
>>
>>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.

I think absence from the registry should suffice for that.

But OTOH we are faced with a current situation where people gaily invent
news headers regardless of any RFC. Sometimes these headers prosper and
eventually find their way into RFCs. A good example is the Mail-Copies-To
header in Netnews. It is now widely supported and even honoured, and so we
have decided to include it in Usefor. But if we had been designing that
feature from scratch, we would certainly have given it a more suitable
name.

If we make it too hard to get a header onto the registry, then people are
going to ignore us, just as they do now. If we make it too easy we are
going to get lots of badly-named headers, just as we do now. The trick
will be to devise a mechanism that strikes a balance between these two
extremes.

-- 
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:782
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Thu, 4 Oct 2001 15:50:15 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> "Dan Wing" <[email-masked]> writes:

>Any registration process needs to be similar, and describe the
>various meanings.  For example, "registering" the header "Precedence"
>wouldn't be useful because its usage isn't fixed (some apps use
>numeric, others use all sorts of text, and so on), so a "registration"
>needs to acknowledge this fact.

But an RFC that defined Precedence properly, set out the approved usages
and deprecated the rest as obsolete might solve the problem. I think that
would gain more acceptance than defining Yet Another Header for the same
job (at least it would please some of the implementors, whereas a new one
would please non of them).

-- 
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: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: Locating RFC [2]822 headers 
Date: Thu, 04 Oct 2001 15:15:15 -0400
Sender: [email-masked]

> > And experience suggests that fields designed by individual
> > implementors aren't suitable for widespread use.
> 
> One obvious counterexample is the very widely used Delivered-To field,
> which provides much more effective loop control than any IETF field.

A single counterexample doesn't refute the general principle, as long as
the generality isn't treated as if it were an absolute. 

Feel free to submit an I-D that describes Delivered-To and request
publication of that document as an RFC.  If it's really as good as you 
say, it will get published and more implementors will be able to learn
about it and implement it correctly.  Of course, if it's not as good as 
you say, its deficiencies will be exposed.
 
> Someone who makes the serious mistake of trusting your type of registry
> might think that the name Delivered-To is available for a new field.

I doubt that anyone wants to reuse a field name which is already
in wide use, regardless of whether that use is beneficial or harmful.

It's certainly useful to list fields that are in wide use.  I just
don't want the registry to become a means for either claiming new
field names or bypassing the standards process in establishing 
legitimacy of new fields.

Keith

Date: 4 Oct 2001 16:23:38 -0000
Mail-Followup-To: [email-masked]
Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Locating RFC [2]822 headers
Sender: [email-masked]

Keith Moore writes:
> And experience suggests that fields designed by individual
> implementors aren't suitable for widespread use.

One obvious counterexample is the very widely used Delivered-To field,
which provides much more effective loop control than any IETF field.

Someone who makes the serious mistake of trusting your type of registry
might think that the name Delivered-To is available for a new field.

---Dan

To: [email-masked]
Xref: clerew local.mime:780
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: draft-klyne-msghdr-registry-00.txt
Date: Thu, 4 Oct 2001 15:11:34 GMT
Lines: 166
Sender: [email-masked]

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

>At 12:02 PM 10/3/01 +0000, Charles Lindsey wrote:

>> >   A registry for non-standards-track message headers is at best
>> >   informational, and at least two such sources of information already
>> >   exist:
>>
>>Indeed, but then this proposed IANA registry is at best informational.

>This touches of the normative vs informational purpose for the registry.

The registry itself is informational (it just tells you where to look).
But the RFCs it points to are normative, and so the registry acquires its
authority indirectly.

>The reason I feel that a registry is in order, rather than just an 
>informational database, is that I am finding situations where I want to 
>leverage the existing set of standards-track definitions in another 
>specification;  I want to be able to include existing header names and 
>semantics by reference.  (My immediate application is representation of 
>message metadata with URIs used to identify header values.)

I think that is essentially my reason #3.

>When thinking about this draft, I considered a two-part registry for 
>normatively defined headers, and a separate catalogue of informally defined 
>headers.  But I felt that there was limited value in duplicating existing 
>efforts, and a simple catalogue of headers-in-use really didn't need to be 
>an IANA registry.  Rather, I felt the useful focus was on those that had 
>been "assigned" by consensus action in the IETF.

If you want to be able to say "do not use that header, it is bogus", then
you need a registry that is pretty complete. In particular, it needs some
way for the man to make his header non-bogus (albeit with some hoops to
jump through first, which should certainly include provision for
discussion within the Internet Community). That is why I would support a
"provisional" section in the registry (or some other word with similar
effect).

> >>> My question here is this:  does anyone else feel that something more 
>strongly normative than a catalogue of headers is called for?

See above. If it is not in the Registry, then it is bogus. If it is in the
registry, then it is whatever the Registry says it is (or what the
document pointed to by the registry says it is).

>> >3.1 Header specification
>>
>>Right. You did not actually say standards track there. I would have no
>>problem with Experimental Protocol RFCs, and I would also like to see
>>provisional registrations (with some stringent rules). But we can discuss
>>that.

>Yes, I was leaving open the choice between "standards action" or "IETF 
>consensus";  I tend to favour the latter, as long as it's obvious from a 
>published RFC whether or not it represents such consensus.  (I wanted the 
>IANA assessment to be dead easy:  the key registration items are the header 
>name and defining RFC, which should be easy to check.  Certianly, a 
>standards-track RFC definition is.)

There is provision in RFC 2434 for "Designated Experts" appointed by the
Area Director to approve registrations. We might make use of that
mechanism for non-standards-track entries, perhaps including my
"provisional" ones. Or maybe there are other mechanisms - the details would
have to be discussed.

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

No, life is not so simple. For example, RFC 2616 defines Content-Type from
the ground up. If RFC 2045 were to disappear in a puff of smoke, RFC 2616
would not be affected. USEFOR does make more use of RFC 2822 for the
headers that are common to both, at least for the syntax. But even there
the semantics are (re)defined in full.

>> >   Specification document:
>> >      A reference to the standards track RFC that defined the header.
>>
>>There will be several specification documents for a given header. I think
>>the register has to state that "this header is intended for use in
>>protocols A, B, and C, and then give the document that defines its use for
>>each of those protocols. Of course, in some cases, the same defining
>>document may be referred to for two or more protocols.

>If this is true, then I don't think a single registry can suffice here.  I 
>think it's fine if different protocols use or constrain the use of a header 
>in different ways, as long as the underlying definition is clear and 
>definitive.  You mentioned the example of HTTP and Content-type:  in this 
>case, I think the basic meaning is clearly defined by RFC 2045;  RFC 2616 
>may refine its interpretation in the context of HTTP, but I don't think it 
>changes the definition.

No, it gives an entirely separate definition, which just happens to follow
the original in most (but not all) respects.

> >>> Question:  does every standardized header truly have a single defining 
>document?

No.

>>Even for a single protocol, there may be more than one document (for
>>example a basic definition, plus some later extension that provides
>>additional functionality).

>Good point.

>In this case, the RFC index will show that the original specification is 
>updated or obsoleted by subsequent documents, so I think it can be argued 
>that the combination of "active" documents provides a single, coherent 
>definition.

Not so. To understand everything you are allowed to write in a
Content-Type, even just for Mail, you need RFC 2231 as well as RFC 2045
(because it extends the syntax of 'token'). But RFC 2231 does not
obsolete RFC 2045. 

>  I'd better re-phrase the previous question:

> >>> Question:  does every standardized header truly have a single coherent 
>definition, tracable from a single initial defining RFC?

Still no.

>>Hmmm! I think you need to stick just to "mail", "news" and "http" (plus
>>any totally separate ones that may appear in the future).

>Well, I was in two minds whether or not to include this in the template.  I 
>don't think it's really needed, but I thought it might be sufficiently 
>helpful to justify the small increase in "paperwork".

> >>> Question:  is this a useful part of the registration template?  If so, 
>what are the appropriate categories?

I think that mechanism will be essential. Here, for example, is how I
would register Content-Type. Note that for each protocol there is a
primary definition, and possibly several secondary definitions (i.e.
extensions).

Header Field-name:	Content-Type
Protocol:	Mail
	Primary definition:	RFC 2045
	Secondary definition:	RFC 2231

Protocol:	Netnews
	Primary definition:	RFC 2045
	Secondary definition:	[[[USEFOR]]]

Protocol:	HTTP
	Primary definition:	RFC 2616

-- 
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: Keith Moore <[email-masked]>, [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Thu, 04 Oct 2001 11:23:27 -0400
Sender: [email-masked]

> I'd like world peace.  So would many others.  There seems to be a bit of
> difficulty in writing the specification for achieving it.

writing the specification isn't the problem in either case.
the problem is a lack of will to implement it.

Date: Thu, 04 Oct 2001 06:26:44 -0700
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Cc: [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

Keith,

I'd like world peace.  So would many others.  There seems to be a bit of 
difficulty in writing the specification for achieving it.

Perhaps you can offer some text for achieving the goal you state?

d/

At 09:52 AM 10/3/2001, Keith Moore wrote:

>What I'd like this document to do is to discourage pollution of the
>message header by unscrupulous vendors trying to degrade interoperability
>with their competitors' products.
>
>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.
>
>Keith

----------
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: "Dan Wing" <[email-masked]>
cc: "Graham Klyne" <[email-masked]>, "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 03 Oct 2001 18:44:35 -0400
Sender: [email-masked]

> Sorry, the header I meant to pick on was "Reply-To:".

well, the current status is standards-track, of course.

though I could make a case for deprecating it, I don't propose
to make that argument in the context of the discussion on the
registry document.  if we use that document as an excuse to 
debate the legitimacy of every header field that's defined in
an RFC it will take 20 years.

Keith

From: "Dan Wing" <[email-masked]>
To: "Graham Klyne" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 3 Oct 2001 15:37:13 -0700
Importance: Normal
Sender: [email-masked]

Sorry, the header I meant to pick on was "Reply-To:".

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Graham Klyne
> Sent: Wednesday, October 03, 2001 2:36 PM
> To: Keith Moore; Dan Wing
> Cc: [email-masked]
> Subject: Re: draft-klyne-msghdr-registry-00.txt
>
>
>
> At 02:12 PM 10/3/01 -0400, Keith Moore wrote:
> >my concern is that we'll register the pollution, and thereby confer
> >legitimacy on it.
>
> That's part of why I focused on RFC-defined headers only.
>
> ...
>
> At 02:59 PM 10/3/01 -0400, Keith Moore wrote:
> >maybe we could have two registries - one of standard headers, and another
> >with discouraged headers.
>
> Well, as I said in my response to Charles, I considered something
> like that
> but in the end didn't because it wasn't clear to me that the benefit
> justified the additional effort.
>
> But I am open to other viewpoints.
>
> ...
>
> At 12:28 PM 10/3/01 -0700, Dan Wing wrote:
> >Playing devil's advocate with that idea, and remembering some active
> >discussion on DRUMS, I'll ask:
> >
> >Which registry would contain "In-Reply-To:" and "References:"?
>
> I think the criterion would be simple:  is it defined in a standards-track
> [or IESG-approved] RFC?    If so, it goes in the "standard"
> registry.  (But
> if you tell me there are headers with different definitions in different
> RFCs, I have to think again.)
>
> #g
>
>
> ------------------------------------------------------------
> Graham Klyne                    MIMEsweeper Group
> Strategic Research              <http://www.mimesweeper.com>
> <[email-masked]>
> ------------------------------------------------------------
>

Date: Wed, 03 Oct 2001 22:35:30 +0100
To: Keith Moore <[email-masked]>, "Dan Wing" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Cc: [email-masked]
Sender: [email-masked]

At 02:12 PM 10/3/01 -0400, Keith Moore wrote:
>my concern is that we'll register the pollution, and thereby confer
>legitimacy on it.

That's part of why I focused on RFC-defined headers only.

...

At 02:59 PM 10/3/01 -0400, Keith Moore wrote:
>maybe we could have two registries - one of standard headers, and another
>with discouraged headers.

Well, as I said in my response to Charles, I considered something like that 
but in the end didn't because it wasn't clear to me that the benefit 
justified the additional effort.

But I am open to other viewpoints.

...

At 12:28 PM 10/3/01 -0700, Dan Wing wrote:
>Playing devil's advocate with that idea, and remembering some active
>discussion on DRUMS, I'll ask:
>
>Which registry would contain "In-Reply-To:" and "References:"?

I think the criterion would be simple:  is it defined in a standards-track 
[or IESG-approved] RFC?    If so, it goes in the "standard" registry.  (But 
if you tell me there are headers with different definitions in different 
RFCs, I have to think again.)

#g

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

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Cc: "Graham Klyne" <[email-masked]>, <[email-masked]>
Subject: RE: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 3 Oct 2001 12:28:06 -0700
Importance: Normal
Sender: [email-masked]

> maybe we could have two registries - one of standard headers, and another
> with discouraged headers.

Playing devil's advocate with that idea, and remembering some active 
discussion on DRUMS, I'll ask:

Which registry would contain "In-Reply-To:" and "References:"?

-d

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "Graham Klyne" <[email-masked]>, [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 03 Oct 2001 14:59:54 -0400
Sender: [email-masked]

maybe we could have two registries - one of standard headers, and another
with discouraged headers.

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Graham Klyne" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 3 Oct 2001 11:53:25 -0700
Importance: Normal
Sender: [email-masked]

> > But I'll ask:  would not the existence of a registry of approved headers
> > make the pollutants more conspicuous by their absence from the registry?
> 
> my concern is that we'll register the pollution, and thereby confer 
> legitimacy on it.

RFC2076 did a nice job of indicating which headers were legit and
which were not legitimate.

Any registration process needs to be similar, and describe the
various meanings.  For example, "registering" the header "Precedence"
wouldn't be useful because its usage isn't fixed (some apps use
numeric, others use all sorts of text, and so on), so a "registration"
needs to acknowledge this fact.

-d

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 03 Oct 2001 14:12:22 -0400
Sender: [email-masked]

> But I'll ask:  would not the existence of a registry of approved headers
> make the pollutants more conspicuous by their absence from the registry?

my concern is that we'll register the pollution, and thereby confer 
legitimacy on it.

Date: Wed, 03 Oct 2001 19:00:37 +0100
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt
Cc: [email-masked]
Sender: [email-masked]

Charles,

Thanks for your many thoughtful comments.  I'll not respond to all of them 
now, but will take them into account when I do another editing pass.  What 
I will do here is try and pick up on some of the fundamental questions you 
raise surrounding this issue.

At 12:02 PM 10/3/01 +0000, Charles Lindsey wrote:
>I think you need to say also the benefits this is intended to achieve. I
>would describe them as:

[...]

> >   A registry for non-standards-track message headers is at best
> >   informational, and at least two such sources of information already
> >   exist:
>
>Indeed, but then this proposed IANA registry is at best informational.

This touches of the normative vs informational purpose for the registry.

The reason I feel that a registry is in order, rather than just an 
informational database, is that I am finding situations where I want to 
leverage the existing set of standards-track definitions in another 
specification;  I want to be able to include existing header names and 
semantics by reference.  (My immediate application is representation of 
message metadata with URIs used to identify header values.)

When thinking about this draft, I considered a two-part registry for 
normatively defined headers, and a separate catalogue of informally defined 
headers.  But I felt that there was limited value in duplicating existing 
efforts, and a simple catalogue of headers-in-use really didn't need to be 
an IANA registry.  Rather, I felt the useful focus was on those that had 
been "assigned" by consensus action in the IETF.

 >>> My question here is this:  does anyone else feel that something more 
strongly normative than a catalogue of headers is called for?

> >3.1 Header specification
> >
> >   Registration of a new message header starts with construction of a
> >   proposal that describes the syntax, semantics and intended use of the
> >   header.  This proposal MUST be published as an RFC.
>
>Right. You did not actually say standards track there. I would have no
>problem with Experimental Protocol RFCs, and I would also like to see
>provisional registrations (with some stringent rules). But we can discuss
>that.

Yes, I was leaving open the choice between "standards action" or "IETF 
consensus";  I tend to favour the latter, as long as it's obvious from a 
published RFC whether or not it represents such consensus.  (I wanted the 
IANA assessment to be dead easy:  the key registration items are the header 
name and defining RFC, which should be easy to check.  Certianly, a 
standards-track RFC definition is.)

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

> >   Specification document:
> >      A reference to the standards track RFC that defined the header.
>
>There will be several specification documents for a given header. I think
>the register has to state that "this header is intended for use in
>protocols A, B, and C, and then give the document that defines its use for
>each of those protocols. Of course, in some cases, the same defining
>document may be referred to for two or more protocols.

If this is true, then I don't think a single registry can suffice here.  I 
think it's fine if different protocols use or constrain the use of a header 
in different ways, as long as the underlying definition is clear and 
definitive.  You mentioned the example of HTTP and Content-type:  in this 
case, I think the basic meaning is clearly defined by RFC 2045;  RFC 2616 
may refine its interpretation in the context of HTTP, but I don't think it 
changes the definition.

 >>> Question:  does every standardized header truly have a single defining 
document?

>Even for a single protocol, there may be more than one document (for
>example a basic definition, plus some later extension that provides
>additional functionality).

Good point.

In this case, the RFC index will show that the original specification is 
updated or obsoleted by subsequent documents, so I think it can be argued 
that the combination of "active" documents provides a single, coherent 
definition.  I'd better re-phrase the previous question:

 >>> Question:  does every standardized header truly have a single coherent 
definition, tracable from a single initial defining RFC?

> >   Intended use:
> >      Specify "general", "mail", "news", "http", "MIME" or cite any
> >      other standards-track RFC defining the protocol with which the
> >      header is intended to be used.
>
>Hmmm! I think you need to stick just to "mail", "news" and "http" (plus
>any totally separate ones that may appear in the future).

Well, I was in two minds whether or not to include this in the template.  I 
don't think it's really needed, but I thought it might be sufficiently 
helpful to justify the small increase in "paperwork".

 >>> Question:  is this a useful part of the registration template?  If so, 
what are the appropriate categories?

>  "General" is too
>vague -

I'm not going to disagree with you here, but if the issue threatens to 
rathole I'll argue for complete removal of the template entry.

> >4. Initial registrations
> >
> >   This specification calls for initial registration of all message
> >   headers defined in existing standards-track documents.  A list of
> >   such headers can be found in RFC 2076 [7] and updates [24].  Section
> >   Section 2.2 of this document contains a list of standards-track
> >   specifications that define message headers.
> >
> >   [[[Need to provide list of headers+documents here for initial
> >   registration?]]]
>
>I think it would be far better to include an Appendix setting out in full
>the initial IANA registration. At the very least, that would force us to
>consider all the special-case problems that will inevitably arise, and
>maybe to fine-tune our document in consequence.

I tend to agree, and I'll happily pull a table of relevant details from RFC 
2076 and updates if there is consensus for this proposal to move 
forward.  (The registration template is deliberately simple and could be 
captured in a simple table.)

>Add consideration of the whole provisional registration issue.

Well, I'm happy to hear consideration, but the feedback I got to my 
original comments suggested to me that any real value in this proposal 
would be in the standard header registrations.

#g

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

Date: Wed, 03 Oct 2001 19:03:27 +0100
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Cc: [email-masked]
Sender: [email-masked]

At 12:52 PM 10/3/01 -0400, Keith Moore wrote:

>What I'd like this document to do is to discourage pollution of the
>message header by unscrupulous vendors trying to degrade interoperability
>with their competitors' products.
>
>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.

Well that's not what I set out to do, and I don't plan to embrace a kind of 
"negative registration" mode.

But I'll ask:  would not the existence of a registry of approved headers 
make the pollutants more conspicuous by their absence from the registry?

#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: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: draft-klyne-msghdr-registry-00.txt 
Date: Wed, 03 Oct 2001 12:52:28 -0400
Sender: [email-masked]

What I'd like this document to do is to discourage pollution of the 
message header by unscrupulous vendors trying to degrade interoperability
with their competitors' products.

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.

Keith

To: [email-masked]
Xref: clerew local.mime:769
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: draft-klyne-msghdr-registry-00.txt
Date: Wed, 3 Oct 2001 12:02:24 GMT
Lines: 275
Sender: [email-masked]

>Network Working Group                                           G. Klyne
>Internet-Draft                                         MIMEsweeper Group
>Expires: March 28, 2002                                     Sep 27, 2001
>
>
>              Registration procedures for message headers
>                     draft-klyne-msghdr-registry-00
>
>
>Abstract
>
>   This specification defines registration procedures for the message
>   headers used by Internet mail, newsgroup feeds, HTTP and other
>   Internet applications.

Aren't you supposed to say somewhere what classification of RFC this is
intended to become? I guess it would be "Best Current Practice", but I am
not sure.

>1. Introduction
>
>   This specification defines registration procedures for the message
>   headers used by Internet mail, newsgroup feeds, HTTP and other
>   Internet applications.

I think you need to say also the benefits this is intended to achieve. I
would describe them as:

1. To serve as an index/directory of established headers, enabling their
meaning and defining documents to be located.

2. To prevent accidental re-use of a header field-name for some different
purpose.

3. To enable those proposing new headers to discern already established
trends and conventions, and to avoid field-names that differ only slightly
from existing ones.

>
>   The primary specification for Internet message headers is the
>   Internet mail message format specification, RFC 2822 [21], but there
>   are many other Internet standards track documents that define
>   additional headers within the same namespace, notably MIME [6] and
>   related specifications.  Other Internet applications that use MIME,
>   such as newsgroup feeds and HTTP web access, also use many of the
>   same headers.

I think you need to make explicit reference to RFC 1036 (news) [[[and
USEFOR]]] and RFC 2616 (HTTP) here.

>   Although in principle each application defines its own set of valid
>   headers, exchange of messages between applications (e.g.  mail to
>   news gateways), common use of MIME encapsulation, and the possibility
>   of common processing for various message types (e.g.  a common
>   message archive and retrieval facility) makes it desirable to have a
>   single point of reference for standardized headers.  The message
>   header registry defined here serves that purpose.
>

>2. Message headers
>
>2.1 Standard and non-standard headers
>
>   Many message headers are defined in standards-track documents, which
>   means they have been subjected to a process of community review and
>   achieved consensus that they provide a useful and well-founded
>   capability.  Many other headers have been defined and adopted for
>   private use.
>
>   The registry defined here is intended for headers defined in IETF
>   standards-track documents, or those that have achieved a comparable
>   level of community review.  Thus, the assignment policy for
>   registration of new message headers is [[[ IETF consensus | Standards
>   action ]]], as defined by RFC 2434 [17].
>
>   A registry for non-standards-track message headers is at best
>   informational, and at least two such sources of information already
>   exist:

Indeed, but then this proposed IANA registry is at best informational.

>
>   o  RFC 2076 [7], as updated [24], contains a list of commonly used
>      message headers, and

I think the intention of this registry should be to supersede the function
of RFC 2076 and its extensions.

>
>   o  Dan Bernstein maintains a list of standard and non-standard mail
>      message headers [25].
>
>
>2.2 Definitions of message headers
>
>   RFC 2822 [21] defines a general syntax for Internet message headers.
>   It also defines a number of headers for use with Internet mail.
>   Additional header names are defined in a variety of standards-track
>   RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3],
>   RFC 1766 [4], RFC 1864 [5], RFC 2156 [11], RFC 2183 [12], RFC 2045
>   [6], RFC 2110 [8], RFC 2298 [13], RFC 2369 [14], RFC 2421 [16], RFC
>   2821 [20], RFC 2912 [22] and RFC 2919 [23].

Make sure any obsoleted RFCs are not in your list.

>
>   Internet applications that use (some of) these message headers
>   include Internet mail [20][21], NNTP newsgroup feeds [1], HTTP web
>   access [18] and any other that uses MIME [6] encapsulation of message
>   content.

I don't see the distinction you are trying to make here. RFC 2616 [18] is
in the business of defining headers just as much as RFC 2822, 1036, or any
of the others in your first list. It belongs with the first lot. Note also
that HTTP is not restricted to web access. It can be used to retrieve any
"resource", whether web related or not.

>
>3. Registration procedure
>
>
>
>3.1 Header specification
>
>   Registration of a new message header starts with construction of a
>   proposal that describes the syntax, semantics and intended use of the
>   header.  This proposal MUST be published as an RFC.

Right. You did not actually say standards track there. I would have no
problem with Experimental Protocol RFCs, and I would also like to see
provisional registrations (with some stringent rules). But we can discuss
that.

>
>   A registered header name MUST conform to the syntax defined by RFC
>   2822, section 3.6.8, for "field name".  Further, the "." character is
                                   ^
				   -
>   reserved to indicate a naming sub-structure and MUST NOT be included
>   in any registered header name.  Currently, no specific sub-structure
>   is defined; if used, any such structure MUST be defined by a
>   standards track RFC document.

I think you say "MUST at least conform...", and then indicate that
individual protocols MAY specify more stringent requirements. For example,
RFC 2616 restricts field-names characters quite severely, and USEFOR will
be even more severe; RFC 1036 REQUIRES a blank after the colon (and USEFOR
will follow it).

>
>   It is further RECOMMENDED that characters in a registered message
>   header name are restricted to those characters that can be used
>   without escaping in a URI [15], namely upper- or lower-case ASCII
>   letters, decimal digits, "(", ")", "+", ",", "-", "=", "@", ";", "$",
>   "_", "!", "*" and "'".

The RFC 2616 set is neither a subset nor a superset of that lot :-( . I
actually see no need for anything other that letters, digits and '-', and
I know of no existing counter-example. It may also be worth noting that
only ASCII letters and digits are permitted in field-names. That is true of
both RFC 2822 and USEFOR (even though USEFOR allows UTF-8 elsewhere in
headers).

>
>   The name of a registered header MUST be unique; if an name is already
>   assigned to an existing registered header name, some other name must
>   be chosen.

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

>
>   Header names beginning with "X-" or "x-" are reserved for private
>   use, and MUST NOT be registered or defined normatively by a standards
>   track RFC.

or defined in ANY RFC for that matter, including Experimental Protocols.

>
>3.2 Registration template
>
>   The registration template for a message header is typically contained
>   in the defining document, or may be prepared separately.
>
>   The registration template for a message header contains the following
>   information:
>
>   Header name:
>      The name requested for the new header.  This MUST conform to the
>      header specification details above.
>
>   Specification document:
>      A reference to the standards track RFC that defined the header.

There will be several specification documents for a given header. I think
the register has to state that "this header is intended for use in
protocols A, B, and C, and then give the document that defines its use for
each of those protocols. Of course, in some cases, the same defining
document may be referred to for two or more protocols.

Even for a single protocol, there may be more than one document (for
example a basic definition, plus some later extension that provides
additional functionality).

>
>   Intended use:
>      Specify "general", "mail", "news", "http", "MIME" or cite any
>      other standards-track RFC defining the protocol with which the
>      header is intended to be used.

Hmmm! I think you need to stick just to "mail", "news" and "http" (plus
any totally separate ones that may appear in the future). "General" is too
vague - better to list the same RFC against two or more protocols if it
applies to them all. And the application of "MIME" may vary considerably
between protocols (for example, there is no Content-Transfer-Encoding in
HTTP). Again, USEFOR will include a list of MIME headers that are
allowed in news articles, and refers to the existing MIME RFCs for their
meaning. However, it does then go on to curtail their usage in various
minor ways.

So a question arises as to which RFC you refer to for a protocol that
just does such minor tinkerings/clarifications.

>
>   Related information:
>      Optionally, citations to additional documents containing further
>      information relevant to the defined message header.

Yes, that may be a way to cover the "tinkerings/clarifications" issue.

>
>3.6 Location of message header registry
>
>   The message header registry is accessible from IANA's web site [27].
>
>4. Initial registrations
>
>   This specification calls for initial registration of all message
>   headers defined in existing standards-track documents.  A list of
>   such headers can be found in RFC 2076 [7] and updates [24].  Section
>   Section 2.2 of this document contains a list of standards-track
>   specifications that define message headers.
>
>   [[[Need to provide list of headers+documents here for initial
>   registration?]]]

I think it would be far better to include an Appendix setting out in full
the initial IANA registration. At the very least, that would force us to
consider all the special-case problems that will inevitably arise, and
maybe to fine-tune our document in consequence.

>Appendix B. Todo
>
>   (This section to be removed on final publication)
>
>   o  Finalize choice of RFC 2434 assignment policy.  See section
>      Section 2.1.

Add consideration of the whole provisional registration issue.

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