[urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris)
John C Klensin <john-ietf@jck.com> Tue, 26 August 2014 00:08 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453F41A04BA for <urn@ietfa.amsl.com>; Mon, 25 Aug 2014 17:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.568
X-Spam-Level:
X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 8q5gp7EPWj2F for <urn@ietfa.amsl.com>; Mon, 25 Aug 2014 17:08:07 -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 F230F1A047B for <urn@ietf.org>; Mon, 25 Aug 2014 17:08:06 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1XM4Iv-000Ijn-AL; Mon, 25 Aug 2014 20:08:05 -0400
Date: Mon, 25 Aug 2014 20:08:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org, Andrew Newton <andy@hxr.us>
Message-ID: <C3C022CAC5456E17CEF34D4E@JcK-HP8200.jck.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.115
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/eZ9qTJt1gzkavCrMIjoLmiutxuE
Subject: [urn] Document status and related issues - semantics clarification (replacing urns-are-not-uris)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 26 Aug 2014 00:08:09 -0000
Hi. I've posted the replacement for draft-ietf-urnbis-urns-are-not-uris-01 as draft-ietf-urnbis-semantics-clarif-00. It is now awaiting Andy's approval which I thought was given shortly after Toronto. Some of you know that my intention was to immediately follow it with a trimmed-down -01 because -00 contains a lot of material we probably won't want long-term. As a preview, exclusive of references (some of them cited from the appendices) and appendices, -00 is only 8 pages long; with them, twice that. I've deferred trying to get -01 out both because -00 took much longer than expected and because I continued to review both the post-Toronto mailing list comments and a number of private communications and concluded that the current draft may not be stable enough to start pulling text out of. I'd also like to have a better idea of what Peter expected to do with 2141bis (or what the WG wants him to do). I'm aware that some text is redundant, especially the repeated comments about zero effect on generic URI parsing systems. That is partially intentional (to be sure those statements didn't get lost when we start removing sections) and partially just temporarily running out of energy. Note too that this draft contains, in Section 6, my cut at the list Andy requested of alternatives with which the WG will need to deal. In the spirit of the discussions in Toronto, this document is intended more as the basis for focusing discussions than as a final piece to be published. To paraphrase what Andy said there, we need to make decisions about what we want to do and only then figure out how much of this, if any, is worth having in an officially-permanent document. While some of the discussion in this -00 draft gets fairly far into "how to do this", I personally concur with something Andy, Henry, and several others have said in different ways: in the short run, we are much more likely to end up with the results we want if we can talk about functionality and not where to put it or what syntax to use. While the I-D uses "query" and "fragment" terminology, it may even be useful to thinks of parts of the URI syntax as "path-stuff", "?-stuff", and "#-stuff", remembering that the connotations of words like "query" and "fragment" are themselves semantics. I expect that we will return to URI terminology before the version of 2141bis that reflects these issues is posted but, for thinking right now it again may be useful to break loose from historical concepts. Some of the above has almost certainly influenced what I've written and how I've written it. That doesn't mean the text is right, but I hope we can be clear about what we are talking about before we get into trouble. Happy reading, john
- [urn] Document status and related issues - semant… John C Klensin
- Re: [urn] Document status and related issues - se… Leslie Daigle (TCE)
- Re: [urn] Document status and related issues - se… John C Klensin
- Re: [urn] Document status and related issues - se… Leslie Daigle (TCE)
- Re: [urn] Document status and related issues - se… John C Klensin
- Re: [urn] Document status and related issues - se… Andrew Newton
- Re: [urn] Document status and related issues - se… John C Klensin
- Re: [urn] Document status and related issues - se… Peter Saint-Andre - &yet