From nobody Mon Feb  2 12:42:25 2015
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 09E511A8AEA for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 12:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.39
X-Spam-Level: **
X-Spam-Status: No, score=2.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RB8HCye5BZJM for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 12:42:17 -0800 (PST)
Received: from bsa2.jck.com (ns.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 9C6171A8AE2 for <urn@ietf.org>; Mon,  2 Feb 2015 12:42:17 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YINp1-0009QR-Ol; Mon, 02 Feb 2015 15:42:15 -0500
Date: Mon, 02 Feb 2015 15:42:10 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sean Leonard <dev+ietf@seantek.com>, urn@ietf.org
Message-ID: <15614C85890F8EDDB6C9030D@JcK-HP8200.jck.com>
In-Reply-To: <54BFEF7B.6070701@seantek.com>
References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <CAAQiQRee2pC3B9_eR1daw=3EEOFMiSXN6ZLjVt8B9RBbLKHV7g@mail.gmail.com> <54ABABB1.1020000@it.aoyama.ac.jp> <E15439505D655B6AA20DFD52@JcK-HP8200.jck.com> <54BFEF7B.6070701@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.35
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/85jFYen4OiI4mALGSNadPKpLX8k>
Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification
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: Mon, 02 Feb 2015 20:42:21 -0000

--On Wednesday, January 21, 2015 10:27 -0800 Sean Leonard
<dev+ietf@seantek.com> wrote:

> On 1/21/2015 6:11 AM, John C Klensin wrote:
>> [query stuff]
>> 
>> <co-editor and all other hats off>
>> I'm pushing this for a specific reason, discussed at length on
>> the list some months ago.  If we really need the flexibility
>> that having a number of different communities of URN uses
>> seems to imply, especially if we anticipate communities and
>> uses that haven't been heard from yet, there are really
>> strong arguments for allowing the query string to be a series
>> of name-value pairs.   As I read 3986, nothing prevents
>> establishing that principle on a per-scheme basis. [...]
> 
> Hate to put a wet blanket on all these desiderata, but
> honestly, who really needs or wants to use q-components in
> URNs?

Sean, I'll let them speak for themselves, but there are a lot of
folks who have made the claim that they need q-components over
the last few years.   If one takes the 3986 binding of
f-components to [MIME] media types seriously, as some people
obviously believe we should do despite the "syntax only"
approach, then q-components are the _only_ qualifications or
service requests one can make about a URN that doesn't have an
intrinsic, "there is exactly one way to resolve this" binding to
an object with a media type.   Also note that anything that one
hides with an %-coding inside an NSS necessarily becomes part of
equality comparison.   That, in turn, is why some of us have
tried to make a p-component distinction to constrain what is
actually considered to be the NSS.

> Let's say you can use q-components, but any common structure
> will only be considered when actual use cases and communities
> materialize. Until then, percent-encode the "?" in a NSS.

See above.   And the observation below.

> The thing is that the definition of URN is that the NSS is
> basically an opaque identifier. As I have argued, NSSes have
> "dividers", but not "hierarchy" (e.g.: urn:ietf:rfc:3986 --
> the : in rfc:3986 is just a divider for convenience).
> q-components shouldn't be part of the NSS since they represent
> parameter thingies.

Ok. but it seems to me that argues strongly against the "Until
then, percent-encode the "?" in a NSS" position I thought you
were taking above.

> "Worry about stuff that matters, when it matters."

Sure.  But I note that part of several problems that have faced
this WG all along was a belief when 3986 was done that either
extensions beyond 2141 didn't matter (at least yet) or URNs
themselves didn't matter (perhaps at all).  That resulting in
constraints (at least claimed constraints) on what could be done
in URNs that are a lot of the reason the WG didn't finish its
work a couple of years ago. 

Because people want to process URNs with generic URI parsers and
to build slightly-more-specific generic URN parsers, these
things do matter now unless we are willing to constrain cases
that are easily imagined to not use URNs but require another
type of non-locator scheme (and starting many of these
discussions all over again).

    john


From nobody Mon Feb  2 13:05:32 2015
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 D82BE1A1A5E for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.411
X-Spam-Level: 
X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 VH-OhR5XkviJ for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:05:29 -0800 (PST)
Received: from bsa2.jck.com (ns.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 0CEA31A036B for <urn@ietf.org>; Mon,  2 Feb 2015 13:05:28 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YIOBT-0009Tt-7o; Mon, 02 Feb 2015 16:05:27 -0500
Date: Mon, 02 Feb 2015 16:05:22 -0500
From: John C Klensin <john-ietf@jck.com>
To: =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= <mark@macchiato.com>
Message-ID: <3038CD74D421C95DD6412C89@JcK-HP8200.jck.com>
In-Reply-To: <CAJ2xs_G-=w=SG6T0y6HBGWWOX3TbCm-Dn9s716xSXjCwAjR-iA@mail.gmail.com>
References: <EBC1460BEB5DD2D707549019@JcK-HP8200.jck.com> <5499B8E5.7080909@andyet.net> <124B24958D718C38C6ACEB64@JcK-HP8200.jck.com> <CAJ2xs_G-=w=SG6T0y6HBGWWOX3TbCm-Dn9s716xSXjCwAjR-iA@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
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/I8XkHLilHkb4IPoaMV2_vaMA8lo>
Cc: urn@ietf.org, Peter Saint-Andre - &yet <peter@andyet.net>
Subject: Re: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment
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: Mon, 02 Feb 2015 21:05:31 -0000

Mark (and others), =20
Sorry for the delay in responding.  You at least know what has
been taking up my time.

--On Wednesday, January 21, 2015 16:12 +0100 Mark Davis =
=E2=98=95=EF=B8=8F
<mark@macchiato.com> wrote:

> While the situation with casing is not trivial, it is not as
> complicated as sometimes portrayed.
>=20
> Unicode does have a 'case normalization', called "case
> folding", which erases case differences, and is widely
> deployed. In a few instances, it does not always match local
> conventions for casing (I can go into details if desired).
> Like normalization, it has stability guarantees (
> http://unicode.org/policies/stability_policy.html#Case_Folding
> ).
>...
> =E2=80=8BI do not wish to weigh in on whether comparison or =
storage
> should be case-sensitive or insensitive=E2=80=8B; just wanted =
to
> point out that there is not a technical barrier if
> case-insensitivity is desired.

Most of the case issues are dictated by 3986 unless we make
explicit decisions for URNs to depart from them, probably on a
per-scheme basis rather than a per-NID one.  But I have to
slightly disagree about the technical barrier.   URNs are
another instance of a family of identifiers that, in general,
have no language or location context.  When case folding
interacts with a need for specific locale knowledge (dotless-i
and maybe Eszett are examples), then, while the number of cases
may be small (and almost certainly  is), those are the sorts of
things that cause some of us to urge caution and careful
consideration of both advantages and risks.

best,
    john


From nobody Mon Feb  2 13:38:53 2015
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 52B9E1A1A51 for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level: 
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 iMmc3zw6CfLv for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:38:49 -0800 (PST)
Received: from bsa2.jck.com (ns.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 6DED31A1A58 for <urn@ietf.org>; Mon,  2 Feb 2015 13:38:49 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YIOhf-0009Xb-EZ; Mon, 02 Feb 2015 16:38:43 -0500
Date: Mon, 02 Feb 2015 16:38:38 -0500
From: John C Klensin <john-ietf@jck.com>
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= <duerst@it.aoyama.ac.jp>, Julian Reschke <julian.reschke@gmx.de>, Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <02A01BD10C44887B3B998C31@JcK-HP8200.jck.com>
In-Reply-To: <54C5BC4F.8080306@it.aoyama.ac.jp>
References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> <E5D13A2B04D97A2B3EE1CD9D@JcK-HP8200.jck.com> <54C4E9C9.7090408@gmx.de> <54C5BC4F.8080306@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
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/39UDy6mogIESThWaa2kd1lcAgtE>
Cc: urn@ietf.org
Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance
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: Mon, 02 Feb 2015 21:38:52 -0000

--On Monday, January 26, 2015 13:02 +0900 "\"Martin J. =
D=C3=BCrst\""
<duerst@it.aoyama.ac.jp> wrote:

> Julian wrote...

>> I believe I asked this before when a variation of this text
>> was proposed before: why wouldn't be appropriate to have a
>> URN in a/@href?
>=20
> I think it might be appropriate for some, but not for others.
> So I suggest to change the text to (including Peter's change)
> "it might not be appropriate to place a certain URN" or some
> such.

I think that is more or less what the text I proposed in
response to Peter says.   What changes to it do you believe are
needed?

I think the above illustrations a general issue that we are
having.   Each of us has a slightly (or more than slightly)
different perspective on which types of URNs are important and
how they will be used.   I have as little trouble as Julian
identifying possible URNs that would be appropriate in a/hrefs.
I don't know about his, but many of mine would be URNs that are
themselves location-independent but that resolve, in ways that
are sensitive to the location of the user making the request,
into network-appropriate URLs that can be used to locate and
retrieve the objects.   =20

IMO, all of us need to be sensitive to the cases that don't
match our expectations and easily-found examples so that we
don't do things that lock those other cases out.  In that
regard, we need to remember that the statements we have been
avoiding, e.g., "URNs are just like any other URI and are
therefore suitable for use an a/hrefs", both constrain what
constitutes a URN and, at least for examples like the one above,
require that an href resolver be able to work recursively when
URI resolution produces a URL rather than producing an object.

IMO, these are really issues for HTML and the definition of
a-elements and what is to be done with them.  And that is
precisely why the text I proposed tries to say "figuring out
whether (and which) URNs are valid in a particular use context
is a problem for that context, not for URNs".  Again, if that
isn't clear or adequate in the text I proposed, please suggest
alternate text.

Note that this situation may shed some light on Sean's comment
about q-components and part of my response to it.   URLs don't
have media types even though many or most URLs identify objects
that do.  So, if f-components are defined as depending on media
types, they cannot be used in a URN that might return a URL
unless they are defined strictly as passing through.... and that
might be incompatible with other types and uses of URNs.=20

Because q-components (or even 3986 queries) have no such
limitations, one might, at least in principle, be used to tell
the URN resolver that was going to select among applicable URLs
the location nexus or other information to be used in doing the
selection. =20

Before someone mentions it, a fully-functional and reasonably
deterministic semantic web might be an alternative to several
parts of the examples above.  But we don't seem to be there yet
so, to paraphrase Sean, these issues matter and matter now even
if one were to anticipate their mattering less at some point in
the future.

     john




From nobody Mon Feb  2 13:47:47 2015
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 249021A1AD9 for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 lkEz3uIi4anx for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 13:47:44 -0800 (PST)
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 236191A037A for <urn@ietf.org>; Mon,  2 Feb 2015 13:47:44 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YIOqL-0009Yg-6I; Mon, 02 Feb 2015 16:47:41 -0500
Date: Mon, 02 Feb 2015 16:47:36 -0500
From: John C Klensin <john-ietf@jck.com>
To: Juha Hakala <juha.hakala@helsinki.fi>
Message-ID: <7C6D259B203588BD3F3AA239@JcK-HP8200.jck.com>
In-Reply-To: <54C096C1.7060304@helsinki.fi>
References: <CC140039C2C8318CADE53C27@JcK-HP8200.jck.com> <5499B9E4.8010609@andyet.net> <54AA8552.9050606@helsinki.fi> <C5F2A3739DB7703328606191@JcK-HP8200.jck.com> <54C096C1.7060304@helsinki.fi>
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.35
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/RPKy_YfLzt82WXQelYORYpxknf0>
Cc: urn@ietf.org
Subject: Re: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs
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: Mon, 02 Feb 2015 21:47:46 -0000

--On Thursday, January 22, 2015 08:20 +0200 Juha Hakala
<juha.hakala@helsinki.fi> wrote:

> Hello,
> 
> On 21.1.2015 19:05, John C Klensin wrote:
>> 
>> --On Monday, January 05, 2015 14:36 +0200 Juha Hakala
>> <juha.hakala@helsinki.fi> wrote:
>> 
>>> There are at least two different cases here. Anyone who knows
>>> anything about usage of standard identifiers would see that
>>> urn:klensin:* URNs are (and probably will be) invalid. But it
>>> is more difficult to work out the status of URNs which look
>>> valid. For instance, even some librarians might think that
>>> urn:isrc:* are OK (ISRC = International Standard Recording
>>> Code, http://isrc.ifpi.org/en/), especially if those URNs are
>>> actionable (they might be). But without formal namespace
>>> registration urn:isrc:*'s are still as invalid as
>>> urn:klensin:* ones, even though it is not likely that NID
>>> "ISRC" will be assigned to some other identifier system than
>>> ISRC.
>> Unless the International Society of Rat Catchers decides to
>> create a namepace to identify their members, species or
>> population information about rats, etc.   That further example
>> is of no interest except as evidence of the really good reason
>> why someone expecting to create and use an ISRC URN had best
>> pay careful and early attention to registration.  I don't
>> think it needs to be reflected in the document although I'd
>> be open to adding a comment if someone else thought it was
>> important and wanted to add text.
> 
> Not all communities using (ISO) standard identifiers will
> register URN namespaces for themselves early on, and it may
> take a while before URN namespace registration becomes a
> standard procedure. There is no way IETF could force for
> instance the ISRC community into registering a namespace, and
> if the International Society of Rat Catchers wish to register
> NID "ISRC" now, there is nothing in rfc2141 or rfc2141bis to
> prevent that, or even inform them that trying to register that
> NID might not be a good idea.
> 
> However, it is easy to reserve NIDs which match acronyms of
> relevant ISO / industry standards to these standards. All it
> takes is a comment to this effect in the RFC. Then the
> International Society of Rat Catchers be required to check in
> advance if the NID ISRC is available using Google or perhaps a
> list of reserved NIDs maintained by  e.g. IANA as an annex to
> the list of registered NIDs. And if the registrant fails to
> make such a check, the expert reviewing the registration
> request should do that, and when necessary ask the registrant
> to change the proposed NID.

Unless those ISO / industry communities are in the habit of
finding RFCs and carefully reading reading them, I don't know
that that a comment in an RFC would help much.  Comments to
relevant SDOs and trade associations might be much more useful.
We've actually got a lot of experience with people checking
whether identifiers are in use using Google, other search
engines, or the perhaps-inevitable Wikipedia pages.  It can be
very useful but, especially if it becomes a normative
requirement it can also lead to various extortion and denial of
service attacks, much as we have seen with some domain names.
So it might be better to design registration procedures to let,
e.g., a recognized standards body register placeholders for NID
strings using some relatively easy process with details being
supplied later _and_ by then trying to make those bodies aware
of the risks of not registering those placeholders.

To the extent to which any of this requires changes to 2141bis,
suggested text and suggestions about where to put it would be
helpful.  See also in that regard my topic (9) on the text
describing expert review.

best,
    john


From nobody Mon Feb  2 17:39:36 2015
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 58E631A1ABF for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 17:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 C7pdX3PzAObf for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 17:39:31 -0800 (PST)
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 9AD1D1A1A9E for <urn@ietf.org>; Mon,  2 Feb 2015 17:39:31 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YISSf-000AMe-3n; Mon, 02 Feb 2015 20:39:29 -0500
Date: Mon, 02 Feb 2015 20:39:24 -0500
From: John C Klensin <john-ietf@jck.com>
To: Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com>
In-Reply-To: <54B4938E.2040509@gmail.com>
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
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/KIKFGxzH7DP9I7-ykWASYRIVxCk>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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, 03 Feb 2015 01:39:33 -0000

--On Monday, January 12, 2015 18:39 -0900 Melinda Shore
<melinda.shore@gmail.com> wrote:

> On 1/5/15 6:03 PM, "Martin J. D=C3=BCrst" wrote:
>> On 2015/01/05 20:23, Juha Hakala wrote:
>>> On 25.12.2014 8:28, John C Klensin wrote:
>>>> The first part of Section 7, "Defining a URN Namespace",
>>>> outlines broad requirements.  Under item (2), it seems
>>>> worthwhile to clarify that the status of *-components be
>>>> specified here (it is explained in more detail in Section
>>>> 7.2, as promised).
>>>>=20
>>>> Suggestion:
>...
>>>> New:
>>>>     2.  The syntax of URNs assigned within the namespace,
>>>>     including whether p-, q-, and/or f-components are
>>>>     allowed.
>...
>>> The downside of this is that people creating registration
>>> requests must find out what the implications of these
>>> components are for their identifier systems. But it should
>>> be easy both to supply this information, and to check if the
>>> information provided in the registration request is OK.
>>>=20
>>> Namespaces which do not intend to support resolution
>>> services should not allow q-component. Namespaces which deal
>>> with digital manifestations may be able to support
>>> f-component.
>>=20
>> We should make sure we write so in the draft.
>...=20
> If nobody has any issues with this, we'll consider it closed.
> The resolution is that the draft will include John's "New"
> text along with some text along the lines of what Juha
> specified.

Sorry for the delay in getting back to this.  I'm fine with the
above but think we should be extremely careful about giving
guidance that someone could construe as a firm rule when we are
not confident we have identified all the cases.  I propose to
add the following to the end of the introduction to Section 3.3
(which introduces the three ?-component types):

	"As general guidance that may not apply to all cases,
	namespaces which do not intend to support resolution
	services should not allow q-component. Namespaces which
	deal with digital manifestations may be able to support
	f-component."

Does that work for everyone?   Can anything think of something
similar to say about p-components?   My personal guess at the
moment is that we are going to have to resolve the question of
whether p-components are a special part of the NSS, presumably
delimited by a "/" after the NSS begins, or an integral part of
the the NSS -- I've inserted a placeholder in the working draft
so we don't forget the question.

    john







From nobody Mon Feb  2 19:30:02 2015
Return-Path: <peter@andyet.net>
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 17D211A1BD2 for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 19:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 HZD-nszcbSZc for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 19:29:59 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1951A1BBE for <urn@ietf.org>; Mon,  2 Feb 2015 19:29:59 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id rd18so13207083iec.9 for <urn@ietf.org>; Mon, 02 Feb 2015 19:29:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bxqd+BqDgJtbYz5js2lzUp/jN0eWrRoiHiHZ2VedxPw=; b=j6E9HHitO5GwUpL8J7OJD/J0Sys1mrBSgkKMIgI/E3t8LgOn+zJVRKWnVeEgmad6OG cau3tYctSL8vn8LPgZtupI6h0D/QdlaS71rda4M8NIRC2Iq/Kk7ZnaR5cHTHuwj2Fu0f H6CYQELGt7XRigKd5wSMRnh1a1jCY6392PZyBg+wvc39WwALlWQYrw1iCxmn9ZztYFg7 ciPZ48/ztJsawpCj1DlEnly1QGi7yf/tagzcvbKQyP7e/Yyz0wYNqX8fqNgUp+yWn+fi SgzflqalNDf5pg+G+cBaWlYYCjg5RFaMcdCX6hgnJSBKdPLskihf/ddsDn4fyp7niVvc 2g8g==
X-Gm-Message-State: ALoCoQkm9eOkYZyACLTSlG1XvJAM6BZpgtDoUZ3feLsQcUIMcdni56poeotc3Xvd6n6iVBozmb2f
X-Received: by 10.50.83.10 with SMTP id m10mr15440063igy.23.1422934198608; Mon, 02 Feb 2015 19:29:58 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id t5sm7324299ign.12.2015.02.02.19.29.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 19:29:57 -0800 (PST)
Message-ID: <54D040B4.9000803@andyet.net>
Date: Mon, 02 Feb 2015 20:29:56 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com>
In-Reply-To: <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/nOlSk5vG56F5ntgUHtF4Af1o-CY>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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, 03 Feb 2015 03:30:01 -0000

On 2/2/15 6:39 PM, John C Klensin wrote:
>
>
> --On Monday, January 12, 2015 18:39 -0900 Melinda Shore
> <melinda.shore@gmail.com> wrote:
>
>> On 1/5/15 6:03 PM, "Martin J. Dürst" wrote:
>>> On 2015/01/05 20:23, Juha Hakala wrote:
>>>> On 25.12.2014 8:28, John C Klensin wrote:
>>>>> The first part of Section 7, "Defining a URN Namespace",
>>>>> outlines broad requirements.  Under item (2), it seems
>>>>> worthwhile to clarify that the status of *-components be
>>>>> specified here (it is explained in more detail in Section
>>>>> 7.2, as promised).
>>>>>
>>>>> Suggestion:
>> ...
>>>>> New:
>>>>>      2.  The syntax of URNs assigned within the namespace,
>>>>>      including whether p-, q-, and/or f-components are
>>>>>      allowed.
>> ...
>>>> The downside of this is that people creating registration
>>>> requests must find out what the implications of these
>>>> components are for their identifier systems. But it should
>>>> be easy both to supply this information, and to check if the
>>>> information provided in the registration request is OK.
>>>>
>>>> Namespaces which do not intend to support resolution
>>>> services should not allow q-component. Namespaces which deal
>>>> with digital manifestations may be able to support
>>>> f-component.
>>>
>>> We should make sure we write so in the draft.
>> ...
>> If nobody has any issues with this, we'll consider it closed.
>> The resolution is that the draft will include John's "New"
>> text along with some text along the lines of what Juha
>> specified.
>
> Sorry for the delay in getting back to this.  I'm fine with the
> above but think we should be extremely careful about giving
> guidance that someone could construe as a firm rule when we are
> not confident we have identified all the cases.  I propose to
> add the following to the end of the introduction to Section 3.3
> (which introduces the three ?-component types):
>
> 	"As general guidance that may not apply to all cases,
> 	namespaces which do not intend to support resolution
> 	services should not allow q-component. Namespaces which
> 	deal with digital manifestations may be able to support
> 	f-component."
>
> Does that work for everyone?

I think that's fine as-is, although I also think we don't want to 
suggest that q-components and f-components in URNs are, necessarily, 
semantically related to queries and fragments in URIs (some might think 
"I want to pass parameters to a resolution service so I need URI 
queries" or "I want to point to sub-parts within media types so I need 
URI fragments").

> Can anything think of something
> similar to say about p-components?   My personal guess at the
> moment is that we are going to have to resolve the question of
> whether p-components are a special part of the NSS, presumably
> delimited by a "/" after the NSS begins, or an integral part of
> the the NSS -- I've inserted a placeholder in the working draft
> so we don't forget the question.

I'm not clear on the distinction between "special part of the NSS" and 
"integral part of the NSS".

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Mon Feb  2 19:36:22 2015
Return-Path: <moore@network-heretics.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 22EB41A1BBE for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 19:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 F4s4nnzLqfJ7 for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 19:36:18 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC3D1A1B44 for <urn@ietf.org>; Mon,  2 Feb 2015 19:36:18 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 99E0B2060F for <urn@ietf.org>; Mon,  2 Feb 2015 22:36:17 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 02 Feb 2015 22:36:17 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=CFY22urIk9Kkz2793/BzoA D63Y8=; b=hIIp+B8kjyFjyLjp+ekkh/s7p/CXToUUIowqd4nGvNMVKXOXZ4SzHZ C2x50ELERUhHhFSA9Rv9neiTJQ2YE9rVegX9vviqoXMrRWgoyLoF6UQcaMKLp2y0 KkU2ny7DoiGwH8Y4EnpGO+XWM1zuejjx5wvbQAs63bFaTBBxhm8UM=
X-Sasl-enc: cxCVMo0tac9z8oBLLQ81OU3oU87Pl8dtwFQxfzHZfaw1 1422934577
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3F7F5C00290; Mon,  2 Feb 2015 22:36:17 -0500 (EST)
Message-ID: <54D0422E.4030807@network-heretics.com>
Date: Mon, 02 Feb 2015 22:36:14 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: urn@ietf.org
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com>
In-Reply-To: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/ZlZedOUXdiDJ_v1E9dBwHnoWQko>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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, 03 Feb 2015 03:36:20 -0000

On 12/25/2014 01:28 AM, John C Klensin wrote:
> The first part of Section 7, "Defining a URN Namespace",
> outlines broad requirements.  Under item (2), it seems
> worthwhile to clarify that the status of *-components be
> specified here (it is explained in more detail in Section 7.2,
> as promised).
>
> Suggestion:
>
> Old:
> 	2.  The syntax of URNs assigned within the namespace.
>
> New:
> 	2.  The syntax of URNs assigned within the namespace,
> 	including whether p-, q-, and/or f-components are
> 	allowed.
>

Sorry to take so long to reply; I got backlogged over the holidays even 
more than usual.

I am still very uncomfortable with making the meanings of p-, q-, and 
f-components specific to a namespace.

I'm not sure how uncomfortable I am with making the syntax (whether such 
components are supported) specific to a namespace.   It seems like a 
slippery slope to me.

I fundamentally don't believe that they type of resource named should be 
specific to a namespace as a matter of URN architecture. I realize that 
there are namespaces that are defined specifically for certain kinds of 
resources, but it should not be assumed by a consumer of a name that a 
particular kind of namespace indicates a particular kind of resource.   
This is something that should be learned at resolution or access time.

So therefore, on balance, I don't think it's appropriate to make the 
syntax for p-, q, or f- components namespace specific.

Keith


From nobody Mon Feb  2 20:58:13 2015
Return-Path: <duerst@it.aoyama.ac.jp>
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 B4C5C1A1F00 for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 20:58:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.199
X-Spam-Level: 
X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ANAQmi5t1Byt for <urn@ietfa.amsl.com>; Mon,  2 Feb 2015 20:58:10 -0800 (PST)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id DF3261A1EFC for <urn@ietf.org>; Mon,  2 Feb 2015 20:58:08 -0800 (PST)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B7CB732E591; Tue,  3 Feb 2015 13:57:22 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 37ce_53bf_1d124b02_e9ec_42c6_a9f3_d9048d43ad1f; Tue, 03 Feb 2015 13:57:22 +0900
Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 20850BF53B; Tue,  3 Feb 2015 13:57:22 +0900 (JST)
Message-ID: <54D05530.6090805@it.aoyama.ac.jp>
Date: Tue, 03 Feb 2015 13:57:20 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com>
In-Reply-To: <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/fcDaa4aOEkpWnfn5lLdJnT0NHXA>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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, 03 Feb 2015 04:58:12 -0000

On 2015/02/03 10:39, John C Klensin wrote:

> --On Monday, January 12, 2015 18:39 -0900 Melinda Shore
> <melinda.shore@gmail.com> wrote:
>
>> On 1/5/15 6:03 PM, "Martin J. D=C3=BCrst" wrote:

>>> We should make sure we write so in the draft.
>> ...
>> If nobody has any issues with this, we'll consider it closed.
>> The resolution is that the draft will include John's "New"
>> text along with some text along the lines of what Juha
>> specified.
>
> Sorry for the delay in getting back to this.  I'm fine with the
> above but think we should be extremely careful about giving
> guidance that someone could construe as a firm rule when we are
> not confident we have identified all the cases.  I propose to
> add the following to the end of the introduction to Section 3.3
> (which introduces the three ?-component types):
>
> 	"As general guidance that may not apply to all cases,
> 	namespaces which do not intend to support resolution
> 	services should not allow q-component. Namespaces which
> 	deal with digital manifestations may be able to support
> 	f-component."
>
> Does that work for everyone?   Can anything think of something
> similar to say about p-components?

Just some grammatical comments:

1) I prefer to be called a 'body' rather than a 'thing', although in=20
isolation, the former doesn't sound very nice, either :-).

2) I'd change "q-component" and "f-component" to "q-components" and=20
"f-components" in accordance with usual language conventions.

Regards,   Martin.


From nobody Tue Feb  3 03:32:47 2015
Return-Path: <juha.hakala@helsinki.fi>
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 24A0C1A88D6 for <urn@ietfa.amsl.com>; Tue,  3 Feb 2015 03:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cN5qpdUlrrWI for <urn@ietfa.amsl.com>; Tue,  3 Feb 2015 03:32:42 -0800 (PST)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6021A00DC for <urn@ietf.org>; Tue,  3 Feb 2015 03:32:41 -0800 (PST)
Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t13BWc5D012548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <urn@ietf.org>; Tue, 3 Feb 2015 13:32:39 +0200
Message-ID: <54D0B1D6.9020507@helsinki.fi>
Date: Tue, 03 Feb 2015 13:32:38 +0200
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: urn@ietf.org
References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <CAAQiQRee2pC3B9_eR1daw=3EEOFMiSXN6ZLjVt8B9RBbLKHV7g@mail.gmail.com> <54ABABB1.1020000@it.aoyama.ac.jp> <E15439505D655B6AA20DFD52@JcK-HP8200.jck.com> <54BFEF7B.6070701@seantek.com> <15614C85890F8EDDB6C9030D@JcK-HP8200.jck.com>
In-Reply-To: <15614C85890F8EDDB6C9030D@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/iILCOtuglcd3hyV5iL-mduABFMg>
Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification
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, 03 Feb 2015 11:32:45 -0000

Hello,

On 2.2.2015 22:42, John C Klensin wrote:
>
> --On Wednesday, January 21, 2015 10:27 -0800 Sean Leonard
> <dev+ietf@seantek.com> wrote:
>
>>
>> Hate to put a wet blanket on all these desiderata, but
>> honestly, who really needs or wants to use q-components in
>> URNs?

Making resolution smarter with the help of q-components is one of the 
main reasons why e.g. libraries want to revise the URN syntax.

Our users may want to retrieve the identified resource. But they may 
also want to fetch descriptive or administrative metadata about it, or 
to see if there are other manifestations of the same work, or related 
works such as translations.

There are other means of passing resolution related parameters to URN 
resolvers, but q-component is probably the most convenient one. Two 
other persistent identifier systems (DOI and ARK) are already using 
query for this purpose. For instance, with ARK it is possible to 
retrieve metadata about the resource, or find out the preservation 
commitment of the organization holding the resource. The metadata 
required for this is held within the ARK resolver itself. This is an 
option in some URN namespaces, while some others may choose alternative 
methods.



> Sean, I'll let them speak for themselves, but there are a lot of
> folks who have made the claim that they need q-components over
> the last few years.   If one takes the 3986 binding of
> f-components to [MIME] media types seriously, as some people
> obviously believe we should do despite the "syntax only"
> approach, then q-components are the _only_ qualifications or
> service requests one can make about a URN that doesn't have an
> intrinsic, "there is exactly one way to resolve this" binding to
> an object with a media type.   Also note that anything that one
> hides with an %-coding inside an NSS necessarily becomes part of
> equality comparison.   That, in turn, is why some of us have
> tried to make a p-component distinction to constrain what is
> actually considered to be the NSS.
>
>> Let's say you can use q-components, but any common structure
>> will only be considered when actual use cases and communities
>> materialize. Until then, percent-encode the "?" in a NSS.

Library community and the use cases it has - such as retrieving 
descriptive metadata of the resource from e.g. national bibliography 
using the URN as a parameter in SRU search - should do, I think.

Please note that the library community may use for instance urn:isbn and 
q-component to retrieve metadata about the book, but it would be an 
abomination to use urn:isbn and the q-component to identify the metadata 
record. Such an extention of the ISBN scope would be completely 
unacceptable to the ISBN community, and metadata records already have 
other identifiers, which should be used to create persistent links to 
those records.

> See above.   And the observation below.
>
>> The thing is that the definition of URN is that the NSS is
>> basically an opaque identifier. As I have argued, NSSes have
>> "dividers", but not "hierarchy" (e.g.: urn:ietf:rfc:3986 --
>> the : in rfc:3986 is just a divider for convenience).
>> q-components shouldn't be part of the NSS since they represent
>> parameter thingies.
> Ok. but it seems to me that argues strongly against the "Until
> then, percent-encode the "?" in a NSS" position I thought you
> were taking above.

Q-component must not be part of the NSS. Queries are ephemeral by 
definition - added to the NSS whenever a user wants something else than 
the default resolution service (assuming that one exist; that does not 
need to be the case). When services and service parameters supported by 
applications change, so do the q-components.

In other words, urn:isbn identifies a certain manifestation of a book. 
But urn:isbn + q-component combo used to retrieve a bibliographic 
records of that book does not (in the URN context) identify the 
retrieved record, and it does not even need to be persistent. In the 
future a different q-component and service may be used to provide a 
comparable service (for instance, the metadata record syntax preferred 
by the user community may have changed). A user does not need to notice 
that anything has changed, since q-components can be added to URNs on 
the fly whenever needed.

Juha

>
>> "Worry about stuff that matters, when it matters."
> Sure.  But I note that part of several problems that have faced
> this WG all along was a belief when 3986 was done that either
> extensions beyond 2141 didn't matter (at least yet) or URNs
> themselves didn't matter (perhaps at all).  That resulting in
> constraints (at least claimed constraints) on what could be done
> in URNs that are a lot of the reason the WG didn't finish its
> work a couple of years ago.
>
> Because people want to process URNs with generic URI parsers and
> to build slightly-more-specific generic URN parsers, these
> things do matter now unless we are willing to constrain cases
> that are easily imagined to not use URNs but require another
> type of non-locator scheme (and starting many of these
> discussions all over again).
>
>      john
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678



From nobody Thu Feb  5 18:00:42 2015
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 99EB21A0019 for <urn@ietfa.amsl.com>; Thu,  5 Feb 2015 18:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.411
X-Spam-Level: 
X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 X6fn2w0s58li for <urn@ietfa.amsl.com>; Thu,  5 Feb 2015 18:00:25 -0800 (PST)
Received: from bsa2.jck.com (ns.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 65C391A0115 for <urn@ietf.org>; Thu,  5 Feb 2015 18:00:23 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YJYDS-00004O-NI; Thu, 05 Feb 2015 21:00:18 -0500
Date: Thu, 05 Feb 2015 21:00:13 -0500
From: John C Klensin <john-ietf@jck.com>
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= <duerst@it.aoyama.ac.jp>, Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <0415C1E8AC978CAF1F47BE7A@JcK-HP8200.jck.com>
In-Reply-To: <54D05530.6090805@it.aoyama.ac.jp>
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com> <54D05530.6090805@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
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/gaw0Y6aw7_I-84H891FypuUf1tw>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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: Fri, 06 Feb 2015 02:00:37 -0000

--On Tuesday, February 03, 2015 13:57 +0900 "\"Martin J.
D=C3=BCrst\"" <duerst@it.aoyama.ac.jp> wrote:

>...
>> 	"As general guidance that may not apply to all cases,
>> 	namespaces which do not intend to support resolution
>> 	services should not allow q-component. Namespaces which
>> 	deal with digital manifestations may be able to support
>> 	f-component."
>>=20
>> Does that work for everyone?   Can anything think of =
something
>> similar to say about p-components?
>=20
> Just some grammatical comments:
>=20
> 1) I prefer to be called a 'body' rather than a 'thing',
> although in isolation, the former doesn't sound very nice,
> either :-).

Sorry... I was very tired when I wrote that and, as you have
probably noticed in other contexts, my typing fingers often get
too far ahead of what passes for my brain.   I am probably
equally tired now, so apologies in advance if I write something
equally careless and/or stupid tonight.

> 2) I'd change "q-component" and "f-component" to
> "q-components" and "f-components" in accordance with usual
> language conventions.

  That was basically Juha's text and I assumed the RFC Editor
would be able to straighten it out if necessary.   I didn't pay
more attention to it because it is connected to a difficulty
with the way we usually write about ABNF. With a different
metalanguage and way of talking about it, I would have written=20

	"As general guidance that may not apply to all cases,
	namespaces that do not intend to support resolution
	services should not allow <q-component>. Namespaces
	which deal with digital manifestations may be able to
	support <f-component>."

>From that point of view, the plurals actually don't work because
we don't have productions for, e.g., "q-components".

But I made the change; the RFC Editor can change it back if that
amuses them.

    john




From nobody Thu Feb  5 18:01:37 2015
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 775231A0120 for <urn@ietfa.amsl.com>; Thu,  5 Feb 2015 18:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 aQMWUaE_ZKfa for <urn@ietfa.amsl.com>; Thu,  5 Feb 2015 18:01:27 -0800 (PST)
Received: from bsa2.jck.com (ns.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 314331A00F0 for <urn@ietf.org>; Thu,  5 Feb 2015 18:01:27 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YJYEX-00004Y-Cs; Thu, 05 Feb 2015 21:01:25 -0500
Date: Thu, 05 Feb 2015 21:01:20 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <31C860749D1C81952EE8F7EC@JcK-HP8200.jck.com>
In-Reply-To: <54D040B4.9000803@andyet.net>
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <7344C61A8E477F2F9D73D9BE@JcK-HP8200.jck.com> <54D040B4.9000803@andyet.net>
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.35
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/7kmYaf5weY2bgyTs8CYcF2joa0Q>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs
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: Fri, 06 Feb 2015 02:01:32 -0000

--On Monday, February 02, 2015 20:29 -0700 Peter Saint-Andre -
&yet <peter@andyet.net> wrote:

>> 	"As general guidance that may not apply to all cases,
>> 	namespaces which do not intend to support resolution
>> 	services should not allow q-component. Namespaces which
>> 	deal with digital manifestations may be able to support
>> 	f-component."
>> 
>> Does that work for everyone?
> 
> I think that's fine as-is, although I also think we don't want
> to suggest that q-components and f-components in URNs are,
> necessarily, semantically related to queries and fragments in
> URIs (some might think "I want to pass parameters to a
> resolution service so I need URI queries" or "I want to point
> to sub-parts within media types so I need URI fragments").

That was a large fraction of the reason why I wanted to say "As
general guidance that may not apply to all cases".   Text to say
that better or more strongly would be welcome.

>> Can anything think of something
>> similar to say about p-components?   My personal guess at the
>> moment is that we are going to have to resolve the question of
>> whether p-components are a special part of the NSS, presumably
>> delimited by a "/" after the NSS begins, or an integral part
>> of the the NSS -- I've inserted a placeholder in the working
>> draft so we don't forget the question.
> 
> I'm not clear on the distinction between "special part of the
> NSS" and "integral part of the NSS".

Right now, the BNF says (with some irrelevant material removed):

      namestring    = assigned-name
                      [ p-component ]
                      [ q-component ]
                      [ f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NSS           = 1*(pchar)
      p-component   = "/" path-absolute

That relationship closely follows the syntactic structure of
3986.  The reservation on prohibition on "/" would allow

      namestring    = assigned-name
                      [ q-component ]
                      [ f-component ]
      assigned-name = "urn" ":" NID ":" NSS
      NSS           = 1*(pchar) [p-component]

Instead, but I don't see how we can avoid choosing one or the
other.

     john








From nobody Fri Feb  6 00:21:06 2015
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 1B0681A1A5F for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 00:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 oDWJyklZJvm0 for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 00:20:57 -0800 (PST)
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 C1BC01A1A5D for <urn@ietf.org>; Fri,  6 Feb 2015 00:20:57 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YJe9l-0000xu-BX; Fri, 06 Feb 2015 03:20:53 -0500
Date: Fri, 06 Feb 2015 03:20:48 -0500
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
Message-ID: <95A9B708CD0D16099D1FE73D@JcK-HP8200.jck.com>
In-Reply-To: <54D0422E.4030807@network-heretics.com>
References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54D0422E.4030807@network-heretics.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.35
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/BsoD6hTKKJWJl8hxHcFPprz1EgI>
Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of	URNs
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: Fri, 06 Feb 2015 08:21:00 -0000

Keith,

While noting your discomfort, even if the WG agreed with you (I
don't need to have an opinion about that at the moment), I don't
know how to translate that discomfort or the comments below into
something actionable wrt the document.  

I note that we've got a lot of experience with path, query, and
fragment components in HTTP URLs.  The interpretation and fine
details of the syntax of the first are determined on a
per-domain basis.  The interpretation and fine details of the
second and third are determined on the basis of the domain and
path and whatever objects they locate.  Sometimes the object to
be located is determined by the domain and path; sometimes it is
actually determined by information embedded in the query.    If
that object cannot be located or the location process doesn't
work, the user gets more or less specific error messages (often
less, amounting to "you lose").

I don't like those outcomes.  Indeed, I believe it is a
fundamental design flaw in the URL/ URI architecture.  But that
horse has left the barn and disappeared over the horizon and, as
the saying goes, no one has died.

URNs are more complicated in some ways, primarily because there
is no requirement for resolution, but it seems to me that an
objection to a certain amount of per-namespace interpretation
ultimately becomes an objection to URNs as part of the general
UR*/ URI model.  The decision to consider them part of that
model cannot be blamed on 3986: it was made long before 2141 and
even before 1630 and 1737.

The current proposed syntax is in the response I sent to Peter
some hours ago.   I've indicated what is in the proposed text.

What would you change and how?

   best,
    john


--On Monday, February 02, 2015 22:36 -0500 Keith Moore
<moore@network-heretics.com> wrote:

> On 12/25/2014 01:28 AM, John C Klensin wrote:
>> The first part of Section 7, "Defining a URN Namespace",
>> outlines broad requirements.  Under item (2), it seems
>> worthwhile to clarify that the status of *-components be
>> specified here (it is explained in more detail in Section 7.2,
>> as promised).
>> 
>> Suggestion:
>> 
>> Old:
>> 	2.  The syntax of URNs assigned within the namespace.
>> 
>> New:
>> 	2.  The syntax of URNs assigned within the namespace,
>> 	including whether p-, q-, and/or f-components are
>> 	allowed.
>> 
> 
> Sorry to take so long to reply; I got backlogged over the
> holidays even more than usual.
> 
> I am still very uncomfortable with making the meanings of p-,
> q-, and f-components specific to a namespace.
> 
> I'm not sure how uncomfortable I am with making the syntax
> (whether such components are supported) specific to a
> namespace.   It seems like a slippery slope to me.
> 
> I fundamentally don't believe that they type of resource named
> should be specific to a namespace as a matter of URN
> architecture. I realize that there are namespaces that are
> defined specifically for certain kinds of resources, but it
> should not be assumed by a consumer of a name that a
> particular kind of namespace indicates a particular kind of
> resource.   This is something that should be learned at
> resolution or access time.
> 
> So therefore, on balance, I don't think it's appropriate to
> make the syntax for p-, q, or f- components namespace specific.





From nobody Fri Feb  6 01:12:46 2015
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 8EED41A049A for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 01:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 aLweaNoxulcY for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 01:12:38 -0800 (PST)
Received: from bsa2.jck.com (ns.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 45D171A03FF for <urn@ietf.org>; Fri,  6 Feb 2015 01:12:38 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YJexn-00012v-RA; Fri, 06 Feb 2015 04:12:35 -0500
Date: Fri, 06 Feb 2015 04:12:30 -0500
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, Sean Leonard <dev+ietf@seantek.com>, urn@ietf.org
Message-ID: <B809F69484DEE2F22CD1E17F@JcK-HP8200.jck.com>
In-Reply-To: <54B61071.3080106@gmx.de>
References: <54B22CF0.8090002@seantek.com> <54B61071.3080106@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.35
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/7PLUgHSUdJFXXBOsVWZPkpWi6w4>
Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin"
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: Fri, 06 Feb 2015 09:12:40 -0000

--On Wednesday, January 14, 2015 07:45 +0100 Julian Reschke
<julian.reschke@gmx.de> wrote:

> On 2015-01-11 08:57, Sean Leonard wrote:
>> ...
>> At broad-scope, it appears that the UTF-8/Unicode assumption
>> in urn: URIs is softened in this draft, compared to RFC 2141.
>> Maybe I missed something awhile back, but why is that? I
>> thought that all URNs are UTF-8/Unicode, and that made
>> everything nice and consistent. ...
> 
> I thought URNs are RFC3986-URIs, in which case they are
> limited to the characters allowed per RFC 3986. Am I missing
> something here?

Not as far as I can tell.  If either of you believe that
something else is needed in the document, please suggest
specific text and where to put it.

best,
    john






From nobody Fri Feb  6 23:38:38 2015
Return-Path: <internet-drafts@ietf.org>
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 686611A1B3E; Fri,  6 Feb 2015 23:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5WSnjfeVfC7F; Fri,  6 Feb 2015 23:37:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22D1A6EED; Fri,  6 Feb 2015 23:37:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150207073701.29186.57059.idtracker@ietfa.amsl.com>
Date: Fri, 06 Feb 2015 23:37:01 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/JKw8GBGRpAdk4To8gHaHMO6IMrU>
Cc: urn@ietf.org
Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-09.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 07 Feb 2015 07:37:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF.

        Title           : Uniform Resource Names (URNs)
        Authors         : Peter Saint-Andre
                          John C Klensin
	Filename        : draft-ietf-urnbis-rfc2141bis-urn-09.txt
	Pages           : 25
	Date            : 2015-02-06

Abstract:
   A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
   that is assigned under the "urn" scheme and a particular URN
   namespace, typically with the intent that the URN will be a
   persistent, location-independent resource identifier or abstract
   designator.  With regard to URN syntax, this document defines the
   canonical syntax for URNs (in a way that is consistent with URI
   syntax), specifies methods for determining URN equivalence, and
   discusses URI conformance.  With regard to URN namespaces, this
   document specifies a method for defining a URN namespace and
   associating it with a namespace identifier, and describes procedures
   for registering namespace identifiers with the Internet Assigned
   Numbers Authority (IANA).  This document obsoletes both RFC 2141 and
   RFC 3406.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Feb  6 23:54:28 2015
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 232581A7028 for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 23:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Ev9T8ymJ03nt for <urn@ietfa.amsl.com>; Fri,  6 Feb 2015 23:54:23 -0800 (PST)
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 2523B1A1B3E for <urn@ietf.org>; Fri,  6 Feb 2015 23:54:23 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YK0De-0003xw-6b for urn@ietf.org; Sat, 07 Feb 2015 02:54:22 -0500
Date: Sat, 07 Feb 2015 02:54:17 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <D8B22CC1F615AE635DCC2E3A@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.35
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/ItBFVIbOx4lziCoCNDexhLnHEwc>
Subject: [urn] New version of draft-ietf-urnbis-rfc2141bis-urn
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: Sat, 07 Feb 2015 07:54:25 -0000

Hi.

As everyone should have seen from the I-D announcement, -09 of
draft-ietf-urnbis-rfc2141bis-urn is now up.  We believe this
version reflects the results of discussions of the numbered
issues identified a while back.  If you don't think so, or have
additional issues, please speak up.  

For those who find such things helpful, note that a Change Log/
summary has been added as Appendix F, describing changes from
version -08 to this version.

I hope we are getting close to the home stretch on this
document, so please make comments as specific as possible --
general expressions of principles or concerns are significantly
less helpful.

I'm personally aware of the following outstanding or
questionable issues, in no particular order.  All of these have
been discussed, or at least mentioned, on the mailing list
within  the last several days:

	(1) The syntax for a URN in Section 3 matters and I'm
	not positive that what is there now represents WG
	consensus.
	
	(2) Peter and I have tweaked the various recommendations
	in Section 3.3 a bit further.  People should be sure
	that what is says is what they want and, if it isn't,
	suggest and discuss very specific alternate text and
	where to put it.
	
	(3) As noted in my response to him (February 06, 2015
	03:20 -0500), I wouldn't know what to do in this
	document to reflect Keith's concerns if the WG believed
	that something should be said.  I'm unsure whether the
	WG can form an opinion as to whether or not something
	should be said without a more actionable statement of
	those concerns, I know I cannot.

In addition, we have discovered that Peter's writing style and
stylistic preferences are not the same as mine.  That should be
no surprise to anyone.  I don't think the differences have
introduced any issues into the document other than those we can
count on the RFC Editor to straighten out.  But, if anyone
notices things they don't like, this would be a good time to
speak up.

I believe the text could go forward without addressing any of
those issues.  If someone thinks they should be addressed,
please say so soon and, again, preferably send text and advice
as to where to put it.

     john


From nobody Mon Feb  9 08:04:56 2015
Return-Path: <ht@inf.ed.ac.uk>
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 B7BBF1A1A59 for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 08:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ymk93KdWba5B for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 08:00:54 -0800 (PST)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 13A4B1A03A8 for <urn@ietf.org>; Mon,  9 Feb 2015 08:00:53 -0800 (PST)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t19G0lbT027069;  Mon, 9 Feb 2015 16:00:47 GMT
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t19G0k7i005785; Mon, 9 Feb 2015 16:00:47 GMT
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t19G0kWg017289; Mon, 9 Feb 2015 16:00:46 GMT
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t19G0ieH017285; Mon, 9 Feb 2015 16:00:44 GMT
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <54B22CF0.8090002@seantek.com> <54B61071.3080106@gmx.de> <B809F69484DEE2F22CD1E17F@JcK-HP8200.jck.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Mon, 09 Feb 2015 16:00:44 +0000
In-Reply-To: <B809F69484DEE2F22CD1E17F@JcK-HP8200.jck.com> (John C. Klensin's message of "Fri\, 06 Feb 2015 04\:12\:30 -0500")
Message-ID: <f5bd25jnkgj.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/W6tqc2ITSMkk73aTDhx8CJEgy2I>
Cc: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin"
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: Mon, 09 Feb 2015 16:00:57 -0000

John C Klensin writes:

> --On Wednesday, January 14, 2015 07:45 +0100 Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>> On 2015-01-11 08:57, Sean Leonard wrote:
>>> ...
>>> At broad-scope, it appears that the UTF-8/Unicode assumption
>>> in urn: URIs is softened in this draft, compared to RFC 2141.
>>> Maybe I missed something awhile back, but why is that? I
>>> thought that all URNs are UTF-8/Unicode, and that made
>>> everything nice and consistent. ...
>> 
>> I thought URNs are RFC3986-URIs, in which case they are
>> limited to the characters allowed per RFC 3986. Am I missing
>> something here?
>
> Not as far as I can tell.  If either of you believe that
> something else is needed in the document, please suggest
> specific text and where to put it.

Perhaps a Note somewhere to the effect that as URNs as defined in
2141bis are URIs, they automatically benefit from 3987.  That is, 3987
defines IRIs, and a (scheme-independent) mapping from IRI to URI, from
which it follows that someone who wants to define a Unicode-friendly
URN can say that that they define a URN namespace xyzzy [here].
Mostly they go on to write their identifiers in Unicode, subject to

 a) The constraints of 3987;

 b) The additional constraint that when mapped per 3987 to URI-land,
    their identifiers always satisfy the requirements of the xyzzy URN
    namespace;

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]


From nobody Mon Feb  9 09:31:22 2015
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 114331A1BEE for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 09:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 hAlRVJvHJRnO for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 09:14:15 -0800 (PST)
Received: from bsa2.jck.com (ns.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 70CDD1A1BCB for <urn@ietf.org>; Mon,  9 Feb 2015 09:14:15 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YKruR-000HfT-MJ; Mon, 09 Feb 2015 12:14:07 -0500
Date: Mon, 09 Feb 2015 12:14:02 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Message-ID: <90B00DCBBE75D9FD0D94B47C@JcK-HP8200.jck.com>
In-Reply-To: <f5bd25jnkgj.fsf@troutbeck.inf.ed.ac.uk>
References: <54B22CF0.8090002@seantek.com> <54B61071.3080106@gmx.de> <B809F69484DEE2F22CD1E17F@JcK-HP8200.jck.com> <f5bd25jnkgj.fsf@troutbeck.inf.ed.ac.uk>
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.35
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/Ubii72uFREi3MtIHA9joUhTxgfI>
Cc: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin"
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: Mon, 09 Feb 2015 17:14:17 -0000

--On Monday, February 09, 2015 16:00 +0000 "Henry S. Thompson"
<ht@inf.ed.ac.uk> wrote:

>> Not as far as I can tell.  If either of you believe that
>> something else is needed in the document, please suggest
>> specific text and where to put it.
> 
> Perhaps a Note somewhere to the effect that as URNs as defined
> in 2141bis are URIs, they automatically benefit from 3987. 

While 3987 is clearly dependent on 3986 and at least implicitly
incorporates some bits of it by reference, there is no
dependency at all, even an informative reference, from 3986 to
3987.   As far as I can tell, 3987 doesn't redefine URIs in any
way -- it just layers IRIs on top of URIs.

I don't see how one gets from those dependencies or IRIs on
URIs, with no dependencies in the other direction, to "URNs ...
automatically benefit from 3987", any more than I think it would
be appropriate to claim that, e.g., TCP automatically benefits
from HTTP.

In addition, because of the "syntax only" agreement, I don't
think we should go out of our way to encourage people to make
any more inferences from generic URIs to URNs than are
absolutely necessary.

   john




From nobody Mon Feb  9 12:14:59 2015
Return-Path: <ht@inf.ed.ac.uk>
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 8EC9D1A87BF for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 11:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pi0LmMDfO735 for <urn@ietfa.amsl.com>; Mon,  9 Feb 2015 11:39:24 -0800 (PST)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC51A3B9C for <urn@ietf.org>; Mon,  9 Feb 2015 11:38:57 -0800 (PST)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t19JcjS1019048;  Mon, 9 Feb 2015 19:38:45 GMT
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t19JciVf017431; Mon, 9 Feb 2015 19:38:45 GMT
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t19JciLW031274; Mon, 9 Feb 2015 19:38:44 GMT
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t19Jchod031269; Mon, 9 Feb 2015 19:38:43 GMT
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <54B22CF0.8090002@seantek.com> <54B61071.3080106@gmx.de> <B809F69484DEE2F22CD1E17F@JcK-HP8200.jck.com> <f5bd25jnkgj.fsf@troutbeck.inf.ed.ac.uk> <90B00DCBBE75D9FD0D94B47C@JcK-HP8200.jck.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Mon, 09 Feb 2015 19:38:43 +0000
In-Reply-To: <90B00DCBBE75D9FD0D94B47C@JcK-HP8200.jck.com> (John C. Klensin's message of "Mon\, 09 Feb 2015 12\:14\:02 -0500")
Message-ID: <f5biofanad8.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/cb2cACGBsQ9s54GH6-vqcFzSS9E>
Cc: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin"
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: Mon, 09 Feb 2015 19:39:27 -0000

John C Klensin writes:

> --On Monday, February 09, 2015 16:00 +0000 "Henry S. Thompson"
> <ht@inf.ed.ac.uk> wrote:
>
>>> Not as far as I can tell.  If either of you believe that
>>> something else is needed in the document, please suggest
>>> specific text and where to put it.
>>=20
>> Perhaps a Note somewhere to the effect that as URNs as defined
>> in 2141bis are URIs, they automatically benefit from 3987.=20
>
> While 3987 is clearly dependent on 3986 and at least implicitly
> incorporates some bits of it by reference, there is no
> dependency at all, even an informative reference, from 3986 to
> 3987.

Precisely.

> As far as I can tell, 3987 doesn't redefine URIs in any
> way -- it just layers IRIs on top of URIs.

Agreed.

> I don't see how one gets from those dependencies or IRIs on
> URIs, with no dependencies in the other direction, to "URNs ...
> automatically benefit from 3987"

Precisely because the layering is 3987 on 3986.  It tells us how to
convert a string (which conforms to IRI syntax) containing supra-ASCII
Unicode characters into a string without such characters, which is
guaranteed to conform to URI syntax.

> In addition, because of the "syntax only" agreement, I don't
> think we should go out of our way to encourage people to make
> any more inferences from generic URIs to URNs than are
> absolutely necessary.

For sure.  My argument goes the other way.  Suppose in the glorious
future to come, ISBN uris are defined to support auto-indexing requests,
so that urn:isbn:978-1-84749-079-7?operation=3Dindex&word=3Dflower will
give me a list of all the pages on which the word 'flower' appears in
Jane Austen's _Persuasion_ (Oneworld Classics 2009 edition).  What if
I want an index for Proust's "Du C=F4t=E9 de Chez Swann" instead?  I can't
write urn:isbn:0-543-72205-8?operation=3Dindex&word=3Dd=E9licieux, it's not
a valid URI, ergo not a valid URN.  But it _is_ a valid IRI.  Which
you may say is not a particularly useful observation.  But I think it
is, because it means there is an RFC we can refer to which specifies,
in detail how to convert our valid IRIs into valid URIs, in this case=20
urn:isbn:0-543-72205-8?operation=3Dindex&word=3Dd%C3%A9licieux

At this point you say "yes, but we don't need 3987 for this, it's in
section 3.2 of 2141bis [1]."  Well, no, it isn't.  3.2 only covers the
NSS, not the q-component.  Furthermore, the wording of 3.2 is, it
seems to me, dangerously ambiguous.   When it says

   names that are valid in a namespace might contain characters that
   are not allowed in URNs according to the "pchar" rule (e.g.,
   characters outside the ASCII range or characters that are reserved
   in URIs, such as "/", "?", and "#").  Such a string MUST be
   translated into a conformant NSS before using it as a protocol
   element or otherwise passing it on to other applications.

it's very easy to read the phrase "names that are valid in a namespace
[despite containing e.g. accented characters]" as saying such
characters may be _allowed_ by the definition of a URN namespace.  I
guess you meant "real-world, pre-existing namespace" here, but then it
really doesn't make sense to go on to say

  namespaces SHOULD NOT allow characters outside the basic Latin
  repertoire

which a) now does seem by 'namespaces' to mean 'URN namespace
definitions' and b) contradicts the ABNF.  urn: URIs themselves _do
not_ consist of _anything_ that's not a pchar -- the 'syntax only'
agreement doesn't give you any wiggle room on that, as I understand
it.  That 'SHOULD NOT' has to be a 'MUST NOT'.  I think that in turn
that means you really do need to say just a bit more about the
difference between the strings people may wish to use for various
purposes and the syntax of urn: URIs, as in the above example.

I don't care very much if you use 3987 for that purpose, or not, I
just thought it would be better to avoid re-drawing the blueprint for
the wheel.

ht

[1] http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-09#section-=
3.2
--=20
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged s=
pam]


From nobody Fri Feb 13 13:17:45 2015
Return-Path: <melinda.shore@gmail.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 F2D1F1A1A57 for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 13:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 MEqulupXeN8X for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 13:17:41 -0800 (PST)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 E50C11A1A8D for <urn@ietf.org>; Fri, 13 Feb 2015 13:17:40 -0800 (PST)
Received: by mail-pa0-f51.google.com with SMTP id eu11so21301641pac.10 for <urn@ietf.org>; Fri, 13 Feb 2015 13:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=N2WSs+Dkf/3iPcNzdVCvdz6wrznOofZGgF7/sea/VzA=; b=doDQyUnNV0uX29RodUWoKHZ6OWwKj1pB94fvCY+nmJ/dNayN6GBt4NcJlB14f2V1M/ vTZ9nmIJOBFWKLDLPvlcGLt/ZFbkxk2V62Iwg5iPVmlQlFwSJI67TaXPijJhpqtO97TZ BRSSh9rUtvJA+37kBDuUuMWIR+oIBERfrrHQvfVnMybq6SMj1FNcU1+Iy7dwXoctwf+d sk9pwSa6nK/i1Ljp1395CNmOU4uJXs0Zt/Oq4OPRxZrefTJDP+AK+dq3RQbuN5rL3kQG W6JiMVcFuU64H78wmFBBQzXtxyAMjoiQtCa7irXv7MYk8l12lY8m4N88FYjtWD9WS1X0 YOTQ==
X-Received: by 10.70.138.15 with SMTP id qm15mr18090816pdb.117.1423862260243;  Fri, 13 Feb 2015 13:17:40 -0800 (PST)
Received: from spandex.local (216-67-79-246-rb1.sol.dsl.dynamic.acsalaska.net. [216.67.79.246]) by mx.google.com with ESMTPSA id em4sm7575618pbc.46.2015.02.13.13.17.38 for <urn@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 13:17:39 -0800 (PST)
Message-ID: <54DE69F1.7030004@gmail.com>
Date: Fri, 13 Feb 2015 12:17:37 -0900
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/hgEaHc9ZrULvxTwONOdZcGbt7u4>
Subject: [urn] Moving 2141bis along
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: Fri, 13 Feb 2015 21:17:43 -0000

Hello, all:

The -09 revision of the bis document was posted last week
(https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/).
We'd really like to get the document closed and move it towards
wglc, and there are two immediate items in the revision on which
we'd like to check consensus.  In particular, we're looking for
feedback on:

1) the URN syntax in section 3, and
2) the recommendations being made in section 3.3

If you haven't read the revision yet please look it over, and
send feedback on these two questions in particular, plus other
issues you believe might prevent the document from moving
forward.

Many thanks!

Melinda


From nobody Fri Feb 13 21:53:40 2015
Return-Path: <internet-drafts@ietf.org>
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 ED2E51A1A3B; Fri, 13 Feb 2015 21:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yTf0iAAobuTd; Fri, 13 Feb 2015 21:53:34 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FAD1A00EC; Fri, 13 Feb 2015 21:53:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150214055334.9551.91725.idtracker@ietfa.amsl.com>
Date: Fri, 13 Feb 2015 21:53:34 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/QAyMMSl3s9RIUZEOqxN38OoAy_8>
Cc: urn@ietf.org
Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-01.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 14 Feb 2015 05:53:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF.

        Title           : URN Semantics Clarification
        Author          : John C Klensin
	Filename        : draft-ietf-urnbis-semantics-clarif-01.txt
	Pages           : 10
	Date            : 2015-02-13

Abstract:
   Experience has shown that identifiers associated with persistent
   names have properties and requirements that may be somewhat different
   from identifiers associated with the locations of objects.  This is
   especially true when such names are expected to be stable for a very
   long time or when they identify large and complex entities.  In order
   to allow Uniform Resource Names (URNs) to evolve to meet the needs of
   the Library, Museum, Publisher, and Information Science communities
   and other users, this specification separates URNs from the semantic
   constraints that many people believe are part of the specification
   for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
   document accordingly.  The syntax of URNs is still constrained to
   that of RFC 3986, so generic URI parsers are unaffected by this
   change.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Feb 13 22:34:37 2015
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 564C01A1A86 for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 22:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 9Ur6ipTOk5Rx for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 22:34:33 -0800 (PST)
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 7ECC91A1A73 for <urn@ietf.org>; Fri, 13 Feb 2015 22:34:33 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YMWJE-000A2y-4d for urn@ietf.org; Sat, 14 Feb 2015 01:34:32 -0500
Date: Sat, 14 Feb 2015 01:34:27 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <E8B90C4A28D5329F74250588@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.35
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/VZqUUiSvCxkzxVj86Mj8TGmByus>
Subject: [urn] The "semantics clarification", aka "syntax only" draft
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: Sat, 14 Feb 2015 06:34:35 -0000

Hi.

As the list has been told by announcements from the tracker,
I've just posted draft-ietf-urnbis-semantics-clarif-01.   The
Change Log is fairly comprehensive but, for those looking for a
quick preview:

* I don't believe that it is substantively different from the
previous version or the intent of the WG on which Andy has ruled
there is consensus.

* I've eliminated material that -00 and list discussions
indicated was going to go away.

* This version is aligned with 2141bis-08 and -09 while the
prior version predated them..

* I've done considerable editorial work to make the document
read more smoothly and make it more ready for publication
(should we decide to do that) as well as to incorporate various
clarifications the need for which was identified on the mailing
list.

Those reading carefully will notice two things in the References:

(1) The reference to 2141bis should have had its date and
authors corrected and should be normative now.  Fixed in the
working version that will evolve into of -02 of this "semantics
clarification" I-D -- I'm not going to repost just to correct
that unless the co-chairs tell me to.

(2) There is essentially a forward pointer to
draft-ietf-urnbis-ns-reg-transition, listing a February 2015
date.  A revised version of that document should be posted
within the next few days.  As a preview, the most important
change in it is eliminating the reference to 3406bis since that
document was collapsed into 2141bis.

    john


From nobody Fri Feb 13 23:25:28 2015
Return-Path: <melinda.shore@gmail.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 5E04E1A1AAF for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 23:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 kddFaAbbHn3E for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 23:25:24 -0800 (PST)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (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 B35361A1A4E for <urn@ietf.org>; Fri, 13 Feb 2015 23:25:24 -0800 (PST)
Received: by pdev10 with SMTP id v10so24027659pde.7 for <urn@ietf.org>; Fri, 13 Feb 2015 23:25:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Qr9shieWZK3FORSqy2ayVZvmphN++B7lBJnbDFJNGoU=; b=AMdM7lh69/Ki3MtzDEefso7Ei7+Beg6oe2UtHfJYIy3L8j3+HmsO7jzajKliZF3Okr /baEBJztxbaHQCwkjKJVNq7EIc/BhcPUtghf1Sxj8hD14fABPnAe43MqSfv/Fi3XmgDF PmCE3R0ERL9v5QaNfW+biUnyUu/nTHuROwYT+QBpbdZpEn87bZpx8v/Hi2bPM//vdPgS oEsu3Kq9dT94wozWPQP21AM83yy6m/AWrtmP/wphOjDTP5JmHJlubIgWD1icEyVjn9eT ArWKHxH1K6VwhFrWeztN8rYv5WiiErWZ3UOMIh8xFlhCeywdcPKdA1x6e4yUaDA8CJPs /s9g==
X-Received: by 10.68.69.6 with SMTP id a6mr21853554pbu.82.1423898724440; Fri, 13 Feb 2015 23:25:24 -0800 (PST)
Received: from spandex.local (216-67-79-246-rb1.sol.dsl.dynamic.acsalaska.net. [216.67.79.246]) by mx.google.com with ESMTPSA id uy8sm8606665pbc.31.2015.02.13.23.25.23 for <urn@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 23:25:23 -0800 (PST)
Message-ID: <54DEF861.7030002@gmail.com>
Date: Fri, 13 Feb 2015 22:25:21 -0900
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: urn@ietf.org
References: <E8B90C4A28D5329F74250588@JcK-HP8200.jck.com>
In-Reply-To: <E8B90C4A28D5329F74250588@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/xwtbL1q1BbTfgJc-wSaIc85KbcM>
Subject: Re: [urn] The "semantics clarification", aka "syntax only" draft
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: Sat, 14 Feb 2015 07:25:26 -0000

On 2/13/15 9:34 PM, John C Klensin wrote:
> (1) The reference to 2141bis should have had its date and
> authors corrected and should be normative now.  Fixed in the
> working version that will evolve into of -02 of this "semantics
> clarification" I-D -- I'm not going to repost just to correct
> that unless the co-chairs tell me to.

I'm not sure where Andy stands on this sort of thing but since
getting through last call and into IESG review often involves
multiple iterations around what are essentially nits, I tend
to feel it's fine to wait until then to resolve known nits.

> (2) There is essentially a forward pointer to
> draft-ietf-urnbis-ns-reg-transition, listing a February 2015
> date.  A revised version of that document should be posted
> within the next few days.  As a preview, the most important
> change in it is eliminating the reference to 3406bis since that
> document was collapsed into 2141bis.

Excellent - thanks so much for all your work on getting revisions
out.

Melinda



From nobody Fri Feb 13 23:50:27 2015
Return-Path: <john@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 569C31A1ABE for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 23:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 cSruJdHP1aza for <urn@ietfa.amsl.com>; Fri, 13 Feb 2015 23:50:22 -0800 (PST)
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 C3D581A1AB1 for <urn@ietf.org>; Fri, 13 Feb 2015 23:50:22 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1YMXUb-000A9v-Hr; Sat, 14 Feb 2015 02:50:21 -0500
Date: Sat, 14 Feb 2015 02:50:16 -0500
From: John C Klensin <john@jck.com>
To: Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <8390655248928ED92B7E9B50@JcK-HP8200.jck.com>
In-Reply-To: <54DEF861.7030002@gmail.com>
References: <E8B90C4A28D5329F74250588@JcK-HP8200.jck.com> <54DEF861.7030002@gmail.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.35
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/RhepowInA8Ix183erEcrv5srPMA>
Subject: Re: [urn] The "semantics clarification", aka "syntax only" draft
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: Sat, 14 Feb 2015 07:50:24 -0000

--On Friday, February 13, 2015 22:25 -0900 Melinda Shore
<melinda.shore@gmail.com> wrote:

> On 2/13/15 9:34 PM, John C Klensin wrote:
>> (1) The reference to 2141bis should have had its date and
>> authors corrected and should be normative now.  Fixed in the
>> working version that will evolve into of -02 of this
>> "semantics clarification" I-D -- I'm not going to repost just
>> to correct that unless the co-chairs tell me to.
> 
> I'm not sure where Andy stands on this sort of thing but since
> getting through last call and into IESG review often involves
> multiple iterations around what are essentially nits, I tend
> to feel it's fine to wait until then to resolve known nits.

My thinking was close to that.  I hope that several people will
read this version in the next few days.  If they do so
carefully, I'm sure they will find other areas where I botched
things (because I always do).  If we get comments on those, I
can incorporate the fixes and reissue before we go into anything
resembling WG LC.    If we don't, I can reissue with that
trivial change before we go into WG LC.  I just saw it as better
to turn immediately to the other draft rather than fussing with
the various systems to reissue now and, with luck, have to
reissue again during the week.

While I think your reasoning is a little different, the end
result is the same.

    best,
     john



From nobody Mon Feb 16 13:46:54 2015
Return-Path: <internet-drafts@ietf.org>
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 6C5AC1A6F10; Mon, 16 Feb 2015 13:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PGDgC_cxpzLp; Mon, 16 Feb 2015 13:46:50 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70E1A3BA6; Mon, 16 Feb 2015 13:46:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150216214650.2974.83498.idtracker@ietfa.amsl.com>
Date: Mon, 16 Feb 2015 13:46:50 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/2k_ceofhOs1IY7JVN9bMFNJVc6M>
Cc: urn@ietf.org
Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-04.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 16 Feb 2015 21:46:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF.

        Title           : Uniform Resource Name (URN) Namespace Registration Transition
        Authors         : John C Klensin
                          Juha Hakala
	Filename        : draft-ietf-urnbis-ns-reg-transition-04.txt
	Pages           : 8
	Date            : 2015-02-16

Abstract:
   The original registration procedure for formal Uniform Resource Name
   (URN) namespaces required IETF Consensus.  That requirement
   discouraged some registrations and increased the risk for problems
   that could occur as a result.  The requirements have now been changed
   in [[RFC 2141bis]].  That document adopts a different model.  This
   document specifies IANA instructions to adapt selected existing
   registrations to the new model.  It also obsoletes some previous RFCs
   to eliminate any ambiguity about the status of new templates and
   updated registrations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-ns-reg-transition-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Feb 16 13:58:47 2015
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 7AA951A6F10 for <urn@ietfa.amsl.com>; Mon, 16 Feb 2015 13:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 syDbYZ1hfh3Z for <urn@ietfa.amsl.com>; Mon, 16 Feb 2015 13:58:37 -0800 (PST)
Received: from bsa2.jck.com (ns.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 0D4601A88BD for <urn@ietf.org>; Mon, 16 Feb 2015 13:58:37 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YNTga-000Isf-1k for urn@ietf.org; Mon, 16 Feb 2015 16:58:36 -0500
Date: Mon, 16 Feb 2015 16:58:30 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <F50740CEF6CEA4D4522F4F9B@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.35
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/npNw-1iXPIoKyxPqdCraqXY-aHQ>
Subject: [urn] The namespace registration trainsition draft, version 04
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: Mon, 16 Feb 2015 21:58:45 -0000

Hi.

As the last of this round of document postings, I've just
submitted draft-ietf-urnbis-ns-reg-transition.

For those familiar with prior versions, there are really no
substantive changes.  The major ones reflect the transition from
a separate 3406bis to the consolidated 2141bis.  So it is
probably reasonable to look at a diff.

I have also made a number of editorial changes that, I hope,
will make the document somewhat more precise.

In addition to a general review of the draft, WG participants
should note that the placeholder "[[CREF3" in Section 2
effectively asks a substantive question about whether there is
content in the now-expired draft-ietf-urnbis-rfc3187bis-isbn-urn
and draft-ietf-urnbis-rfc3044bis-issn-urn that needs to be moved
into either this documents or 2141bis.  If such content is not
identified soon, we will assume the answer is "no" and will
remove the placeholder.

The immediately-following "[[CREF4" ask a similar question about
other registered namespaces that might need specific transition
information.  Again, if there are such issues, please comment
soon or the placeholder will simply be removed.

Note that these placeholders have now been present in versions
of this document for well over a year and there have been no
comments in response to either.

best,
   john




From nobody Mon Feb 16 14:05:45 2015
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 28D431A6F22 for <urn@ietfa.amsl.com>; Mon, 16 Feb 2015 14:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Uc_NYQK0BuDM for <urn@ietfa.amsl.com>; Mon, 16 Feb 2015 14:05:41 -0800 (PST)
Received: from bsa2.jck.com (ns.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 7F13A1A0154 for <urn@ietf.org>; Mon, 16 Feb 2015 14:05:41 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YNTnQ-000ItU-JN for urn@ietf.org; Mon, 16 Feb 2015 17:05:40 -0500
Date: Mon, 16 Feb 2015 17:05:35 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <DAA17D321BD470A0D65CF05B@JcK-HP8200.jck.com>
In-Reply-To: <F50740CEF6CEA4D4522F4F9B@JcK-HP8200.jck.com>
References: <F50740CEF6CEA4D4522F4F9B@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.35
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/q1fz3D6vQ15HXUzb-kfblKKAzzA>
Subject: [urn] (more) The namespace registration trainsition draft, version 04
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: Mon, 16 Feb 2015 22:05:43 -0000

Hi.

One thing I didn't mention in my earlier note and should have.
Because the changes are small and should be non-substantive, I
did not ask Juha to review this version before it was posted,
so, if it introduced any new problems, they are my fault alone.

    john


From nobody Fri Feb 20 02:31:18 2015
Return-Path: <gk@ninebynine.org>
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 AC14B1A882B; Fri, 20 Feb 2015 02:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 LFobtOAXHMN6; Fri, 20 Feb 2015 02:31:14 -0800 (PST)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFFC1A87A4; Fri, 20 Feb 2015 02:31:14 -0800 (PST)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YOkrY-0003dz-bZ; Fri, 20 Feb 2015 10:31:12 +0000
Received: from oerc-dynamic-225.oerc.ox.ac.uk ([129.67.194.225]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YOkrY-0005Z2-Ei; Fri, 20 Feb 2015 10:31:12 +0000
Message-ID: <54E70CEE.8030203@ninebynine.org>
Date: Fri, 20 Feb 2015 10:31:10 +0000
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: urn@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/CgUz4yi0muwa9nwLexyzSQXs2lY>
Cc: Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] URN "semantics clarification", aka "syntax only" draft
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: Fri, 20 Feb 2015 10:31:16 -0000

Hi John, all,

(bcc: apps-discuss@ietf.org)

I've just taken a skim of 
http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I think 
the intent is fine but have a couple of questions or points of clarification.

My main concern is that URNs should be considered to be a kind of URI, and 
should be consistently usable in all contexts where a URI is usable (though, 
clearly, use in a context that requires dereferencing would be undefined in the 
same way as use of an unknown URI scheme would be).  Failure to satisfy this 
constraint would, IMO, force a bifurcation between URIs and URNs, which is 
something you say you want to avoid.

This means that not only should they conform to URI syntax, but also should 
conform to RFC3986 URI relative resolution rules.  For example, my code applies 
relative resolution without concern for the URI scheme used.  ("Traditional" 
URNs avoid syntactic constructions that include the possibility of relative 
references.)  (FWIW, I also happen to find that relative references are useful 
in naming contexts as well as retrieval contexts.)

Jumping to section 4, which appears to be the substantive part of this document, 
the main change I am seeing is a change of terminology from "path", "query" and 
"fragment" to "p-component", "q-component" and "f-component".  I take this to be 
a distancing of these elements in URNs from some commonly used conventions used 
with location-based URIs (aka URLs).  To the extent that this helps to reduce 
confusion, this seems fine to me (thought I also think it's an open question as 
to whether new terminology does reduce confusion).

...

You claim:

"In particular, the Generic URI Syntax specification goes beyond
    syntax to specify the meaning and interpretation of various fields,
    especially the "query" and "fragment" ones and the various syntax
    forms and interpretations it allows for <hier-part>. "

I disagree with this characterization with respect to "query" elements ("The 
query component contains non-hierarchical data that, along with data in the path 
component (Section 3.3), serves to identify a resource within the scope of the 
URI's scheme and naming authority (if any)." -- 
http://tools.ietf.org/html/rfc3986#section-3.4), though I accept it's commonly 
used to invoke dynamic search type operations.

For fragments, I accept that for a URN, where there is no dereferencing, the 
dependence on media type is difficult.  RDF 
[http://www.w3.org/TR/rdf11-concepts/] addresses this by simply treating the 
fragment as part of the overall name string, without further interpretation.

It then becomes an application design/implementation issue to avoid use of 
fragments of retrieved entities in ways that conflict with their use in names 
(cf. http://www.w3.org/TR/webarch/#fragid, 
http://www.w3.org/TR/webarch/#media-type-fragid).  In partyicular: "If no such 
representation exists, then the semantics of the fragment are considered unknown 
and, effectively, unconstrained." [ibid]

For paths, it's not clear to me whether you consider the relative resolution 
algorithm of RFC3986 to be part of the path semantics.  Per my comments above, I 
would be very concerned if you try to say that the resolution algorithm is not 
applicable to URNs, as that would mean that an application needs to know if its 
dealing with a URN or URI when performing otherwise scheme-independent processing.

...

In summary, assuming that you do not intend to exclude relative resolution from 
URN handling, the documents appears to me to be a "null specification", in that 
it does not actually exclude anything that is required by RFC3986.  I don't mean 
that its not useful - I think there are issues here that are usefully 
articulated and explained, but in the final analysis these clarifications should 
apply to *any* URI scheme used as a name rather than a locator.

And URI schemes are always allowed to layer their own semantics on top of 
RFC3986, so again the notion "removes URN semantics from the scope of RFC 3896" 
isn't really saying anything new that I can see.

So I think section 4 would more usefully be titled "Clarifications to RFC3986 as 
applied to URNs".

#g
--

By way of (partial) background to these comments, I'm currently working on a 
tool for small-scale research data management for which these are very real 
issues [https://github.com/gklyne/annalist].  I use URIs as both names and as 
locators, depending on context (not on the form of URI used).  Goals of my work 
include facilitation of data sharing, and provision of a path for data on 
researchers' desktops to library-managed data repositories - so both location 
and naming issues come in to play.


From nobody Fri Feb 20 10:59:07 2015
Return-Path: <nico@cryptonector.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 2744C1A046D for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 10:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 LIYMJyVnWbn6 for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 10:59:04 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 771741A007D for <urn@ietf.org>; Fri, 20 Feb 2015 10:59:04 -0800 (PST)
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 391FF264070; Fri, 20 Feb 2015 10:59:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=znh3HCIXHbhsnz Smaf9roLnxnZQ=; b=GHW30zBwJvKruAIUKkQgU2I8OCbKNqB0lKtYHxM0RIva1a bIXqb90yyG5+N4Te+1zRpDbj+6iLeXDXdvZlb95jSDAnZ85GRF7eAlpPN7eRCGwl bNmdiTBZibYi+sai32vqi8EW1j1Z3pvP/vpNkxDq3AryHxw6zEo11BtcFb3qM=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id 7C3FE26406B; Fri, 20 Feb 2015 10:59:03 -0800 (PST)
Date: Fri, 20 Feb 2015 12:59:02 -0600
From: Nico Williams <nico@cryptonector.com>
To: Graham Klyne <gk@ninebynine.org>
Message-ID: <20150220185900.GA18878@localhost>
References: <54E70CEE.8030203@ninebynine.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54E70CEE.8030203@ninebynine.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/MjsNI38GIKi06_-7AaYUzc0wo-o>
Cc: urn@ietf.org, Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] [apps-discuss] URN "semantics clarification", aka "syntax only" draft
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: Fri, 20 Feb 2015 18:59:06 -0000

On Fri, Feb 20, 2015 at 10:31:10AM +0000, Graham Klyne wrote:
> (bcc: apps-discuss@ietf.org)

Thanks, I'd not have seen this.

> I've just taken a skim of
> http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01,
> and I think the intent is fine but have a couple of questions or
> points of clarification.
> 
> My main concern is that URNs should be considered to be a kind of
> URI, and should be consistently usable in all contexts where a URI
> is usable (though, clearly, use in a context that requires
> dereferencing would be undefined in the same way as use of an
> unknown URI scheme would be).  Failure to satisfy this constraint
> would, IMO, force a bifurcation between URIs and URNs, which is
> something you say you want to avoid.

Rephrased as a question for proponents: what is the difference between a
URN that some code doesn't know what to do with, and a URI whose scheme
the same code doesn't know?

> This means that not only should they conform to URI syntax, but also
> should conform to RFC3986 URI relative resolution rules.  For
> example, my code applies relative resolution without concern for the
> URI scheme used.  ("Traditional" URNs avoid syntactic constructions
> that include the possibility of relative references.)  (FWIW, I also
> happen to find that relative references are useful in naming
> contexts as well as retrieval contexts.)

I see no reason that a URN couldn't name a resource with dynamic
behavior (think of a document with embedded code) or fragments (think of
an HTML document).

> Jumping to section 4, which appears to be the substantive part of
> [...]

Section 1 says

  This specification excludes URNs from those definitions of meaning and
  interpretation so that RFC 3986 applies to their syntax only.

where "those definitions of meaning and interpretation" refers to
"especially the "query" and "fragment" ones and the various syntax forms
and interpretations it allows for <hier-part>".

So... keep the syntax and throw away the semantics.  But why bother?

What harm results from keeping the semantics?  What is the benefit of
dropping the semantics?

I grant that in the absence of knowledge of the semantics of a URN's
query and fragment parts one can only treat the whole thing as an opaque
string, or, at best, drop the query and fragment (semantics!) to see if
the remainder is known or not.  E.g., a URN sans query & fragment might
appear in a registry, which might help determine whether the URN can be
dereferenced (in which case the query and fragment might gain meaning),
how it might be described to a user (in which case there may be no
meaning of the query & fragment, or the user might be the only one to
determine the meaning of the query & fragment), and so on.

What is the meaning of keeping the syntax but dropping the related
semantics?  The answer to this one seems to be: URNs become strings with
no meaning that must adhere to the RFC 3986 syntax pro-forma, because
too many bits of code will want to parse them, so don't break them.

Back to section 4, the consequences of this change are unclear.  The
change itself is unclear.  "This specification removes URN semantics
from the scope of RFC 3896."  But then we keep the syntax, with
different names for some elements.  What's the point?  What's the
benefit?

> In summary, assuming that you do not intend to exclude relative
> resolution from URN handling, the documents appears to me to be a
> "null specification", in that it does not actually exclude anything
> that is required by RFC3986.  I don't mean that its not useful - I

Exactly, that's my take as well, except that I don't see the use.  You
seem to see the use.  Can you explain it to me?

Incidentally, where in the WG's charter does this I-D fall?

> think there are issues here that are usefully articulated and
> explained, but in the final analysis these clarifications should
> apply to *any* URI scheme used as a name rather than a locator.

Well, yes (assuming there is a use to this).

> And URI schemes are always allowed to layer their own semantics on
> top of RFC3986, so again the notion "removes URN semantics from the
> scope of RFC 3896" isn't really saying anything new that I can see.

+1

Nico
-- 


From nobody Fri Feb 20 12:05:20 2015
Return-Path: <dev+ietf@seantek.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 769F01A011E; Fri, 20 Feb 2015 12:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 Jru4fZxaHmtS; Fri, 20 Feb 2015 12:05:17 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2591A0089; Fri, 20 Feb 2015 12:05:15 -0800 (PST)
Received: from [10.37.3.37] (unknown [38.104.134.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2CE2B509BF; Fri, 20 Feb 2015 15:05:11 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=windows-1252
From: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <54E70CEE.8030203@ninebynine.org>
Date: Fri, 20 Feb 2015 12:05:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <129582A1-F3E5-4EC5-A3A9-EEFBDA75B345@seantek.com>
References: <54E70CEE.8030203@ninebynine.org>
To: urn@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/8fYlvqYmgNhE3_Ck3Ace1zd4f1s>
Cc: Graham Klyne <gk@ninebynine.org>, Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] [apps-discuss] URN "semantics clarification", aka "syntax only" draft
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: Fri, 20 Feb 2015 20:05:19 -0000

(also bcc=92ing apps-discuss=85although not exactly sure why it=92s =
bcc=92ed)

On Feb 20, 2015, at 2:31 AM, Graham Klyne <gk@ninebynine.org> wrote:

> Hi John, all,
>=20
> (bcc: apps-discuss@ietf.org)
>=20
> I've just taken a skim of =
http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I =
think the intent is fine but have a couple of questions or points of =
clarification.
>=20
> My main concern is that URNs should be considered to be a kind of URI, =
and should be consistently usable in all contexts where a URI is usable =
(though, clearly, use in a context that requires dereferencing would be =
undefined in the same way as use of an unknown URI scheme would be). =20

+1. I agree with Graham, namely, that a URN should be considered a kind =
of URI. (On that particular sentence I agree +1000.) It=92s not just =
that they are syntactically the same=97a URN is a species of URI, =
namely, a URI scheme. Compare with HTTP URI being a URI. It=92s worth =
pointing out that since RFC 3986 says that URIs are semantics-free =
(mostly), that part of the URI spec may be cited in support of the =
premise that just because a URN is a kind of URI, it doesn=92t imply =
much else with regard to semantics.

> Failure to satisfy this constraint would, IMO, force a bifurcation =
between URIs and URNs, which is something you say you want to avoid.
>=20
> This means that not only should they conform to URI syntax, but also =
should conform to RFC3986 URI relative resolution rules.  For example, =
my code applies relative resolution without concern for the URI scheme =
used.  ("Traditional" URNs avoid syntactic constructions that include =
the possibility of relative references.)  (FWIW, I also happen to find =
that relative references are useful in naming contexts as well as =
retrieval contexts.)

There are philosophical and practical problems with URI=92s relative =
resolution rules as applied to urn: URIs, which have been covered =
extensively on the urn mailing list around October-November 2014, so =
best to check that. I am happy to elaborate on my understanding if that =
helps things but want to keep this e-mail short now.

>=20
> Jumping to section 4, which appears to be the substantive part of this =
document, the main change I am seeing is a change of terminology from =
"path", "query" and "fragment" to "p-component", "q-component" and =
"f-component".  I take this to be a distancing of these elements in URNs =
from some commonly used conventions used with location-based URIs (aka =
URLs).  To the extent that this helps to reduce confusion, this seems =
fine to me (thought I also think it's an open question as to whether new =
terminology does reduce confusion).

I actually disagree with the terms p-component, q-component, and =
f-component on editorial grounds. The problem is that =93path=94, =
=93query=94, and =93fragment=94 were thought to imply some things that =
URNBIS people disagreed with. However, calling them x-component is =
annoying to me=85particularly because a fragment is a fragment is a =
fragment.

For discussion purposes in I-Ds I was okay with it, but in any final =
RFCs I request that we go back to calling them =93path=94, =93query=94, =
and =93fragment=94. Specifically, how about referring to them as the =
=93path production of [RFC3986]=94 and similar? By calling it =93path =
production=94 you are specifically referring to the RFC 3986 URI ABNF =
grammar, which is about syntax, and does not imply that URNs are =
=93path-oriented=94 or the like.

Cheers,

Sean=


From nobody Fri Feb 20 19:16:28 2015
Return-Path: <peter@andyet.net>
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 F31231A1A31 for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 19:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 NvAzhOvw35jO for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 19:16:23 -0800 (PST)
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (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 318001A1A5E for <urn@ietf.org>; Fri, 20 Feb 2015 19:16:23 -0800 (PST)
Received: by iecat20 with SMTP id at20so12338887iec.12 for <urn@ietf.org>; Fri, 20 Feb 2015 19:16:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wLdB2JqrVgL6szSZ1uFdjTZILKkCjEdTbrQD/1f1A8g=; b=eEwYxo85HOVTbonCuriQVoQc8Yur8bIlPw6i0j72a4hdYR43X+hOC9b7wDAnoD5vaX TYfqIOzbtbZmmC26KWT7wrPr0efaToXW/ukQdqzT4nf+4hA2I/paqtCc676TZAXpBTZ9 UJDhW8RB9gZdLl09zW+BZmCg+wZFavTNLN0ns1m8Opq5wkJ+P35aUUr7dE9YasrhjelS WnuXGveiDNE7prPWfv9lMdL4YnQau7zc1L2jrAj0oeLGtJNIAO9aac8GQYoEvsXY5U9G hwGpkp5mJiZdYnvRmxDM+SJtKhMgBAjcwCBcmAEho69mobi1ZYktLsHo1wink2WT6qmn brHA==
X-Gm-Message-State: ALoCoQnUW9c/ZwAe5wDKkmfg5C4hJcP2SYf0JiDoF3/Kx03yQsyzG6Xs8joI5A0yGhiXfOdQmvur
X-Received: by 10.50.79.229 with SMTP id m5mr572956igx.23.1424488582674; Fri, 20 Feb 2015 19:16:22 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j77sm18113153ioj.30.2015.02.20.19.16.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 19:16:22 -0800 (PST)
Message-ID: <54E7F885.4000304@andyet.net>
Date: Fri, 20 Feb 2015 20:16:21 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
References: <54E7F813.8010201@andyet.net>
In-Reply-To: <54E7F813.8010201@andyet.net>
X-Forwarded-Message-Id: <54E7F813.8010201@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/fIfqXfmoIrmCbrfckflZ6yNJeNk>
Subject: [urn] Fwd: Re: request for assignment of informal urn
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: Sat, 21 Feb 2015 03:16:27 -0000

Of interest from the urn-nid list...


-------- Forwarded Message --------
Subject: Re: request for assignment of informal urn
Date: Fri, 20 Feb 2015 20:14:27 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
To: yoshiki.sameshima.vf@hitachi-solutions.com
CC: tomohiro.misawa.rf@hitachi-solutions.com, 
takanobu.hosoe.ju@hitachi-solutions.com, urn-nid@apps.ietf.org

On 2/18/15 2:59 AM, yoshiki.sameshima.vf@hitachi-solutions.com wrote:
> Peter,
>
>> I'm confused. Why do we need a new URN namespace, given that we already
>> have a URN namespace for UUIDs and a URN namespace for ISBNs?
>
> URN is a kind of URI, and it can contain a fragment syntactically.

Are you aware that we are updating the core definition of URNs to allow
this in a more official way? See here:

https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

(RFC 2141 does not really allow this.)

> But the rfc of urn:uuid (RFC 4122) does not describe the semantics of a fragment.
> The same is true in the rfc of urn:isbn (RFC 3187).

I think the right approach is to update those specifications.

> We also want to include an epub file name as well as an EPUBCFI fragment.

Can you show us some examples of this usage?

> This is the reason why we submit the request of our informal urn specification
> describing semantics and syntax of epub file name and EPUBCFI fragment.

Trying to squeeze new definitions of urn:uuid and urn:isbn into an
informal namespace feels like the wrong way to do things.

Peter

>
> Best regards,
> Yoshiki Sameshima
>
>
>> On 2/9/15 2:22 AM, yoshiki.sameshima.vf@hitachi-solutions.com wrote:
>>> Dear URN NID members,
>>>
>>> This is a request for assignment of informal urn.
>>>
>>> The following is a URN Namespace Definition according to the template
>>> described in RFC 3406.
>>>
>>> Please send comments to addresses in the cc field.
>>>
>>> Best regards,
>>>
>>> Yoshiki Sameshima, Hitachi Solutions
>>>
>>>
>>> ---------------- URN Namespace Definition ----------------
>>>
>>> I. Namespace ID
>>>
>>> To be assigned.
>>>
>>>
>>> 2. Registration Information
>>>
>>> Version 1
>>> Date: 2015-02-09
>>>
>>>
>>> 3. Declared registrant of the namespace
>>>
>>> Name:		Yoshiki SAMESHIMA
>>> 		Takanobu HOSOE
>>> 		Tomohiro MISAWA
>>> Affiliation:	Hitachi Solutions, Ltd.
>>> Address:	4-12-7 Higashi-Shinagawa Shinagawa-ku, Tokyo 140-0002 Japan
>>> Contact:	Yoshiki Sameshima
>>> 		yoshiki (dot) sameshima (dot) vf (at) hitachi-solutions (dot) com
>>>
>>>
>>> 4. Declaration of structure
>>>
>>> The identifier structure is as follows:
>>>
>>> NEW-URN	= "urn:" ASSIGNED-SCHEME ":" ( CoNETS-EPUB-UUID / CoNETS-EPUB-ISBN )
>>>
>>> ; There are two types of the new scheme.
>>>
>>>
>>> ;;;
>>> ;;; First type: CoNETS EPUB UUID
>>> ;;;
>>>
>>> CoNETS-EPUB-UUID = "conets-epub-uuid:" UUID *( "/" FILE ) [ "#" EPUBCFI ]
>>> UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))
>>> FILE = PCHAR *PCHAR
>>>
>>> ; The first type is a combination of UUID, optionally file name and EPUBCFI.
>>> ; A bulky book or a series of books may have a single UUID, but it may consist
>>> ; of multiple epub publication files. In this case the epub file name is
>>> ; included in the URN.
>>> ; A piece of content or any location in an epub publication file is identified
>>> ; with EPUBCFI, which is a fragment identifier for epub publication, such as
>>> ; chapter, image, page, etc. EPUBCFI is specified in EPUB Canonical Fragment
>>> ; Identifier Specification. See Sec. 5.
>>> ; PCHAR is the same as RFC 3986 or its successors.
>>>
>>>
>>> ;;;
>>> ;;; Second type: CoNETS EPUB ISBN
>>> ;;;
>>>
>>> CoNETS-EPUB-ISBN = "conets-epub-isbn:" ISBN *( "/" FILE ) [ "#" EPUBCFI ]
>>> ISBN = 1*(DIGIT / ALPHA) 0*("-" 1*(DIGIT / ALPHA))
>>>
>>> ; The second type is as the same as CoNETS-EPUB-UUID except that ISBN is used
>>> ; instead of UUID. ISBN in URN can be found in RFC 3187
>>> ; 'Using International Standard Book Numbers as Uniform Resource Names.'
>>>
>>>
>>> 5. Relevant ancillary documentation
>>>
>>> Definition of EPUBCFI can be found in:
>>>       International Digital Publishing Forum,
>>>       EPUB Canonical Fragment Identifier (epubcfi) Specification
>>>       http://www.idpf.org/epub/linking/cfi/epub-cfi.html
>>>
>>>
>>> 6. Identifier uniqueness considerations
>>>
>>> The URN consists of epub publication identifier (UUID or ISBN), optionally an epub
>>> publication file and a fragment that identifies content or location in the epub
>>> file. That is, the URN points some part in the epub publication, and reassignment
>>> of the URN cannot happen.
>>>
>>>
>>> 7. Identifier persistence considerations
>>>
>>> Each time the publication is revised, the UUID/ISBN is changed, and a URN will
>>> persist in identifying a particular publication even after its lifetime.
>>>
>>> As for usability of the identifier, identifier resolution is processed locally
>>> in this version as described in Section 9, and the usability is assured as long as
>>> the publication is stored locally. Future versions of this specification may
>>> specify global repository and persistence of usability of the URN identifier.
>>>
>>>
>>> 8. Process of identifier assignment
>>>
>>> UUID is 128 bits long, and requires no central registration process. The generation
>>> process described in RFC 4122 will give a unique identifier from all other UUIDs
>>> that have been or will be assigned. ISBN is assigned from the International ISBN
>>> Agency. As for the other part of the identifier, FILE and EPUBCFI, the assignment
>>> is open.
>>
>> I'm confused. Why do we need a new URN namespace, given that we already
>> have a URN namespace for UUIDs and a URN namespace for ISBNs?
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://andyet.com/
>>



-- 
Peter Saint-Andre
https://andyet.com/



From nobody Fri Feb 20 19:35:50 2015
Return-Path: <peter@andyet.net>
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 914C11A1A6C for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 19:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 4heicgwiULgi for <urn@ietfa.amsl.com>; Fri, 20 Feb 2015 19:35:47 -0800 (PST)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 5CA331A1A6B for <urn@ietf.org>; Fri, 20 Feb 2015 19:35:47 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id hn18so7593125igb.2 for <urn@ietf.org>; Fri, 20 Feb 2015 19:35:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SIoi5YAK1aHYtGh+yZctHqu//iFpPdW8wfbscbllI+k=; b=lKt6WYzAbdyimhsYhfLlSy7WPo8lHE9kuVcRMesiu5RPp7CIo8/IOv0IdIjB4yc1+D vzND7JOQ+2sm72R8SiBB/bkmpoSBHjKhKLPrldXlOJuegw8+fjH3ej6Pzv9ePPZVUSdg 9lU5wnP1QX1C+quTheGz+GJ8RyEjwBdfZOamVOj+7v300ExuJ5Ai7vq5Atn9tt6Jkr3O 1TcBLBUGOyk+HZVHBEx9e5Q7pvEaQ8NOtFPotnFoWye+QdIUZprt3RVm9vHKHro7Seny Z56RN50Vc0OtBeUKkv1kQNAJ7ZzK9n1+b1JSbn5Ly+rW9L2czdM4NfELL2ZT6nHX4Ttj VnPA==
X-Gm-Message-State: ALoCoQnKxRibJkM2Tc8ZpMLP2CiX3qK5BXaIY6v6+MlBkl/LuEB7wZZe/KeiEzClK6ffpSXHtZbo
X-Received: by 10.50.43.162 with SMTP id x2mr653779igl.46.1424489746726; Fri, 20 Feb 2015 19:35:46 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id tg4sm2171399igb.4.2015.02.20.19.35.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 19:35:46 -0800 (PST)
Message-ID: <54E7FD11.8090303@andyet.net>
Date: Fri, 20 Feb 2015 20:35:45 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <F50740CEF6CEA4D4522F4F9B@JcK-HP8200.jck.com>
In-Reply-To: <F50740CEF6CEA4D4522F4F9B@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/F8HK7-9mHtX9DEHlhtbpK3MGCTg>
Subject: Re: [urn] The namespace registration trainsition draft, version 04
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: Sat, 21 Feb 2015 03:35:49 -0000

On 2/16/15 2:58 PM, John C Klensin wrote:
> Hi.
>
> As the last of this round of document postings, I've just
> submitted draft-ietf-urnbis-ns-reg-transition.

Hi John & Juha,

Thanks again for writing this document.

> For those familiar with prior versions, there are really no
> substantive changes.  The major ones reflect the transition from
> a separate 3406bis to the consolidated 2141bis.  So it is
> probably reasonable to look at a diff.

Given that it's been a while since I first review the document, I've 
decided to read it again. Here are a few small comments.

First, I sense a small ambiguity in the Introduction:

    Those
    potential problems included the possibility of the same name being
    used to identify different namespaces with different rules.

I tripped slightly over the word "name" given that we're talking about 
Uniform Resource Names. Perhaps "string" or "namespace identifier" would 
be better than "name" here.

> I have also made a number of editorial changes that, I hope,
> will make the document somewhat more precise.
>
> In addition to a general review of the draft, WG participants
> should note that the placeholder "[[CREF3" in Section 2
> effectively asks a substantive question about whether there is
> content in the now-expired draft-ietf-urnbis-rfc3187bis-isbn-urn
> and draft-ietf-urnbis-rfc3044bis-issn-urn that needs to be moved
> into either this documents or 2141bis.  If such content is not
> identified soon, we will assume the answer is "no" and will
> remove the placeholder.

Although I have not yet looked at those expired I-Ds in detail (they are 
rather long), I trust Juha to do the right thing about the information 
contained in them.

> The immediately-following "[[CREF4" ask a similar question about
> other registered namespaces that might need specific transition
> information.  Again, if there are such issues, please comment
> soon or the placeholder will simply be removed.

My feeling is that it would be best to focus this document on ISBN and 
ISSN only. I also doubt that we have the energy here to complete a 
review of all the registered namespaces. However, I would be happy to 
glance at them to see if any need special attention.

Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Sat Feb 21 04:31:37 2015
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 9F99F1A6FEB for <urn@ietfa.amsl.com>; Sat, 21 Feb 2015 04:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.701
X-Spam-Level: *
X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_34=0.6] autolearn=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 1Cd_V6sDA6FW for <urn@ietfa.amsl.com>; Sat, 21 Feb 2015 04:31:33 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1201A6F7C for <urn@ietf.org>; Sat, 21 Feb 2015 04:31:32 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=P5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YP9DX-00009S-7j; Sat, 21 Feb 2015 07:31:31 -0500
Date: Sat, 21 Feb 2015 07:31:25 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
Message-ID: <CD751045E4CA043D443B802E@P5>
In-Reply-To: <54E7F885.4000304@andyet.net>
References: <54E7F813.8010201@andyet.net> <54E7F885.4000304@andyet.net>
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
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/9CZIVQZdENLZfMERCsI2Tj3M-P8>
Subject: Re: [urn] Fwd: Re: request for assignment of informal urn
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: Sat, 21 Feb 2015 12:31:35 -0000

Peter,

You are too kind.  The proposed registration is simply invalid
until after 2141bis is approved because it contains invalid
syntax.  On the other hand, we should probably try to understand
it better and try to draw the authors into the WG because:

(1) This appears to use a p-component, which I think some people
here are convinced is unnecessary.

(2) It is possible that 2141bis is in need of some language
advising against creating new URNs (even informal ones) that
appear to incorporate namespaces from existing ones without at
least consulting with the managers of those prior namespaces.
This seems particularly relevant because of potential
ambiguities in what the p-component actually means.  I don't
think they should be prevented from doing such a registration,
but being given an opportunity to understand its implications
seems useful. 

(3) Finally, if I correctly understand their ABNF, they would
end up with, e.g.,

  urn:urn-NNNN:conets-epub-isbn:X-XXX-XXXXX-X/FOO/BAR

It would seem to me that their identifying string is either
unneeded or excessive because it would be possible to either
create two informal URNs, each reflecting one of the underlying
identifiers, and get rid of the extra string or to create a
single informal URN for Hitachi-related epubs, and then make the
sub-namespaces (yeech) extensible beyond these two without
having to come back to the URN-NID list or whatever replaces it.


Again, it seems to me that it would be desirable to at least be
sure they understand those alternatives.

And we really need to get on with the work of this WG.  I take
this application as a further sign of the need for it.

   john


--On Friday, 20 February, 2015 20:16 -0700 Peter Saint-Andre -
&yet <peter@andyet.net> wrote:

> Of interest from the urn-nid list...
> 
> 
> -------- Forwarded Message --------
> Subject: Re: request for assignment of informal urn
> Date: Fri, 20 Feb 2015 20:14:27 -0700
> From: Peter Saint-Andre - &yet <peter@andyet.net>
> To: yoshiki.sameshima.vf@hitachi-solutions.com
> CC: tomohiro.misawa.rf@hitachi-solutions.com,
> takanobu.hosoe.ju@hitachi-solutions.com, urn-nid@apps.ietf.org
> 
> On 2/18/15 2:59 AM, yoshiki.sameshima.vf@hitachi-solutions.com
> wrote:
>> Peter,
>> 
>>> I'm confused. Why do we need a new URN namespace, given that
>>> we already have a URN namespace for UUIDs and a URN
>>> namespace for ISBNs?
>> 
>> URN is a kind of URI, and it can contain a fragment
>> syntactically.
> 
> Are you aware that we are updating the core definition of URNs
> to allow
> this in a more official way? See here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-
> urn/
> 
> (RFC 2141 does not really allow this.)
> 
>> But the rfc of urn:uuid (RFC 4122) does not describe the
>> semantics of a fragment. The same is true in the rfc of
>> urn:isbn (RFC 3187).
> 
> I think the right approach is to update those specifications.
> 
>> We also want to include an epub file name as well as an
>> EPUBCFI fragment.
> 
> Can you show us some examples of this usage?
> 
>> This is the reason why we submit the request of our informal
>> urn specification describing semantics and syntax of epub
>> file name and EPUBCFI fragment.
> 
> Trying to squeeze new definitions of urn:uuid and urn:isbn
> into an
> informal namespace feels like the wrong way to do things.
> 
> Peter
> 
>> 
>> Best regards,
>> Yoshiki Sameshima
>> 
>> 
>>> On 2/9/15 2:22 AM,
>>> yoshiki.sameshima.vf@hitachi-solutions.com wrote:
>>>> Dear URN NID members,
>>>> 
>>>> This is a request for assignment of informal urn.
>>>> 
>>>> The following is a URN Namespace Definition according to
>>>> the template described in RFC 3406.
>>>> 
>>>> Please send comments to addresses in the cc field.
>>>> 
>>>> Best regards,
>>>> 
>>>> Yoshiki Sameshima, Hitachi Solutions
>>>> 
>>>> 
>>>> ---------------- URN Namespace Definition ----------------
>>>> 
>>>> I. Namespace ID
>>>> 
>>>> To be assigned.
>>>> 
>>>> 
>>>> 2. Registration Information
>>>> 
>>>> Version 1
>>>> Date: 2015-02-09
>>>> 
>>>> 
>>>> 3. Declared registrant of the namespace
>>>> 
>>>> Name:		Yoshiki SAMESHIMA
>>>> 		Takanobu HOSOE
>>>> 		Tomohiro MISAWA
>>>> Affiliation:	Hitachi Solutions, Ltd.
>>>> Address:	4-12-7 Higashi-Shinagawa Shinagawa-ku, Tokyo
>>>> 140-0002 Japan Contact:	Yoshiki Sameshima
>>>> 		yoshiki (dot) sameshima (dot) vf (at) hitachi-solutions
>>>> 		(dot) com
>>>> 
>>>> 
>>>> 4. Declaration of structure
>>>> 
>>>> The identifier structure is as follows:
>>>> 
>>>> NEW-URN	= "urn:" ASSIGNED-SCHEME ":" ( CoNETS-EPUB-UUID /
>>>> CoNETS-EPUB-ISBN )
>>>> 
>>>> ; There are two types of the new scheme.
>>>> 
>>>> 
>>>> ;;;
>>>> ;;; First type: CoNETS EPUB UUID
>>>> ;;;
>>>> 
>>>> CoNETS-EPUB-UUID = "conets-epub-uuid:" UUID *( "/" FILE ) [
>>>> "#" EPUBCFI ] UUID = 1*(HEXDIGIT) 0*( "-" 1*(HEXDIGIT))
>>>> FILE = PCHAR *PCHAR
>>>> 
>>>> ; The first type is a combination of UUID, optionally file
>>>> name and EPUBCFI. ; A bulky book or a series of books may
>>>> have a single UUID, but it may consist ; of multiple epub
>>>> publication files. In this case the epub file name is ;
>>>> included in the URN.
>>>> ; A piece of content or any location in an epub publication
>>>> file is identified ; with EPUBCFI, which is a fragment
>>>> identifier for epub publication, such as ; chapter, image,
>>>> page, etc. EPUBCFI is specified in EPUB Canonical Fragment
>>>> ; Identifier Specification. See Sec. 5.
>>>> ; PCHAR is the same as RFC 3986 or its successors.
>>>> 
>>>> 
>>>> ;;;
>>>> ;;; Second type: CoNETS EPUB ISBN
>>>> ;;;
>>>> 
>>>> CoNETS-EPUB-ISBN = "conets-epub-isbn:" ISBN *( "/" FILE ) [
>>>> "#" EPUBCFI ] ISBN = 1*(DIGIT / ALPHA) 0*("-" 1*(DIGIT /
>>>> ALPHA))
>>>> 
>>>> ; The second type is as the same as CoNETS-EPUB-UUID except
>>>> that ISBN is used ; instead of UUID. ISBN in URN can be
>>>> found in RFC 3187 ; 'Using International Standard Book
>>>> Numbers as Uniform Resource Names.'
>>>> 
>>>> 
>>>> 5. Relevant ancillary documentation
>>>> 
>>>> Definition of EPUBCFI can be found in:
>>>>       International Digital Publishing Forum,
>>>>       EPUB Canonical Fragment Identifier (epubcfi)
>>>>       Specification
>>>>       http://www.idpf.org/epub/linking/cfi/epub-cfi.html
>>>> 
>>>> 
>>>> 6. Identifier uniqueness considerations
>>>> 
>>>> The URN consists of epub publication identifier (UUID or
>>>> ISBN), optionally an epub publication file and a fragment
>>>> that identifies content or location in the epub file. That
>>>> is, the URN points some part in the epub publication, and
>>>> reassignment of the URN cannot happen.
>>>> 
>>>> 
>>>> 7. Identifier persistence considerations
>>>> 
>>>> Each time the publication is revised, the UUID/ISBN is
>>>> changed, and a URN will persist in identifying a particular
>>>> publication even after its lifetime.
>>>> 
>>>> As for usability of the identifier, identifier resolution
>>>> is processed locally in this version as described in
>>>> Section 9, and the usability is assured as long as the
>>>> publication is stored locally. Future versions of this
>>>> specification may specify global repository and persistence
>>>> of usability of the URN identifier.
>>>> 
>>>> 
>>>> 8. Process of identifier assignment
>>>> 
>>>> UUID is 128 bits long, and requires no central registration
>>>> process. The generation process described in RFC 4122 will
>>>> give a unique identifier from all other UUIDs that have
>>>> been or will be assigned. ISBN is assigned from the
>>>> International ISBN Agency. As for the other part of the
>>>> identifier, FILE and EPUBCFI, the assignment is open.
>>> 
>>> I'm confused. Why do we need a new URN namespace, given that
>>> we already have a URN namespace for UUIDs and a URN
>>> namespace for ISBNs?
>>> 
>>> Peter
>>> 
>>> --
>>> Peter Saint-Andre
>>> https://andyet.com/





From nobody Sat Feb 21 05:24:10 2015
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 98CA41A1A2E for <urn@ietfa.amsl.com>; Sat, 21 Feb 2015 05:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=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 wYAtEVkZ_yvJ for <urn@ietfa.amsl.com>; Sat, 21 Feb 2015 05:24:07 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ABD1A19F6 for <urn@ietf.org>; Sat, 21 Feb 2015 05:24:07 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=P5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YPA2O-0000Ch-KE; Sat, 21 Feb 2015 08:24:04 -0500
Date: Sat, 21 Feb 2015 08:23:59 -0500
From: John C Klensin <john-ietf@jck.com>
To: Graham Klyne <gk@ninebynine.org>, urn@ietf.org
Message-ID: <C4F18152B469A8DFC201EAA2@P5>
In-Reply-To: <54E70CEE.8030203@ninebynine.org>
References: <54E70CEE.8030203@ninebynine.org>
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
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/W_2TYnrbaJdB45hClcaqOHjf7V8>
Cc: Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] [apps-discuss] URN "semantics clarification", aka "syntax only" draft
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: Sat, 21 Feb 2015 13:24:09 -0000

--On Friday, 20 February, 2015 10:31 +0000 Graham Klyne
<gk@ninebynine.org> wrote:

> Hi John, all,
> 
> (bcc: apps-discuss@ietf.org)
> 
> I've just taken a skim of
> http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-
> 01, and I think the intent is fine but have a couple of
> questions or points of clarification.
> 
> My main concern is that URNs should be considered to be a kind
> of URI, and should be consistently usable in all contexts
> where a URI is usable (though, clearly, use in a context that
> requires dereferencing would be undefined in the same way as
> use of an unknown URI scheme would be).  Failure to satisfy
> this constraint would, IMO, force a bifurcation between URIs
> and URNs, which is something you say you want to avoid.
>...

Graham,

Independent of my personal opinions, 2141bis already contains
very explicit text allowing relative resolution (Section 5,
paragraph 2 of draft-ietf-urnbis-rfc2141bis-urn-09).  Do you
think that text needs to be repeated in
"draft-ietf-urnbis-semantics-clarif and, if so,

(i) Why?
(ii) Could you please propose text and where to put it?

> (FWIW, I also happen to find that
> relative references are useful in naming contexts as well as
> retrieval contexts.)

You might also want to suggest some text for 2141bis (or for the
various "revise 3986" efforts that are far out of scope for this
WG) that explains how the base reference from which relative
references are to be expanded is reliably obtained for URNs.  If
may be that I've just gotten bleary-eyed trying to read it, but
I see nothing in 3986 that defines using a URI from one scheme
to provide a base for a relative URI from another.

> Jumping to section 4, which appears to be the substantive part
> of this document, the main change I am seeing is a change of
> terminology from "path", "query" and "fragment" to
> "p-component", "q-component" and "f-component".  I take this
> to be a distancing of these elements in URNs from some
> commonly used conventions used with location-based URIs (aka
> URLs).  To the extent that this helps to reduce confusion,
> this seems fine to me (thought I also think it's an open
> question as to whether new terminology does reduce confusion).

That text was inserted for consistency with 2141bis.  It seems
to me that is the document you should be reading (and fairly
carefully, rather than skimming).

> ...
> You claim:
> 
> "In particular, the Generic URI Syntax specification goes
> beyond
>     syntax to specify the meaning and interpretation of
> various fields,
>     especially the "query" and "fragment" ones and the various
> syntax
>     forms and interpretations it allows for <hier-part>. "
 
> I disagree with this characterization with respect to "query"
> elements ("The query component contains non-hierarchical data
> that, along with data in the path component (Section 3.3),
> serves to identify a resource within the scope of the URI's
> scheme and naming authority (if any)." --
> http://tools.ietf.org/html/rfc3986#section-3.4), though I
> accept it's commonly used to invoke dynamic search type
> operations.

I believe this is another element of the discussion about what
3986 { requires | says | implies | can be interpreted to say |
is read by some as saying }.  I think that making progress in
this WG involves getting past those discussions (moving them
into a forum where changes or interpretations of 3986 are
discussed) and I believe that is consistent with Andy's
consensus call on the separation of syntax from semantics. 

FWIW, because of the way the syntax is specified, part of what
causes the interpretations with which you disagree is the term
"non-hierarchical".  If that is a constraint on syntax, I can't
find it in 3986, especially its ABNF.   If it is a semantic
constraint, I don't see any reason why it should apply _as a
requirement_ to URNs that use q-components.

If you believe the text in draft-ietf-urnbis-rfc2141bis-urn-09
would be improved by saying something like "some have
interpreted the Generic URI Syntax specification as going beyond
syntax...", I'd be happy to make the change if others agree and
it would help get us unstuck.  If you think other changes are in
order, please suggest text rather than simply expressing
disagreement.

> For fragments, I accept that for a URN, where there is no
> dereferencing, the dependence on media type is difficult.  RDF
> [http://www.w3.org/TR/rdf11-concepts/] addresses this by
> simply treating the fragment as part of the overall name
> string, without further interpretation.

I believe RDF is out of scope for this WG, but I personally
believe that is non-conformant with fairly clear language in
3986.  Again, to the extent that interpretation is correct, it
is an issue between RDF and 3986 and relates to this WG only as
evidence that other schemes are finding 3986's specifications
unreasonably restrictive.   It is perhaps worth noting that this
WG went down the "if parts of 3986 seem inapplicable or
excessively constraining, just ignore them and specify something
else" years ago.  It was forced out of that position by people
complaining that various things that people wanted to do with/in
URNs were impossible because they were inconsistent with 3986,
starting the path that led to the "syntax only" approach.

> It then becomes an application design/implementation issue to
> avoid use of fragments of retrieved entities in ways that
> conflict with their use in names (cf.
> http://www.w3.org/TR/webarch/#fragid,
> http://www.w3.org/TR/webarch/#media-type-fragid).  In
> partyicular: "If no such representation exists, then the
> semantics of the fragment are considered unknown and,
> effectively, unconstrained." [ibid]

I look forward to the I-D, and perhaps a WG, that establishes
the Webarch work as superceding, or as a formal clarification
to, 3986.

> For paths, it's not clear to me whether you consider the
> relative resolution algorithm of RFC3986 to be part of the
> path semantics.  Per my comments above, I would be very
> concerned if you try to say that the resolution algorithm is
> not applicable to URNs, as that would mean that an application
> needs to know if its dealing with a URN or URI when performing
> otherwise scheme-independent processing.

See above.
 
> ...
> 
> In summary, assuming that you do not intend to exclude
> relative resolution from URN handling, the documents appears
> to me to be a "null specification", in that it does not
> actually exclude anything that is required by RFC3986.  I
> don't mean that its not useful - I think there are issues here
> that are usefully articulated and explained, but in the final
> analysis these clarifications should apply to *any* URI scheme
> used as a name rather than a locator.

See above.

> And URI schemes are always allowed to layer their own
> semantics on top of RFC3986, so again the notion "removes URN
> semantics from the scope of RFC 3896" isn't really saying
> anything new that I can see.
> 
> So I think section 4 would more usefully be titled
> "Clarifications to RFC3986 as applied to URNs".

But some people with different interpretations of 3986 than you
(or I, see below) have claimed that we could not couch things as
clarifications because they contracted 3986.

Again, FWIW, the position you describe in the two paragraphs
quoted above is exactly where I, personally, started and, to a
considerable extent, still am.   I believe that this
clarification draft should never have been needed and that the
year or 18 months the WG spent getting to it was a waste of
time.  Were I inclined toward conspiracy theories, I might even
suggest that the causes of our having to spend time on this lie
in theories that URNs (as distinct from assorted locators and
abstractions of locators) are fundamentally unnecessary and
undesirable and that the WG has, so far, survived efforts to
have it die the death of a thousand cuts (or ten thousand picked
nits).  But we are where were are and some formal clarification
of interpretation of and separation from the semantics (whether
examples, recommendations, or requirements) of 3986 seems to be
in order.

If my frustration with all of this and the time it has taken up
already is coming through, I apologize.

> By way of (partial) background to these comments, I'm
> currently working on a tool for small-scale research data
> management for which these are very real issues
> [https://github.com/gklyne/annalist].  I use URIs as both
> names and as locators, depending on context (not on the form
> of URI used).  Goals of my work include facilitation of data
> sharing, and provision of a path for data on researchers'
> desktops to library-managed data repositories - so both
> location and naming issues come in to play.

Good luck.

Please read 2141bis. 
  
    john



From nobody Mon Feb 23 02:17:57 2015
Return-Path: <ht@inf.ed.ac.uk>
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 0A2B11A0A85 for <urn@ietfa.amsl.com>; Mon, 23 Feb 2015 02:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8tfqeimQCTz0 for <urn@ietfa.amsl.com>; Mon, 23 Feb 2015 02:17:53 -0800 (PST)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 106991A07BE for <urn@ietf.org>; Mon, 23 Feb 2015 02:17:52 -0800 (PST)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t1NAHTun004913;  Mon, 23 Feb 2015 10:17:35 GMT
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t1NAHTM6012028; Mon, 23 Feb 2015 10:17:29 GMT
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t1NAHSY2018753; Mon, 23 Feb 2015 10:17:28 GMT
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t1NAHRaS018749; Mon, 23 Feb 2015 10:17:27 GMT
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <54E70CEE.8030203@ninebynine.org> <C4F18152B469A8DFC201EAA2@P5>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Mon, 23 Feb 2015 10:17:27 +0000
Message-ID: <f5by4npaq4o.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/tj7Zfb9Ub7BCaCq0IXeMTMDyZvE>
Cc: urn@ietf.org, Graham Klyne <gk@ninebynine.org>, Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] [apps-discuss] URN "semantics clarification", aka "syntax only" draft
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: Mon, 23 Feb 2015 10:17:56 -0000

John C Klensin writes:

> --On Friday, 20 February, 2015 10:31 +0000 Graham Klyne
> <gk@ninebynine.org> wrote:
> ...
>> (FWIW, I also happen to find that
>> relative references are useful in naming contexts as well as
>> retrieval contexts.)
>
> You might also want to suggest some text for 2141bis (or for the
> various "revise 3986" efforts that are far out of scope for this
> WG) that explains how the base reference from which relative
> references are to be expanded is reliably obtained for URNs.  If
> may be that I've just gotten bleary-eyed trying to read it, but
> I see nothing in 3986 that defines using a URI from one scheme
> to provide a base for a relative URI from another.

Point of clarification?  "a relative URI from another [scheme]"?  Not
sure what you mean here.  There are, IIUC, three strings involved in
"reference resolution", as defined in 3986 [1].  Only two of these are
(usually/necessarily) URIs:

 1) The base URI;
 2) A string which is to be resolved against (1);
 3) The result URI.

None of these is "a relative URI".  There is no production in the
spec. named ...relative-URI. 3986 [2] calls it a "relative reference".
Having said that, I too often use the phrase "relative URI", to mean
(2), but it's actually not sanctioned by the spec., and often gets us
in to trouble.

If (2) begins with a scheme, the result just _is_ (2) (see the
pseudo-code for reference resolution in 3986 [3]); If (2) does not
begin with a scheme, it's not "from another scheme".

So in neither case can I see what you're looking for and not
finding. . .  Please clarify (an example would probably help).

ht

[1] https://tools.ietf.org/html/rfc3986#section-5
[2] https://tools.ietf.org/html/rfc3986#section-4
[3] https://tools.ietf.org/html/rfc3986#section-5.2.2
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]


From nobody Mon Feb 23 03:17:00 2015
Return-Path: <gk@ninebynine.org>
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 88F931A1A27 for <urn@ietfa.amsl.com>; Mon, 23 Feb 2015 03:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 uxWFIQd9Urs7 for <urn@ietfa.amsl.com>; Mon, 23 Feb 2015 03:16:57 -0800 (PST)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 800341A1A1F for <urn@ietf.org>; Mon, 23 Feb 2015 03:16:56 -0800 (PST)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YPr0Q-0008C1-n9; Mon, 23 Feb 2015 11:16:54 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1YPr0P-0002RY-G6; Mon, 23 Feb 2015 11:16:54 +0000
Message-ID: <54EB0C27.9050709@ninebynine.org>
Date: Mon, 23 Feb 2015 11:16:55 +0000
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, John C Klensin <john-ietf@jck.com>
References: <54E70CEE.8030203@ninebynine.org> <C4F18152B469A8DFC201EAA2@P5> <f5by4npaq4o.fsf@troutbeck.inf.ed.ac.uk>
In-Reply-To: <f5by4npaq4o.fsf@troutbeck.inf.ed.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/fN_ypSMKzKGdkCAHNYAFq77cdxQ>
Cc: urn@ietf.org, Graham Klyne <graham.klyne@oerc.ox.ac.uk>
Subject: Re: [urn] [apps-discuss] URN "semantics clarification", aka "syntax only" draft
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: Mon, 23 Feb 2015 11:16:59 -0000

Oops, good catch!  I missed the "from another" when making my previous response. :(

RFC3986 mentions a non-recommended extension for interpreting relative 
references with scheme names:

[[
Some parsers allow the scheme name to be present in a relative
    reference if it is the same as the base URI scheme.  This is
    considered to be a loophole in prior specifications of partial URI
    [RFC1630].  Its use should be avoided but is allowed for backward
    compatibility.
]]
-- https://tools.ietf.org/html/rfc3986#section-5.4.2

But even here, the schemes must be the same, so there's no issue of the relative 
resolution going across schemes.


<aside>
This is noted as an issue from earlier specs.  It seems to me that the URN 
effort has been going, off-and-on, for a long time.  I suspect that many of the 
misunderstandings attributed to RFC3906 may actually be hang-overs from previous 
versions of the spec.  A key role for RFC 3986 was to clean up a number of these 
complicating issues from earlier versions of the spec (in part by drawing back 
on specifying semantics of URIs and focusing on the syntax?).
</aside>

#g
--


On 23/02/2015 10:17, Henry S. Thompson wrote:
> John C Klensin writes:
>
>> --On Friday, 20 February, 2015 10:31 +0000 Graham Klyne
>> <gk@ninebynine.org> wrote:
>> ...
>>> (FWIW, I also happen to find that
>>> relative references are useful in naming contexts as well as
>>> retrieval contexts.)
>>
>> You might also want to suggest some text for 2141bis (or for the
>> various "revise 3986" efforts that are far out of scope for this
>> WG) that explains how the base reference from which relative
>> references are to be expanded is reliably obtained for URNs.  If
>> may be that I've just gotten bleary-eyed trying to read it, but
>> I see nothing in 3986 that defines using a URI from one scheme
>> to provide a base for a relative URI from another.
>
> Point of clarification?  "a relative URI from another [scheme]"?  Not
> sure what you mean here.  There are, IIUC, three strings involved in
> "reference resolution", as defined in 3986 [1].  Only two of these are
> (usually/necessarily) URIs:
>
>   1) The base URI;
>   2) A string which is to be resolved against (1);
>   3) The result URI.
>
> None of these is "a relative URI".  There is no production in the
> spec. named ...relative-URI. 3986 [2] calls it a "relative reference".
> Having said that, I too often use the phrase "relative URI", to mean
> (2), but it's actually not sanctioned by the spec., and often gets us
> in to trouble.
>
> If (2) begins with a scheme, the result just _is_ (2) (see the
> pseudo-code for reference resolution in 3986 [3]); If (2) does not
> begin with a scheme, it's not "from another scheme".
>
> So in neither case can I see what you're looking for and not
> finding. . .  Please clarify (an example would probably help).
>
> ht
>
> [1] https://tools.ietf.org/html/rfc3986#section-5
> [2] https://tools.ietf.org/html/rfc3986#section-4
> [3] https://tools.ietf.org/html/rfc3986#section-5.2.2
>


From nobody Tue Feb 24 18:46:45 2015
Return-Path: <melinda.shore@gmail.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 A478E1A88DB for <urn@ietfa.amsl.com>; Tue, 24 Feb 2015 18:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 PxXkRY3QChQf for <urn@ietfa.amsl.com>; Tue, 24 Feb 2015 18:46:42 -0800 (PST)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 6DB5D1A00DC for <urn@ietf.org>; Tue, 24 Feb 2015 18:46:42 -0800 (PST)
Received: by pdbfp1 with SMTP id fp1so1432269pdb.5 for <urn@ietf.org>; Tue, 24 Feb 2015 18:46:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=yLH49DLso+/ToIOJJ1z5rE7IoFCevMjJZ1R0GKPNEiI=; b=zZjXnmF7KMSzdnUSEWGectdyp3XHqwc0rsrypM4UHk46qa6Noh3G9jUZbs/jbR/wQp VLL3ZU8nb6zXDxn0Y6DypVSGbQE1JRqq2JHtpQAhUhgDNFe90EuL6EpQOUGjGiRPBTzH k+KJQaniQ40aH7JcEnIUGfS426BxammyyxRcbMcz8GSCvFWsDEConfGqbO3JSA+/Lhp6 fIgCM0GInaWZlRpfQUwteZSdIGFN89HYnX6PoyNKGjvXeFIqBoDhWZ5kjSrsFGlt/eWX 1visjdYqQle9YG19iaZG/zCTj3QslHe5LvEuIa+jKVm2xCwXCh8Hph/2bPEj/5CKDc1b p2mw==
X-Received: by 10.70.123.70 with SMTP id ly6mr1603023pdb.154.1424832401673; Tue, 24 Feb 2015 18:46:41 -0800 (PST)
Received: from spandex.local (209-112-212-92-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.212.92]) by mx.google.com with ESMTPSA id qo4sm25849404pdb.71.2015.02.24.18.46.40 for <urn@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 18:46:41 -0800 (PST)
Message-ID: <54ED378F.70009@gmail.com>
Date: Tue, 24 Feb 2015 17:46:39 -0900
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/adtPRloMRMQSs8mG6I_xGtow-vc>
Subject: [urn] Moving 2141bis forward
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: Wed, 25 Feb 2015 02:46:43 -0000

Hi, all:

We absolutely must move 2141bis towards working group
last call and publication.  Discussion over the past few
weeks has not raised new issues, nor has it led to new
conclusions about past complaints.  Over the next week
or so we will be requesting early directorate review and
intend to have the draft in working group last call as
soon as the directorate reviews complete without picking
up major problems that need resolution.

Thanks,

Melinda and Andy


From nobody Tue Feb 24 19:08:37 2015
Return-Path: <peter@andyet.net>
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 4914D1A1A86 for <urn@ietfa.amsl.com>; Tue, 24 Feb 2015 19:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 vUbOuQE5T6e9 for <urn@ietfa.amsl.com>; Tue, 24 Feb 2015 19:08:34 -0800 (PST)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 3D2821A0545 for <urn@ietf.org>; Tue, 24 Feb 2015 19:08:34 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id hn18so32236392igb.2 for <urn@ietf.org>; Tue, 24 Feb 2015 19:08:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=klQTjsmDqGK9HzWbaz2YqwuL99DYTPM+0imETUkMnEw=; b=bw/9H503xWHiDU4CgU8nbui1nOpn5RaP+lr5wplv5/mFkRqPGvJWQiWX8vL7LplZeE pe8S+zBSaPu8zJo73aHrAxaDjb8vlyK69ujNEuCfPJ0hDwl9vFRi1DX3JffawHTQW4TY hpU+AKW/EcAuFlBArj+QYI4+TwdPpuDYOwFDN8r09DDdtLEjzBfZQ1g35WqYraA80pnl 0hj6wjEuEnsj8lgjzkddufOK46LVqZyfb/Ha7Dh0M7sivBVbs578FyQVfNtUJe6aBKOM JTtK49D+WVo43kFzniVqDC/2B1dhF3oNCcM+bdmyjnL0BwF3+ZNv3w7dq0oQ+L0WPrNg R2Cw==
X-Gm-Message-State: ALoCoQkypJPYO6ntmqeNJbQfdAw97ImPeJLh7RNR6iNGWc7SkzxDarSewyAopNyai9EWZUW/IDNQ
X-Received: by 10.107.46.230 with SMTP id u99mr1808077iou.21.1424833713351; Tue, 24 Feb 2015 19:08:33 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d6sm21514327iod.11.2015.02.24.19.08.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 19:08:32 -0800 (PST)
Message-ID: <54ED3CAD.2060206@andyet.net>
Date: Tue, 24 Feb 2015 20:08:29 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <E8B90C4A28D5329F74250588@JcK-HP8200.jck.com>
In-Reply-To: <E8B90C4A28D5329F74250588@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/1rSaJ6FgECn14wXXbKp2bw9UCZo>
Subject: Re: [urn] The "semantics clarification", aka "syntax only" draft
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: Wed, 25 Feb 2015 03:08:35 -0000

On 2/13/15 11:34 PM, John C Klensin wrote:
> Hi.
>
> As the list has been told by announcements from the tracker,
> I've just posted draft-ietf-urnbis-semantics-clarif-01.

I've reviewed this version and I think that it captures the reasoning 
behind the idea of syntax-only consistency with RFC 3986. I might have a 
few small editorial suggestions for the author and will send those under 
separate cover.

Peter