Re: [Ietf-message-headers] Changes to netnews header registrations

[Graham Klyne <[e-mail]>]

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:
> 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.
>
>
>> 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 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
>> (https://tools.ietf.org/html/rfc5536#section-6).
>
> 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
>> (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.
>
> 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,
>