Re: [Rfcplusplus] Qualified labels

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

On 10/07/2018 14:49, Robert Sparks wrote:
> _sigh_ - even after carefully trying to point to a particular edge, I 
> transcribed the number incorrectly.
> 
> Please substitute 5289 for all the rfc number examples I pointed to below.

Right. My thinking is that the label would indeed need to be ephemeral
in case a document changes status, and I guess that would lead to
tombstones in the citation libraries. Or to put it another way,
a document would have a label stack, with the current label on top,
but the previous ones still there for the sake of previous citations.
So the label stack for RFC5289 should** be

1. RFC5289-PS
2. RFC5289-INFO

and that for RFC2460 should be

1. RFC2460-OBS
2. RFC2460-DS

** However, you have hit upon a bug. The IESG may believe that
they upgraded RFC5289, but it seems that nobody told the RFC Editor,
since it is still officially listed as Informational. Even the tracker
is confused. So we have a procedural glitch in this area already.

   Brian


> 
> RjS
> 
> p.s. 
> <https://datatracker.ietf.org/doc/status-change-uplifting-rfc5289-to-ps/>
> 
> 
> On 7/9/18 9:44 PM, Robert Sparks wrote:
>>
>>
>> On 7/9/18 9:23 PM, Brian E Carpenter wrote:
>>> Hi,
>>>
>>> I don't think there's any disagreement that better labels are
>>> desirable. I do think this would all be a lot simpler if we
>>> could just agree to move to a single-stage standards track,
>>> but since we must support status changes within the standards
>>> track, including obsoletion, we are forced to have external
>>> labels that are not in the archived format. That's an opportunity
>>> as well as a challenge. So here's a proposal:
>>>
>>> 1) Continue to use the RFC series as today for multiple purposes.
>>> But recognise more clearly that the number is an archival reference.
>>>
>>> 2) For all normal purposes, including citations, use a *qualified*
>>> label. Rather than writing a formal definition, there's an example
>>> of each qualifier below.
>>>
>>> An advantage is that this can be retrofitted straightforwardly
>>> to *all* RFCs, indexes, citation libraries, etc.
>> If we were to pursue this path:
>>
>> That's not quite straightforward. It's easy if you just snapshot the 
>> current qualifiers, but if you want to be historically correct, it's 
>> going to take some non-straightforward work. It would also need a 
>> decision about edges like the following (both for handling what has 
>> happened, and what could happen in the future):
>>
>> Would RFC5249-INFO and RFC5249-PS be different documents, or aliases 
>> for the same document? (I assume having RFC5249-INFO disappear from 
>> the archival record would be unacceptable). How would a user finding 
>> RFC5249-INFO learn about RFC5249-PS? (And a string of very familiar 
>> questions would follow here).
>>>   And it
>>> could be removed just as easily if it proves to be a problem
>>> rather than a solution.
>>>
>>> RFC8200-STD (or RFC8200-STD86)
>>> RFC8414-PS
>>> RFC5681-DS
>>> RFC2026-BCP (or RFC2026-BCP9)
>>>
>>> RFC7557-EXPT
>>> RFC8394-INFO  (for IETF informationals)
>>> RFC7663-IAB
>>> RFC7575-RSCH  (for IRTF informationals)
>>> RFC8351-INDEP (for Independent informationals)
>>>
>>> RFC2460-OBS
>>> RFC1128-UNK
>>> RFC1130-HIST
>>>
>>> Regards
>>>      Brian
>>>
>>> _______________________________________________
>>> Rfcplusplus mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rfcplusplus
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rfcplusplus
> 
> _______________________________________________
> Rfcplusplus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rfcplusplus
>