[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