Subject: Re: IANA considerations

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 01 Jan 2006 14:57:54 +0100

--On 28. desember 2005 19:41 +0000 Charles Lindsey <[email-masked]> 
wrote:

>
> 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 tedious). I like the idea of not making -usefor depend
>> on this.
>
> 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.

Note that the registry points to the documents that contain the complete 
registration templates. I don't think we can break the rules by not 
submitting the templates.

(The question of how IANA maintains registries is a completely different 
subject.)

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Jan 2006 13:22:59 +0100

Harald Tveit Alvestrand wrote:

> the registry points to the documents that contain the complete
> registration templates. I don't think we can break the rules
> by not submitting the templates.

Okay, so either a separate document (my preference, same style
as for mail and http), or complete templates in the core spec.
(ugh).  It's a piece of cake to create the former, but I don't
want to waste time for it if we then pick the latter strategy.

With split documents an outline for the core spec. would be:

IANA Considerations

  The news header fields specified or obsoleted by this memo
  are listed separately in [draft-ietf-usefor-hdrreg-00] with
  the registration templates for the IANA registry of header
  fields.
[...]

Informative References
[...]
  [draft-ietf-usefor-hdrreg-00] Registration of news header
  fields specified or obsoleted by [RFC XXXX] (this memo).

xml2rfc has some magic supporting self-references [RFC XXXX],
and draft-ietf-usefor-hdrreg-00 would be an informational RFC.

                             Bye, Frank

---

From: Ken Murchison <[email-masked]>
Date: Mon, 02 Jan 2006 09:46:58 -0500

Harald Tveit Alvestrand wrote:
> 
> 
> --On 22. desember 2005 08:17 -0500 Ken Murchison <[email-masked]> 
> wrote:
> 
>>>    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).
>>
>> 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?
> 
> 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.

Do we really have to use the same format as given by the template, or 
just provide the same information as specified by the template?  If the 
latter, then I think a table such as the one I stole from Charles is fine.

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

I don't believe that the sentences that refer to the obsoleted headers 
provide enough of a definition, especially without an ABNF grammar 
somewhere.  Referencing s-o-1036 would be good if it has a formal 
definition of the headers.  The dependency is only bad if s-o-1036 
doesn't get into the RFC editor queue before USEFOR.

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 02 Jan 2006 17:18:11 +0100

--On mandag, januar 02, 2006 09:46:58 -0500 Ken Murchison 
<[email-masked]> wrote:

> just provide the same information as specified by the template?

I don't see much leeway in RFC 3864 section 3 and 4:

3.  Registry Usage Requirements

   RFCs defining new header fields for Internet mail, HTTP, or MIME MUST
   include appropriate header registration template(s) (as given in
   Section 4.2) for all headers defined in the document in their IANA
   considerations section.  Use of the header regi stry MAY be mandated
   by other protocol specifications, however, in the absence of such a
   mandate use of the registry is not required.

4.  Registration Procedure

   The procedure for registering a message header field is:

   1.  Construct a header field specification

   2.  Prepare a registration template

   3.  Submit the registration template

Perusing the Mail header registry document, RFC 4021, clarifies that the 
words PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE are not part of 
the template, luckily :-)

                  Harald

---

From: Ken Murchison <[email-masked]>
Date: Mon, 02 Jan 2006 12:17:11 -0500

> I don't see much leeway in RFC 3864 section 3 and 4:

So, what is the decision of the chair regarding the format and location 
of the IANA header registry entries?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 03 Jan 2006 14:14:53 +0100

> of the IANA header registry entries?

Given that the editor is willing to do it, the chair rules that the 
registration forms for the headers defined here will go into the USEFOR-07 
draft. I'll leave it to the editor's license whether it's inside the IANA 
considerations section or a new appendix pointed to by the IANA 
considerations section.

I've created #1156 to keep track of this.

                          Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 3 Jan 2006 17:05:45 GMT

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

>Note that the registry points to the documents that contain the complete=20
>registration templates. I don't think we can break the rules by not=20

Aaaarrrrrgh! I had not noticed that, and it is absolutely not what RFC
3864 was intended to bring about, as I understood it at the time, and
absolutely not the way things used to be done.

Hmmmmm! Last time I looked in anger at an IANA Registry, it contained what
was in the template. For example, I once looked at the template for
news/transmission (which was in the format specified by RFC 2048). From
the IANA site, following various links, I found the template (which AIAIR
was still somewhere under www.iana.org), and in due course used it to
construct the revised template which you will now find in USEPRO. Likewise
the template for message/news, which we propose to declare obsolete in
USEPRO.

I have just looked for those two templates again, and they are not to be
found. All they do is refer you to RFC 1036 (and they are not there as you
well know) and to Henry Spencer's no-longer-working email address.

And yet some templates are there (for example, I can find
application/msword). Indeed, most of the templates not defined in RFCs
seem to be there.

Google eventually found me a copy of the current
application/news-transmission template, but it wasn't on any IANA site, or
any site controled by Henry Spencer. Indeed, it is totally unclear who
owns the site I found.

>(The question of how IANA maintains registries is a completely different=20
>subject.)

Indeed so. What is the point of having an IANA registry if it manages to
lose specifications entrusted to it?

I think we need to understand what the role of IANA really is before
proceeding any futher with this.

-- 
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: Frank Ellermann <[email-masked]>
Date: Tue, 03 Jan 2006 21:25:20 +0100

Charles Lindsey wrote:

> in the format specified by RFC 2048

That's now AFAIK obsoleted by 4288 + 4289.

> All they do is refer you to RFC 1036

If that's about message/news it might be old, I've
never seen a complete message/news template.  Bye

http://web.archive.org/web/*/http://www.iana.org/assignments/media-types/message/

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 3 Jan 2006 17:21:25 GMT

>latter, then I think a table such as the one I stole from Charles is fine.

I think the first thing to understand is that the templates do not need to
be as verbose as the ones found in RFC 4229 and RFC 4021 (one should bear
in mind that those documents were separate from the RFCs where the headers
were actually desccribed, which will not be the case with USEFOR). So
Frank's worries concerning the umpteen pages it might eat up in our
document are nothing like so bad as he supposes.

The table that has been proposed contains all the information that we are
required to supply (though we have the option of saying more in particular
cases if we feel the need). Even writing them out in full in the format
prescribed by RFC 3864 would not be that bad, though it would look pretty
boring (as will always be the case when you have an RFC introducing a lot
of templates all at once).

Putting them in a table is much more user friendly. Essentially, it is a
rule whereby you could construct each individual template if you really
wanted to, but what is the point?

So my view is that we should try to publish them in table form, and if the
IETF tell us to rewrite them, or instruct the RFC-Editor to expand them in
full, then we should worry about it if/when that happens.

>doesn't get into the RFC editor queue before USEFOR.

I think the main thing to ensure is that it doesn't have to be a normative
reference (and I see no reason why it should be - from a standards point
of view, all we are saying is "Don't use this header", which does not
actually _require_ any definition of what that header might have once
meant).

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 4 Jan 2006 11:59:25 GMT

>never seen a complete message/news template.  Bye

I think Google could find it for you. And I have certainly found it on the
IANA website in the past.

Both message/news and application/news-transmission were registered
privately by Henry Spencer in the days when IANA was less fussy about
where things came from. Neither was ever in any RFC

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jan 2006 13:31:47 +0100

> full, then we should worry about it if/when that happens.

We follow the rule. We write templates.

I like the table too, as a summary. But we follow the rule, until the rule 
changes.

                     Harald