Subject: IANA considerations

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Dec 2005 20:34:35 +0100

Hi, here's my proposal for the missing IANA considerations:

1 - we create a simple draft-ietf-usefor-hdrreg-00.txt, that
    would be a WG -00, so we need Alexey's or Harald's OK

2 - we add an informative reference to that I-D in the future
    "WG last call xmas edition" (draft-ietf-usefor-usefor-07),
    with IANA considerations as a pointer to the hddrreg-draft

3 - in essence that news header registry draft would be like...

http://www.ninebynine.org/IETF/Messaging/HdrRegistry/draft-lindsey-hdrreg-netnews-01.xml

...with minor editorial changes for all details:

Update boilerplate s/full3667/full3978/ , docName, WG, date,
and normative reference to 3864.  Remove the 2119 keywords.

Add informative reference to 4021, add normative reference to
draft-ietf-usefor-usefor.  Remove references to 1036 and 2119.

s/1036/draft-ietf-usefor-usefor/g
s/informational/standard/g

Split the registered header fields into two (or maybe three)
categories (old chapter 2 => new chapters 2, 3, and maybe 4).

One chapter for the deprecated / historic news header fields,
status "historic":  

       NNTP-Posting-Date       (no spec., dummy source Usefor)
       NNTP-Posting-Host       (no spec., dummy source Usefor)
       Relay-Version           (no spec.  => Usefor or 1036 ?)
       Posted-Version          (no spec.  => Usefor or 1036 ?)
       Date-Received           (no spec.  => Usefor or 1036 ?)
       Also-Control            (Usefor or s-o-1036 ?)
       See-Also                (Usefor or s-o-1036 ?)
       Article-Names           (Usefor or s-o-1036 ?)
       Article-Updates         (Usefor or s-o-1036 ?)

One chapter for the hardcore Netnews header fields, as in the
old 2004 draft, status "standard":

       Message-ID
       References
       Newsgroups
       Path
       Control
       Supersedes
       Followup-To
       Expires
       Distribution
       Supersedes
       Approved
       Xref
       Organization
       Summary
       Lines                 (comment: obsolescent)
       Archive               (comment: new)
       User-Agent            (comment: new)
       Injection-Info        (comment: new)
       Injection-Date        (comment: new)
         
Maybe a chapter for the most important mail header fields also
_required_ (= mandatory) in NetNews, with essentially the same
syntax and semantics as in mail / 2822, status "standard":

       Date
       From
       Subject

Or add this to the "main" chapter (?)  Dummy IANA and security
considerations as is, no I18N considerations, ready.

                         Bye, Frank

---

From: Ken Murchison <[email-masked]>
Date: Mon, 19 Dec 2005 11:25:15 -0500

>     with IANA considerations as a pointer to the hddrreg-draft

What is the reasoning behind creating a separate I-D?  Since we're 
(re)defining Usenet in USEFOR, why not include the header registry in 
our document?  Email and HTTP have separate documents because the 
protocol documents predated RFC 3864.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 20 Dec 2005 00:05:15 +0100

Ken Murchison wrote:

> What is the reasoning behind creating a separate I-D?

The IANA header registry stuff is kind of boring.  I like it
very much, but my tastes are a bit extraordinary.  Adding the
about 22 KB (plus more fields minus boilerplate) in a revised

<http://tools.ietf.org/html/draft-lindsey-hdrreg-netnews>

to the about 64 KB in draft-ietd-usefor-usefor would result
in about one quarter "IANA header registration considerations".

Therefore I think it's better to split this...

> why not include the header registry in our document?

...but I don't insist on it.  It's only a matter of taste:

As it is draft-ietf-usefor-usefor is short and sweet with no
nonsense.  14 pages of header registrations would inflate it.

                       Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Dec 2005 17:55:42 GMT

>    would be a WG -00, so we need Alexey's or Harald's OK

No, there is no need to do that. RFC 3864 requires us to include the
proper IANA registrations within USEFOR itself.

>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/draft-lindsey-hdrreg-netnews-01.xml

That document dealt with provisional registrations for the headers as they
stand in RFC 1036, etc. And yes, I really ought to submit it as an
informational RFC.

But the format of that document is far more complex that RFC 3864 requires
(it was copied from the style of Graham Klyne's over-verbose mail
document).

If you want a text to insert into USEFOR, then you will find all you want
in the IANA Considerations section (10.2) of draft-ietf-usefor-article-13.
It is a bit out of date, because we have changed some headers, but it is
in exactly the format that RFC 3864 asks for.

-- 
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: Ken Murchison <[email-masked]>
Date: Wed, 21 Dec 2005 09:18:42 -0500

> in exactly the format that RFC 3864 asks for.

OK, here's what I have in my current copy.  Note that I had to pull the 
protocol and change controller out of the <texttable>, since its is the 
only way that xml2rfc would render the text version without mangling it.

6.  IANA Considerations

    IANA is requested to register the following header fields in the
    Permanent Message Header Field Repository, in accordance with the
    procedures set out in [RFC3864].

       NOTE: For each of the registered header fields, the Applicable
       protocol is "netnews" and the Author/Change controller is "IETF".

    +----------------+-----------+--------------------------------------+
    | Header field   | Status    | Specification document(s)            |
    | name           |           |                                      |
    +----------------+-----------+--------------------------------------+
    | Approved       | standard  | This document (Section 3.2.9)        |
    |                |           |                                      |
    | Archive        | standard  | This document (Section 3.2.12)       |
    |                |           |                                      |
    | Comments       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Control        | standard  | This document (Section 3.2.5)        |
    |                |           |                                      |
    | Date           | standard  | This document (Section 3.1.2),       |
    |                |           | [RFC2822] (Section 3.6.1)            |
    |                |           |                                      |
    | Distribution   | standard  | This document (Section 3.2.7)        |
    |                |           |                                      |
    | Expires        | standard  | This document (Section 3.2.4)        |
    |                |           |                                      |
    | Followup-To    | standard  | This document (Section 3.2.3)        |
    |                |           |                                      |
    | From           | standard  | This document (Section 3.1.1),       |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Injection-Date | standard  | This document (Section 3.2.1)        |
    |                |           |                                      |
    | Injection-Info | standard  | This document (Section 3.2.14)       |
    |                |           |                                      |
    | Keywords       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Lines          | obsoleted | This document (Section 3.3.1)        |
    |                |           |                                      |
    | Message-ID     | standard  | This document (Section 3.1.3),       |
    |                |           | [RFC2822] (Section 3.6.4)            |
    |                |           |                                      |
    | Newsgroups     | standard  | This document (Section 3.1.5)        |
    |                |           |                                      |
    | Organization   | standard  | This document (Section 3.2.10)       |
    |                |           |                                      |
    | Path           | standard  | This document (Section 3.1.6)        |
    |                |           |                                      |
    | References     | standard  | This document (Section 3.2.2),       |
    |                |           | [RFC2822] (Section 3.6.4)            |
    |                |           |                                      |
    | Reply-To       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Sender         | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Subject        | standard  | This document (Section 3.1.4),       |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Summary        | standard  | This document (Section 3.2.8)        |
    |                |           |                                      |
    | Supersedes     | standard  | This document (Section 3.2.6)        |
    |                |           |                                      |
    | User-Agent     | standard  | This document (Section 3.2.13)       |
    |                |           |                                      |
    | Xref           | standard  | This document (Section 3.2.11)       |
    +----------------+-----------+--------------------------------------+

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 06:08:40 +0100

> | Lines          | obsoleted | This document (Section 3.3.1)        |

AFAIK there's no status "obsoleted" in 3864.  You could only
mention this in the comment of a complete registration form.

Say "standard", it's only a registry, details are irrelevant
if the source has it right.

You forgot the registrations for all header fields declared
to be "historic" by draft-ietf-usefor-usefor-06:

IMHO the IANA registry needs the last known status "historic",
and the source for this last known status, and that's always
draft-ietf-usefor-usefor-06. 

In theory s-o-1036 is the first source for the deprecation of
Relay-Version / Posted-Version / Date-Received, but it's no
RFC at the moment, let's just register the complete "historic"
zoo and be done with it.
                         Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Dec 2005 12:12:16 GMT

>       protocol is "netnews" and the Author/Change controller is "IETF".

We also need to consider whether User-Agent should also apply to the
protocol "email". It was designed with that intent, and our draft says so
(indeed, it would also have been identical to the HTTP protocol version,
but for some differences in the lexical conventions of HTTP). It is used
as much in email as in Netnews (though syntax varies somewhat on both,
because it has not been written down before, except in the HTTP
standards).

Probably we should check with IESG whether they would be willing for us to
do this, since it would stretch our charter somewhat. OTOH, I doubt anyone
is going to bother to do an ID for the same header in email jusr repeating
our syntax.

The same thing might apply to the Organization header, which is widely
used in email.

