Re: Visibility of current RFC Maturity Levels (and how they got there (was: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic)

[Barry Leiba <[e-mail]>]

Well, if people are really going to the .txt files on rfc-editor.org,
then nothing we do in the process of changing an RFC's status will
help them, and it doesn't matter whether we use "obsoletes" or not.

If they're using most other means, they will see the current state of
"Historic", and they will have a way to navigate to the status-change
document.  Because of that, having an RFC that uses "obsoletes" seems
mostly unnecessary, except that the "obsoleted by" pointers might be a
little easier to find, depending upon the access mechanism you're
using.

My sense is that someone who cares enough to want to find out why the
RFC is Historic is likely to be able to handle the navigation.

Barry


On Tue, May 15, 2018 at 5:09 PM, Benjamin Kaduk <[e-mail]> wrote:
> On Tue, May 15, 2018 at 12:17:11PM +1200, Brian E Carpenter wrote:
>> Top posting to note that if you find the RFC via its DOI you
>> also get the correct status first. I think the RFC Editor has
>> done the best they can, consistent with the policy that the
>> bits in the canonical form of an RFC never change.
>
> That touches on John Klensin's question about where people would
> reasonably expect to find things (RFCs and metadata about them).
>
> For me as an AD, I am either looking at the tools.ietf.org HTML
> version or the datatracker page, or I am lamenting Google's
> algorithm that placed me somewhere else.  But I don't know what
> "people in general" are "reasonably expecting" to do; perhaps the
> RFC Editor's plain-text repository remains canonical in usage as
> well as in archival status, even if it is not for me.  (It's also
> unclear how useful http/rsync/etc access logs would be for trying to
> answer this question.)
>
> -Ben



-- 
Barry
--
Barry Leiba  ([e-mail])
http://internetmessagingtechnology.org/