Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03
John C Klensin <john-ietf@jck.com> Sun, 15 May 2016 15:44 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 3A43012D125 for <urn@ietfa.amsl.com>; Sun, 15 May 2016 08:44:13 -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 c4E4i7r6eApa for <urn@ietfa.amsl.com>; Sun, 15 May 2016 08:44:11 -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 7E5CD12D0F6 for <urn@ietf.org>; Sun, 15 May 2016 08:44:11 -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 1b1yDA-000JkI-Nr; Sun, 15 May 2016 11:44:08 -0400
Date: Sun, 15 May 2016 11:44:03 -0400
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Message-ID: <1F5D414703BF94503600A5E3@JcK-HP8200.jck.com>
In-Reply-To: <c19ff352-cd49-d664-9365-28898cff3050@gmx.de>
References: <231532ef-e195-b73d-4a34-eb445bdd1900@gmx.de> <c19ff352-cd49-d664-9365-28898cff3050@gmx.de>
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/8PCQdJP8v3mcf4FSG0MTrMdPfAo>
Subject: Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03
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: Sun, 15 May 2016 15:44:13 -0000
--On Sunday, May 15, 2016 14:48 +0200 Julian Reschke <julian.reschke@gmx.de> wrote: > Hi there, > > I haven't seen any substantial feedback on what I wrote two > weeks ago. Thus here's my attempt to rephrase this in order to > get more people to think about it. I have been waiting for the co-chairs to take a position on whether you are reopening an old topic and will continue to wait. The difference between this topic and those to which I have been responding (to at least a subset) is that, while I believe we discussed those others and move on, my recollection is that Andy made a formal consensus call and closed this one. If we start revisiting old topics without substantial new information, it very nearly guarantees that we will never get finished. Reluctantly and against my better judgment, but in the interests of saving time, a clarification below. > On draft-ietf-urnbis-semantics-clarif-03: > > This currently updates RFC 3986. Of course we can do this, but > RFC 3986 is a full standard, and thus this draft needs to be > crystal clear about what exactly is being updated. I don't > think it currently does that; it does some hand-waving with > respect to what fragments and queries are (without saying > exactly what's wrong in RFC 3986). It does *not* talk about > changes to equivalence and relative resolution, although > draft-ietf-urnbis-rfc2141bis-urn-16 seems to attempt to change > them. The update to 3986 is to remove URNs from the scope of URNs except with regard to URI syntax. 3986 says, effectively, that URNs are just like any other URIs; the "update" is that they they are not. The informal description of draft-ietf-urnbis-semantics-clarif as "syntax only" is consistent with that. That particular "syntax only" decision has some fairly sweeping implications, which were discussed at the time. In particular, it makes the definitions in 3986 --either whatever precise ones appear or whatever oral tradition they have accumulated in other forums -- irrelevant: they are not syntax. So one can argue, for example, that the way draft-ietf-urnbis-semantics-clarif uses the term "resource" or distinctions it attempts to make about it are undesirable, but one cannot appeal to inconsistency with 3986 to support that view. In addition, to the degree to which the WG has already closed out this issue, an argument about inappropriateness is presumably out of order unless it includes fundamentally new arguments. However, again, that requires a judgment by the co-chairs. Some of Juha's recent comments highlight another reason for making the "syntax only" distinction and drawing a hard line with it: the usage (I'm reluctant to say "definition") of the term "identifier" in 3986 is incompatible with the meaning and use of that term in the library and information sciences community. Making progress on URNs requires, at least IMO, not trying to resolve that incompatibility but does require that the terminology of 3986 not be treated as authoritative for URNs. As to what should be in which document, the status of draft-ietf-urnbis-semantics-clarif has, for a long time, been "decide whether to fold all or part of this into 2141bis when the WG has consensus about the substantive content of the latter". I've been reluctant to do a major merge because of concern about introducing mistakes in the process, but am happy to try to do whatever the WG actually wants. Finally, the "syntax only" separation is intended to remove the implication that URNs (at least of the "urn:" scheme, but that was deliberately left ambigious) are separate from all other URIs (if one believes that the language of 3986 creates a dichotomy, "all other URIs" == "URLs") and therefore that questions like "how does this affect URL processors?" have a uniform answer of "not at all, because even 3986 says that URNs are not URLs". best, john
- [urn] Feedback on draft-ietf-urnbis-semantics-cla… Julian Reschke
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… Sean Leonard
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… Julian Reschke
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… Julian Reschke
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… John C Klensin
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… Andrew Newton
- Re: [urn] Feedback on draft-ietf-urnbis-semantics… Julian Reschke
- [urn] Summary of WG decisions Re: Feedback on dra… Sean Leonard
- Re: [urn] Summary of WG decisions Re: Feedback on… Andrew Newton
- Re: [urn] Summary of WG decisions Re: Feedback on… Julian Reschke
- Re: [urn] Summary of WG decisions Re: Feedback on… John C Klensin
- Re: [urn] Summary of WG decisions Re: Feedback on… Andrew Newton
- Re: [urn] Summary of WG decisions Re: Feedback on… John C Klensin