I think we also need to mention various other headers now deprecated or
obsoleted.

   NNTP-Posting-Host netnews deprecated IETF
   NNTP-Posting-Date netnews deprecated IETF
   Also-Control netnews obsoleted IETF
   See-Also netnews obsoleted IETF
   Article-Names netnews obsoleted IETF
   Article-Updates netnews obsoleted IETF

A proper reference for the last 4 would be Son-of-1036, which we propose
to refer to in any case. The 1st two have no published definition that I
know of apart from the source code of INN. However, they are both much
used, and we have explicitly deprecated their continued use in USEFOR. I
think it would still be proper to describe IETF as the "Change Controller"
(but not as Author, obviously).

I think it important that one should be able to look up any header one may
have encountered in some article in the IANA registry in order to see what
its official status, if any, might be (surely that is the whole point of
the registry).

---

From: Ken Murchison <[email-masked]>
Date: Thu, 22 Dec 2005 08:17:11 -0500

> The same thing might apply to the Organization header, which is widely

I have no problem adding this (if I can get xml2rfc to behave well with 
another column in the table), if somebody wants to do the legwork with 
IETF/IESG to determine if we can/should add this to our doc.

>    NNTP-Posting-Host netnews deprecated IETF
                                ^^^^^^^^^^

RFC 3864 doesn't list "deprecated", just "standard", "experimental", 
"informational", "historic", "obsoleted".  I supposed we *could* use 
"deprecated", but perhaps we could get by with "historic".

> (but not as Author, obviously).

If s-o-1036 actually defines a header, then I think we can probably 
register it.  If there is no definition anywhere that we can reference, 
then how can we register it?  I certainly don't want to add ABNF to our 
doc for headers that are dead.

Harald, any thoughts?

> its official status, if any, might be (surely that is the whole point of

I agree in theory.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 14:22:07 +0100

Charles Lindsey wrote:

> We also need to consider whether User-Agent should also apply
> to the protocol "email". It was designed with that intent
> and our draft says so

Easy for 2822bis to adopt this if they like it...

> Probably we should check with IESG whether they would be
> willing for us to do this, since it would stretch our charter
> somewhat.

...that's a good reason to stay away from it.  They could be
tempted to ask us why it took us six years to figure out the
Message-ID, and why we want to screw up mail before the Path-
syntax is 100% clear.

>    Article-Updates netnews obsoleted IETF

What about Relay-Version / Posted-Version / Date-Received ?
Apparently they are only mentioned (already as obsolete) in
appendix A.3 of s-o-1036, but not in 1036.

Why do we have them at all, what was Henry talking about when
he wrote "early versions of the news software" ?  His examples
are 1983, RfC 1036 was published 1987.  Should we just remove
this from our draft, because it's ancient pre-1036 history ?

 [NNTP-Posting-*]
> I think it would still be proper to describe IETF as the
> "Change Controller" (but not as Author, obviously).

We grabbed them and deprecate them in a not-yet IETF PS, so
that's "Change Controller: IETF" as per the 3864 rules...

...oops, I just see that "obsoleted" for "Lines" is allowed:

| Status:
|  Specify "standard", "experimental", "informational",
|  "historic", "obsoleted", or some other appropriate value

Maybe "obsoleted" is the correct value for NNTP-Posting-* (?)

My first guess would be "historic" => old and not more needed,
"obsoleted" => old and replaced by something better.  If that
makes sense NNTP-Posting-* are "obsoleted", the othere are all
"historic", but the 'obsolescent' Lines is still "standard".

                     Bye, Frank

---

From: Ken Murchison <[email-masked]>
Date: Thu, 22 Dec 2005 08:17:49 -0500

> mention this in the comment of a complete registration form.

 From RFC 3864:

    "Status:
       Specify "standard", "experimental", "informational", "historic",
       "obsoleted", or some other appropriate value according to the type
       and status of the primary document in which it is defined."

> to be "historic" by draft-ietf-usefor-usefor-06:

See my response to Charles' message.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 14:49:06 +0100

> See my response to Charles' message.

Yes, our articles crossed at some point behind my monitor. ;-)

Let's take "historic" for the four s-o-1036 header fields,
because the plan for s-o-1036 was publication as "historic".

For NNTP-Posting-* "obsoleted" is fine, we replace them by
our Injection-*, and they are not yet "historic", they are
even not specified in any RFC (AFAIK).

For "Lines" you could say "obsolescent" or "deprecated" if
you don't like "standard", that's what the draft does, and
3864 allows any "appropriate value".

