Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986
John C Klensin <john-ietf@jck.com> Tue, 31 May 2016 17:11 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4905A12D63A for <urn@ietfa.amsl.com>; Tue, 31 May 2016 10:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 pPCxqxw51OHu for <urn@ietfa.amsl.com>; Tue, 31 May 2016 10:11:18 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6B812D520 for <urn@ietf.org>; Tue, 31 May 2016 10:11:18 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1b7nCE-000AW1-Kh; Tue, 31 May 2016 13:11:14 -0400
Date: Tue, 31 May 2016 13:11:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <E438B36A07F723A65D839E02@JcK-HP8200.jck.com>
In-Reply-To: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com>
References: <2c9b4833-2893-f40a-de06-0f55c8ff468e@seantek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/zIPPnP7IXDR_9NX2qe1RZvTqRbQ>
Cc: urn@ietf.org
Subject: Re: [urn] Thread about urnbis-semantics-clarif-03 in the context of updating 3986
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 17:11:25 -0000
Just one reminder on this subject... The WG has always (or more or less always) considered urnbis-semantics-clarif as primarily a working document for its own convenience in developing 2141bis and anything else relevant. We've agreed (I think several times) to defer the question of whether to actually publish it as an RFC until we were winding up our work (that might be now -- now my call). If the WG concludes that it is no longer needed (or, in retrospect, never was), I'd be the first one to applaud and take it out of my queue. That "maybe we will publish and maybe we won't" approach has almost certainly resulted in a more casual attitude toward precise text than would have been the case for a draft that was clearly going to be standards-track or RFC-publication-track. The assumption, perhaps unrealistic or wrong in retrospect, has been that, if the WG decided to publish it or its offspring as an RFC, we would go over it and clean details up at that point. The approach also dictated at least two other sets of decisions that have been raised (again) recently: (1) The reference to it from 2141bis is Informative, not Normative. If 2141bis is not constructed well enough to justify that distinction, it is a problem with it (2141bis) and suggestions about text are welcome. (2) There is some, perhaps a good deal, of text in urnbis-semantics-clarif that is intended to convey the general sense that the WG isn't sure (and doesn't have clear consensus) whether there is are issues between 2141bis (etc.?) and 3986 or not; if there are conflicts, read this document and 2141bis as authoritative for URNs and not 3986; if there are not, you can ignore this document. Section 2, which, as Sean points out, was carried forward largely unchanged from the "URNs are not URIs" document (see below), attempts to cover that point. In rereading it, it occurs to me that an entirely different approach could be taken, which would be to say just that, i.e., to start from "Some people in the community think there is a conflict between these URN specs and 3986. Others disagree. If readers find apparent conflicts, especially in the scheme-specific syntax for URNs, then 2141bis should be treated as authoritative for URNs independent of what they believe 3986 says." Such a statement, I'd hope with better wording, could easily be incorporated into 2141bis and this whole "semantics versus syntax" discussion and all of the baggage associated with it discarded. Or, if someone thinks a separate document is needed, replacing urnbis-semantics-clarif, as far as I'm concerned, please have at it. Finally, not because I'm particularly attached to either document, but because it might be important, one clarification: the "URNs are not URIs" proposal came about after some fairly extensive discussions within the WG about both the apparent substantive issues involved and about how to change the WG discussion focus back to URNs and away from seemingly-interminable discussions about the relationship between URNs and whatever people thought 3986 said, a set of discussions that also included examination of places where 3986 appeared to change or constrain 2141 and/or 3406 without explicitly discussing or updating those documents, leaving all three in an ambiguous state. I no longer remember how much of those discussions were on the mailing list, in formal meetings, and in sequences of small group conversations, but note that draft-ietf-urnbis-urns-are-not-uris really was a WG document for which I drew the short straw to assemble and edit -- fwiw, the original idea was not mine although I think the syntax split one might have been. At a subsequent meeting, the WG decided on the narrower approach that draft-ietf-urnbis-semantics-clarif attempts to capture. I drew that short straw too and, being lazy (and, IIR, on instructions from that meeting), reused as much text as I thought feasible. I hope that the "URNs are not URIs" approach is part of our past and we can concentrate on moving forward, but it was a WG document, did have some level of consensus (although obviously not enough) and I don't think dismissing it as "John's polemic" is at all helpful. That earlier approach could become relevant again in one particular situation that I hope won't arise. The in-meeting conclusion and subsequent list discussion that discarded "URNs are not URIs" in favor of the syntax-semantics separation was, I believe, ultimately tentative and experimental wrt the question of whether the latter separation could be made to work. If the WG were to conclude that a distinction is needed and the syntax-semantics separation is not feasible in practice, unless we simply decided to abandon URNs, the result would presumably be a return to the "URNs are not URIs" approach. That approach would require updating 3896 as well, but only to the extent of removing the example at the end of Section 1.1.2, modifying the example in Section 3, and modifying the discussion in 1.1.3 to remove the discussion of URNs and maybe non-locator names. One of the attractions of that updating relationship was that there was never any question of its documentary effect on 3986 (unlike the current discussion about the much finer distinction of the "semantics-clarif" approach). best, john
- [urn] Thread about urnbis-semantics-clarif-03 in … Sean Leonard
- Re: [urn] Thread about urnbis-semantics-clarif-03… John C Klensin
- Re: [urn] Thread about urnbis-semantics-clarif-03… Andrew Newton
- Re: [urn] Thread about urnbis-semantics-clarif-03… Sean Leonard
- Re: [urn] Thread about urnbis-semantics-clarif-03… John C Klensin