Re: [usefor] [Ietf-message-headers] Changes to netnews header registrations (correction)

[Graham Klyne <[e-mail]>]

On 16/05/2016 09:20, Graham Klyne wrote:
> 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).
That link should have been https://tools.ietf.org/html/rfc3864#section-1.  Sorry.

#g
--

>
>
> 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,
>>
>
> _______________________________________________
> Ietf-message-headers mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-message-headers
>