Re: [Tools-discuss] RFC Email announcements

[Brian E Carpenter <[e-mail]>]

Tom,

The email is transitory; the point is to use the info URL as the primary reference, for the reasons I gave. That's what the RFC Editor service has 
decided to do, and I fully support that choice.

Regards
    Brian

On 02-Feb-22 15:24, Tom Pusateri wrote:
> That’s in the email. I’ve already decided I wanted to read it when I clicked on the link.
> 
> We publish documents not meta data.
> 
> And my preference would have the rfc links be in the document References too (not the info links).
> 
> Tom
> 
>> On Feb 1, 2022, at 8:59 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>> On 02-Feb-22 14:07, Tom Pusateri wrote:
>>> The following email was received this morning announcing a new RFC.
>>> I think the link supplied to this document could be improved by
>>> referencing the rfc page instead of the info page.
>>> https://www.rfc-editor.org/rfc/rfc9187.html
>>
>> Disagree. Here's why:
>>
>> 1. The info page shows the current status, e.g. Historic, Updated By, and so on. We need people to be aware of the status before reading or citing an RFC. For example, it tells me that RFC9817 is not from the IETF.
>> It tells me that RFC2460 is obsolete.
>>
>> That is not an "administrative" matter. It's what you need to know before reading the text.
>>
>> 2. We probably agree that the HTML is the best one to actually read, but opinions may differ.
>>
>>     Brian
>>
>>> Here's why:
>>> 1. We should maximize the content and not the meta data. This is a
>>> common theme and I think we should be doing everything we can to
>>> emphasize the content we create and that is used by the most number of
>>> people and not the meta data that is used by a much smaller
>>> administrative group.
>>> 2. The rfc page contains a link at the top to the info page if that's
>>> what you really want but it probably isn't because there's already lots
>>> of meta data in the email.
>>> 3. If you're really into meta-data, the top of the rfc page also
>>> contains a link to the datatracker. :)
>>> Thanks,
>>> Tom
>>> -------- Forwarded Message --------
>>> Subject: RFC 9187 on Sequence Number Extension for Windowed Protocols
>>> Date: Mon, 31 Jan 2022 23:17:49 -0800 (PST)
>>> From: [e-mail]
>>> To: [e-mail], [e-mail]
>>> CC: [e-mail], [e-mail]
>>> A new Request for Comments is now available in online RFC libraries.
>>>                   RFC 9187
>>>           Title:      Sequence Number Extension for Windowed Protocols
>>>         Author:     J. Touch
>>>           Status:     Informational
>>>           Stream:     Independent
>>>           Date:       January 2022
>>>           Mailbox:    [e-mail]
>>>           Pages:      10
>>>           Updates/Obsoletes/SeeAlso:   None
>>>           I-D Tag:    draft-touch-sne-02.txt
>>>           URL:        https://www.rfc-editor.org/info/rfc9187
>>>           DOI:        10.17487/RFC9187
>>> Sliding window protocols use finite sequence numbers to determine
>>> segment placement and order. These sequence number spaces wrap around
>>> and are reused during the operation of such protocols. This document
>>> describes a way to extend the size of these sequence numbers at the
>>> endpoints to avoid the impact of that wrap and reuse without
>>> transmitting additional information in the packet header. The
>>> resulting extended sequence numbers can be used at the endpoints in
>>> encryption and authentication algorithms to ensure input bit patterns
>>> do not repeat over the lifetime of a connection.
>>> INFORMATIONAL: This memo provides information for the Internet community.
>>> It does not specify an Internet standard of any kind. Distribution of
>>> this memo is unlimited.
>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>> To subscribe or unsubscribe, see
>>>     https://www.ietf.org/mailman/listinfo/ietf-announce
>>>     https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>> For searching the RFC series, see https://www.rfc-editor.org/search
>>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>>> Requests for special distribution should be addressed to either the
>>> author of the RFC in question, or to [e-mail].  Unless
>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>> unlimited distribution.
>>> The RFC Editor Team
>>> Association Management Solutions, LLC
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> ___________________________________________________________
>>> Tools-discuss mailing list - [e-mail]
>>> This list is for discussion, not for action requests or bug reports.
>>> * Report datatracker and mailarchive bugs to: [e-mail]
>>> * Report tools.ietf.org bugs to: [e-mail]
>>> * Report all other bugs or issues to: [e-mail]
>>> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>> ___________________________________________________________
>> Tools-discuss mailing list - [e-mail]
>> This list is for discussion, not for action requests or bug reports.
>> * Report datatracker and mailarchive bugs to: [e-mail]
>> * Report tools.ietf.org bugs to: [e-mail]
>> * Report all other bugs or issues to: [e-mail]
>> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss