Subject: [apps-discuss] Changes to netnews header registrations

From: Graham Klyne <[email-masked]>
Date: Fri, 13 May 2016 07:23:03 +0100

As reviewer for the IANA message headers registry 
(http://www.iana.org/assignments/message-headers/message-headers.xhtml), I've 
received a request to change references to to rename "[Son-of-1036]" references 
to "[RFC1849]"?  This document is now published as a historic RFC.

I propose to make a recommendation that goes beyond the original request, and as 
such I thought I should submit my proposed recommendation to public review.

I think the requested change is appropriate with respect to the following 
message header fields:

     Also-control
     Article-names
     Article-updates
     See-also

(Did I miss any?)

I also think that RFC5536 should be cited for these headers, as it is this 
document that formally declared them to be obsolete 
(https://tools.ietf.org/html/rfc5536#section-6).

While we're at it, I'd suggest also citing RFC5536 for the following header 
fields, also obsoleted by that document 
(https://tools.ietf.org/html/rfc5536#section-3.3 and #section-6):

     Date-Received        netnews    obsoleted    [RFC0850]
     Posting-Version        netnews    obsoleted    [RFC0850]
     Relay-Version        netnews    obsoleted    [RFC0850]
     NNTP-Posting-Date        netnews    obsoleted
     NNTP-Posting-Host        netnews    obsoleted    [RFC2980]

If I hear no objection within a few days, I'll pass this recommendaton to IANA.

#g
--

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 13 May 2016 17:20:40 +0200

Hi Graham,

First of all, thanks for reviewing the request I sent.
I add the USEFOR IETF WG in copy of this message, in case they wish to 
comment.

> (http://www.iana.org/assignments/message-headers/message-headers.xhtml),
> I've received a request to change references to rename
> "[Son-of-1036]" references to "[RFC1849]"?  This document is now
> published as a historic RFC.
>
> I propose to make a recommendation that goes beyond the original
> request, and as such I thought I should submit my proposed
> recommendation to public review.
>
> I think the requested change is appropriate with respect to the
> following message header fields:
>
>     Also-control
>     Article-names
>     Article-updates
>     See-also
>
> (Did I miss any?)

These are indeed the 4 message header fields obsoleted by RFC1849.

> I also think that RFC5536 should be cited for these headers, as it is
> this document that formally declared them to be obsolete

Yes, RFC5536 can be cited instead of, or along with, RFC1849.

> While we're at it, I'd suggest also citing RFC5536 for the following
> header fields, also obsoleted by that document

Couldn't X-Trace and X-Complaints-To header fields also be added to that 
list?

X-Trace        netnews    obsoleted    [RFC5536]
X-Complaints-To        netnews    obsoleted    [RFC5536]

They are indeed mentioned at the same time as NNTP-Posting-Host in 
Section 3.2.8 of RFC5536, and are no longer useful with Injection-Info 
header field:

       NOTE: Some of this information has previously been sent in non-
       standardized header fields such as NNTP-Posting-Host, X-Trace,
       X-Complaints-To, and others.  Once a news server generates an
       Injection-Info header field, it should have no need to send these
       non-standard header fields.

While we're at it, couldn't MIME-related header fields also be added as 
standard for netnews?

MIME-Version        netnews    standard    [RFC5536][RFC5322]
Content-Type        netnews    standard    [RFC5536][RFC5322]
Content-Transfer-Encoding        netnews    standard    [RFC5536][RFC5322]
Content-Disposition        netnews    standard    [RFC5536][RFC5322]
Content-Language        netnews    standard    [RFC5536][RFC5322]

As a matter of fact, Section 3.2 of RFC5536 speaks of them, with added 
restrictions in syntax:

    None of the header fields appearing in this section are required to
    appear in every article, but some of them may be required in certain
    types of articles.  Further discussion of these requirements appears
    in [RFC5537] and [USEAGE].

    The header fields Comments, Keywords, Reply-To, and Sender are used
    in Netnews articles in the same circumstances and with the same
    meanings as those specified in [RFC5322], with the added restrictions
    detailed above in Section 2.2.  Multiple occurrences of the Keywords
    header field are not permitted.

    comments        =  "Comments:" SP unstructured CRLF

    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

    reply-to        =  "Reply-To:" SP address-list CRLF

    sender          =  "Sender:" SP mailbox CRLF

    The MIME header fields MIME-Version, Content-Type, Content-Transfer-
    Encoding, Content-Disposition, and Content-Language are used in
    Netnews articles in the same circumstances and with the same meanings
    as those specified in [RFC2045], [RFC2183], and [RFC3282], with the
    added restrictions detailed above in Section 2.2.

Thanks,

-- 
Julien ÉLIE

« Pour célébrer ce jour heureux, buvons un coup, buvons-en deux. »
   (Aristophane)

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 May 2016 09:20:35 +0100

Hi Julien,

Thanks for your update and confirmation of the affected fields.

TL;DR: I don't propose to recommend the additional changes you suggest as I'm 
not seeing that they really contribute to the purpose of the registry (cf. 
https://tools.ietf.org/html/rfc3864#section-2.2.2).

In slightly more detail, I offer the following reasons:

1. My rationale in suggesting the changes I did was to help keep the registry 
reasonably aligned with the relevant IANA considerations RFC sections.  The 
additional headers you mention don't appear in the document IANA considerations.

2. With reference to the X-headers you mention, I see little point in adding 
new, non-standard headers to the registry simply to indicate they are now 
obsolete.  (There could be a case for doing this if they are in widespread use, 
but I think that should be a separate discussion, and a new RFC with its own 
IANA considerations section. I suspect it's not worth the effort!)

3. The other headers you mention are not substantively changed by RFC 5536: the 
restrictions noted are specifically with respect to the netnews protocol, and as 
such are not really relevant to the registry purpose.

4. I did consider that "netnews" might be added to the protocol options for the 
MIME-version and Content-* header fields you mention, but as they are already 
registered as MIME headers that doesn't seem to serve any useful purpose (see 
https://tools.ietf.org/html/rfc3864#section-2.2.2).

#g
--

On 13/05/2016 16:20, Julien ÉLIE wrote:
> I add the USEFOR IETF WG in copy of this message, in case they wish to comment.
>
>
> Couldn't X-Trace and X-Complaints-To header fields also be added to that list?
>
> They are indeed mentioned at the same time as NNTP-Posting-Host in Section 3.2.8
> of RFC5536, and are no longer useful with Injection-Info header field:
>
> While we're at it, couldn't MIME-related header fields also be added as standard
> for netnews?
>

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 May 2016 09:33:01 +0100

> https://tools.ietf.org/html/rfc3864#section-2.2.2).
That link should have been https://tools.ietf.org/html/rfc3864#section-1.  Sorry.

#g
--

> obsolete.  (There could be a case for doing this if they are in widespread 
> use, but I think that should be a separate discussion, and a new RFC with its 
> own IANA considerations section. I suspect it's not worth the effort!)
>
> 3. The other headers you mention are not substantively changed by RFC 5536: 
> the restrictions noted are specifically with respect to the netnews protocol, 
> and as such are not really relevant to the registry purpose.
>
> 4. I did consider that "netnews" might be added to the protocol options for 
> the MIME-version and Content-* header fields you mention, but as they are 
> already registered as MIME headers that doesn't seem to serve any useful 
> purpose (see https://tools.ietf.org/html/rfc3864#section-2.2.2).
>
> #g
> -- 
>
>
> _______________________________________________
> Ietf-message-headers mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-message-headers
>

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 16 May 2016 17:57:00 +0200

Hi Graham,

> TL;DR: I don't propose to recommend the additional changes you suggest
> as I'm not seeing that they really contribute to the purpose of the
> registry (cf. https://tools.ietf.org/html/rfc3864#section-2.2.2).

OK, Content-* header fields used by netnews are not supposed to be 
registered.  Yet, is it the same for MIME-Version, that is not mentioned 
in neither Section 1 nor Section 2.2.2 of RFC3864?

> 2. With reference to the X-headers you mention, I see little point in
> adding new, non-standard headers to the registry simply to indicate they
> are now obsolete.  (There could be a case for doing this if they are in
> widespread use, but I think that should be a separate discussion, and a
> new RFC with its own IANA considerations section. I suspect it's not
> worth the effort!)

It depends on when we can say a header field is "wide-spread".
I've just had a look in two newsgroups:

* last 1043 messages (roughly October 2014-May 2016) in news.software.nntp:
391 (37%) contain X-Trace
216 (21%) contain X-Complaints-To

* last 1437 messages (roughly August 2014-May 2016) in soc.culture.french:
612 (43%) contain X-Trace
97 (7%) contain X-Complaints-To

Of course wider stats should be done because the generation of these 
headers depend on the news servers the users connect to.

X-Trace seems in wide-spread use, though.
I agree that writing a new RFC to just obsolete it is probably not worth 
the effort.  However, maybe X-Trace (and maybe other headers) could be 
added in IANA considerations section of an update of RFC 5536 if we ever 
move it to Draft Standard?

-- 
Julien ÉLIE

« La différence entre un chanteur et une paire de chaussures est que
   le chanteur doit partir avant de lasser. La paire de chaussures, il
   vaut mieux les lacer avant de partir. » (Philippe Geluck)