IETF Logo Mail Archive

Re: [Rfcplusplus] Qualified labels

Robert Sparks <rjsparks@nostrum.com> Tue, 10 July 2018 02:49 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A8131158 for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 19:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXzNVuSY68dd for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 19:49:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80D7131179 for <rfcplusplus@ietf.org>; Mon, 9 Jul 2018 19:49:52 -0700 (PDT)
Received: from unescapeable.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6A2npHm059400 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <rfcplusplus@ietf.org>; Mon, 9 Jul 2018 21:49:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local
From: Robert Sparks <rjsparks@nostrum.com>
To: rfcplusplus@ietf.org
References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com> <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com>
Message-ID: <7787043f-1ab0-f957-2d26-e915009c4d3f@nostrum.com>
Date: Mon, 09 Jul 2018 21:49:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/UuB_GZftTCqdDkoYLgLtRCnJv90>
Subject: Re: [Rfcplusplus] Qualified labels
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 02:50:01 -0000

_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.

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
>> Rfcplusplus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rfcplusplus
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusplus

v2.23.0 | Report a Bug | By Email