For the three s-o-1036 appendix A.3 header fields last seen
1983 (before RFC 1036) let's delete the intro of chapter 3.3
in -06, and start directly after "In addition...":

| This standard obsoletes four header fields defined in
| [Son-of-1036]:
[...]
                          Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Dec 2005 03:14:47 +0100

--On 22. desember 2005 08:17 -0500 Ken Murchison <[email-masked]> 
wrote:

>> think it would still be proper to describe IETF as the "Change
>> Controller" (but not as Author, obviously).
>

Grumble. The HTTP and Mail documents both give full templates per header, 
and as you say, this makes for a very long document (easy to produce, just 
tedious). I like the idea of not making -usefor depend on this.

The issue of documenting obsoleted headers is problematic. We From [email-masked] Sun Dec 25 21:53:06 2005
Date: Mon, 26 Dec 2005 03:14:47 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: IANA considerations
Sender: [email-masked]

--On 22. desember 2005 08:17 -0500 Ken Murchison <[email-masked]> 
wrote:

>> think it would still be proper to describe IETF as the "Change
>> Controller" (but not as Author, obviously).
>

Grumble. The HTTP and Mail documents both give full templates per header, 
and as you say, this makes for a very long document (easy to produce, just 
tedious). I like the idea of not making -usefor depend on this.

The issue of documenting obsoleted headers is problematic. We can (in 
theory) argue that the sentences referring to them as "obsoleted" in 
usefor-usefor is enough definition for an obsoleted header. It would be 
more proper to have son-of-1036 as the reference - but that introduces a 
dependency, which is bad.

More opinions?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Dec 2005 03:24:12 +0100

--On 22. desember 2005 12:12 +0000 Charles Lindsey <[email-masked]> 
wrote:

> because it has not been written down before, exccan (in 

More opinions?

--=====02BE2954ACB18CDA98B0=====
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--=====02BE2954ACB18CDA98B0=====--

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Dec 2005 03:24:12 +0100

> The same thing might apply to the Organization header, which is widely

After the snafu over the Newsgroups: headers.... No, we won't do that.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Dec 2005 03:22:19 +0100

> mention this in the comment of a complete registration form.

3864 section 4.2.1:

   Status:
      Specify "standard", "experimental", "informational", "historic",
      "obsoleted", or some other appropriate value according to the type
      and status of the primary document in which it is defined.  For
      non-IETF specifications, those formally approved by other
      standards bodies should be labelled as "standard"; others may be
      "informational" or "deprecated" depending on the reason for
      registration.

Seems to be a field where syntax checking is not going to be terribly 
strict.... if a field was defined in 822 and deprecated in 2822, I suppose 
the correct status would be "standard-but-obsoleted"......

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Dec 2005 13:03:17 GMT

>Message-ID, and why we want to screw up mail before the Path-

Eh? You are mixing a whole bunch of separate issues there. If a header is
widely used across several protocols, then it is sensible to define it in
one place (unless some controversy arises), and the IANA registry then
mentions that one place for both protocols. So the machinery is there -
the question is whether to use it. Anyway, I think we need to hear Harald
on this one.

>appendix A.3 of s-o-1036, but not in 1036.

Yes, they could usefully be mentioned. The only difference is that the
first four were actually proposed for current use in S-o-1036, whereas the
last three were already dead and buried by then (so perhaps 'Historic' is
the word to use). But S-o-1036 is still a good reference for what they
used to be like.

BTW, I have now heard back from Henry Spencer. Seems he lost his email
connection through a massive cockup by his ISP. Yes, he still intends to
publish S-o-1036 as an infomational/whatever RFC, so on the strength of
that, I think we can now remove the historic appendices from both USEFOR
and USEPRO, and possibly simplify the section that declares some things
'obsolete'. We should then refer to S-o-1036 in a suitable place.

As for the two NNTP-POSTING-* ones, I see benefit in mentioning them, and
the lack of formal definition need be no bar. "Long established custom"
should be good enough if you don't want to mention the source code of INN.

There are also some other headers with "Long standing custom" usage (such
as Mail-Copies-To) but their future is still in the balance (we did not
include them, but we did not bar them from future work).

>that's "Change Controller: IETF" as per the 3864 rules...

Indeed,

>Maybe "obsoleted" is the correct value for NNTP-Posting-* (?)

Could be. Or we are allowed to invent new words if really necessary.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Dec 2005 19:41:11 GMT

In <4E1927EA4BCAE0EFDB80BE29@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>Grumble. The HTTP and Mail documents both give full templates per header,=20
>and as you say, this makes for a very long document (easy to produce, just=20

Well looking at the registries IANA have actually constructed
(http://www.iana.org/assignments/message-headers/perm-headers.html and
http://www.iana.org/assignments/message-headers/prov-headers.html), they
have only taken the bare bones of those documents - essentially what Ken's
table proposed), so I think that is all we are obliged to provide. In
fact, they haven't even included the 'Status' and 'Author/Change
controller' fields at all, which I find odd. And for sure, if we want any
"related information" to be attached to some header, we will need to say
so explicitly in out IANA Considerations.

>The issue of documenting obsoleted headers is problematic. We can (in=20
>theory) argue that the sentences referring to them as "obsoleted" in=20
>usefor-usefor is enough definition for an obsoleted header. It would be=20
>more proper to have son-of-1036 as the reference - but that introduces a=20

I would say that if we declare the Foo-Bar header to be "obsolete", then
the document which delcares it obsolete is the primary reference that is
needed. A secondary reference to any document that might have defined it
previously would be a sensible addition, if such exists, but I would
suppose that would be of the nature of an "informative" reference, and as
such need not create a dpendency. In any case, I presume we are going to
have an informative reference to S-o-1036 in lieu of those Historical
Appendices,

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Dec 2005 19:45:38 GMT

In <CA4640EE41B1F3E153B07D27@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>Seems to be a field where syntax checking is not going to be terribly=20
>strict.... if a field was defined in 822 and deprecated in 2822, I suppose=20

For which you could use the word "obsolescent". However, that might
require some explanation. We are really up against the problem that the
IETF machinery does not seem to cope well with the case where a Standard
has been superseded by a Proposed Standard (and everybody agrees that the
old one is to be considered dead), but nobody has gotten around to moving the
new standard along the track.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 30 Dec 2005 04:27:40 +0100

Charles Lindsey wrote:

> We are really up against the problem that the IETF machinery
> does not seem to cope well with the case where a Standard
> has been superseded by a Proposed Standard (and everybody
> agrees that the old one is to be considered dead), but nobody
> has gotten around to moving the new standard along the track.

For 2821, a PS broken by design (= essentially a DDoS machine),
the fatal design flaw was already a part of STD 3 (1123).  And
"everybody agrees with 1123 5.3.6a" would be utter dubious, but
I digress.

I don't see anything of this issue here, the status of 1036 is
"unknown", not "standard".  S-o-1036 would be "historic", and
draft-ietf-usefor-usefor will be the only game in town (as PS)
for the NetNews article format.

The new header field registry offers "standard" for anything on
standards track (and even for wannabe-standards published by
other SDOs like ISO, W3C, Unicode, ECMA, etc., roll-your-own).

Apparently it also allows "obsolescent" or "deprecated" for
our case "Lines:".  IMO good enough, the draft uses precisely
these adjectives in 3.3.1
                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 30 Dec 2005 05:02:07 +0100

Charles Lindsey wrote:

> You are mixing a whole bunch of separate issues there.

Indeed.  I prefer to have a limited list of attack vectors in
the "IETF last call", in essence Message-ID and our "magic SP".

> If a header is widely used across several protocols, then it
> is sensible to define it in one place (unless some
> controversy arises), and the IANA registry then mentions that
> one place for both protocols. So the machinery is there -
> the question is whether to use it.

If the 2822 folks wish to adopt our User-Agent as is, even with
our weird "magic SP", they can do it.  In theory you could also
register it directly for mail (without 2822bis), just post the
registration form on the msghdr list, wait two weeks, and then
IANA is obliged to add it to the registry (AFAIK - only Martin
tested it for a provisional Archived-At registration).

> he still intends to publish S-o-1036 as an infomational/
> whatever RFC, so on the strength of that, I think we can now
> remove the historic appendices from both USEFOR and USEPRO,
> and possibly simplify the section that declares some things
> 'obsolete'.

Good news.  Let Henry finish off these three pre-1036 header
fields in his "IANA considerations".  We can then focus on our

> Could be. Or we are allowed to invent new words if really

Apparently we are, but for NNTP-* "obsoleted" is fine, and for
the four s-o-1036 header fields "historic" is okay.  For Lines:
"standard" or "deprecated" or "obsolescent" will do, and that's
then at least consistent with our own usage of "obsoleted" and
"historic" for different purposes.
                                  Bye, Frank