Re: [Rfcplusplus] Qualified labels
Robert Sparks <rjsparks@nostrum.com> Tue, 10 July 2018 02:44 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 0AFE4131070 for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 19:44:26 -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 epODcs-BCHdi for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 19:44:23 -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 793D61310D4 for <rfcplusplus@ietf.org>; Mon, 9 Jul 2018 19:44:23 -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 w6A2iM8x058428 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <rfcplusplus@ietf.org>; Mon, 9 Jul 2018 21:44:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be unescapeable.local
To: rfcplusplus@ietf.org
References: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <0dbf07da-969c-9704-9618-8d3d7ff03004@nostrum.com>
Date: Mon, 09 Jul 2018 21:44:22 -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: <888b184e-51ea-23fc-afaa-f9b5116d480a@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/198qs595iXm3i5m4V2JHXjx8KK8>
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:44:27 -0000
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
- Re: [Rfcplusplus] Qualified labels Robert Sparks
- Re: [Rfcplusplus] Qualified labels Robert Sparks
- [Rfcplusplus] Qualified labels Brian E Carpenter
- Re: [Rfcplusplus] Qualified labels Brian E Carpenter
- Re: [Rfcplusplus] Qualified labels Alice Russo
- Re: [Rfcplusplus] Qualified labels Alice Russo
- Re: [Rfcplusplus] Qualified labels Brian E Carpenter