From nobody Fri May  1 07:10:48 2015
Return-Path: <ldaigle@thinkingcat.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 22D3C1B31F5 for <urn@ietfa.amsl.com>; Fri,  1 May 2015 07:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 QAwszuMpVGkM for <urn@ietfa.amsl.com>; Fri,  1 May 2015 07:10:47 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0723F1B31EA for <urn@ietf.org>; Fri,  1 May 2015 07:10:46 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 903DD318093; Fri,  1 May 2015 07:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=4BM5YvpihrSp4BK6vh+ZwfAtYLs=; b=MTd83xFyMyys enH2t6arJvw5uPPLBO3Tx/5XHgf31J80swFX98bcSif8GKmx7Gcc/ji+wi6BNN9K tvjH4DMhDStStn6bMSoaiOetRwvI7iGlPfU79q/emTuSxgEZPSZDeCMqbs6fK2eN I7ALF1ipqcES63jtz9FSsZ3f5chXokQ=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 2F9E631807C; Fri,  1 May 2015 07:10:46 -0700 (PDT)
Message-ID: <55438965.9020901@thinkingcat.com>
Date: Fri, 01 May 2015 10:10:45 -0400
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>,  "urn@ietf.org" <urn@ietf.org>
References: <55430DDE.5070104@network-heretics.com>
In-Reply-To: <55430DDE.5070104@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/4tEvIawbLuDqUhu8FiRViNXGuqg>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 01 May 2015 14:10:48 -0000

Not sure I'm entirely getting this right, but ISTM the proposed text 
would support:

1/ Me using urn:isbn:<blat>  in a local resolver in my house to resolve 
to items in my book collection.  (And teddy bears.  Because we know 
about ISBNs).

2/ Me standing up a completely independent URN resolution service for 
all registered URN namespaces and resolving them any way I choose -- 
i.e., not necessarily to the resources intended by the namespace creator 
and/or assigner.  And it's not clear to me how others would be able to 
determine the intended resolution service outcome.

I think "1/" isn't preventable, but shouldn't be promoted.  I think "2/" 
needs to be prevented to the extent possible.

RFC2276 is a pretty broad net.

Leslie.

On 5/1/15 1:23 AM, Keith Moore wrote:
> For reference, the current (-11) text of section 7.3.6:
>
> 7.3.6.  Resolution
>
>     The "Resolution" section MUST specify whether resolution mechanisms
>     are supported or anticipated for URNs assigned within the namespace,
>     and if so SHOULD specify or reference the rules governing those
>     mechanisms.
>
>     In particular, if resolution is anticipated and resolver registration
>     of some kind is required, for example via a Resolution Discovery
>     System [RFC2276], this section SHOULD list the requirements for
>     becoming a recognized resolver of URNs in the relevant namespace.
>
> I believe this section needs work for multiple reasons:
>
>   * resolution is, fundamentally, not a per-namespace operation. A
>     namespace can support a resolution service for URNs that it assigns
>     if it chooses to do so (and it will likely have high quality
>     information), but any other party can also provide a service to look
>     up URNs from any namespace.   Tying resolution services to any
>     specific party degrades the persistence of URNs, because a URN
>     should remain valid and potentially resolvable even if its namespace
>     (or the organization operating it) ceases to exist, or even if its
>     namespace imposes barriers to use of its resolution services.
>   * Rules for resolution should not be namespace-specific, because this
>     discourages general-purpose resolution services.   (A namespace can
>     of course recommend specific resolution services and/or specific
>     protocols for use with those services, but this section is worded as
>     if resolution itself were some sort of fundamentally
>     namespace-specific operation)
>
> Here's a stab at alternate text:
>
> 7.3.6. Resolution
>
>     The "Resolution" section is optional.  If included, it SHOULD
> specify whether the namespace intends to operate or recommend any
> resolution services for URNs using that namespace.   In addition, if the
> namespace intends to implement registration for publicly-advertised
> resolution services (for example using a system like that described in
> [RFC2276]) the Resolution section SHOULD list the requirements for being
> publicly-advertised using that mechanism.
>
> Note: The above is not intended to restrict URN resolution to services
> provided by or recommended by the namespace operator. In principle, any
> party may operate a resolution service for any set of URNs.
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>


From nobody Fri May  1 07:17:42 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 B59C11B320F for <urn@ietfa.amsl.com>; Fri,  1 May 2015 07:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JdWZWuX-fy9w for <urn@ietfa.amsl.com>; Fri,  1 May 2015 07:17:40 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F2D1B2A05 for <urn@ietf.org>; Fri,  1 May 2015 07:17:40 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 68AA6208FB for <urn@ietf.org>; Fri,  1 May 2015 10:17:39 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 01 May 2015 10:17:39 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=icFdENzPTMDYzLw yHj7uiZYWEZo=; b=NSnVGfv53iPWr+Od3uc+/mlp568fW8Ua1lAt0VHOVVGSQPb 7c/XOh71cDWtA7KvBjzi2DWFKSrrOlVB8aX4ws+KEuCQwf63uPPJ9HFLHYzRkQQ/ OipTM9s6OB0U9fdthirw2iKKDjp192NcUgwKP06lxfTXcr0YSy+ux6tEbwk0=
X-Sasl-enc: g27LUUkXsi+hx6rWkn+XWfNGNOJOgbmC/PLp3AO+7Dmy 1430489859
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EF9E680167; Fri,  1 May 2015 10:17:38 -0400 (EDT)
Message-ID: <55438AFF.7030906@network-heretics.com>
Date: Fri, 01 May 2015 10:17:35 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <55438965.9020901@thinkingcat.com>
In-Reply-To: <55438965.9020901@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/nSGCKC_jydf0Jx8zvOzuToo5IE8>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 01 May 2015 14:17:41 -0000

On 05/01/2015 10:10 AM, Leslie Daigle (ThinkingCat) wrote:
>
> Not sure I'm entirely getting this right, but ISTM the proposed text 
> would support:
>
> 1/ Me using urn:isbn:<blat>  in a local resolver in my house to 
> resolve to items in my book collection.  (And teddy bears. Because we 
> know about ISBNs).
>
> 2/ Me standing up a completely independent URN resolution service for 
> all registered URN namespaces and resolving them any way I choose -- 
> i.e., not necessarily to the resources intended by the namespace 
> creator and/or assigner.  And it's not clear to me how others would be 
> able to determine the intended resolution service outcome.
>
> I think "1/" isn't preventable, but shouldn't be promoted.  I think 
> "2/" needs to be prevented to the extent possible.
I disagree.  Anybody should be able to operate a URN resolution service 
for any reason that they choose.  In particular, it's completely 
reasonable for any library to allow its holdings to be looked up by URN, 
or for there to be resolution services that aggregate catalogs from 
several libraries.    It's also completely reasonable for any enterprise 
to operate a URN resolution service for its own holdings, including 
those holdings only accessible to members/employees of that 
organization.   And it's perfectly reasonable for users to configure 
their clients to query any resolution service available to them, 
including multiple services for the same namespace.

Saying that there should be no private resolution services is like 
saying that libraries or booksellers shouldn't permit their catalogs to 
be searched by ISBN.

To be clear, I'm certainly not proposing that all such resolution 
services should be publicly advertised for general use.

Keith

p.s. I'm currently writing a short document on URN resolution that 
illustrates how this works.


From nobody Fri May  1 12:48:44 2015
Return-Path: <ldaigle@thinkingcat.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 BDA601B2E2A for <urn@ietfa.amsl.com>; Fri,  1 May 2015 12:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 f2H6wmu45LMp for <urn@ietfa.amsl.com>; Fri,  1 May 2015 12:48:41 -0700 (PDT)
Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8071B2E24 for <urn@ietf.org>; Fri,  1 May 2015 12:48:41 -0700 (PDT)
Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 170B02005D90E; Fri,  1 May 2015 12:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=IJp32yQl+st/FU222E43HhfIXsU=; b=Cs/QGvHwgmUe bwmuX7nEvvArGa1FP48VYwCLig6KggSfb9bgyIOTKm15hqdU7DwpEUPjfjECZLpw ValptpoeiDgVWljS8lZHH6mXPKvVVaiyZr9y8uNMRl8h+7ZaSrShy7ujq9m/Ox9q jtpWtbFYYrKdxa50v93pgFBlSlnK9Pw=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id A8C822005D91F; Fri,  1 May 2015 12:48:40 -0700 (PDT)
Message-ID: <5543D897.9060502@thinkingcat.com>
Date: Fri, 01 May 2015 15:48:39 -0400
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <55438965.9020901@thinkingcat.com> <55438AFF.7030906@network-heretics.com>
In-Reply-To: <55438AFF.7030906@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/3CGryKzSn6GSTChX_WKbRDXh2cU>
Subject: [urn] Fundamental question: resolution Re: suggested change for -12 of rfc2141bis section 7.3.6
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, 01 May 2015 19:48:42 -0000

I certainly appreciate the use cases you cite.    We had a BoF about 
that a decade and a half ago, remember?  C15N.  Contextualization. (More 
info/reminders at  http://web.thinkingcat.com/wordpress/attic/#c15n ).

But, it seems to me your model completely divorces the namespace from 
resources, and allows for any kind of mapping between the two, with no 
ability to detect which mapping the resource holder (or name minter) 
intended.  I don't see that as "permanence" or "persistence".

The danger in conflating the use of an identifier in some consensual 
mapping service with namespace-supported resolution is that you lose any 
ability to use a URN to find the authoritative response intended for a 
given URN.

Leslie.

On 5/1/15 10:17 AM, Keith Moore wrote:
> On 05/01/2015 10:10 AM, Leslie Daigle (ThinkingCat) wrote:
>>
>> Not sure I'm entirely getting this right, but ISTM the proposed text
>> would support:
>>
>> 1/ Me using urn:isbn:<blat>  in a local resolver in my house to
>> resolve to items in my book collection.  (And teddy bears. Because we
>> know about ISBNs).
>>
>> 2/ Me standing up a completely independent URN resolution service for
>> all registered URN namespaces and resolving them any way I choose --
>> i.e., not necessarily to the resources intended by the namespace
>> creator and/or assigner.  And it's not clear to me how others would be
>> able to determine the intended resolution service outcome.
>>
>> I think "1/" isn't preventable, but shouldn't be promoted.  I think
>> "2/" needs to be prevented to the extent possible.
> I disagree.  Anybody should be able to operate a URN resolution service
> for any reason that they choose.  In particular, it's completely
> reasonable for any library to allow its holdings to be looked up by URN,
> or for there to be resolution services that aggregate catalogs from
> several libraries.    It's also completely reasonable for any enterprise
> to operate a URN resolution service for its own holdings, including
> those holdings only accessible to members/employees of that
> organization.   And it's perfectly reasonable for users to configure
> their clients to query any resolution service available to them,
> including multiple services for the same namespace.
>
> Saying that there should be no private resolution services is like
> saying that libraries or booksellers shouldn't permit their catalogs to
> be searched by ISBN.
>
> To be clear, I'm certainly not proposing that all such resolution
> services should be publicly advertised for general use.
>
> Keith
>
> p.s. I'm currently writing a short document on URN resolution that
> illustrates how this works.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Fri May  1 13:04:14 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 E7B2F1A8AB5 for <urn@ietfa.amsl.com>; Fri,  1 May 2015 13:04:12 -0700 (PDT)
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 NHicOkXYu8zx for <urn@ietfa.amsl.com>; Fri,  1 May 2015 13:04:11 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454B31A8ABF for <urn@ietf.org>; Fri,  1 May 2015 13:04:11 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B545420C51 for <urn@ietf.org>; Fri,  1 May 2015 16:04:10 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 01 May 2015 16:04:10 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=C/VPYkDToxp8GyG JOcnVJaTkaP0=; b=YH14jujPGzIMOmbRTVMIG9XshNnO4Pz4t4RxkrMiij9yXBN zrBDrPhBCCiwgtStKTomq0RdRl3p1nczwrhTnONp22JSgsl+ZyJ50yWM8iJjm2rp mk3GpHm/Zl94GaC5EEKcFZ8BQoAHyW4Ev0nZUebcxPg+3t8DUKZzM/jaSLD4=
X-Sasl-enc: xyiJ26w2IFA3qJ91Negrbs5FfvuRov7+hSM9+ktuv+A7 1430510650
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 4568BC00011; Fri,  1 May 2015 16:04:10 -0400 (EDT)
Message-ID: <5543DC36.6040402@network-heretics.com>
Date: Fri, 01 May 2015 16:04:06 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <55438965.9020901@thinkingcat.com> <55438AFF.7030906@network-heretics.com> <5543D897.9060502@thinkingcat.com>
In-Reply-To: <5543D897.9060502@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/egm-9dT3tbqi98BEU-uldOOSJ2Q>
Subject: Re: [urn] Fundamental question: resolution Re: suggested change for -12 of rfc2141bis section 7.3.6
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, 01 May 2015 20:04:13 -0000

On 05/01/2015 03:48 PM, Leslie Daigle (ThinkingCat) wrote:
>
> I certainly appreciate the use cases you cite.    We had a BoF about 
> that a decade and a half ago, remember?  C15N. Contextualization. 
> (More info/reminders at 
> http://web.thinkingcat.com/wordpress/attic/#c15n ).

I remember a lot from 15 years ago (or so I like to tell myself), but 
not that BOF.

> But, it seems to me your model completely divorces the namespace from 
> resources, and allows for any kind of mapping between the two, with no 
> ability to detect which mapping the resource holder (or name minter) 
> intended.  I don't see that as "permanence" or "persistence".

I do see it as promoting persistence.   What I think is detrimental to 
persistence is to promote the notion that only a resolution service 
operated by or authorized by a namespace is valid for resolution.   
If/when a namespace is no longer used to create new URNs and/or the 
organization running a namespace is no longer viable, the old URNs 
produced by that namespace should still be valid.

However, users will naturally want the best resolution information they 
can find, and if namespaces do a good job of providing and recommending 
resolution services for their URNs, and those services are generally 
available, I believe users will prefer them.   But even in those 
circumstances there are valid use cases for other resolution services 
than those advertised by a namespace - again: the local library, your 
company's private library, a preferred bookseller or two.

>
>
> The danger in conflating the use of an identifier in some consensual 
> mapping service with namespace-supported resolution is that you lose 
> any ability to use a URN to find the authoritative response intended 
> for a given URN.

Not so.   But you do need a mechanism to tell your software which 
resolution services are authoritative, and which of the services are 
preferred over others.

Keith

p.s.  Again, I'm trying to address this in the short document I'm 
writing, but I've been tied up dealing with a First Amendment emergency 
today so probably won't get it done before the weekend.


From nobody Mon May  4 14:20:11 2015
Return-Path: <ldaigle@thinkingcat.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 10A441B2C74 for <urn@ietfa.amsl.com>; Mon,  4 May 2015 14:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.244
X-Spam-Level: *
X-Spam-Status: No, score=1.244 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 VPdWnmQJuZsv for <urn@ietfa.amsl.com>; Mon,  4 May 2015 14:20:07 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 72C351B2C73 for <urn@ietf.org>; Mon,  4 May 2015 14:20:07 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 3294477805F; Mon,  4 May 2015 14:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= thinkingcat.com; bh=EYHFpY/2uq86SC4FBdA64IwzKAk=; b=cpmw4DSWj+Gq TU280owtOno5aFVEe6ArIc71kyjwTxn9zwHmzBanlpJMFi2YJ8erBuxQG3KTAJSC LxRsKn1wt4ROc8FHg4Iv7wUGxjG/k5Hgfwqf2iCxWILO4ujpdXEweEf00Vsd3Pby b+eFcvLmi+P310XSjnW7f9zOiPdRsdw=
Received: from aran-w.int.lexiconix.com (pool-108-44-246-138.clppva.fios.verizon.net [108.44.246.138]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 4EBA6778071; Mon,  4 May 2015 14:20:06 -0700 (PDT)
Message-ID: <5547E284.7040105@thinkingcat.com>
Date: Mon, 04 May 2015 17:20:04 -0400
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <55438965.9020901@thinkingcat.com> <55438AFF.7030906@network-heretics.com> <5543D897.9060502@thinkingcat.com> <5543DC36.6040402@network-heretics.com>
In-Reply-To: <5543DC36.6040402@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/9XZOI5BS5cJenfv6YyINxqXcjYU>
Subject: Re: [urn] Fundamental question: resolution Re: suggested change for -12 of rfc2141bis section 7.3.6
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, 04 May 2015 21:20:09 -0000

In-line...

On 5/1/15 4:04 PM, Keith Moore wrote:
> On 05/01/2015 03:48 PM, Leslie Daigle (ThinkingCat) wrote:
>>
>> I certainly appreciate the use cases you cite.    We had a BoF about
>> that a decade and a half ago, remember?  C15N. Contextualization.
>> (More info/reminders at
>> http://web.thinkingcat.com/wordpress/attic/#c15n ).
>
> I remember a lot from 15 years ago (or so I like to tell myself), but
> not that BOF.

How's your recollection on RESCAP? 
http://web.thinkingcat.com/wordpress/attic/#rescap

>
>> But, it seems to me your model completely divorces the namespace from
>> resources, and allows for any kind of mapping between the two, with no
>> ability to detect which mapping the resource holder (or name minter)
>> intended.  I don't see that as "permanence" or "persistence".
>
> I do see it as promoting persistence.   What I think is detrimental to
> persistence is to promote the notion that only a resolution service
> operated by or authorized by a namespace is valid for resolution.

Great, whatever you want to do to data in your own networks, have at it.

But, in other contexts, overriding intended network actions with a 
different flavour is considered "hijacking", and we generally try to 
avoid it.

> If/when a namespace is no longer used to create new URNs and/or the
> organization running a namespace is no longer viable, the old URNs
> produced by that namespace should still be valid.

Valid for what?  How does some other entity know what they were meant to 
point to (authoritatively)?

In terms of wholesale changing of resolution services in a conscious and 
intentional way, that was part of the purpose of DDDS.  Which this 
generation of WG discussion seems to have thrown out with the 
implementation in DNS.

>
> However, users will naturally want the best resolution information they
> can find, and if namespaces do a good job of providing and recommending
> resolution services for their URNs, and those services are generally
> available, I believe users will prefer them.   But even in those
> circumstances there are valid use cases for other resolution services
> than those advertised by a namespace - again: the local library, your
> company's private library, a preferred bookseller or two.

I agree that there are valid use cases for finding other copies of 
resources.  I disagree that should be conflated within the resolution 
system.
>
>>
>>
>> The danger in conflating the use of an identifier in some consensual
>> mapping service with namespace-supported resolution is that you lose
>> any ability to use a URN to find the authoritative response intended
>> for a given URN.
>
> Not so.   But you do need a mechanism to tell your software which
> resolution services are authoritative, and which of the services are
> preferred over others.

All strictly IMO:   It's not a mechanism.  It's got to be part of the 
standard.  Software is something people write to implement the standard, 
and is not the subject of discussion here.

Leslie.
>
> Keith
>
> p.s.  Again, I'm trying to address this in the short document I'm
> writing, but I've been tied up dealing with a First Amendment emergency
> today so probably won't get it done before the weekend.
>


From nobody Mon May  4 14:50:49 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 9B72E1B2CAA for <urn@ietfa.amsl.com>; Mon,  4 May 2015 14:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  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 rAdbTHEYfWFZ for <urn@ietfa.amsl.com>; Mon,  4 May 2015 14:50:38 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F711B2CA9 for <urn@ietf.org>; Mon,  4 May 2015 14:50:37 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2CA41204DC for <urn@ietf.org>; Mon,  4 May 2015 17:50:37 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 04 May 2015 17:50:37 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=NvAJLZGiLwJXfcv eBLcM57W2HL8=; b=VDddkRfIS1UbHl9oyfsvDvdtJtB2gAYf6Ou9hw0Mf+TZvNg KqQBn6cfF0CsI/DLqH4gZLySl+Mu9n2FwgOiTfmBBQjGS8HYnm/+wiyy+JmYzu5n LdRGe1y5piACkVYAN02bSuJx4iSsjtU119qr4hJ1JT/eqlS10Q4wyxLR3ZkM=
X-Sasl-enc: /tH1ANOa2A3nzgyL6SkQAHFu8HWtPApRTNoBch7tGm1F 1430776236
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id B5197C00019; Mon,  4 May 2015 17:50:36 -0400 (EDT)
Message-ID: <5547E9A0.7060502@network-heretics.com>
Date: Mon, 04 May 2015 17:50:24 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <55438965.9020901@thinkingcat.com> <55438AFF.7030906@network-heretics.com> <5543D897.9060502@thinkingcat.com> <5543DC36.6040402@network-heretics.com> <5547E284.7040105@thinkingcat.com>
In-Reply-To: <5547E284.7040105@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/4-xUqG9jeGMaukQ93EwcxIyoyzo>
Subject: Re: [urn] Fundamental question: resolution Re: suggested change for -12 of rfc2141bis section 7.3.6
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, 04 May 2015 21:50:41 -0000

On 05/04/2015 05:20 PM, Leslie Daigle (ThinkingCat) wrote:
> In-line...
>
> On 5/1/15 4:04 PM, Keith Moore wrote:
>> On 05/01/2015 03:48 PM, Leslie Daigle (ThinkingCat) wrote:
>>>
>>> I certainly appreciate the use cases you cite.    We had a BoF about
>>> that a decade and a half ago, remember?  C15N. Contextualization.
>>> (More info/reminders at
>>> http://web.thinkingcat.com/wordpress/attic/#c15n ).
>>
>> I remember a lot from 15 years ago (or so I like to tell myself), but
>> not that BOF.
>
> How's your recollection on RESCAP? 
> http://web.thinkingcat.com/wordpress/attic/#rescap

A bit better.   Thanks for the pointer to that; some of us were just 
talking about RESCAP in Dallas.

>
>>
>>> But, it seems to me your model completely divorces the namespace from
>>> resources, and allows for any kind of mapping between the two, with no
>>> ability to detect which mapping the resource holder (or name minter)
>>> intended.  I don't see that as "permanence" or "persistence".
>>
>> I do see it as promoting persistence.   What I think is detrimental to
>> persistence is to promote the notion that only a resolution service
>> operated by or authorized by a namespace is valid for resolution.
>
> Great, whatever you want to do to data in your own networks, have at it.
>
> But, in other contexts, overriding intended network actions with a 
> different flavour is considered "hijacking", and we generally try to 
> avoid it.

I don't view URNs as inherently tied to "intended network actions". The 
URN system is a discipline for naming resources.    Now it happens that 
it's frequently useful to be able to ask network-based services for 
information about URNs.   But which services are "authoritative" sources 
of information about a URN depends on what you're looking for.   If 
you're looking for the information which the namespace itself associates 
with that URN, the best service to consult is probably one either 
operated by or recommended by that namespace.   If you're looking for a 
copy of that resource on a particular library or archive, you probably 
want to ask that library or archive, because it is authoritative for 
that kind of information.   That's not "hijacking", it's just a 
different use case.

OTOH, it's extremely dangerous to architect a single source for all 
information about a URN.  Single sources provide excellent vectors for 
denial-of-service attacks, control of information usage, and monitoring 
of information usage - all of which are threats to a free society.

>
>> If/when a namespace is no longer used to create new URNs and/or the
>> organization running a namespace is no longer viable, the old URNs
>> produced by that namespace should still be valid.
>
> Valid for what?  How does some other entity know what they were meant 
> to point to (authoritatively)?

How does someone today know what an ISBN created long ago was meant to 
point to?   As best as I understand, the answer is that there are 
organizations that compile such information and make their databases 
available.

> In terms of wholesale changing of resolution services in a conscious 
> and intentional way, that was part of the purpose of DDDS.  Which this 
> generation of WG discussion seems to have thrown out with the 
> implementation in DNS.

IMO, DDDS needs another look.   I think some of those documents suffer 
from lack of clarity but the underlying ideas were fairly sound.   There 
definitely needs to be a way to discover namespace-advertised services 
that provide information about URNs. I just don't think that those 
services are the only sources that should ever be consulted.

>
>>
>> However, users will naturally want the best resolution information they
>> can find, and if namespaces do a good job of providing and recommending
>> resolution services for their URNs, and those services are generally
>> available, I believe users will prefer them.   But even in those
>> circumstances there are valid use cases for other resolution services
>> than those advertised by a namespace - again: the local library, your
>> company's private library, a preferred bookseller or two.
>
> I agree that there are valid use cases for finding other copies of 
> resources.  I disagree that should be conflated within the resolution 
> system.

Well, if it's just a matter of what we call each operation, I don't care 
that much.  Having different terms for the two might be useful.   I 
would however like for software to be capable of consulting both 
namespace-recommended and other sources of information about a URN 
(depending on the use case); and for some of the same protocols, schema, 
and data formats to be potentially usable across those different use cases.

>>
>>>
>>>
>>> The danger in conflating the use of an identifier in some consensual
>>> mapping service with namespace-supported resolution is that you lose
>>> any ability to use a URN to find the authoritative response intended
>>> for a given URN.
>>
>> Not so.   But you do need a mechanism to tell your software which
>> resolution services are authoritative, and which of the services are
>> preferred over others.
>
> All strictly IMO:   It's not a mechanism.  It's got to be part of the 
> standard.  Software is something people write to implement the 
> standard, and is not the subject of discussion here.

Again, I think there are different kinds of authority, and the namespace 
isn't the only source of authoritative information for every use case.

But of course we do need to be clear about what's part of the standard 
and what's merely an implementation recommendation or suggestion.

Keith

p.s. thanks for this message though - responding to it helped to clarify 
for me that the use case associated with a URN needs to guide the 
implementation's choice of which services to consult, and also that the 
use case is probably something that should be able to be exposed in an 
r-component.   more on that later, hopefully later tonight.


From nobody Tue May  5 05:53:56 2015
Return-Path: <L.Svensson@dnb.de>
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 D26491AC3D8 for <urn@ietfa.amsl.com>; Tue,  5 May 2015 05:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.15
X-Spam-Level: 
X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 rC5spOvM8q8r for <urn@ietfa.amsl.com>; Tue,  5 May 2015 05:53:51 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 488881AC3E2 for <urn@ietf.org>; Tue,  5 May 2015 05:53:50 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id DF4BB8AD0E; Tue,  5 May 2015 14:53:49 +0200 (CEST)
X-AuditID: 0a453fe7-f79106d0000047dd-87-5548bd5deaf6
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id FB.A2.18397.D5DB8455; Tue,  5 May 2015 14:53:49 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Tue, 5 May 2015 14:53:49 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>, Keith Moore <moore@network-heretics.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Thread-Topic: [urn] suggested text for r-components
Thread-Index: AQHQfkq3yIyC5F0Aa06lmWIlnaVHxZ1ksQMAgAAxEACAAQC5gIAHhMUw
Date: Tue, 5 May 2015 12:53:48 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF663A1@dnbf-ex1.AD.DDB.DE>
References: <5539CC41.4050204@network-heretics.com> <5541899A.6030106@andyet.net> <5541B2C2.4060308@network-heretics.com> <55428A1D.9080306@thinkingcat.com>
In-Reply-To: <55428A1D.9080306@thinkingcat.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.155]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta0gUURiGOzuzu+O2x07r6p62LB2CqMjKCvZHN6JyI8OgjArKxnZy13bV ZnZF649lFG2QKYZllK7YhSgy7WKZRoNQSllEFworM03sohJuFnSbmzb275vn+973vN85DEVY /hjtlCfLz3JZjJc2mEjTiiXhWVsanalz3gmJjsYzlwlHSbjN4GjtbCYcxwoHdEtJZ1v7c6Oz uvqHzllyf4Ozs+ycfi252bTQxXo9uSw3e/E2kzvcX6jPGYzMC+0bBAXg5dggiKAwmo9/HijW K3UMfvzmsiEITJQFNQN899gAoXxcB7jicJ0xCIyUAc3A/W5p3opKAW56hqSaQPG49m2pTqqj UCL+2Rw0KDPzcOvB46I/JdYrcUdHpoRJNBW3Fx+WxyFajev3h0iptqBK8aSvsn0Emo1fhq/L MwDF4pqaR4RylA3XfhhSIyNcfVvhGEXj3ve/VR6HC4STRmV+Du5vq1C1M/HZ0CdCOXc8bjnR RR4FMeUa23KNpFwjKddIKgF5AUTyvoy5CYwrweVKT3CxtUB5qZ56cOTJcgEgCtBmOOhzplr0 TC6f7xNACqWjo+HDmyKKTM925bsZ3p3GBbwsT1shcVvEcASnB7w76cnwzi6R2kYoH+BzPNs9 2QE+LcB5BYApQpTWX5OkLiZ/N8tlK4YCmEiRtA0WN+xdb0EZjJ/dybI5LDfc3UhRNIaXGkTh eI7NYPN2eLz+4bao65E6SNuRA8XDKimQXdv4P5OOihBAMmUWg1VJLpDPYXy8J0P1joLELZGa h6nsGwuLORHGDMPRnq1gnd0Gm+RI0oQ7kDWS1R4DBSnSOE1DsrTHwbxJSamWCRo+2vUjWCU+ URR0SRdvFv+3fxktMFuCY1UoR5wEq6SI0Sr73ytZfFsrvLBLXtjP+LUL6zl5YZWqC49RFlbh aDt7AUiEZaGiTbYv/lPfMqebM9unFAlDUZ9OO7qu3Di0bU3dj/2h+GUNLXuCGzuaUoYudj/f +se3aO0HC+pOX0gPhV+1fj5Z2t0Uqn3bZwUn4q5d5TOJ9fNvxr2I7f5cl5R3b0HE6wcpCQOh aZs7+w7WWL97u/rBQC89rvD8uZZfvviGqU9pknczc2cQHM/8BVXdLl+SBAAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/-WHhedVqv_qi1g3DPuDFnrKfFs8>
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] suggested text for r-components
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, 05 May 2015 12:53:55 -0000

Also below:
=20
> Below...
>=20
> On 4/30/15 12:42 AM, Keith Moore wrote:
> > On 04/29/2015 09:47 PM, Peter Saint-Andre - &yet wrote:
> >>
> >> Overall I'm still feeling queasy about r-components. It's a large
> >> change to the spec and I feel that it's strongly tied to resolution. I
> >> am wondering whether later on (i.e., when and if someone writes a spec
> >> that updates or obsoletes RFC 2276) we can define r-components as a
> >> convention used in relation to URN resolution. Because r-components
> >> are allowed by q-component syntax, this seems feasible. And because
> >> they represent a significant and untried addition to URNs, this seems
> >> desirable (at least to me).
> >
> > Of course r-components are strongly tied to resolution, since their
> > intended purpose is to affect resolution.  :-)
> >
> > The essential thing to establish now, IMO, is the separation between a
> > query that's passed to a resource and a query that's passed to a
> > resolution service (even if part of the logic of that service is
> > implemented in the client).    If we don't do that now, code will be
> > written that passes everything after the first "?" to the resource as a
> > query, and that will make it much more difficult to implement resolutio=
n
> > services later without breaking things.
> >
>=20
> I think this:
>=20
> > However what might work is to define a syntax for r-components in
> > 2141bis and declare that they're reserved for future use by an IETF
> > standard.   And I think we should go ahead and try to define a standard
> > framework for resolution, but maybe that doesn't have to be a blocking
> > item for 2141bis.
>=20
> is the sort of thing I was thinking of when I said leaving a "hook".

Works for me. I feel quite comfortable with Keith's proposal, and I guess t=
he exact definition would be an update to rfc 2483.

Lars=20


From nobody Sun May 10 11:51:04 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 38C401A8A3E for <urn@ietfa.amsl.com>; Sun, 10 May 2015 11:51:03 -0700 (PDT)
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 anKavSnY3GGd for <urn@ietfa.amsl.com>; Sun, 10 May 2015 11:51:02 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 342111A8A25 for <urn@ietf.org>; Sun, 10 May 2015 11:51:02 -0700 (PDT)
Received: by pabtp1 with SMTP id tp1so92155317pab.2 for <urn@ietf.org>; Sun, 10 May 2015 11:51:01 -0700 (PDT)
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=cJcAPUPihkeH7KvhP2IvAFYW+PEVes4Iw4rbJ16KqRs=; b=a7AFtHDAfewRPZsF9eHuLCW26CbO1FJneB8P0c0z8ppA/DcDKrPcMytvn+E8NKyg3U djkIv68WZsFT1c+hxItnf44NPoUqEoCIZdKB8+MynTntrJxhSY1jZUR7Gdagr+13v2Zu RlETmHykDYPNLo78Qk1Yyz1E990Mz+gfHuKP9ekZe3jNHFqD3biY+GyNQ6ZyqjMFrwRz xn/IvaWu9QdJRwE3ZUjB9kDL4dWT722X1R/CVK8OycXhqwjGO/zr8AUabx6CGMWOgwJb MOoLMR6QkPa7d775IOGpshXjKnUclrqQWR2Kl6eynzcWABEFRhWdOVAOTXivEjRJmAAT 2KxA==
X-Received: by 10.68.198.36 with SMTP id iz4mr13265678pbc.167.1431283861803; Sun, 10 May 2015 11:51:01 -0700 (PDT)
Received: from spandex.local (209-193-49-114-rb2.nwc.dsl.dynamic.acsalaska.net. [209.193.49.114]) by mx.google.com with ESMTPSA id qm2sm10838859pdb.57.2015.05.10.11.51.00 for <urn@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 11:51:00 -0700 (PDT)
Message-ID: <554FA892.90208@gmail.com>
Date: Sun, 10 May 2015 10:50:58 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/SNlBhL-vyBfYImzkRrOq_xo9vOY>
Subject: [urn] r-component syntax
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: Sun, 10 May 2015 18:51:03 -0000

Hi, all:

There seems to be agreement on specifying a syntax for r-components,
largely as a defensive mechanism against possible future bad behavior.
Rather than specifying that space as "reserved" it probably makes
more sense, and is more consistent with IETF practice, to distinguish
between things that are used as part of URN processing and things that
are opaque to URN processing and passed through without being touched
(thanks to John for providing some clarifying thoughts on this).  Is
there agreement on this?

Thanks,

Melinda


From nobody Sun May 10 12:28:09 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 E51B81A8AB4 for <urn@ietfa.amsl.com>; Sun, 10 May 2015 12:28:07 -0700 (PDT)
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 ZZc6ht7nCk5n for <urn@ietfa.amsl.com>; Sun, 10 May 2015 12:28:04 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71491A8AAF for <urn@ietf.org>; Sun, 10 May 2015 12:28:04 -0700 (PDT)
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 1YrWtP-000450-D3; Sun, 10 May 2015 15:28:03 -0400
Date: Sun, 10 May 2015 15:27:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <B75A448A898B521DADE02049@JcK-HP8200.jck.com>
In-Reply-To: <554FA892.90208@gmail.com>
References: <554FA892.90208@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-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/iBTLii9aM71VEiFPKJugqqaEx5U>
Subject: Re: [urn] r-component syntax
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: Sun, 10 May 2015 19:28:08 -0000

--On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
<melinda.shore@gmail.com> wrote:

> There seems to be agreement on specifying a syntax for
> r-components, largely as a defensive mechanism against
> possible future bad behavior. Rather than specifying that
> space as "reserved" it probably makes more sense, and is more
> consistent with IETF practice, to distinguish between things
> that are used as part of URN processing and things that are
> opaque to URN processing and passed through without being
> touched (thanks to John for providing some clarifying thoughts
> on this).  Is there agreement on this?

Melinda, thanks.

As a shortcut to save a bit of time, I think that, if we decide
to allow r-components, the syntax for in section 3 of 2141bis-11
would change so that the changed productions would read:

       q-component = "?" query [ "??" r-component ]
	       Note that <query> in the above cannot contain "??"
       r-component = query

That could also be done in a somewhat more complex way to
eliminate the note, e.g., as 

       q-component = "?" q-string [ "??" r-component ]
       r-component = r-string

where the definition of q-string would repeat the text of
Section 3.4 of RFC 3986 but explicitly exclude, and terminate
on, "??" as well as "#" and r-string would match that Section
3.4 text.

It could also be done more like:

      namestring    = assigned-name
                      [ q-component [r-component] ]
                      [ f-component ]
       q-component = "?" q-string
       r-component = "??" r-string

If anyone who thinks we should adopt r-components has a strong
preference among those alternatives, please say so, otherwise,
Peter and I will draw straws or equivalent.

Independent of the above, if we are going to adopt r-components,
we will need some text to describe them and some examples,
preferably real.  Peter and I can make that up, but suggestions
from WG participants who have thought deeply about this would be
much better.

   best,
    john


From nobody Sun May 10 14:38:10 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 0AEE21AC3F5 for <urn@ietfa.amsl.com>; Sun, 10 May 2015 14:38:09 -0700 (PDT)
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 Rv2iOQoe_Fxv for <urn@ietfa.amsl.com>; Sun, 10 May 2015 14:38:07 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6C71AC3F9 for <urn@ietf.org>; Sun, 10 May 2015 14:38:06 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1924A205C5 for <urn@ietf.org>; Sun, 10 May 2015 17:38:05 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 10 May 2015 17:38:05 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XpgrfymXS++V/An g2B2lM3yZGko=; b=pHpf2pgpI8v2KrvqjU//qrA5NuJ3d66OrXqL3hVdhWwKoW8 rhDKnaIr2qNT7vlMAGOd+xaieM2Om4NUtvMWq6zRYYeHHyGq0831sbCGbOLjha12 pasOqEcGzMnh/7OEmUzNGc5wAYv+HxkPGeEmoR5wojeuJQV+1wczH18T11Ic=
X-Sasl-enc: WhfYPNDyf+g5gPND69UKOShQh2I10dnukkQImxEAu/ZM 1431293884
Received: from [192.168.1.67] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B2CBEC00013; Sun, 10 May 2015 17:38:04 -0400 (EDT)
Message-ID: <554FCFAF.6020605@network-heretics.com>
Date: Sun, 10 May 2015 17:37:51 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com>
In-Reply-To: <B75A448A898B521DADE02049@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/S74bsAWIx4CPLKum6ILJEYxA_XU>
Subject: Re: [urn] r-component syntax
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: Sun, 10 May 2015 21:38:09 -0000

On 05/10/2015 03:27 PM, John C Klensin wrote:
>
> --On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
> <melinda.shore@gmail.com> wrote:
>
>> There seems to be agreement on specifying a syntax for
>> r-components, largely as a defensive mechanism against
>> possible future bad behavior. Rather than specifying that
>> space as "reserved" it probably makes more sense, and is more
>> consistent with IETF practice, to distinguish between things
>> that are used as part of URN processing and things that are
>> opaque to URN processing and passed through without being
>> touched (thanks to John for providing some clarifying thoughts
>> on this).  Is there agreement on this?
> Melinda, thanks.
>
> As a shortcut to save a bit of time, I think that, if we decide
> to allow r-components, the syntax for in section 3 of 2141bis-11
> would change so that the changed productions would read:
>
>         q-component = "?" query [ "??" r-component ]
> 	       Note that <query> in the above cannot contain "??"
>         r-component = query
>
> That could also be done in a somewhat more complex way to
> eliminate the note, e.g., as
>
>         q-component = "?" q-string [ "??" r-component ]
>         r-component = r-string
>
> where the definition of q-string would repeat the text of
> Section 3.4 of RFC 3986 but explicitly exclude, and terminate
> on, "??" as well as "#" and r-string would match that Section
> 3.4 text.

I had two reasons for suggesting that r-component precede (appear to the 
left of) q-component:

1.  Doing so places no constrains on the contents of q-components. 
Granted that it's unlikely that there are many existing services that 
use "??" within a query, but it seemed safer to not assume that.

2.  Putting r-components first preserves the property of http[s] and I 
think most other URIs that components are processed left-to-right.   
With most URIs, query processing happens before fragment processing (the 
fragment might apply to the output that the service generates in 
response to the query).     With a URN, the r-component should be used 
first (during resolution), then the q-component (query sent to 
resource), then the f-component (fragment of result).


> Independent of the above, if we are going to adopt r-components,
> we will need some text to describe them and some examples,
> preferably real.  Peter and I can make that up, but suggestions
> from WG participants who have thought deeply about this would be
> much better.

Let me see what I can come up with.

Keith


From nobody Sun May 10 16:38:43 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 3684D1A1B3C for <urn@ietfa.amsl.com>; Sun, 10 May 2015 16:38:42 -0700 (PDT)
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 6xGpuUv0-jiM for <urn@ietfa.amsl.com>; Sun, 10 May 2015 16:38:40 -0700 (PDT)
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 0ECBC1A1A83 for <urn@ietf.org>; Sun, 10 May 2015 16:38:40 -0700 (PDT)
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 1Yranu-0004LS-HR; Sun, 10 May 2015 19:38:38 -0400
Date: Sun, 10 May 2015 19:38:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
Message-ID: <23601CE735D7E5A28E5B230F@JcK-HP8200.jck.com>
In-Reply-To: <554FCFAF.6020605@network-heretics.com>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <554FCFAF.6020605@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/P6kRO1qFZovsABAFDkThKt5uOG0>
Subject: Re: [urn] r-component syntax
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: Sun, 10 May 2015 23:38:42 -0000

--On Sunday, May 10, 2015 17:37 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> On 05/10/2015 03:27 PM, John C Klensin wrote:
>> 
>> --On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
>> <melinda.shore@gmail.com> wrote:
>> 
>>> There seems to be agreement on specifying a syntax for
>>> r-components, largely as a defensive mechanism against
>>> possible future bad behavior. Rather than specifying that
>>> space as "reserved" it probably makes more sense, and is more
>>> consistent with IETF practice, to distinguish between things
>>> that are used as part of URN processing and things that are
>>> opaque to URN processing and passed through without being
>>> touched (thanks to John for providing some clarifying
>>> thoughts on this).  Is there agreement on this?
>> Melinda, thanks.
>> 
>> As a shortcut to save a bit of time, I think that, if we
>> decide to allow r-components, the syntax for in section 3 of
>> 2141bis-11 would change so that the changed productions would
>> read:
>> 
>>         q-component = "?" query [ "??" r-component ]
>> 	       Note that <query> in the above cannot contain "??"
>>         r-component = query
>> 
>> That could also be done in a somewhat more complex way to
>> eliminate the note, e.g., as
>> 
>>         q-component = "?" q-string [ "??" r-component ]
>>         r-component = r-string
>> 
>> where the definition of q-string would repeat the text of
>> Section 3.4 of RFC 3986 but explicitly exclude, and terminate
>> on, "??" as well as "#" and r-string would match that Section
>> 3.4 text.
> 
> I had two reasons for suggesting that r-component precede
> (appear to the left of) q-component:

Hmm.  Glad I asked the question.

> 1.  Doing so places no constrains on the contents of
> q-components. Granted that it's unlikely that there are many
> existing services that use "??" within a query, but it seemed
> safer to not assume that.
> 
> 2.  Putting r-components first preserves the property of
> http[s] and I think most other URIs that components are
> processed left-to-right.   With most URIs, query processing
> happens before fragment processing (the fragment might apply
> to the output that the service generates in response to the
> query).     With a URN, the r-component should be used first
> (during resolution), then the q-component (query sent to
> resource), then the f-component (fragment of result).

With the understanding that I'm mostly agnostic (and, again,
speaking only for myself), the counterargument is that, if
r-component comes first, then it has to be terminated by "?" or
"#" and "?" cannot appear within it.  As an example, chosen
because I'm getting tired of Western European examples and ones
that rely on ISBNs or ISSN, but exposing my bias toward
name-value pairs, assume one was looking for an instance of an
object within, say, India, with the UK as a second choice,
wanted to identify an edition-style, and, if the object was
retrieved, ask about a particular chapter (or some there term),
so we might have

URN-processing info: ?location=IN,GB?Ed=Shakala?lang=hi-IN
Information to be passed to object or its processor:
?verse=X.71.1

Now, leaving the particular work as an exercise, with
r-component second, we would have:

 urn:....?verse=X.71.1??location=IN,GB?Ed=Shakala?lang=hi-IN

(noting that additional material in the q-component could just
use "?" as a delimiter), while r-component first would give us:

 urn:....??location=IN,GB%3FEd=Shakala%3Flang=hi-IN?verse=X.71.1

My rather extreme negative reaction to requiring the use of
%-encoding to achieve the basic structure of a URN (or other URI
string) was what initially sent me in quest of a way to
accomplish and identify both functions without lexical division
of one of the p-/q-/f-components into subcomponent fields and
then led me, instinctively, to r-component second.

I note that the underpinnings of the example above would lend
itself to non-ASCII characters in the NSS and/or p-component, so
%-encoding is likely, adding to the confusion if it is also
necessarily used to encode "?".

It is a tradeoff against your two arguments.  Personally, I find
it pretty persuasive because, (1) forcing r-components into
%-encoding in order to support embedded "?" seems like a far
worse constraint than forcing q-components into %-encoding if it
were necessary to embed "??" (or "#", etc.) and (2) while I
recognize the reality of the "processed from left to right"
convention that you identify, I couldn't quickly find that (as
distinct from "parsed from left to right") as a requirement
except in the context of the 3986 discussion of hierarchical
identifiers (Section 1.2.3) to which URNs are already exceptions
in several respects.


>> Independent of the above, if we are going to adopt
>> r-components, we will need some text to describe them and
>> some examples, preferably real.  Peter and I can make that
>> up, but suggestions from WG participants who have thought
>> deeply about this would be much better.
> 
> Let me see what I can come up with.

thanks.

    john


From nobody Sun May 10 17:27:40 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 C41321A702B for <urn@ietfa.amsl.com>; Sun, 10 May 2015 17:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 vYiiyhnNGASv for <urn@ietfa.amsl.com>; Sun, 10 May 2015 17:27:37 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07951A6FF8 for <urn@ietf.org>; Sun, 10 May 2015 17:27:37 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 47E6D20528 for <urn@ietf.org>; Sun, 10 May 2015 20:27:37 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 10 May 2015 20:27:37 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=HGOHREfqK340QM7 PoFHNtXk9Zx0=; b=WLPPpk9MxXCNFshhpDa2XRmpom3gCd+T03kyIVvLhzbL56E MfC7BKCNDaZeVSlpp1U4y/OdAe9j57i6IQS6vCs9HwR4jTxA7c9UBGMecyrNNBiz 58JJujhux9WlQPdsWcBV6Ex1bKAxFoa7VYjOWRxmVhNIA6a2ZMatVHadTw24=
X-Sasl-enc: eR5O9FQ9wf3ajX0m7CLkkVLPx+2BOHsXmMLtuqoSltRj 1431304057
Received: from [192.168.1.67] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id CD530C00013; Sun, 10 May 2015 20:27:36 -0400 (EDT)
Message-ID: <554FF76B.5030304@network-heretics.com>
Date: Sun, 10 May 2015 20:27:23 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <554FCFAF.6020605@network-heretics.com> <23601CE735D7E5A28E5B230F@JcK-HP8200.jck.com>
In-Reply-To: <23601CE735D7E5A28E5B230F@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/S2umLGf21NOpYfZ6zZd3N3_zsDI>
Subject: Re: [urn] r-component syntax
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, 11 May 2015 00:27:39 -0000

On 05/10/2015 07:38 PM, John C Klensin wrote:
>> I had two reasons for suggesting that r-component precede
>> (appear to the left of) q-component:
> Hmm.  Glad I asked the question.
>
>> 1.  Doing so places no constrains on the contents of
>> q-components. Granted that it's unlikely that there are many
>> existing services that use "??" within a query, but it seemed
>> safer to not assume that.
>>
>> 2.  Putting r-components first preserves the property of
>> http[s] and I think most other URIs that components are
>> processed left-to-right.   With most URIs, query processing
>> happens before fragment processing (the fragment might apply
>> to the output that the service generates in response to the
>> query).     With a URN, the r-component should be used first
>> (during resolution), then the q-component (query sent to
>> resource), then the f-component (fragment of result).

FWIW, I just remembered a 3rd reason for putting r-component to the left 
of q-component [*]:

3. Putting r-component to the left of q-component means that the 
portions of the URN that get fed to the resolution service are 
adjacent.    So it's conceivable that the portion of a URN fed to a 
resolution service is obtained by removing the q-component and f-component.

I said "conceivable" since my current thinking is that the application 
client actually has to know something about r-components.  E.g. if the 
content specifies an r-component of "u2r;revision=1.2" the client might 
need to know that it can satisfy a "u2r" request by finding a location 
using "u2l" and requesting the resource from that location.   Also, if 
the service request is not specified in an r-component, the client still 
needs to know what to request from the resolution service.   This 
doesn't make me entirely happy, as it is a less-than-clean separation 
between the resolution service and other client behavior, but it's what 
makes the most sense to me at the moment.

As ugly as %-encoding is, I don't think the requirement to encode '?' 
that appears in r-components is a huge problem, given that (as you point 
out) it's quite likely that non-ASCII characters will appear in 
r-components and they'll also need to be encoded.   Given the wide range 
of characters that require encoding that can reasonably appear in an 
r-component, what's the cost of having to encode 0x3f in addition to the 
rest?   But (for reasons which your example makes quite clear) neither 
would I recommend using '?' (encoded or otherwise) as a separator 
between portions (name-value-pairs or whatever) of an r-component.

I also like the idea of being able to copy a URN q-component to a URL 
query component, and a URN f-component to a URL fragment, without having 
to do any re-encoding (and I'm far from confident that these 
translations will only ever be needed in one direction).   I strongly 
suspect that if different encodings are used for queries vs. 
q-components and fragments vs. f-components that implementations will 
botch those translation steps and/or behave inconsistently from one another.

Regarding name-value pairs: I started out thinking that r-components 
should be name-value pairs.   My current thinking is that they're more 
like expressions in WHERE clauses (and some other portions) of SQL 
SELECT statements.   In other words, I think they're more likely to be 
constraints that are imposed on the result set rather than some named 
attributes.   You could of course still express such things with NVPs, e.g.

urn:example:foo:bar??svc=u2c;where=revision_date.gt.%2220140123%22.and.content_type.eq.%22text/plain%22;order=desc;order_by=revision_date;limit=10

but to me, NVPs don't look as useful in r-components as I originally 
assumed they would be.

(though it strikes me that the above example is so ugly, and things 
could easily get so much worse, that maybe we'd be better off encoding 
the entire r-component in base64)

Keith

[*]  To be clear, I didn't actually arrive at this preference using case 
analysis.   Putting r-component to the left just seemed right to me, 
then I saw what appeared to be several advantages of doing it that 
way.    There might be larger disadvantages that I haven't seen yet.


From nobody Mon May 25 11:15:09 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 047631B2D22 for <urn@ietfa.amsl.com>; Mon, 25 May 2015 11:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.801
X-Spam-Level: ***
X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 S3l-LJ9Vm1QI for <urn@ietfa.amsl.com>; Mon, 25 May 2015 11:15:04 -0700 (PDT)
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 938571B2D10 for <urn@ietf.org>; Mon, 25 May 2015 11:15:04 -0700 (PDT)
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 1Ywwty-000630-Mg; Mon, 25 May 2015 14:15:02 -0400
Date: Mon, 25 May 2015 14:14:57 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>
Message-ID: <ABC814B799B9975CE692229F@P5>
In-Reply-To: <554FF76B.5030304@network-heretics.com>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <554FCFAF.6020605@network-heretics.com> <23601CE735D7E5A28E5B230F@JcK-HP8200.jck.com> <554FF76B.5030304@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
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/ExiHWwTW4I6b0wtyjoeq-SGng7g>
Cc: urn@ietf.org
Subject: Re: [urn] r-component syntax
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, 25 May 2015 18:15:07 -0000

Keith,

I've been delaying responding to this in the hope that someone
else would speak up.  But, with the exception of the two of us,
and Melinda, there has been only silence since her note asking
about agreement on 10 May.

In the hope that it will start a conversation, or at least
elicit some "doesn't matter to me, just decide and move on"
responses from others, a few comments about object order.  I've
trimmed most of the original notes. For those who need to go
back and review, see the messages on 10 May at 
http://www.ietf.org/mail-archive/web/urn/current/maillist.html 

My apologies in advance to anyone who does not want to get far
into parsing theory, etc.


--On Sunday, 10 May, 2015 20:27 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> FWIW, I just remembered a 3rd reason for putting r-component
> to the left of q-component [*]:
> 
> 3. Putting r-component to the left of q-component means that
> the portions of the URN that get fed to the resolution service
> are adjacent.    So it's conceivable that the portion of a URN
> fed to a resolution service is obtained by removing the
> q-component and f-component.
> 
> I said "conceivable" since my current thinking is that the
> application client actually has to know something about
> r-components.  E.g. if the content specifies an r-component of
> "u2r;revision=1.2" the client might need to know that it can
> satisfy a "u2r" request by finding a location using "u2l" and
> requesting the resource from that location.   Also, if the
> service request is not specified in an r-component, the client
> still needs to know what to request from the resolution
> service.   This doesn't make me entirely happy, as it is a
> less-than-clean separation between the resolution service and
> other client behavior, but it's what makes the most sense to
> me at the moment.

To a considerable extent, we have gotten into a situation in
which, despite the "semantics separation" (aka "syntax only")
decision, we can't make the decisions that would be most natural
for URNs taken in isolation from [other] URIs.  That is, on
balance, ok, but what is driving it has been a lot of notions
and claims about real and hypothetical generic URI parsers,
including discussions of fragments existing separately from URIs
and having their own semantics whatever anyone else says, the
presence of "/" dragging us into relative references, and so on.
The one effort I know of to determine what is actually out there
and what it does (Sam Ruby's efforts that you and others might
have heard discussed on other lists) has not yielded a very
coherent picture and now, I understand, has been suspended
because the browser folks didn't seem to be very interested.

I think it is safe to say that, when one gets to the edge cases,
there is a lot of different behavior out there.  Whether that is
the result of carelessness or not being able to understand 3986
is obviously not the issue.

Absent Sam's results (and asking and answering questions I'm not
sure he has asked), I think it is far more likely that, 3986
aside, "??" first is going to trigger a syntax error in some
generic parser whose authors haven't imagined such things than
getting into the query having shut off any code that treats "?"
as special.

I don't know if it makes any difference in reality (see below),
but the distinction does affect the metalanguage.  If
r-component is to the right, we have

   <query> = <q-component> [ "??" <r-component> ]
where <q-component> is exactly an RFC 3986 <query> with the
restriction that <query-text> cannot contain a literal
appearance of "??" even though "?" is allowed.  That requires a
two-character look-ahead in the parser, but that should not be a
big deal these days.

By contrast, if it is to the left, we really cannot use the 3986
structure any more because 
    [...] ?? foo ? bar
makes "foo" an r-component and bar a <query> but
    [...] ? ? foo ? bar
make the <query> "? foo ? bar".   If one contemplates
error-prone constructions that could yield weird error messages,
that could be a winner.

However, to return to fundamentals, there are two ways to think
about URI parsing.  In one model, it is all hierarchical: the
generic URI parser separates scheme from everything else, passes
the whole business to a scheme specific parser and it does its
thing.  In the other, which has seemed to be the main focus, a
generic URI parser breaks things into designated bits and passes
those bits off to whatever needs to deal with them, presumably
pre-isolated.  In the latter case, it doesn't really make any
difference how things are organized in the URI string -- in
principle we could tag everything, put pieces in random order,
and then recombine the components after parsing -- as long as
the parsing process is plausible and unambiguous.   In
compiler-speak, the output of a generic parser is a parse tree
and "it is better for these things to come in that order in the
raw string" just are not significant as long as pieces of the
tree are passed off to other processors or other processors can
find their place in the tree.

None of that applies to what is (or ought to be) really
important, which is whether end users can make sense of any of
this.  But we know the answer to that question, with or without
r-components: users don't have much of a clue about the internal
structure of URIs and most of what they think they know is
wrong.  All of the esoteric arguments about the meaning of the
various provisions of 3986 just reinforce that few; I'll start
having hope for end users understanding the details and
implications of URI syntax the day I see a one-sheet
pocket-sized card that summarizes all of the relevant details
and does so accurately.   Whatever we do with a trick syntax
that introduces a delimiter (or delimiter sequence) that makes
more differentiation for URNs than is common for URIs is going
to make that problem worse.

>From that point of view, r-component first is probably going to
be a little more intuitive for some users, and a little less for
some others.  For some members of the first group, the case gets
stronger if they think about <fragments> as something separate
and aside from the URI (taking us back to the other argument).
For the others, this either doesn't make any difference (i.e.,
either it is confusing either way and one better get used to it
or URIs more complex than what 2141 permits are essentially
opaque and only a masochist is going to try to understand what
is going on internally.

> As ugly as %-encoding is, I don't think the requirement to
> encode '?' that appears in r-components is a huge problem,
> given that (as you point out) it's quite likely that non-ASCII
> characters will appear in r-components and they'll also need
> to be encoded.   Given the wide range of characters that
> require encoding that can reasonably appear in an r-component,
> what's the cost of having to encode 0x3f in addition to the
> rest?   But (for reasons which your example makes quite clear)
> neither would I recommend using '?' (encoded or otherwise) as
> a separator between portions (name-value-pairs or whatever) of
> an r-component.

While I don't like "ugly", I'm not nearly as worried about it as
I am about the potential of complete confusion about what the
rules are, especially because I believe that URNs are more
likely to actually be seen and typed by users than the typical
multi-line complex URL.   I had occasion last week to review the
discussions that were a major part of killing IRI work in the
IETF and it involved exactly the same issues we've been going
around on for months as well as more recent ones --
relationships between URIs and fragments; when %-encoding is
required, optional, or prohibited; and so on.   The IRI
experience, IMO, was less about the specifics of those
discussions than that they drove people away until there was
insufficient participation on the broader issues to get the work
done.  I think the desire to not repeat more of that discussion
--and suffer the same fate, which I think is a very real
possibility given participation on the list-- is a very strong
argument to avoid more cases of mandatory %-encoding.

> I also like the idea of being able to copy a URN q-component
> to a URL query component, and a URN f-component to a URL
> fragment, without having to do any re-encoding (and I'm far
> from confident that these translations will only ever be
> needed in one direction).   I strongly suspect that if
> different encodings are used for queries vs. q-components and
> fragments vs. f-components that implementations will botch
> those translation steps and/or behave inconsistently from one
> another.

While I agree with the principle you are suggesting, it is not
clear to me what is has to do with the "where does the
r-component go" discussion unless it is an argument for putting
it after the q-component.

> Regarding name-value pairs: I started out thinking that
> r-components should be name-value pairs.   My current thinking
> is that they're more like expressions in WHERE clauses (and
> some other portions) of SQL SELECT statements.   In other
> words, I think they're more likely to be constraints that are
> imposed on the result set rather than some named attributes.
> You could of course still express such things with NVPs, e.g.
> 
> urn:example:foo:bar??svc=u2c;where=revision_date.gt.%222014012
> 3%22.and.content_type.eq.%22text/plain%22;order=desc;order_by=
> revision_date;limit=10
> 
> but to me, NVPs don't look as useful in r-components as I
> originally assumed they would be.

I think the SQL analogy is pure speculation, that all of the
examples we've seen on the list have been much more amenable to
name-value pairs or other constructions (as is most existing
multiple-term query usage I've seen in URIs) and that mixing the
syntax of URIs (which, as suggested above, almost no end user
understands in detail) with SQL SELECT clauses (which probably
fewer end users actually understand) is a recipe for total
confusion.   In particular, I note that we've seen several real
examples where qualifying clauses are needed to distinguish
between "identify object and return information about it" and
"identify specific metadata and return their values".  And that
lends itself rather better to name-value pairs or something
similar than it does to SQL-like constructions, at least unless
the "target" of the URN is actually a relational database or
part of it.  I also note that SQL-like constructions are not
particularly well adapted to non-relational databases, e.g.,
hierarchical constructions and that we not only have a lot of
those around but some of them are built into URI design.

> (though it strikes me that the above example is so ugly, and
> things could easily get so much worse, that maybe we'd be
> better off encoding the entire r-component in base64)

Sigh.  And make the things totally incomprehensible to anything
resembling a user and, without a computer-based decoder, most
experts.

     john



From nobody Tue May 26 15:04:08 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 93CFE1B3203 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OjYrSxfa_7xS for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:04:02 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (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 6A96A1A8AEC for <urn@ietf.org>; Tue, 26 May 2015 15:04:02 -0700 (PDT)
Received: by iebgx4 with SMTP id gx4so123604ieb.0 for <urn@ietf.org>; Tue, 26 May 2015 15:04:01 -0700 (PDT)
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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xKUmSrqfqgb9wWs4/JYmmpqJdBkR59mR7t4qduGJp6A=; b=GjYzXB7bNUucD36EDkehEzzIfHa16TTZ66rYsjKbG3hEC+gEWx0UY50rPyaeFFy/ZH L4OZzM3ade0IQOc+JPbcs0xOMhKlTuGTdBfTEY+NXv4xeuMV7hvFLK3cwhiMAmV80PbE tp9b9n2tgFImyDAh/tyPFRgclsOJb63cgHMdcj/kLj5RVwHxpZFN7/gP+BNUgIq9Gfbu SDjebM8RcIjn1V5Syg9mkyb1i9QZIMQx0Hh2zc5cVToakxZuBvy6dtKRENUHp0PiTko1 elgA17yQHY2itzDLcRdi35QNzcmTTHFicfE8rpo5ykE/PwhBnwzC+gvWJ+RRzsYPPCff 38Bw==
X-Gm-Message-State: ALoCoQlubC4XzmVjpTn80gF8dDK4/HF6eOVxkPf+Debm0od6UHaMVz1YB5Dim3au+OlGjvViD3A4
X-Received: by 10.50.62.148 with SMTP id y20mr32384499igr.17.1432677841805; Tue, 26 May 2015 15:04:01 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d8sm306722igl.19.2015.05.26.15.04.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 15:04:01 -0700 (PDT)
Message-ID: <5564EDCF.1000203@andyet.net>
Date: Tue, 26 May 2015 16:03:59 -0600
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.6.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Keith Moore <moore@network-heretics.com>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <554FCFAF.6020605@network-heretics.com> <23601CE735D7E5A28E5B230F@JcK-HP8200.jck.com> <554FF76B.5030304@network-heretics.com> <ABC814B799B9975CE692229F@P5>
In-Reply-To: <ABC814B799B9975CE692229F@P5>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/dz6Ti34kKehfAysfNMp1_4oMEuA>
Cc: urn@ietf.org
Subject: Re: [urn] r-component syntax
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 22:04:07 -0000

On 5/25/15 12:14 PM, John C Klensin wrote:
> Keith,
>
> I've been delaying responding to this in the hope that someone
> else would speak up.  But, with the exception of the two of us,
> and Melinda, there has been only silence since her note asking
> about agreement on 10 May.
>
> In the hope that it will start a conversation, or at least
> elicit some "doesn't matter to me, just decide and move on"
> responses from others, a few comments about object order.  I've
> trimmed most of the original notes. For those who need to go
> back and review, see the messages on 10 May at
> http://www.ietf.org/mail-archive/web/urn/current/maillist.html
>
> My apologies in advance to anyone who does not want to get far
> into parsing theory, etc.
>
>
> --On Sunday, 10 May, 2015 20:27 -0400 Keith Moore
> <moore@network-heretics.com> wrote:
>
>> FWIW, I just remembered a 3rd reason for putting r-component
>> to the left of q-component [*]:
>>
>> 3. Putting r-component to the left of q-component means that
>> the portions of the URN that get fed to the resolution service
>> are adjacent.    So it's conceivable that the portion of a URN
>> fed to a resolution service is obtained by removing the
>> q-component and f-component.
>>
>> I said "conceivable" since my current thinking is that the
>> application client actually has to know something about
>> r-components.  E.g. if the content specifies an r-component of
>> "u2r;revision=1.2" the client might need to know that it can
>> satisfy a "u2r" request by finding a location using "u2l" and
>> requesting the resource from that location.   Also, if the
>> service request is not specified in an r-component, the client
>> still needs to know what to request from the resolution
>> service.   This doesn't make me entirely happy, as it is a
>> less-than-clean separation between the resolution service and
>> other client behavior, but it's what makes the most sense to
>> me at the moment.
>
> To a considerable extent, we have gotten into a situation in
> which, despite the "semantics separation" (aka "syntax only")
> decision, we can't make the decisions that would be most natural
> for URNs taken in isolation from [other] URIs.  That is, on
> balance, ok, but what is driving it has been a lot of notions
> and claims about real and hypothetical generic URI parsers,
> including discussions of fragments existing separately from URIs
> and having their own semantics whatever anyone else says, the
> presence of "/" dragging us into relative references, and so on.
> The one effort I know of to determine what is actually out there
> and what it does (Sam Ruby's efforts that you and others might
> have heard discussed on other lists) has not yielded a very
> coherent picture and now, I understand, has been suspended
> because the browser folks didn't seem to be very interested.
>
> I think it is safe to say that, when one gets to the edge cases,
> there is a lot of different behavior out there.  Whether that is
> the result of carelessness or not being able to understand 3986
> is obviously not the issue.
>
> Absent Sam's results (and asking and answering questions I'm not
> sure he has asked), I think it is far more likely that, 3986
> aside, "??" first is going to trigger a syntax error in some
> generic parser whose authors haven't imagined such things than
> getting into the query having shut off any code that treats "?"
> as special.
>
> I don't know if it makes any difference in reality (see below),
> but the distinction does affect the metalanguage.  If
> r-component is to the right, we have
>
>     <query> = <q-component> [ "??" <r-component> ]
> where <q-component> is exactly an RFC 3986 <query> with the
> restriction that <query-text> cannot contain a literal
> appearance of "??" even though "?" is allowed.  That requires a
> two-character look-ahead in the parser, but that should not be a
> big deal these days.
>
> By contrast, if it is to the left, we really cannot use the 3986
> structure any more because
>      [...] ?? foo ? bar
> makes "foo" an r-component and bar a <query> but
>      [...] ? ? foo ? bar
> make the <query> "? foo ? bar".   If one contemplates
> error-prone constructions that could yield weird error messages,
> that could be a winner.
>
> However, to return to fundamentals, there are two ways to think
> about URI parsing.  In one model, it is all hierarchical: the
> generic URI parser separates scheme from everything else, passes
> the whole business to a scheme specific parser and it does its
> thing.  In the other, which has seemed to be the main focus, a
> generic URI parser breaks things into designated bits and passes
> those bits off to whatever needs to deal with them, presumably
> pre-isolated.  In the latter case, it doesn't really make any
> difference how things are organized in the URI string -- in
> principle we could tag everything, put pieces in random order,
> and then recombine the components after parsing -- as long as
> the parsing process is plausible and unambiguous.

+1

With that in mind, it seems to me that r-component to the right and 
q-component to the left would introduce less potential for ambiguity and 
thus is slightly preferable.

Peter

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


From nobody Tue May 26 15:06: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 7C3271B3231 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-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 f84dec2fbDjN for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:06:47 -0700 (PDT)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (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 B795F1B322C for <urn@ietf.org>; Tue, 26 May 2015 15:06:47 -0700 (PDT)
Received: by pdea3 with SMTP id a3so100167924pde.2 for <urn@ietf.org>; Tue, 26 May 2015 15:06:47 -0700 (PDT)
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=KHlVW2sTj7G7B9xTgxBHsw+c2UJKKjZW4ESWMAgRexI=; b=nDRZTAe23TkcUsynfhWlkKqNcCkQlvYDD6oz4eSbQ56GSu4Bc+CK4XLHzU+vJU4Uzg tz/7UUdY71GgmWsxWh5uQmM98q3DzUy0EeqUQan/YbBGGm2sxYAyN/YesPSID1xn3VwI zfP3s1hayTJtiv3p3nTwLaT3RV6rWgPXWRTkPXAVQoVJcT0INKhF8aEpAXuEwZkg2hx7 PfTSOA4AAqDnj8It8Zh6FYpZD61c/AUW4/iUgpKZKoir85obUz92FG+1DMYUKFHz9XTD TnWVko3lt8fT4n16gAYu9ndc69qZsC/fqUWrWO07Qsed4sDnxvxMivxFWo46qZaLCfsr b5vQ==
X-Gm-Message-State: ALoCoQmefy23TIvQ4edQ6uPML7gMbHfZYqz947vqugyl2LzZBuCwVlYoyIOIDmlwuzbcsj0hSYTC
X-Received: by 10.70.133.66 with SMTP id pa2mr53335873pdb.164.1432678007399; Tue, 26 May 2015 15:06:47 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id vn7sm3274108pab.26.2015.05.26.15.06.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 15:06:46 -0700 (PDT)
Message-ID: <5564EE74.9000805@andyet.net>
Date: Tue, 26 May 2015 16:06:44 -0600
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.6.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com>
In-Reply-To: <B75A448A898B521DADE02049@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/lxv_-_zM-6jZDK_f2B9EbvRc9n0>
Subject: Re: [urn] r-component syntax
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 22:06:49 -0000

On 5/10/15 1:27 PM, John C Klensin wrote:
>
>
> --On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
> <melinda.shore@gmail.com> wrote:
>
>> There seems to be agreement on specifying a syntax for
>> r-components, largely as a defensive mechanism against
>> possible future bad behavior. Rather than specifying that
>> space as "reserved" it probably makes more sense, and is more
>> consistent with IETF practice, to distinguish between things
>> that are used as part of URN processing and things that are
>> opaque to URN processing and passed through without being
>> touched (thanks to John for providing some clarifying thoughts
>> on this).  Is there agreement on this?
>
> Melinda, thanks.
>
> As a shortcut to save a bit of time, I think that, if we decide
> to allow r-components, the syntax for in section 3 of 2141bis-11
> would change so that the changed productions would read:
>
>         q-component = "?" query [ "??" r-component ]
> 	       Note that <query> in the above cannot contain "??"
>         r-component = query
>
> That could also be done in a somewhat more complex way to
> eliminate the note, e.g., as
>
>         q-component = "?" q-string [ "??" r-component ]
>         r-component = r-string
>
> where the definition of q-string would repeat the text of
> Section 3.4 of RFC 3986 but explicitly exclude, and terminate
> on, "??" as well as "#" and r-string would match that Section
> 3.4 text.
>
> It could also be done more like:
>
>        namestring    = assigned-name
>                        [ q-component [r-component] ]
>                        [ f-component ]
>         q-component = "?" q-string
>         r-component = "??" r-string
>
> If anyone who thinks we should adopt r-components has a strong
> preference among those alternatives, please say so, otherwise,
> Peter and I will draw straws or equivalent.

I prefer the latter - it feels more readable.

> Independent of the above, if we are going to adopt r-components,
> we will need some text to describe them and some examples,
> preferably real.  Peter and I can make that up, but suggestions
> from WG participants who have thought deeply about this would be
> much better.

Yes, text and examples would be appreciated. (Although any examples are 
quite speculative at this point.)

Peter

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


From nobody Tue May 26 15:19:55 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 227791B3281 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:19:53 -0700 (PDT)
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 kOQiavscabES for <urn@ietfa.amsl.com>; Tue, 26 May 2015 15:19:51 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (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 368D41B326B for <urn@ietf.org>; Tue, 26 May 2015 15:19:51 -0700 (PDT)
Received: by iepj10 with SMTP id j10so278004iep.3 for <urn@ietf.org>; Tue, 26 May 2015 15:19:50 -0700 (PDT)
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=cYedDWz3cgu2Zu/OsN0gCNKeVvkwSkaHoGHnX1WJ1JM=; b=bFF/CI8eiTjoaawwNyoIZFNE+nIO4yJxH0J7EfFJlj674e3HepaRf5Zcxouc6HdUVX /ToPFgbLqMoRugXavAoO7X3az/bz1JgRjYjUmdwQFfgZw0rj064LQud2TAPerDi27EQi YMi7NC0cb03jCCtv41kg7rj8B2V2L9rtXQ0GM4nyia/VUgngNfC/oZvAD3o7Wlt6RTrx P+nJWH+66QIZWIU9NkGUGicFIC+hQdt5cocjgnrVat0DeXkv4hJMEfc6sM950ML0uqsX M/d0y6KBajQdAlo8JdUC/AFCfvk/l9HubNOrQ74N8cjWeByKxW7VWmU7I9yu6/Yt3Tno WsAw==
X-Gm-Message-State: ALoCoQnHntYeqbG1CwmlvuDurkQjp0dP8mOJpydGnozU6AzDSNgoDWEazlkINpo5z5nD3gBAsIYT
X-Received: by 10.50.43.137 with SMTP id w9mr7612068igl.30.1432678790627; Tue, 26 May 2015 15:19:50 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id r4sm352556igh.9.2015.05.26.15.19.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 15:19:49 -0700 (PDT)
Message-ID: <5564F184.7080206@andyet.net>
Date: Tue, 26 May 2015 16:19:48 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com>
In-Reply-To: <552FAB04.1040205@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/dR4YAhUwER1WVM3eLpLANA7CEbg>
Subject: Re: [urn] Namespace consensus and registrations
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 22:19:53 -0000

On 4/16/15 6:28 AM, Keith Moore wrote:
> On 04/15/2015 11:02 PM, Peter Saint-Andre - &yet wrote:
>>> Perhaps the simplest and clearest response that I can offer is that I
>>> don't care what the label is ("Expert Review" vs "IETF Consensus" or
>>> whatever), so much as I care that there be an opportunity for public
>>> review.   If the process specified for "Expert Review" requires that
>>> there be public review, that the opportunity for review is advertised in
>>> IETF and other appropriate fora, and especially if we can somehow
>>> arrange that the "expert(s)" considering the results of that public
>>> review really do understand the subtleties of URNs (admitting that this
>>> is really difficult), I'm okay with that and think it's about the best
>>> that we can do. It's potentially even better than "IETF Consensus"
>>> because while that does require public review, nothing about the process
>>> for choosing Area Directors ensures that IESG will have URN expertise.
>>>
>>> So I'll be very interested to read -11's text on this subject.
>>
>> Even before version -11, 2141bis (and before that 3406) stipulated
>> that discussion was to occur on the urn-nid@ietf.org list. I would
>> prefer that we deprecate the urn-nid list and have discussion on this
>> list, but in any case, yes, public review is very much part of the
>> process.
>
> Given the apparently small number of active participants on this list,
> I'm not sure that's the best way to ensure wide review among the
> communities who would be most concerned with maintaining URN sanity.   I
> realize that having narrowly-focused but yet mostly-unmoderated mailing
> lists that can occasionally blow up is the IETF Way, but there might be
> some parties who would just like to get something similar to Last Call
> announcements for URN namespaces without having to subject themselves to
> arbitrary amounts of email traffic.  Even within IETF, there seems to be
> a set of people who are interested in and knowledgeable about URNs who
> don't participate on this list.
>
> Maybe there could be two lists, urn-announce and urn-discuss? (perhaps
> this list could serve the latter role)   urn-announce traffic could be
> forwarded to urn-discuss, but not vice versa?   Any announcements of
> proposed URN changes could be sent to urn-announce but would request
> that responses be sent directly to the expert(s) evaluating the proposal
> rather than as replies to the urn-announce list.

In the interest of reducing complexity, I would prefer to have one list 
and to have it be this list (urn@ietf.org).

> (Also, the comment period should last long enough that any organization
> that cares would have time to discuss things within its membership and
> form its own opinion, which probably means a comment period should last
> considerably longer than a month.)

Right now, draft-ietf-urnbis-rfc2141bis-urn has no time limit on reviews 
(RFC 3406 said it was 2 weeks). It might be best to say that the expert 
reviewers need to reply within 2 weeks, not that all discussion needs to 
be completed in 2 weeks (which is unrealistic anyway).

Peter

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


From nobody Tue May 26 16:09:57 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 21E041B3300 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 16:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.201
X-Spam-Level: 
X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 2UuiyWRSsgPF for <urn@ietfa.amsl.com>; Tue, 26 May 2015 16:09:54 -0700 (PDT)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (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 3C2CA1B32FD for <urn@ietf.org>; Tue, 26 May 2015 16:09:54 -0700 (PDT)
Received: by iebgx4 with SMTP id gx4so1077115ieb.0 for <urn@ietf.org>; Tue, 26 May 2015 16:09:53 -0700 (PDT)
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=zkMioc+P+arzIo2NgwzBNlK4xcEP4KEivZZFmCifwa8=; b=JGwE4hTQlX8L6GgPrBsmxaUlgWpMK0L9yE+OvLACy5oW3RbkNEaBMGmlvRq4Tu+qbC VyoT20NMti5eM1nYTDsKhC72agBYXgMlExUoJRUyAG1Vo4v0JPgPA8B2ohWoMaDwTsHn U3b6qKJL9zkyRpShwstVgk84ckcDS4d5JDMkeJb4voq4wIdJeuQcYW7Q4XL5gTJEMnyN R+tL8xt22/t9SkbQCzUx57gGXGGXycBD+f1F9ZAVuLfb3+F0S0WLyqcHzLibmWV8yyCL MdjOw2LNOGJU5Tf8vbuPVnQjAyLRyLyhXIXmn7gvAPRGJOGdr02SmAaGuuNmAPFMLVzG lmBQ==
X-Gm-Message-State: ALoCoQk6IvdKo4pF1vK4ERjxD5OwPUd+tpZ92LeROp/EBEW79rdV+MZ6Eo+JmKs1lPkmzYaBntKq
X-Received: by 10.43.178.195 with SMTP id ox3mr166330icc.10.1432681793697; Tue, 26 May 2015 16:09:53 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j84sm12153294ioo.3.2015.05.26.16.09.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:09:52 -0700 (PDT)
Message-ID: <5564FD3F.9070302@andyet.net>
Date: Tue, 26 May 2015 17:09:51 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>,  "urn@ietf.org" <urn@ietf.org>
References: <55430DDE.5070104@network-heretics.com>
In-Reply-To: <55430DDE.5070104@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/GMMJcajykLjUhhqSL4hOC--bM3A>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 23:09:56 -0000

On 4/30/15 11:23 PM, Keith Moore wrote:
> For reference, the current (-11) text of section 7.3.6:
>
> 7.3.6.  Resolution
>
>     The "Resolution" section MUST specify whether resolution mechanisms
>     are supported or anticipated for URNs assigned within the namespace,
>     and if so SHOULD specify or reference the rules governing those
>     mechanisms.
>
>     In particular, if resolution is anticipated and resolver registration
>     of some kind is required, for example via a Resolution Discovery
>     System [RFC2276], this section SHOULD list the requirements for
>     becoming a recognized resolver of URNs in the relevant namespace.
>
> I believe this section needs work for multiple reasons:
>
>   * resolution is, fundamentally, not a per-namespace operation. A
>     namespace can support a resolution service for URNs that it assigns
>     if it chooses to do so (and it will likely have high quality
>     information), but any other party can also provide a service to look
>     up URNs from any namespace.   Tying resolution services to any
>     specific party degrades the persistence of URNs, because a URN
>     should remain valid and potentially resolvable even if its namespace
>     (or the organization operating it) ceases to exist, or even if its
>     namespace imposes barriers to use of its resolution services.

URNs from many NIDs are not intended to be resolvable at all, i.e., they 
are what we have termed "abstract designators". Most or all of the URNs 
used as XML namespace names are abstract designators.

>   * Rules for resolution should not be namespace-specific, because this
>     discourages general-purpose resolution services.   (A namespace can
>     of course recommend specific resolution services and/or specific
>     protocols for use with those services, but this section is worded as
>     if resolution itself were some sort of fundamentally
>     namespace-specific operation)
>
> Here's a stab at alternate text:
>
> 7.3.6. Resolution
>
>     The "Resolution" section is optional.

It seems safer for all sections of the template to be mandatory. If no 
resolution is envisioned (primarily because the URNs for a given 
namespace are intended to be abstract designators), then it's good to 
make that explicit here.

> If included, it SHOULD
> specify whether the namespace intends to operate or recommend any
> resolution services for URNs using that namespace.

I don't think a namespace can operate a resolution service! :-) But I 
suppose you meant something like "the organization responsible for a 
namespace".

>  In addition, if the
> namespace intends to implement registration for publicly-advertised
> resolution services (for example using a system like that described in
> [RFC2276]) the Resolution section SHOULD list the requirements for being
> publicly-advertised using that mechanism.

I think that's acceptable. I know Leslie is concerned about rogue 
resolution services, but if the organization that assigns URNs in a 
namespace is able to specify its requirements for appropriate resolution 
of those URNs, then we have some mechanism for determining if a service 
is resolving those URNs in a way that is consistent with the assigning 
organization's intent.

Peter

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


From nobody Tue May 26 16:17:27 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 8F3711B32ED for <urn@ietfa.amsl.com>; Tue, 26 May 2015 16:17:25 -0700 (PDT)
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 YFZl5Mq7Kdol for <urn@ietfa.amsl.com>; Tue, 26 May 2015 16:17:23 -0700 (PDT)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.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 A48241B32EB for <urn@ietf.org>; Tue, 26 May 2015 16:17:23 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so1226538igb.0 for <urn@ietf.org>; Tue, 26 May 2015 16:17:23 -0700 (PDT)
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=pVJaBpVpvbC5838zYvurt9RSJNGGgtWe+Ze6R376UfY=; b=VnuaLGdLWYRYFGZm0ixZgNfWfpO7kzzW/xEkWJpNlyn866i+yJhA6PCQ5zfYDIhMKD dJrdAZ3uBuVcj99XyKqiK0pqMQvcU9G4OBjX254XmfKkYNqNCI0ZH/rBqigfj828Drgi xudfikf+sYBD9pf5EUA5mDM0MN43urFjlGszuK+ajDr7f0zIUMycMEmNYXer1wZvDkSv MYQjHG1MSomilCR52PFB+C8/OFYjrFqK4DfQt2DR2rYC8g6EmyR/BfaiBKpMtylFID3s XLBZq/PKQ65ztM2sfeEBPhhOLjbXFdMRAOBML90XtrvUAgH/Nne/sXaL11ybgbg3d7cj ubLQ==
X-Gm-Message-State: ALoCoQkGPba1UZS5iwCndOF2iGUH0QNKPGHfTWkMD8s6rj/S8VUFoiQvwTYqNGuav1Gkfb8o8n96
X-Received: by 10.107.29.148 with SMTP id d142mr39397910iod.9.1432682243130; Tue, 26 May 2015 16:17:23 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n14sm12154936ion.5.2015.05.26.16.17.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:17:22 -0700 (PDT)
Message-ID: <5564FF01.70204@andyet.net>
Date: Tue, 26 May 2015 17:17:21 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>,  "urn@ietf.org" <urn@ietf.org>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net>
In-Reply-To: <5564FD3F.9070302@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/2QWcMZok3Z8C1mPtMFgAm0P-Qus>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 23:17:25 -0000

On 5/26/15 5:09 PM, Peter Saint-Andre - &yet wrote:
> On 4/30/15 11:23 PM, Keith Moore wrote:
>> For reference, the current (-11) text of section 7.3.6:
>>
>> 7.3.6.  Resolution
>>
>>     The "Resolution" section MUST specify whether resolution mechanisms
>>     are supported or anticipated for URNs assigned within the namespace,
>>     and if so SHOULD specify or reference the rules governing those
>>     mechanisms.
>>
>>     In particular, if resolution is anticipated and resolver registration
>>     of some kind is required, for example via a Resolution Discovery
>>     System [RFC2276], this section SHOULD list the requirements for
>>     becoming a recognized resolver of URNs in the relevant namespace.
>>
>> I believe this section needs work for multiple reasons:
>>
>>   * resolution is, fundamentally, not a per-namespace operation. A
>>     namespace can support a resolution service for URNs that it assigns
>>     if it chooses to do so (and it will likely have high quality
>>     information), but any other party can also provide a service to look
>>     up URNs from any namespace.   Tying resolution services to any
>>     specific party degrades the persistence of URNs, because a URN
>>     should remain valid and potentially resolvable even if its namespace
>>     (or the organization operating it) ceases to exist, or even if its
>>     namespace imposes barriers to use of its resolution services.
>
> URNs from many NIDs are not intended to be resolvable at all, i.e., they
> are what we have termed "abstract designators". Most or all of the URNs
> used as XML namespace names are abstract designators.
>
>>   * Rules for resolution should not be namespace-specific, because this
>>     discourages general-purpose resolution services.   (A namespace can
>>     of course recommend specific resolution services and/or specific
>>     protocols for use with those services, but this section is worded as
>>     if resolution itself were some sort of fundamentally
>>     namespace-specific operation)
>>
>> Here's a stab at alternate text:
>>
>> 7.3.6. Resolution
>>
>>     The "Resolution" section is optional.
>
> It seems safer for all sections of the template to be mandatory. If no
> resolution is envisioned (primarily because the URNs for a given
> namespace are intended to be abstract designators), then it's good to
> make that explicit here.
>
>> If included, it SHOULD
>> specify whether the namespace intends to operate or recommend any
>> resolution services for URNs using that namespace.
>
> I don't think a namespace can operate a resolution service! :-) But I
> suppose you meant something like "the organization responsible for a
> namespace".
>
>>  In addition, if the
>> namespace intends to implement registration for publicly-advertised
>> resolution services (for example using a system like that described in
>> [RFC2276]) the Resolution section SHOULD list the requirements for being
>> publicly-advertised using that mechanism.
>
> I think that's acceptable. I know Leslie is concerned about rogue
> resolution services, but if the organization that assigns URNs in a
> namespace is able to specify its requirements for appropriate resolution
> of those URNs, then we have some mechanism for determining if a service
> is resolving those URNs in a way that is consistent with the assigning
> organization's intent.

I propose the following text:

    The "Resolution" section MUST specify whether resolution mechanisms
    are intended or anticipated for URNs assigned within the namespace
    (e.g., URNs within some namespaces are intended to act as abstract
    designators and thus are not intended to be resolved).

    If resolution is intended, then this section SHOULD specify whether
    the organization that assigns URNs within the namespace intends to
    operate or recommend any resolution services for URNs within that
    namespace.  In addition, if the assigning organization intends to
    implement registration for publicly advertised resolution services
    (for example using a system like that described in [RFC2276]), then
    this section SHOULD list or reference the requirements for being
    publicly advertised by the assigning organization.

Peter

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


From nobody Tue May 26 19:12:40 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 989741A3B9B for <urn@ietfa.amsl.com>; Tue, 26 May 2015 19:12:38 -0700 (PDT)
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 xrNMD2o5b257 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 19:12:36 -0700 (PDT)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (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 4FECA1A1BC6 for <urn@ietf.org>; Tue, 26 May 2015 19:12:36 -0700 (PDT)
Received: by obbea2 with SMTP id ea2so88828825obb.3 for <urn@ietf.org>; Tue, 26 May 2015 19:12:35 -0700 (PDT)
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=zgyCdLIHqrlMlmyEzzrrW09I9ledeeL+Tv/UAgcWjhY=; b=hwPNhShoDeC/uBLSSG4uRYAZVPfR7Pjn+8dA8bYANrchH3IYVDtR3QbkRGWp6yaAPF CCtqQZMbAn+2YFB/EGU0waIChNh3jU7YNgPS6zM7JygX+TE5Dw3g00qwJJ4SuVkqDkFh YHkjcWGF5as0BWUHBNnEkbsm71ShiH+aWTB6Rw1LXe+ocLmwFA9Wfn/xxAXo40qRtCwb /LMp3ywBsc9FByJpX1JOFEyA+EKMAQ1eJTnNLfay7FUSOT/+SRNj+eu4tZBHfoSIBgLi 1RHuoQfcY4UsngCskktSeOKnPXdynUBCRjduwVryMVFFgkgq6FMCrBVC1jx3mNrtlTwk 66NQ==
X-Gm-Message-State: ALoCoQljJK11Gv8wY4FlHT1HyF681QLaALxrm1Ld3QXLPSOx8BPUXxAjHkavxBYDfSUOmwnpy1On
X-Received: by 10.202.227.130 with SMTP id a124mr23398289oih.59.1432692755586;  Tue, 26 May 2015 19:12:35 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id kv2sm10112277obc.20.2015.05.26.19.12.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 19:12:33 -0700 (PDT)
Message-ID: <5565280F.1070602@andyet.net>
Date: Tue, 26 May 2015 20:12:31 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  John C Klensin <john-ietf@jck.com>, "Svensson, Lars" <L.Svensson@dnb.de>, urn@ietf.org
References: <24637769D123E644A105A0AF0E1F92EFFAC84913@dnbf-ex1.AD.DDB.DE> <55079325.1010300@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC85A6E@dnbf-ex1.AD.DDB.DE> <5509ABC6.2040707@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC923DC@dnbf-ex1.AD.DDB.DE> <5514CE1E.4010201@andyet.net> <24637769D123E644A105A0AF0E1F92EFFAC95C26@dnbf-ex1.AD.DDB.DE> <4442EEA947F0A2535EE886EE@JcK-HP8200.jck.com> <55312E47.6050309@thinkingcat.com>
In-Reply-To: <55312E47.6050309@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/FbiQZCqlxa0zwqpeaXYTgEjfvOk>
Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10
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, 27 May 2015 02:12:38 -0000

On 4/17/15 10:01 AM, Leslie Daigle (ThinkingCat) wrote:
>
> Coming back to this -- I do think that resolves a major issue in the
> document.  Re-reading the March 31 document this morning, it struck me
> that it doesn't define what an NSS is.
>
> There is verbiage about what an NSS is not. [1]  In the example
> discussed, the NSS is "".
>
> In RFC2141, the NSS *is* the identifier.  It must be unique and
> persistent in its identification of a resource.   Which is a bit
> ridiculous for "".  If the document was updated as proposed here, I
> would think it would be appropriate to have guidance about
> "assigned-name" being the identifier alluded to in:
>
>
>  > A URN namespace is a collection of identifiers that obey three
>  > constraints.  Such a namespace is (1) unique, (2) assigned in a
>  > consistent way, and (3) assigned according to a common definition.

That's a good point. I'll strive to make that a bit clearer in the next 
version. (I'm now holding the pen for -12.)

Peter

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


From nobody Tue May 26 19:35:34 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 6B30C1AD0BA for <urn@ietfa.amsl.com>; Tue, 26 May 2015 19:35:33 -0700 (PDT)
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 EFitFlIQWmE2 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 19:35:32 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.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 DA46C1AD0B6 for <urn@ietf.org>; Tue, 26 May 2015 19:35:31 -0700 (PDT)
Received: by pdfh10 with SMTP id h10so104452506pdf.3 for <urn@ietf.org>; Tue, 26 May 2015 19:35:31 -0700 (PDT)
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=qOjPjUtGvmT2fdxYoWDbzhs5IpFk3BajO17gZYKQztw=; b=NJkMyf3VS/X7n5+moefu9ywFhoGpgp3NKmBoqT++0RONovpGW57xIJh9M3w7GKdToJ QVkW8RCUFLicp+5LtPK8BIoyj81KMjGT8lVECqBiMu4klt1TI6O66ttrC/E3ECmVfwAF QvdbdOhzFLbWzjEbH++I+xbAHCSXMZ3cGOmbkwjit5THO1sqNjlZUZn3abTR6zmPQ1SK PZWX8A2vMQVqh8T2mPy7X7etyxc9Jg/ybCd5WlJrQnrwI1WGjEO0gzydBlHypxYkpoV6 coxO5tUWO3f0aFox6xG1vw2GuUBIO0wvFVQYDz3fSXsxBnF1NHW6/oyqHwb+YeEQ7rdM sExA==
X-Gm-Message-State: ALoCoQmP3/jl6EXaUFEjHdYCEaQKepGs+VaqixCtblBzh4+wGbmAhKSsKIfljm89gws8MFjbHOKG
X-Received: by 10.70.128.130 with SMTP id no2mr54402590pdb.95.1432694131502; Tue, 26 May 2015 19:35:31 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id je4sm671435pbb.17.2015.05.26.19.35.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 19:35:30 -0700 (PDT)
Message-ID: <55652D6F.3050506@andyet.net>
Date: Tue, 26 May 2015 20:35:27 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com>
In-Reply-To: <55312E53.2010605@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/wuCWn1HWh6jfO7QaBh48SllZFVI>
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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, 27 May 2015 02:35:33 -0000

On 4/17/15 10:01 AM, Leslie Daigle (ThinkingCat) wrote:
>
>
> I think this is a rational, if hypothetical, reason for p-components,
> and my requirement would be for the document to be clear about the use:
>
>> For those namespaces that need additional qualification (beyond
>> the traditional NSS) that still participates in equality
>> checking, that has so far left p-components as the only logical
>> option.  Perhaps there is some other syntax that would do the
>> job --a hypothetical X-component -- but, so far, no one has
>> proposed one and the logic of 3986 is such that I think we can
>> expect any such syntax proposal to produce cries of pain about
>> generic URI parsers and related topics.
>
>
> IMO, that can be achieved by being clear about what the NSS is, assert
> that relative URNs are not expected/permitted, and attest that "/"
> should not be used in a URN simply because one is importing a namespace
> that happens to use them and it's a matter of syntactic convenience not
> to escape them with %-encoding.

How is this for proposed text?

    The namespace specific string (NSS) is a unique identifier that is
    assigned in a consistent way and that conforms to the definition of
    the relevant namespace.  The combination of the NID (unique across
    the entire "urn" scheme) and the NSS (unique within the namespace)
    ensures that the resulting URN is a globally unique URI.

    This document modifies the syntax of the NSS to allow the following
    characters: "/", "~", and "&".

    In particular, allowing the "/" character effectively makes it
    possible to encapsulate hierarchical identifiers from other naming
    systems.  For instance, consider the hypothetical example of a
    hierarchical naming system in which the identifiers take the form of
    a series of numbers separated by the "/" character, such as "1/406/
    47452/2".  If the naming authority for such identifiers were to use
    URNs, it would be natural to place the existing identifiers in the
    NSS, resulting in URNs such as "urn:example:1/406/47452/2".
    Nevertheless, it is not appropriate the "/" character be used in a
    URN merely because the URN namespace is importing a naming system
    that happens to use the character; it is simply a matter of syntactic
    convenience not to escape the character with percent-encoding.

Peter

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


From nobody Tue May 26 20:01: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 ECBBC1AD26E for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:01:48 -0700 (PDT)
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 HbvfPHHWaApd for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:01:47 -0700 (PDT)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 29D251AD21C for <urn@ietf.org>; Tue, 26 May 2015 20:01:47 -0700 (PDT)
Received: by igcau1 with SMTP id au1so4156492igc.1 for <urn@ietf.org>; Tue, 26 May 2015 20:01:46 -0700 (PDT)
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=34OUDqDBHpiYaaRzgBg6ey637CetmoYUXmjLxRm1Xf8=; b=YGs7fogejLz83r6hQmLUMCGNIbCzLuetyucCL7fKsgOZMiXeQEPEL/Bd849TdDaAaV E8xMCHibeD6GDYymBP2fWuh/uHkfGEufxTXyt27+g3b23dxpuZwTEDxK0/fuHMorMSku yUTNjnSyPUCLmjsxhQXOFvBbznl0FYqzX9TKodOi2XrRgKbT9KDHL8LQeEz8N5lusYCP psan4mLvcBUb7HycFIAM1wSybXNedcuUez0PX2LM5042zKxK9fNptgWcTMgBcAryuV21 wiKS/sOMJOPiJUaVFoAkbVjWW3Snp0prO8r7R6JEvUoUQlr/iRJ6B6OyliT2Sx1vkX1L lmcw==
X-Gm-Message-State: ALoCoQmXldCAY0rBNJeor7acmpdwenJE2Pe6ung2/BlZ0GDMbzpvDgXnph6+l7Jc4QXHEMrYWzgJ
X-Received: by 10.50.18.39 with SMTP id t7mr1069891igd.3.1432695706560; Tue, 26 May 2015 20:01:46 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id x4sm12553686iod.26.2015.05.26.20.01.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 20:01:44 -0700 (PDT)
Message-ID: <55653396.1030008@andyet.net>
Date: Tue, 26 May 2015 21:01:42 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com>
In-Reply-To: <5536BEF9.4060603@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/78hKQSNHvlBx1RJnPUOczkykkFs>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 03:01:49 -0000

On 4/21/15 3:19 PM, Keith Moore wrote:
> On 04/21/2015 12:32 PM, Leslie Daigle (ThinkingCat) wrote:
>>
>> [Apologies for delayed/lost e-mail -- mail server issues. ]
>>
>> In-line...
>>
>> On 4/17/15 8:05 PM, Keith Moore wrote:
>>> On 04/17/2015 05:27 PM, Leslie Daigle (ThinkingCat) wrote:
>>>> Hi,
>>>>
>>>> Thinking through the r-component idea a bit...   I think your
>>>> argumentation for r-components is pretty compelling, especially as we
>>>> work to make clear why f-components don't fit that particular bill.
>>>> However, I am more than a little concerned about getting too complex
>>>> and bolting stuff on at this point.
>>>>
>>>> I won't argue that DDDS has been used for just about everything
>>>> *except* providing the standard for URN resolution, but in working it
>>>> out we I'm sure you recall we did did actually talk through
>>>> "resolution services" (for ease of reference for anyone who missed it
>>>> -- https://tools.ietf.org/html/rfc2483).
>>>>
>>>> Again, not quite what you are describing now (I read you to be
>>>> thinking more about parameters one would send, not services one would
>>>> request), but perhaps enough to illustrate that there is a whole farm
>>>> of things one might wish to consider if one stops and thinks about
>>>> using URNs in action.
>>>>
>>>> I think pursuing r-components as part of this document would slow this
>>>> one down a fair bit.
>>>>
>>>> Is there a way to leave enough of a hook in the syntax to pursue
>>>> r-component as a separate document?  (BTW...  does "??" actually fly
>>>> with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).
>>>
>>> "Leaving [just] enough of a hook" is exactly what I want to do in this
>>> document.  I think that means:  (a) define the syntax for URNs including
>>> that of r-components, (b) explain the role of r-components in URN
>>> resolution, and (c) set up an IANA registry of r-component names and
>>> values.   Maybe also (d) explain how this is syntax compatible with
>>> 3986.  I think that's about enough for 2141bis.
>>>
>>
>> I think that's considerably more than a hook, it's in danger of being
>> a fishing expedition.
>>
>> I might support (a) and (b), (d) is a requirement, but (c) is a real
>> reach unless or until there's  (electronic) ink on (digital) paper for
>> where to go with this idea, as a general idea, with consensus support.
>>
>> Otherwise -- it's one person's great idea, and if you don't happen to
>> finish writing it down, someone else will come along in a decade and
>> fill it in very differently than anything you might ever have thought
>> of (or that we, collectively, might have agreed to).
>
> It's reasonable to want to look at actual text.   And we've certainly
> seen a lot of examples of people coming along in a decade and filling in
> things very differently than originally conceived, in this space.
>
> Of course it's not the registry which is difficult to set up, it's the
> rules for what can go in the registry.

I agree with Leslie that a registry of r-component name-value pairs is 
way out of scope for now - even establishing the registry. Let some 
future (resolution-specific) document do that, if it's even needed.

Peter

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


From nobody Tue May 26 20:06:49 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 AFAC01B33FA for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 wFvfWrKYXXVE for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:06:46 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE451B33F9 for <urn@ietf.org>; Tue, 26 May 2015 20:06:46 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4FA3420BEE for <urn@ietf.org>; Tue, 26 May 2015 23:06:45 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 26 May 2015 23:06:45 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=YyEHyT3/p1ZO0gZ 6iNn32YNQdZY=; b=V5r4wHi0NuNBvpam80Gh6k+KD6dPZk18cHT4AoqrC/YAQyF 888wVADUUerXjFX4ak1J7jdPKH/ypenVfNucCst0oFmMizNV318Jr+Y/RldRdSbo u3WYVsNPymO321RGqXTA9IjIoPMsmJ2hTSVXSAcYeIFgvrxoKanQACEu4yPw=
X-Sasl-enc: qZ7m/nxVRTrfNfaKCm/BDLzgyER9GxPeusJ7XeiBBdG8 1432696005
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D8DD6680178; Tue, 26 May 2015 23:06:44 -0400 (EDT)
Message-ID: <556534B6.4020509@network-heretics.com>
Date: Tue, 26 May 2015 23:06:30 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com> <55653396.1030008@andyet.net>
In-Reply-To: <55653396.1030008@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/3QCUAvTuClgHUHYoudc6zOlP0IM>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 03:06:47 -0000

On 05/26/2015 11:01 PM, Peter Saint-Andre - &yet wrote:
> I agree with Leslie that a registry of r-component name-value pairs is 
> way out of scope for now - even establishing the registry. Let some 
> future (resolution-specific) document do that, if it's even needed.
So in other words, it's perfectly okay to have no interoperability for 
the meaning of r-components?

Keith


From nobody Tue May 26 20:18:14 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 9E38C1A008A for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:18:12 -0700 (PDT)
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 FIu-gvsXcHmk for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:18:11 -0700 (PDT)
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 16ABF1A0084 for <urn@ietf.org>; Tue, 26 May 2015 20:18:11 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so74553370igb.1 for <urn@ietf.org>; Tue, 26 May 2015 20:18:10 -0700 (PDT)
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=TmYO947NG2rdfvLmBMYa0L/74JlCAkruQkbQsBZrEas=; b=lOtE/J65RDSNGNpUbnghIr2+OPlTz/g0CL8SFJPTN3cH/K/mdq3fkUwcSIJbzBFuYZ XU8t5V6nIuo8MkDdoMpxeaz9lXQKG/zD3gdBnFzPurU5G+/pw9VW3yWomoGyqYH7FC0g PhTqwCIr6BQZceRw9okgRi0cGHJR/S1Q/Dc/n3ey5iagPdCPPb1Gbh1yQ1kz100WUamO X7LBS79jdS6Q84kYmaurezaJE0O26yuXvScHCSUkdvonuTj2Su2Xmzn4jvg1BdT942Sn pgReZwiUeY6OS0WaJ0m1SqUETCksOOis0Ku+KV2plIaIlQZrzvLtAGubPyk2njBn+Yhm WxoQ==
X-Gm-Message-State: ALoCoQklTXmdev4NHEPQbcFiRyyf44Y43wuYnYczMcngHZtkTPM3R7MNhL2uFiMxjFdmni6kkZR8
X-Received: by 10.42.164.7 with SMTP id e7mr942655icy.70.1432696690496; Tue, 26 May 2015 20:18:10 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h138sm12600270ioe.2.2015.05.26.20.18.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 20:18:09 -0700 (PDT)
Message-ID: <5565376F.4080802@andyet.net>
Date: Tue, 26 May 2015 21:18:07 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com> <55653396.1030008@andyet.net> <556534B6.4020509@network-heretics.com>
In-Reply-To: <556534B6.4020509@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/poOoThuUOwt1wA2Z47z0CD5iHdc>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 03:18:12 -0000

On 5/26/15 9:06 PM, Keith Moore wrote:
> On 05/26/2015 11:01 PM, Peter Saint-Andre - &yet wrote:
>> I agree with Leslie that a registry of r-component name-value pairs is
>> way out of scope for now - even establishing the registry. Let some
>> future (resolution-specific) document do that, if it's even needed.
> So in other words, it's perfectly okay to have no interoperability for
> the meaning of r-components?

Just as I am not opposed to motherhood and apple pie, I am also not 
opposed to interoperability. However, we don't know anything about 
r-components. They're a hook. How can we start defining name-value pairs 
for services that are themselves undefined?

Peter

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


From nobody Tue May 26 20:30:19 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 CDA771A016A for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level: 
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 snglxDLKzGJm for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:30:16 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 E6BE11A0167 for <urn@ietf.org>; Tue, 26 May 2015 20:30:15 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so4524118igb.0 for <urn@ietf.org>; Tue, 26 May 2015 20:30:15 -0700 (PDT)
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=Y8lW8BMpZv71r5MBX4u57gipRRqOeMAod5mUNjWP6Yw=; b=CvVAsQjGymI3bHJef8nA9vGwh4Hjg07xRzLmYnm/QHMrW0KTJZDlZShBBnFbk1Faag qVKJ21UTHpr7mQIZgY+Oqn43ca8gr8JOmmR9kubsgCFj0pLe2T41II+a43wzkH33GiwB RRAiUH/+U516uwQQjf6jYQvA387CzJrEckzdYcjLJg4YIawWmXVu/dbYxX8yd83Ko42q f2QydF3e6Xdhv5yA2Dq3H/sxAu4fz6m9b8HtsAeYZW2SG8hmmBMh2L06kMRe58+0f7gP LRtRCkOQX02FGJ2O8u3x23zieGhGtJjfjlVquWxLr7QNbTjIb8TRO+JR6GfL57MMTxNf 3N9w==
X-Gm-Message-State: ALoCoQkX2gMys2QG6kY1UfDN96wJWsUAIuaB1GhCZb1SXYeZQYB5fTN7KbKL2u2t7h0eSdkMbH3j
X-Received: by 10.107.14.193 with SMTP id 184mr3623356ioo.15.1432697415150; Tue, 26 May 2015 20:30:15 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 137sm12594655ioo.29.2015.05.26.20.30.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 20:30:13 -0700 (PDT)
Message-ID: <55653A44.2070701@andyet.net>
Date: Tue, 26 May 2015 21:30:12 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  Keith Moore <moore@network-heretics.com>, "urn@ietf.org" <urn@ietf.org>
References: <55388B0E.3080806@network-heretics.com> <553FA044.2000206@thinkingcat.com>
In-Reply-To: <553FA044.2000206@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/qCHeUBCdXEBNF4JZ4asl0FKxggY>
Subject: Re: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
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, 27 May 2015 03:30:18 -0000

On 4/28/15 8:59 AM, Leslie Daigle (ThinkingCat) wrote:
>
> I've been chewing on the proposed f-component and q-component text.

Me too. I will chew on it further and try to formulate even clearer text 
based on what Keith has so helpfully proposed.

> I
> think we need to be clear(er) about the overall concept:  how do
> fragments and queries fit with instance-independent naming of resources?
>    I think it was, indeed, progress to focus on their use as applied to
> resolution to content (via URN or URL), but I don't think the concept of
> composing parts is quite captured in the proposed text.

Could you perhaps describe a bit more what you mean by "the concept of 
composing parts"?

> It reads as a
> bunch of complex rules, from which people might (or might not) derive a
> shared concept.

Agreed that the shared concept is key here.

> Example:  If I have a URN for a particular article, that could resolve
> to a URL or a URL for a book with a fragment ID for the article's
> position within the book.   Suppose the f-component on the URN is for a
> particular section of the article.  By the rules outlined below, that
> resolves correctly IFF the resolution process goes for content or gets a
> URL that is undecorated by fragments.

That's not good.

> Leslie.
>
> On 4/23/15 2:02 AM, Keith Moore wrote:

<snip/>

>> (new section.  note: text in brackets/italics about r-components should
>> only be included if r-component proposal is adopted)
>>
>> TBD.A. Use of f- and q-components in URN resolution
>>
>> Since a URN, by design, does not contain either explicitly or implicitly
>> the name or address of a network service which can be used to access the
>> resource named by the URN, an application wishing to access that
>> resource must somehow discover one or more "resolution services" which
>> can, given the URN, either provide the resource content directly, or
>> provide information to the application to enable it to access the
>> resource.
>>
>> Though f- and q-components may appear in a URN, they are not assigned or
>> managed by the URN namespace, but instead evaluated in the context of
>> the named resource.   Specifically, an f-component of a URN refers to a
>> "fragment" of the resource named by the URN, and a q-component of a URN
>> is used to specify a "query" to be evaluated by the resource named by
>> the URN.   This convention ensures consistent use of these components
>> across all URN namespaces, and preserves the ability to reference
>> "fragments" of resources named by URNs that have fragments, and to
>> specify "queries" with resources named by URNs that support queries.
>> In order to preserve this ability, f-components and q-components MUST
>> NOT be transmitted to a URN resolution service except when that service
>> is being requested to provide direct access (or access via proxy) to the
>> resource itself.   For all other requests, the client MUST transmit only
>> the "assigned-part" of a URN /[ along with any r-component//, if
>> specified ]/ to the URN resolution service.
>>
>> A resolution service processing a request for a URN MUST ignore any
>> f-component or q-component of that URN unless the request is to provide
>> direct access (or access via proxy) to the named resource.   If the
>> request is to provide access to the named resource (as opposed to, say,
>> resource locations or resource metadata), the resolution service MUST
>> ignore the f-component of the URN and SHOULD (if possible) process the
>> q-component as if it were a query transmitted to the resource, returning
>> the resource's response to that query.  If the resolution service cannot
>> provide the requested access to the resource, but instead returns
>> resource locations, the f-component and q-component of the request URN
>> MUST be ignored in determining these locations, and MUST NOT be included
>> as fragment and query (respectively) in the returned locations.
>>
>> These rules are intended to impose a layer separation between the URN
>> resolution service and the content, and to discourage the URN resolution
>> service from returning different results depending on the presence of f-
>> and/or q-components in the request.
>>
>> If the resource named by a URN that contains an f- and/or q-component is
>> accessed via an intermediate URI (other than a URN) obtained from a
>> resolution service, and that intermediate URI contains neither a
>> fragment nor a query, the q-component (if present) is appended to the
>> intermediate URI as a query, and the f-component (if present) is
>> appended to the intermediate URI as a fragment (in that order).  The
>> resulting URI is then processed according to RFC 3986.
>>
>> Example: If the URN urn:example:foo?bar#zot appears in a link, the
>> client application might transmit the assigned-part of that URN
>> (urn:example:foo) to a resolution service with a request for resource
>> locations.   The resolution service might then return the intermediate
>> URI http://example.com/whatnot/xyzzy as one of those locations.   The
>> client would then append ?bar#zot to that intermediate URI producing
>> http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
>> processed per normal RFC 3986 rules.
>>
>> A resolution service MAY return an intermediate URI which contains a
>> fragment and/or a query.   If the intermediate URI contains a fragment
>> or a query, any f- or q-component from the URN is ignored.   (This
>> situation is basically no different than anyone composing a URI from a
>> base URI plus a fragment and/or query without being aware of what
>> fragments and/or queries are valid in the context of the named
>> resource.   Any user or document author may combine URIs with arbitrary
>> queries and/or fragments, but that doesn't mean that the results will do
>> what the user or author intended.)
>>
>> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
>> resolution service might be requested to return locations of the URN
>> urn:example:foo .  If such a service returned an intermediate URI
>> http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar
>> nor the f-component #zot would be appended to the intermediate URI
>> before processing it.
>>
>> If the content of a resource named by a URN containing an f-component is
>> obtained directly from a resolution service, the f-component SHOULD be
>> treated as a "fragment" and evaluated with respect to that content, just
>> as if the content had been obtained from any other service.



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


From nobody Tue May 26 20:31:11 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 777E41A016A for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 v88E2HUYdfa6 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:31:09 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8061A0167 for <urn@ietf.org>; Tue, 26 May 2015 20:31:09 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7E0F620A66 for <urn@ietf.org>; Tue, 26 May 2015 23:31:08 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 26 May 2015 23:31:08 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=NnQBLYnKc+Wlaco VjUtCZMX4IdU=; b=joId/U8vFuoxiBFT7lprIGfMRmTECJ6nnEzviZkwwuXIJVG amev91yjVG9Oh0pfVOL36HEafjlH29MuNNBORsg7kgjJtSvBcMh8kIq8L9OLhtDk ASCn9asmRQDvpIFtxdbf6654o4O92nI5OiYTSMABoTH53kicevc/dDoFD7mI=
X-Sasl-enc: ANGnVL45VXPGShjzZQqFff4tsCcVIq1fe3l25X3GDuVN 1432697468
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 07CBAC00015; Tue, 26 May 2015 23:31:07 -0400 (EDT)
Message-ID: <55653A6D.5040400@network-heretics.com>
Date: Tue, 26 May 2015 23:30:53 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net>
In-Reply-To: <5564FF01.70204@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/wYVl1iz2D_EE6mHLpiRcsZGthFc>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 27 May 2015 03:31:10 -0000

On 05/26/2015 07:17 PM, Peter Saint-Andre - &yet wrote:
>
> I propose the following text:
>
>    The "Resolution" section MUST specify whether resolution mechanisms
>    are intended or anticipated for URNs assigned within the namespace
>    (e.g., URNs within some namespaces are intended to act as abstract
>    designators and thus are not intended to be resolved).
>
>    If resolution is intended, then this section SHOULD specify whether
>    the organization that assigns URNs within the namespace intends to
>    operate or recommend any resolution services for URNs within that
>    namespace.  In addition, if the assigning organization intends to
>    implement registration for publicly advertised resolution services
>    (for example using a system like that described in [RFC2276]), then
>    this section SHOULD list or reference the requirements for being
>    publicly advertised by the assigning organization. 

Mumble.

1. I agree that a URN namespace* that assigns its URNs only for use as 
"abstract designators" rather than as resource names should state this 
in the namespace registration.

<rant>
IMO, such URN namespaces should never have been granted; this was and is 
a misuse of URNs.  But that water has long since passed under the bridge 
at least for some existing namespaces.   The only reason that I think 
this is useful to have in the namespace registration is that a 
namespace* that only intends that its URNs be used as "abstract 
designators" is unlikely to exercise any control whatsoever about the 
association of such names with resources, so the URNs that they assign 
really aren't usable as persistent resource names.   In effect, putting 
this flag in the namespace registration is equivalent to saying 
"Warning: these are not really URNs."   Because Uniform Resource Names 
really were intended to be Resource Names, not merely "abstract 
designators" no matter how widely URNs have been misused for the latter.
</rant>

2. I also agree that a namespace* that intends to operate or recommend 
any resolution services should state this in its namespace registration.

What I don't think is appropriate is for the registration to specify 
whether resolution mechanisms are "intended or anticipated", since 
that's really not up to the namespace*.

So what I would propose is to not put the first question in the 
Resolution section, but to have a separate question for that:

     Are all of the URNs assigned (currently or in the future) under this
     namespace intended exclusively for use as "abstract designators",
     that is, never as names of actual resources?  (yes or no)

Then the Resolution section text would look something like this:

     If the URNs assigned under this namespace are intended exclusively
     for use as "abstract designators" this section should read "Not 
Applicable".

     If any of the URNs assigned under this namespace are intended for 
use as
     resource names, the Resolution section SHOULD specify
     whether the assigning organization intends to operate or
     recommend any resolution services for URNs within that
     namespace.  In addition, if the assigning organization intends to
     implement registration for publicly advertised resolution services
     (for example using a system like that described in [RFC2276]), then
     this section SHOULD list or reference the requirements for being
     publicly advertised by the assigning organization.

Keith

* almost but not quite a shorthand for "organization operating a 
namespace" - since the rules for operating the namespace should continue 
to apply even if the organization changes.


From nobody Tue May 26 20:35:18 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 DCED31A01EA for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:35:16 -0700 (PDT)
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 7FIhlvPgnnDE for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:35:15 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43741A01A8 for <urn@ietf.org>; Tue, 26 May 2015 20:35:15 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 40BF020B1A for <urn@ietf.org>; Tue, 26 May 2015 23:35:15 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 26 May 2015 23:35:15 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=aBbU5IGUQe24qnc gFA6u1kfsRAI=; b=foKkmhr3gI7IoZ/8vu8Gfek3NCq+v18isG0b2nkOV4Lh+hP tvxHZOzEOpz6mtcP5got65kfYh8ZohdCjd4RbegA7ujC1DpVG4ipXHrqiZcdFlbp VshhBKeZ9ed2WO6Egc8WmSRztrkDZw+YgTIRVwsosMxFD+l/XLsH21JxVwi4=
X-Sasl-enc: 050IvSZ2iVF71oZeoWNysRNckWWc2iFvmGkroExYfBMa 1432697715
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id CB7E3680128; Tue, 26 May 2015 23:35:14 -0400 (EDT)
Message-ID: <55653B64.2090807@network-heretics.com>
Date: Tue, 26 May 2015 23:35:00 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com> <55653396.1030008@andyet.net> <556534B6.4020509@network-heretics.com> <5565376F.4080802@andyet.net>
In-Reply-To: <5565376F.4080802@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/LwIyxCgjarmeaV5fsRMzpE5QsQ4>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 03:35:17 -0000

On 05/26/2015 11:18 PM, Peter Saint-Andre - &yet wrote:
> On 5/26/15 9:06 PM, Keith Moore wrote:
>> On 05/26/2015 11:01 PM, Peter Saint-Andre - &yet wrote:
>>> I agree with Leslie that a registry of r-component name-value pairs is
>>> way out of scope for now - even establishing the registry. Let some
>>> future (resolution-specific) document do that, if it's even needed.
>> So in other words, it's perfectly okay to have no interoperability for
>> the meaning of r-components?
>
> Just as I am not opposed to motherhood and apple pie, I am also not 
> opposed to interoperability. However, we don't know anything about 
> r-components. They're a hook. How can we start defining name-value 
> pairs for services that are themselves undefined?

An empty registry is better than no registry at all.   Either that or we 
define the r-component syntax but reserve its actual use for a future 
standards-track document.   Based on past experience, I actually think 
the latter is riskier - i.e. r-components are more likely to be used in 
ways that are undocumented and/or non-interoperable if we require 
standards-track than if we simply have a registry.

Then again, I strongly believe that restricting r-components to 
name-value pairs is also a bad idea.

Keith


From nobody Tue May 26 20:44:03 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 B5BFB1A0451 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:44:02 -0700 (PDT)
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 SooaK4uqLyfp for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:44:01 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 00F521A0395 for <urn@ietf.org>; Tue, 26 May 2015 20:44:00 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so4683611igb.0 for <urn@ietf.org>; Tue, 26 May 2015 20:44:00 -0700 (PDT)
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=wlkxEl3CgHYz4cIDiZb+kRqZcFwDwUhPiX3YjVwCRb0=; b=CvzeCKaleuKNYyXyD/kJoO/4HN951miGa/a0io5tg/vw0x/QnuS0aXs/TowpIbZOvm 2gbvi5zWOc2dMtaHDraKVWnv1ysybTOL7ovsdrrUWR5mhdaxCTwL2InW2VgSeC9TJ7EA 6aLfUE6qqODUAIJOf8RmAnzLoWg+WEnLaKrdQOyHbBvb6eyyBrcsIZHI5XIsV2llMwfe 1yJZ67znnZlMHcTl5lLhzWHXvYfkNcUy7Lgf6Unpem346/y3Om9w1K55/GFBVBF71SdI nBd6o94Eehc/4N3t6Qs/8W+x9JR10Dpz/WwItK2nqzQ2M/zjOJ0fjN2dbQigrncSTpZb 3tKA==
X-Gm-Message-State: ALoCoQkbeAnQXjxNyhZp3gpXKrvrGJ8RDIEDaa7w5kwnYeg0Swgkz92QyKiAhvsUTU1OtwsM1oL1
X-Received: by 10.50.56.104 with SMTP id z8mr1212471igp.45.1432698240473; Tue, 26 May 2015 20:44:00 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j20sm929103igt.16.2015.05.26.20.43.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 20:43:59 -0700 (PDT)
Message-ID: <55653D7D.6080607@andyet.net>
Date: Tue, 26 May 2015 21:43:57 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com> <55653396.1030008@andyet.net> <556534B6.4020509@network-heretics.com> <5565376F.4080802@andyet.net> <55653B64.2090807@network-heretics.com>
In-Reply-To: <55653B64.2090807@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/azzB1Uu2vDH3O6F-6o4sYiorK44>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 03:44:02 -0000

On 5/26/15 9:35 PM, Keith Moore wrote:
> On 05/26/2015 11:18 PM, Peter Saint-Andre - &yet wrote:
>> On 5/26/15 9:06 PM, Keith Moore wrote:
>>> On 05/26/2015 11:01 PM, Peter Saint-Andre - &yet wrote:
>>>> I agree with Leslie that a registry of r-component name-value pairs is
>>>> way out of scope for now - even establishing the registry. Let some
>>>> future (resolution-specific) document do that, if it's even needed.
>>> So in other words, it's perfectly okay to have no interoperability for
>>> the meaning of r-components?
>>
>> Just as I am not opposed to motherhood and apple pie, I am also not
>> opposed to interoperability. However, we don't know anything about
>> r-components. They're a hook. How can we start defining name-value
>> pairs for services that are themselves undefined?
>
> An empty registry is better than no registry at all.   Either that or we
> define the r-component syntax but reserve its actual use for a future
> standards-track document.   Based on past experience, I actually think
> the latter is riskier - i.e. r-components are more likely to be used in
> ways that are undocumented and/or non-interoperable if we require
> standards-track than if we simply have a registry.

The way I see it, the URI specification and the HTTP specification don't 
define a registry of name-value pairs for the query component in HTTP. 
Instead, the query component is used in a highly flexible manner and 
each service that offers access via HTTP has its own API for interacting 
with the service. In the world of web services, we don't have 
interoperability across all services, but we don't need to do so as long 
as each service has a well-defined API. I don't quite understand why a 
similar regime would not work for URNs.

> Then again, I strongly believe that restricting r-components to
> name-value pairs is also a bad idea.

I'm confused. In a message earlier in this thread, you said:

    "Leaving [just] enough of a hook" is exactly what I want to do
    in this document.  I think that means:  (a) define the syntax for
    URNs including that of r-components, (b) explain the role of
    r-components in URN resolution, and (c) set up an IANA registry of
    r-component names and values.   Maybe also (d) explain how this is
    syntax compatible with 3986.  I think that's about enough for
    2141bis.

I thought that by suggesting a registry of names and values, you were 
suggesting that r-components would include name-value pairs.

Peter

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


From nobody Tue May 26 20:53:34 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 B650F1A1A03 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:53:33 -0700 (PDT)
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 uPWI4sJ8_hjR for <urn@ietfa.amsl.com>; Tue, 26 May 2015 20:53:28 -0700 (PDT)
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 D79F01A1A2C for <urn@ietf.org>; Tue, 26 May 2015 20:53:27 -0700 (PDT)
Received: by igcau1 with SMTP id au1so4764272igc.1 for <urn@ietf.org>; Tue, 26 May 2015 20:53:27 -0700 (PDT)
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=LTGvdWhHAS1fSQXIxSLK2caw1INIzF0/gEtqrRwghSQ=; b=Zbm+vjsx9K0GyE3A7hLKWvihFottikIrictIjSxbO0ILX5dkw3WUnZYoagDEY/b5eI H/8Xt408lXRFsgW6gXyQggu0mkLuNyZsCvA+37MkubhFNr1O3ZJhzBw6aV1wZwNhoZWk 2YgdYYVQcNUXeBNGWdkFIdcFa5qbcUmyiyQY20OJZWw2k+Q3AoO0AoR6W2UdZFO/DeIs ds6f1X32ckjGf6XxdxZFKc/YlC3fI+7mVGl2k5TnXUIenq7ibK1T87TCZO+UVpsGRSrZ CrE+mRAkLsB3003aeRtqMUNqfwU4wqD3DnOWF8P554b6kJmkDvOEshceFBH3XrmUSTcU H6wA==
X-Gm-Message-State: ALoCoQkaVNCvWrplQFO4rygGLQV/yroOEYXmtD69/QsDc1LUA0D1QhkNbtVqSLTtaA6aQ0zGaC41
X-Received: by 10.107.16.149 with SMTP id 21mr32110173ioq.53.1432698807171; Tue, 26 May 2015 20:53:27 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g1sm12655222iog.4.2015.05.26.20.53.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 20:53:26 -0700 (PDT)
Message-ID: <55653FB4.1040800@andyet.net>
Date: Tue, 26 May 2015 21:53:24 -0600
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.6.0
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>, urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com>
In-Reply-To: <55653A6D.5040400@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/8pyahZ8lfB4LuIu8_MyhNBR8kto>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 27 May 2015 03:53:33 -0000

On 5/26/15 9:30 PM, Keith Moore wrote:
> On 05/26/2015 07:17 PM, Peter Saint-Andre - &yet wrote:
>>
>> I propose the following text:
>>
>>    The "Resolution" section MUST specify whether resolution mechanisms
>>    are intended or anticipated for URNs assigned within the namespace
>>    (e.g., URNs within some namespaces are intended to act as abstract
>>    designators and thus are not intended to be resolved).
>>
>>    If resolution is intended, then this section SHOULD specify whether
>>    the organization that assigns URNs within the namespace intends to
>>    operate or recommend any resolution services for URNs within that
>>    namespace.  In addition, if the assigning organization intends to
>>    implement registration for publicly advertised resolution services
>>    (for example using a system like that described in [RFC2276]), then
>>    this section SHOULD list or reference the requirements for being
>>    publicly advertised by the assigning organization.
>
> Mumble.
>
> 1. I agree that a URN namespace* that assigns its URNs only for use as
> "abstract designators" rather than as resource names should state this
> in the namespace registration.
>
> <rant>
> IMO, such URN namespaces should never have been granted; this was and is
> a misuse of URNs.  But that water has long since passed under the bridge
> at least for some existing namespaces.   The only reason that I think
> this is useful to have in the namespace registration is that a
> namespace* that only intends that its URNs be used as "abstract
> designators" is unlikely to exercise any control whatsoever about the
> association of such names with resources, so the URNs that they assign
> really aren't usable as persistent resource names.   In effect, putting
> this flag in the namespace registration is equivalent to saying
> "Warning: these are not really URNs."   Because Uniform Resource Names
> really were intended to be Resource Names, not merely "abstract
> designators" no matter how widely URNs have been misused for the latter.
> </rant>

I would hazard that a preponderance of the formal namespaces approved so 
far exist for the purpose of assigning abstract designators:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Thus tilting at that particular windmill strikes me as futile.

> 2. I also agree that a namespace* that intends to operate or recommend
> any resolution services should state this in its namespace registration.
>
> What I don't think is appropriate is for the registration to specify
> whether resolution mechanisms are "intended or anticipated", since
> that's really not up to the namespace*.

Well, it is, but see below.

> So what I would propose is to not put the first question in the
> Resolution section, but to have a separate question for that:
>
>      Are all of the URNs assigned (currently or in the future) under this
>      namespace intended exclusively for use as "abstract designators",
>      that is, never as names of actual resources?  (yes or no)

Fair enough - that's another way to ask the question about intentions.

(BTW in -12 we'll have some text that attempts to define the concept of 
"abstract designator" more clearly.)

> Then the Resolution section text would look something like this:
>
>      If the URNs assigned under this namespace are intended exclusively
>      for use as "abstract designators" this section should read "Not
> Applicable".
>
>      If any of the URNs assigned under this namespace are intended for
> use as
>      resource names, the Resolution section SHOULD specify
>      whether the assigning organization intends to operate or
>      recommend any resolution services for URNs within that
>      namespace.  In addition, if the assigning organization intends to
>      implement registration for publicly advertised resolution services
>      (for example using a system like that described in [RFC2276]), then
>      this section SHOULD list or reference the requirements for being
>      publicly advertised by the assigning organization.

WFM.

> * almost but not quite a shorthand for "organization operating a
> namespace" - since the rules for operating the namespace should continue
> to apply even if the organization changes.

Right, it's the rules that matter - the rules define the namespace and 
the assigning organiation follows the rules. Or so we hope. :-)

Peter

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


From nobody Tue May 26 21:42:16 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 EFB701A6FDB for <urn@ietfa.amsl.com>; Tue, 26 May 2015 21:42:14 -0700 (PDT)
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 hpPvyZkQtbnU for <urn@ietfa.amsl.com>; Tue, 26 May 2015 21:42:12 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64B61A6F33 for <urn@ietf.org>; Tue, 26 May 2015 21:42:12 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 39695209F2 for <urn@ietf.org>; Wed, 27 May 2015 00:42:12 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 27 May 2015 00:42:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=95oiXEMkAnpKBHU gE1kHpyJX47k=; b=rfZcpXkWfcAePUOJaP6Z46CCRMLq4w+7fz19jHjYsKOU0Cc acEBuxnKYfYI/kT5q/oX8F6bnyiT3L/O/xhDs2o7uh4t+0cHvH3vngCeXTn9Xrib PzVPEELaxkfWYOX6vxzWu22GbE0M+IFxQbUV9xkGa3ufVyvmZ3u6ZqqFY4ZE=
X-Sasl-enc: /oxzCG3JA8W/WHXfV3zG1YpfxMhWt+1+j5ACTYx1+BGH 1432701731
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C568EC00015; Wed, 27 May 2015 00:42:11 -0400 (EDT)
Message-ID: <55654B15.70102@network-heretics.com>
Date: Wed, 27 May 2015 00:41:57 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net>
In-Reply-To: <55653FB4.1040800@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/5NBvW3d0aHLsYycpw3P2pbbx5Eg>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 27 May 2015 04:42:15 -0000

On 05/26/2015 11:53 PM, Peter Saint-Andre - &yet wrote:
> On 5/26/15 9:30 PM, Keith Moore wrote:
>> On 05/26/2015 07:17 PM, Peter Saint-Andre - &yet wrote:
>>>
>>> I propose the following text:
>>>
>>>    The "Resolution" section MUST specify whether resolution mechanisms
>>>    are intended or anticipated for URNs assigned within the namespace
>>>    (e.g., URNs within some namespaces are intended to act as abstract
>>>    designators and thus are not intended to be resolved).
>>>
>>>    If resolution is intended, then this section SHOULD specify whether
>>>    the organization that assigns URNs within the namespace intends to
>>>    operate or recommend any resolution services for URNs within that
>>>    namespace.  In addition, if the assigning organization intends to
>>>    implement registration for publicly advertised resolution services
>>>    (for example using a system like that described in [RFC2276]), then
>>>    this section SHOULD list or reference the requirements for being
>>>    publicly advertised by the assigning organization.
>>
>> Mumble.
>>
>> 1. I agree that a URN namespace* that assigns its URNs only for use as
>> "abstract designators" rather than as resource names should state this
>> in the namespace registration.
>>
>> <rant>
>> IMO, such URN namespaces should never have been granted; this was and is
>> a misuse of URNs.  But that water has long since passed under the bridge
>> at least for some existing namespaces.   The only reason that I think
>> this is useful to have in the namespace registration is that a
>> namespace* that only intends that its URNs be used as "abstract
>> designators" is unlikely to exercise any control whatsoever about the
>> association of such names with resources, so the URNs that they assign
>> really aren't usable as persistent resource names.   In effect, putting
>> this flag in the namespace registration is equivalent to saying
>> "Warning: these are not really URNs."   Because Uniform Resource Names
>> really were intended to be Resource Names, not merely "abstract
>> designators" no matter how widely URNs have been misused for the latter.
>> </rant>
>
> I would hazard that a preponderance of the formal namespaces approved 
> so far exist for the purpose of assigning abstract designators:
>
> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>
> Thus tilting at that particular windmill strikes me as futile.

Those namespaces would be mostly harmless, except that people keep 
making assumptions about how URNs are supposed to work based on those 
mistakes.

>
>> 2. I also agree that a namespace* that intends to operate or recommend
>> any resolution services should state this in its namespace registration.
>>
>> What I don't think is appropriate is for the registration to specify
>> whether resolution mechanisms are "intended or anticipated", since
>> that's really not up to the namespace*.
>
> Well, it is, but see below.

No it's not.   It might not matter for the current discussion, but it's 
really important to understand that the namespace does not control 
resolution.

>
>> So what I would propose is to not put the first question in the
>> Resolution section, but to have a separate question for that:
>>
>>      Are all of the URNs assigned (currently or in the future) under 
>> this
>>      namespace intended exclusively for use as "abstract designators",
>>      that is, never as names of actual resources?  (yes or no)
>
> Fair enough - that's another way to ask the question about intentions.
>
> (BTW in -12 we'll have some text that attempts to define the concept 
> of "abstract designator" more clearly.)
>
>> Then the Resolution section text would look something like this:
>>
>>      If the URNs assigned under this namespace are intended exclusively
>>      for use as "abstract designators" this section should read "Not
>> Applicable".
>>
>>      If any of the URNs assigned under this namespace are intended for
>> use as
>>      resource names, the Resolution section SHOULD specify
>>      whether the assigning organization intends to operate or
>>      recommend any resolution services for URNs within that
>>      namespace.  In addition, if the assigning organization intends to
>>      implement registration for publicly advertised resolution services
>>      (for example using a system like that described in [RFC2276]), then
>>      this section SHOULD list or reference the requirements for being
>>      publicly advertised by the assigning organization.
>
> WFM.
>
>> * almost but not quite a shorthand for "organization operating a
>> namespace" - since the rules for operating the namespace should continue
>> to apply even if the organization changes.
>
> Right, it's the rules that matter - the rules define the namespace and 
> the assigning organiation follows the rules. Or so we hope. :-)
>
> Peter
>


From nobody Tue May 26 21:50:13 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 0115E1A86E9 for <urn@ietfa.amsl.com>; Tue, 26 May 2015 21:50:12 -0700 (PDT)
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 q28Uqmr5L_TG for <urn@ietfa.amsl.com>; Tue, 26 May 2015 21:50:10 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE181A854B for <urn@ietf.org>; Tue, 26 May 2015 21:50:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CA6E820872 for <urn@ietf.org>; Wed, 27 May 2015 00:50:09 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 27 May 2015 00:50:09 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PTLCfDskt1QmTsZ DIvmVCsklL7U=; b=loXTU3Lu4HKvpGJW9/zmWUByupJqS/05B8UcFhNTaytTcZf pMTle7KWArVvPiLP0fuo1UoFwr+h69a+kXdRDkmPa2KRGC3RhA9LBZhcMl0ifog0 rEBaEJkvs6Ohe/PutzzDgC9gIQuhKt2gYYNzwF+IAG7esoFqUfgxv7zMVGRc=
X-Sasl-enc: h0uTKoiuzJo2QzoMn5G9I+KunYcTh4gl9acpdwHVec0a 1432702209
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F94768012C; Wed, 27 May 2015 00:50:09 -0400 (EDT)
Message-ID: <55654CF2.6000807@network-heretics.com>
Date: Wed, 27 May 2015 00:49:54 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <712C16AF1A4F3A3F50DB512F@JcK-HP8200.jck.com> <552D3AB0.4060006@network-heretics.com> <552F15AD.2050405@andyet.net> <552F6234.4080509@network-heretics.com> <55317AA4.70105@thinkingcat.com> <55319FD5.1070404@network-heretics.com> <55367BBA.3020807@thinkingcat.com> <5536BEF9.4060603@network-heretics.com> <55653396.1030008@andyet.net> <556534B6.4020509@network-heretics.com> <5565376F.4080802@andyet.net> <55653B64.2090807@network-heretics.com> <55653D7D.6080607@andyet.net>
In-Reply-To: <55653D7D.6080607@andyet.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/7xEBrt6R-gHUmIG8gL2MRYWz9ns>
Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?
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, 27 May 2015 04:50:12 -0000

On 05/26/2015 11:43 PM, Peter Saint-Andre - &yet wrote:
> On 5/26/15 9:35 PM, Keith Moore wrote:
>> On 05/26/2015 11:18 PM, Peter Saint-Andre - &yet wrote:
>>> On 5/26/15 9:06 PM, Keith Moore wrote:
>>>> On 05/26/2015 11:01 PM, Peter Saint-Andre - &yet wrote:
>>>>> I agree with Leslie that a registry of r-component name-value 
>>>>> pairs is
>>>>> way out of scope for now - even establishing the registry. Let some
>>>>> future (resolution-specific) document do that, if it's even needed.
>>>> So in other words, it's perfectly okay to have no interoperability for
>>>> the meaning of r-components?
>>>
>>> Just as I am not opposed to motherhood and apple pie, I am also not
>>> opposed to interoperability. However, we don't know anything about
>>> r-components. They're a hook. How can we start defining name-value
>>> pairs for services that are themselves undefined?
>>
>> An empty registry is better than no registry at all.   Either that or we
>> define the r-component syntax but reserve its actual use for a future
>> standards-track document.   Based on past experience, I actually think
>> the latter is riskier - i.e. r-components are more likely to be used in
>> ways that are undocumented and/or non-interoperable if we require
>> standards-track than if we simply have a registry.
>
> The way I see it, the URI specification and the HTTP specification 
> don't define a registry of name-value pairs for the query component in 
> HTTP. Instead, the query component is used in a highly flexible manner 
> and each service that offers access via HTTP has its own API for 
> interacting with the service. In the world of web services, we don't 
> have interoperability across all services, but we don't need to do so 
> as long as each service has a well-defined API. I don't quite 
> understand why a similar regime would not work for URNs.

HTTP queries are not like r-components.   An HTTP query is evaluated in 
the context of the specific service named by the URL.   An r-component 
should be a directive that potentially can be interpreted by any 
resolution service, not something that's inherently specific to any 
particular resource or namespace. R-components are similar in this 
respect to header field names in email messages, where the meaning of a 
field-name needs to be consistent across all email.
>
>> Then again, I strongly believe that restricting r-components to
>> name-value pairs is also a bad idea.
>
> I'm confused. In a message earlier in this thread, you said:
>
>    "Leaving [just] enough of a hook" is exactly what I want to do
>    in this document.  I think that means:  (a) define the syntax for
>    URNs including that of r-components, (b) explain the role of
>    r-components in URN resolution, and (c) set up an IANA registry of
>    r-component names and values.   Maybe also (d) explain how this is
>    syntax compatible with 3986.  I think that's about enough for
>    2141bis.
>
> I thought that by suggesting a registry of names and values, you were 
> suggesting that r-components would include name-value pairs.

Since I wrote that, I've come to believe that people will want to use 
relational expressions in r-components to narrow the result set of a 
search, rather than to set options to specific values. Restricting the 
syntax of r-components to name-value pairs would make this more difficult.

On the other hand, as John and I have been discussing, it doesn't take a 
very complex relational expression to make for a very complex and huge 
URN.   So maybe r-components will have fairly narrow applicability, and 
in those applications where it's useful to specify relational 
expressions to narrow the result set of data to be obtained during URN 
resolution, that will need to be specified outside the URN itself - say 
in a call to a URN resolution library from JavaScript or another language.

Keith



From nobody Wed May 27 04:06:16 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 E92D81ACDA9 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 04:06:14 -0700 (PDT)
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 JP2Cc8zVeJg7 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 04:06:08 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8C21ACDCA for <urn@ietf.org>; Wed, 27 May 2015 04:06:08 -0700 (PDT)
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 1YxZ9u-000La2-JQ; Wed, 27 May 2015 07:06:02 -0400
Date: Wed, 27 May 2015 07:05:57 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <69987EDAF5C813D15ADB184D@JcK-HP8200.jck.com>
In-Reply-To: <55652D6F.3050506@andyet.net>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@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/GUlsZ82LvpgBvhYeyil4gAlntoo>
Cc: "Leslie Daigle \(ThinkingCat\)" <ldaigle@thinkingcat.com>, urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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, 27 May 2015 11:06:15 -0000

--On Tuesday, May 26, 2015 20:35 -0600 Peter Saint-Andre - &yet
<peter@andyet.net> wrote:

>...
>     In particular, allowing the "/" character effectively
> makes it
>     possible to encapsulate hierarchical identifiers from
> other naming
>     systems.  For instance, consider the hypothetical example
> of a
>     hierarchical naming system in which the identifiers take
> the form of
>     a series of numbers separated by the "/" character, such
> as "1/406/
>     47452/2".  If the naming authority for such identifiers
> were to use
>     URNs, it would be natural to place the existing
> identifiers in the
>     NSS, resulting in URNs such as "urn:example:1/406/47452/2".
>     Nevertheless, it is not appropriate the "/" character be
> used in a
>     URN merely because the URN namespace is importing a naming
> system
>     that happens to use the character; it is simply a matter
> of syntactic
>     convenience not to escape the character with
> percent-encoding.

Peter,

Up to the last sentence (and including the parts not quoted
above, this seems ok to me.  But I can't quite parse that last
sentence or figure out what it means -- it seems to be
contradicting the text above it.

    john



From nobody Wed May 27 04:57: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 039961ACE6F for <urn@ietfa.amsl.com>; Wed, 27 May 2015 04:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.61
X-Spam-Level: 
X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 svhZlHi5ISl9 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 04:57:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB741ACE31 for <urn@ietf.org>; Wed, 27 May 2015 04:57:44 -0700 (PDT)
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 1YxZxq-000Mvb-RQ; Wed, 27 May 2015 07:57:38 -0400
Date: Wed, 27 May 2015 07:57:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
Message-ID: <D5077E71059E236621C66D15@JcK-HP8200.jck.com>
In-Reply-To: <55654B15.70102@network-heretics.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net> <55654B15.70102@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/peWEU11Lk9XTo25haru5g4ixQ4s>
Subject: [urn] Historical URNs, rants, and progress (was: Re: suggested change for -12 of rfc2141bis section 7.3.6)
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, 27 May 2015 11:57:48 -0000

--On Wednesday, May 27, 2015 00:41 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> On 05/26/2015 11:53 PM, Peter Saint-Andre - &yet wrote:
>> On 5/26/15 9:30 PM, Keith Moore wrote:
>>> On 05/26/2015 07:17 PM, Peter Saint-Andre - &yet wrote:
>...

>>> Mumble.
>>> 
>>> 1. I agree that a URN namespace* that assigns its URNs only
>>> for use as "abstract designators" rather than as resource
>>> names should state this in the namespace registration.
>>> 
>>> <rant>
>>> IMO, such URN namespaces should never have been granted;
>>> this was and is a misuse of URNs.  But that water has long
>>> since passed under the bridge at least for some existing
>>> namespaces.   The only reason that I think this is useful to
>...
>>> intended to be Resource Names, not merely "abstract
>>> designators" no matter how widely URNs have been misused for
>>> the latter. </rant>

For the record, while I'm picking up on some comments that Keith
wrote, he is not the only one and this is not specifically about
him.

Personal opinion/request: I understand the reason for these
sorts of rants/ comments from those who had (or believed they
had) a very clear view of URNs years ago (and whether they are
explicitly identified or not).  They pose two difficulties and I
wish they would stop.  

First, not only is it water under the bridge, but the door has
closed.  Perhaps early documents should have described several
types of URNs and identified multiple types with multiple
schemes (reserving the term "URN" itself as "URL" is effectively
reserved).  They/we didn't do that and, as Peter points out,
probably most of the URNs in use today do not conform to those
early assumptions in one way or another.      While it arguably
made things worse, the text in RFC 3986 that says that there are
such things as "URN"s and that only some of them conform to the
"urn:" scheme, it at least was an attempt to address the issue.  

For the same reason, I object to anything resembling a casual
reference to RFCs 1737, 2276, or the 2915, 2168, and 3401 family
in 2141bis.  Common, probably dominant, practices have evolved
past those documents, 3401 and friends have not been broadly
used and adopted and general-purpose NAPTR records have proven
problematic, and so on.  We don't add clarity to what URNs are
about today (and in the likely future) by citing those
documents, even as examples.  What we do is to add confusion or
at least fodder for the next rounds of nit-picking arguments and
moral outrage about certain types of usage.

I think there is a place for a reprise and summary in the form
of an updated theory of URNs and URN resolution -- a document
that would presumably obsolete 1737 and 2276 and comment on the
applicability of DDDS (and hence 3401ff).  But it doesn't appear
to be to be within scope for this WG.  Even if it were, it is
fairly clear we don't have the energy for it.

The other problem is that hair-splitting arguments about the
true nature of URNs (etc.) drives people with more pragmatic
interests and less time away from  the WG, leading to a
situation in which we have long-thread discussions, typically
about esoteric (if not irrelevant) issues among a handful of
people, losing broader perspectives and review.

Can we just stop?  If we cannot stop, might I encourage the
co-chairs to start weighing the impact of such discussions on WG
progress with an eye to identifying them as disruptive?


>...
>> Thus tilting at that particular windmill strikes me as futile.

Worse than futile.  IMO, they are making it much more difficult
for the WG to make anything resembling progress.

> Those namespaces would be mostly harmless, except that people
> keep making assumptions about how URNs are supposed to work
> based on those mistakes.

See comments about "updated theory" above.  If someone wants to
write that document and discuss it -- but not on this WG's list
at least until after we get 2141bis published -- I'm willing to
read it and review.   But I don't think comments about
"mistakes" in very wide use on this list are helpful unless they
are also actionable and contain specific proposals for text that
would fit into 2141bis and that do not involve turning back the
clock.

>>> 2. I also agree that a namespace* that intends to operate or
>>> recommend any resolution services should state this in its
>>> namespace registration.
>>> 
>>> What I don't think is appropriate is for the registration to
>>> specify whether resolution mechanisms are "intended or
>>> anticipated", since that's really not up to the namespace*.
>> 
>> Well, it is, but see below.
> 
> No it's not.   It might not matter for the current discussion,
> but it's really important to understand that the namespace
> does not control resolution.

Until we provide more resources --and perhaps whips or guns-- to
the Protocol Police -- nothing we specify controls anything
else.  "Intended or anticipated" is an intended/expected best
practices statement, not a statement about "control".     And,
again, these hair-splitting discussions are hurting us.

And, if we are going to make a distinction between "abstract
designator" and something else, I hope we can come up with a
different term than "resource name", if only because "when is a
Uniform Resource Name not a resource name" is not just a trivia
contest question but an invitation to precisely the sort of
historical hair-splitting that I hope we can avoid.

>...

best,
    john


From nobody Wed May 27 05:27:26 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 991881ACEEC for <urn@ietfa.amsl.com>; Wed, 27 May 2015 05:27:24 -0700 (PDT)
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 xJSurSvbozPb for <urn@ietfa.amsl.com>; Wed, 27 May 2015 05:27:22 -0700 (PDT)
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 B8C391ACE99 for <urn@ietf.org>; Wed, 27 May 2015 05:27:22 -0700 (PDT)
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 1YxaQZ-000Niu-BN; Wed, 27 May 2015 08:27:19 -0400
Date: Wed, 27 May 2015 08:27:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, Keith Moore <moore@network-heretics.com>, urn@ietf.org
Message-ID: <98F6D08AB5C3B32F6D5D42A0@JcK-HP8200.jck.com>
In-Reply-To: <5564F184.7080206@andyet.net>
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com> <5564F184.7080206@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/XkRwg3ij3EB9EEbAfMJmnTOkZ8M>
Subject: Re: [urn] Namespace consensus and registrations
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, 27 May 2015 12:27:24 -0000

--On Tuesday, May 26, 2015 16:19 -0600 Peter Saint-Andre - &yet
<peter@andyet.net> wrote:

>> (Also, the comment period should last long enough that any
>> organization that cares would have time to discuss things
>> within its membership and form its own opinion, which
>> probably means a comment period should last considerably
>> longer than a month.)
> 
> Right now, draft-ietf-urnbis-rfc2141bis-urn has no time limit
> on reviews (RFC 3406 said it was 2 weeks). It might be best to
> say that the expert reviewers need to reply within 2 weeks,
> not that all discussion needs to be completed in 2 weeks
> (which is unrealistic anyway).

How would you feel about a sentence indicating that the reply
might recommend other actions -- discussion on specific other
mailing lists, pursuing standardization, etc. -- as well as
commenting on the proposed registration itself.

On a related note, I think it is entirely reasonable to include
space in the template for people to describe how their namespace
uses any or all of p-/q-/r-/f-components without getting
involved with elaborate standardization attempts or registration
models for the syntax and contents of those fields.

    john


From nobody Wed May 27 05:39:33 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 5F46A1A87AB for <urn@ietfa.amsl.com>; Wed, 27 May 2015 05:39:32 -0700 (PDT)
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 1Bi99yeDdGYb for <urn@ietfa.amsl.com>; Wed, 27 May 2015 05:39:31 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2A81ACEFC for <urn@ietf.org>; Wed, 27 May 2015 05:35:27 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9C9302085A for <urn@ietf.org>; Wed, 27 May 2015 08:35:26 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 27 May 2015 08:35:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=OdOfWkm669WgoOo uFC0YUjj5wPQ=; b=OYMjB/+yU6HOt/ptCREUekpBdYrtkCkfK6+SO4yYvAe8c4z nzMiTjX87EpwAys4hQ/ZaIRFKFuAHC9eQk0Zz+qEwWlanN99JmygWiZ7U/nH+j5M NLSt/LXzfi5GCz5bQtQykWeivofavW+frOoZuynfLZ4nHc3gH2gNh6hufQvk=
X-Sasl-enc: rRcq6edps1PcuQqo87hiLu1ajZPVhGT9CJxLCrZyrkGU 1432730126
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 13E136800F2; Wed, 27 May 2015 08:35:26 -0400 (EDT)
Message-ID: <5565B9FE.90100@network-heretics.com>
Date: Wed, 27 May 2015 08:35:10 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com> <5564F184.7080206@andyet.net> <98F6D08AB5C3B32F6D5D42A0@JcK-HP8200.jck.com>
In-Reply-To: <98F6D08AB5C3B32F6D5D42A0@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/YcOQVao5xcGdentu1GNxVvuTgAk>
Subject: Re: [urn] Namespace consensus and registrations
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, 27 May 2015 12:39:32 -0000

On 05/27/2015 08:27 AM, John C Klensin wrote:
> On a related note, I think it is entirely reasonable to include
> space in the template for people to describe how their namespace
> uses any or all of p-/q-/r-/f-components without getting
> involved with elaborate standardization attempts or registration
> models for the syntax and contents of those fields.

Strongly disagree with this.

- I thought we had done away with p-components and just decided to 
permit '/' in NSS.
- q-components are interpreted by the resource, not by the namespace.  
It's very important to make this clear, otherwise there will be tussles 
over their use.
- f-components are interpreted in light of the resource content, not by 
the namespace.  It's very important to make this clear, otherwise there 
will be tussles over their use.
- r-components could potentially be namespace-specific, but different 
namespaces shouldn't interpret the same r-components in different ways, 
any more than different email providers or user agents interpret 
different email header fields in different ways.

Keith


From nobody Wed May 27 07:41:43 2015
Return-Path: <L.Svensson@dnb.de>
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 F32EF1B2B80 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 07:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Level: 
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 0ipC0oP8NHmG for <urn@ietfa.amsl.com>; Wed, 27 May 2015 07:41:39 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1DB1B2B25 for <urn@ietf.org>; Wed, 27 May 2015 07:41:39 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 58A3F8ACE4; Wed, 27 May 2015 16:41:38 +0200 (CEST)
X-AuditID: 0a453fe7-f79136d0000011d7-ec-5565d7a2b0b0
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 9A.E8.04567.2A7D5655; Wed, 27 May 2015 16:41:38 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Wed, 27 May 2015 16:41:37 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Peter Saint-Andre - &yet <peter@andyet.net>, John C Klensin <john-ietf@jck.com>, Melinda Shore <melinda.shore@gmail.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] r-component syntax
Thread-Index: AQHQmABAs06zp5hkNkqJ5bHwVqKW/Z2P5I7w
Date: Wed, 27 May 2015 14:41:36 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF6E4F5@dnbf-ex1.AD.DDB.DE>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <5564EE74.9000805@andyet.net>
In-Reply-To: <5564EE74.9000805@andyet.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.195]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Ta2xLYRjHvT1n7VnX196d7vLqNqFxy0SZyyyI24iyJS6zEBGc6tE2uq05 p102YpkwohkhyKJhxbo1+ECWCMvcWre5DRtz9wEjLFZk5hLEuXRz5ttzfs/z/5//c54ciqC/ aAyUo8jNckWM06jWktq5M76OOfqILRgXqUTZla2/1NnbtvnI7JuvrhDZ+7d8Us0kzS3P2zXm Rt8LjTkQ+KEytx3rJBaRK7TTrKzTUcJyY6ev0dojJ67HuB7j0iNbLxMV4AHtBbEURhPxi2d+ lVwn43svT6q9QEvR6ArAVX96VPLDGYBvRQ5qvEBDqVEGjtjF+UTkBzh4aYFY69FwHLj4GMh8 BA7u9arlejzu9odIL6AoUphpqZTGIcrFza3PCbGmkRuHwu0x4kisYN582ixigNLxqVN3pREC peCGt99i5JQIB87JHKMk/P71H0mK0RC8pc4kj4/DkRZ/VDoa1x/pJOS3JuAbB96Qu0GST+Hq U0h8ColPITkMyONgIF9oyzQxVpPVajFZ2QYgH+fdWbCrdU4YIAoYdXCfgS2gY5gSvqwwDBZS KmMSzGgT0EBLsbXMzvD21ZzHyfLGRFj7UMCwD1s8zvXGwTC4SaApfZT38C7HWkexh1/t4Zxh gClCkBokqZUp28ByxbJhGKRSpDEF7mnavJRGNsbNrmdZF8v1dpdTlBHDhnZBmMCxNrZ0ncPp 7m0LOk4MiZQdKdBQ+E4MZFA2/s+komLDII/SCcGWiP6QdzGFvMMW9dbDSa0C1fVSyTcd3hZ9 k3thf8+bIN+QAjeKZkicsHuK+rIakuGEcqERr2iIloYhMPTAUkAPUvD+rh/AfOFEetgt+uqE X+xfRhreFz9pXBRKEdPkiElR9r9XnnDbRJh11Sou7GbcyoUXlEsLR2l04bnl0sJR2N/OUAHi f24/PCF/ZNaiZXVbQyuaKnJXjnnKzV6VqjlkO3NhOdvccW1esGNA5mJHy9Schz1PuvQJUzp2 75i1o6n0zjVTdVbNoMxf+1emdp031XzvOWDZGa+vv5ST4amrDlZMzkkfZRr2+TjR1tn4Wze7 9ndeTVp7w8Y4MAC4qtQ5AZS73fIx2UjydiYzg+B45i9r7aqihQQAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/BTYFJBZ-dVvi7NswEc3cArIfWNM>
Subject: Re: [urn] r-component syntax
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, 27 May 2015 14:41:42 -0000

On Wednesday, May 27, 2015 12:07 AM, Peter Saint-Andre - &yet wrote:
=20
> On 5/10/15 1:27 PM, John C Klensin wrote:
> >
> >
> > --On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
> > <melinda.shore@gmail.com> wrote:
> >
> >> There seems to be agreement on specifying a syntax for
> >> r-components, largely as a defensive mechanism against
> >> possible future bad behavior. Rather than specifying that
> >> space as "reserved" it probably makes more sense, and is more
> >> consistent with IETF practice, to distinguish between things
> >> that are used as part of URN processing and things that are
> >> opaque to URN processing and passed through without being
> >> touched (thanks to John for providing some clarifying thoughts
> >> on this).  Is there agreement on this?
> >
> > Melinda, thanks.
> >
> > As a shortcut to save a bit of time, I think that, if we decide
> > to allow r-components, the syntax for in section 3 of 2141bis-11
> > would change so that the changed productions would read:
> >
> >         q-component =3D "?" query [ "??" r-component ]
> > 	       Note that <query> in the above cannot contain "??"
> >         r-component =3D query
> >
> > That could also be done in a somewhat more complex way to
> > eliminate the note, e.g., as
> >
> >         q-component =3D "?" q-string [ "??" r-component ]
> >         r-component =3D r-string
> >
> > where the definition of q-string would repeat the text of
> > Section 3.4 of RFC 3986 but explicitly exclude, and terminate
> > on, "??" as well as "#" and r-string would match that Section
> > 3.4 text.
> >
> > It could also be done more like:
> >
> >        namestring    =3D assigned-name
> >                        [ q-component [r-component] ]
> >                        [ f-component ]
> >         q-component =3D "?" q-string
> >         r-component =3D "??" r-string
> >
> > If anyone who thinks we should adopt r-components has a strong
> > preference among those alternatives, please say so, otherwise,
> > Peter and I will draw straws or equivalent.

I feel a bit confused. Is it really meant that the r-component can only exi=
st as an appendix to a q-component? The position of the square brackets sug=
gest that. I always thought that we could pass instructions to a resolver w=
ithout having a q-component.

My suggestion would be:

	namestring	=3D assigned-name
		[q-component]
		[r-component]
		[f-component]
	q-component =3D "?" q-string
	r-component =3D "??" r-string

(r-component before q-component works for me, too).

> I prefer the latter - it feels more readable.

Yes, the latter syntax is more readable.

> > Independent of the above, if we are going to adopt r-components,
> > we will need some text to describe them and some examples,
> > preferably real.  Peter and I can make that up, but suggestions
> > from WG participants who have thought deeply about this would be
> > much better.
>=20
> Yes, text and examples would be appreciated. (Although any examples are
> quite speculative at this point.)

I shall discuss with relevant people at my place.

Best,

Lars=20


From nobody Wed May 27 09:40:41 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 A4BCB1A7D82 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 09:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 3aRhipVjoYr3 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 09:40:37 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B541A7D80 for <urn@ietf.org>; Wed, 27 May 2015 09:40:37 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DE73720C45 for <urn@ietf.org>; Wed, 27 May 2015 12:40:36 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 27 May 2015 12:40:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=FBPoKPIp7zdugtY 3IgLgW1aZKJo=; b=JXHPjnW40FncuxzzYATtrB5Weqlpe0mYzdDyOOkqrhCNl4H 1k5BlHE8r4U9oo4MjTcuf8Dtx6tOh7yASPzWIPcN59UB43QH6QclCWja5KqHQfmt pRIDDfOGDEJgdfyf9zHS9DkYsTo6C7DWd9lBX7ug0j+YoBSgEi+4a5Mdkd/A=
X-Sasl-enc: iGTRFWhh/3g0qeC1072hxzdueVHcwa7euqOBWSk20ybw 1432744836
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C8C0C0001F; Wed, 27 May 2015 12:40:36 -0400 (EDT)
Message-ID: <5565F374.2080505@network-heretics.com>
Date: Wed, 27 May 2015 12:40:20 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <554FCFAF.6020605@network-heretics.com> <23601CE735D7E5A28E5B230F@JcK-HP8200.jck.com> <554FF76B.5030304@network-heretics.com> <ABC814B799B9975CE692229F@P5>
In-Reply-To: <ABC814B799B9975CE692229F@P5>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/w_c76ksAsPukp7H0cCa1xHXBOy4>
Cc: urn@ietf.org
Subject: Re: [urn] r-component syntax
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, 27 May 2015 16:40:40 -0000

Regarding the placement of r-components relative to the other parts of 
the URN:   I still believe, for reasons already stated, that having them 
appear on the left side of the q-component (corresponding to the left 
side of the "query" per 3986 syntax) is better than having them appear 
on the right side of any q- or f-component (corresponding to the right 
side of the "query" per 3986 syntax).   However, as far as I can tell, 
either approach can be implemented in a technically sound and 
interoperable way - I just think having the r-component on the left is 
easier to explain and less likely to be incorrectly implemented.   
Assuming I'm right about that last statement, I'll be happy if we can 
get r-components added to the URN syntax in either fashion.

The lack of responses bothers me more, not so much because there's 
nobody else to weigh in on this particular issue, but because I suspect 
that any change in the URN syntax along these lines needs more 
eyeballs.  In particular, it needs the benefit of review by several 
people with experience in implementing web protocols and/or familiarity 
with existing implementations.   Just as an example, it wouldn't 
surprise me at all if there were running code that parses URNs according 
to 3986 or 2141 but expects "queries" for URIs in general to be 
formatted as if they represented data generated from an HTML form (using 
'&' as a separator between name-value pairs) and which doesn't behave 
well when given URIs with queries not formatted like this.   That might 
argue for a very different way of distinguishing r-components from the 
other parts of the URN.

Maybe we'll get some of those eyeballs in Last Call, but that seems like 
an awkward time to have such a discussion.

Some specific responses about syntax:

On 05/25/2015 02:14 PM, John C Klensin wrote:
> If r-component is to the right, we have
>
>     <query> = <q-component> [ "??" <r-component> ]
> where <q-component> is exactly an RFC 3986 <query> with the
> restriction that <query-text> cannot contain a literal
> appearance of "??" even though "?" is allowed.  That requires a
> two-character look-ahead in the parser, but that should not be a
> big deal these days.
>
> By contrast, if it is to the left, we really cannot use the 3986
> structure any more because
>      [...] ?? foo ? bar
> makes "foo" an r-component and bar a <query> but
>      [...] ? ? foo ? bar
> make the <query> "? foo ? bar".   If one contemplates
> error-prone constructions that could yield weird error messages,
> that could be a winner.

I'm not sure what you mean by "we really cannot use the 3986 structure 
any more".    In either case the new 2141bis combined syntax for 
<q-component> and <r-component> has to be compatible with the 3986 
syntax for <query> (or at least I assume this is the goal to try to 
minimize pushback from the "3986 is carved in stone"  camp).   If 
<r-component> is on the left, the r-component appears leftmost in the 
<query> preceded and followed by '?'.   If <r-component> is on the 
right, then it appears on the right side of the <query> preceded by 
'??'. With either approach, if the entire <query> ever gets fed to (say) 
an HTTP-based application, without first stripping out the <r-component> 
and whatever separators, neither the results nor any error message is 
likely to make much sense.

> However, to return to fundamentals, there are two ways to think
> about URI parsing.  In one model, it is all hierarchical: the
> generic URI parser separates scheme from everything else, passes
> the whole business to a scheme specific parser and it does its
> thing.  In the other, which has seemed to be the main focus, a
> generic URI parser breaks things into designated bits and passes
> those bits off to whatever needs to deal with them, presumably
> pre-isolated.  In the latter case, it doesn't really make any
> difference how things are organized in the URI string -- in
> principle we could tag everything, put pieces in random order,
> and then recombine the components after parsing -- as long as
> the parsing process is plausible and unambiguous.   In
> compiler-speak, the output of a generic parser is a parse tree
> and "it is better for these things to come in that order in the
> raw string" just are not significant as long as pieces of the
> tree are passed off to other processors or other processors can
> find their place in the tree.
Agreed, that's a very minor concern.   Though to the extent that 
ordinary users get involved in composing or parsing URNs at all, I do 
think that users are more likely to be able to correctly model the 
behavior of URNs when the components are processed left-to-right, than 
when the components are processed middle, left, then right.

(I have no idea how often will ordinary users end up composing or 
parsing URNs.  But, I originally thought that ordinary users would 
rarely end up reading or writing raw HTML, and I was wrong.)

> None of that applies to what is (or ought to be) really
> important, which is whether end users can make sense of any of
> this.  But we know the answer to that question, with or without
> r-components: users don't have much of a clue about the internal
> structure of URIs and most of what they think they know is
> wrong.  All of the esoteric arguments about the meaning of the
> various provisions of 3986 just reinforce that few; I'll start
> having hope for end users understanding the details and
> implications of URI syntax the day I see a one-sheet
> pocket-sized card that summarizes all of the relevant details
> and does so accurately.   Whatever we do with a trick syntax
> that introduces a delimiter (or delimiter sequence) that makes
> more differentiation for URNs than is common for URIs is going
> to make that problem worse.

As far as I can tell, users build up their own mental models for how 
computer systems work.   They rarely understand how things actually 
work, but the models that they build in their heads do a fair job of 
predicting how the computers will behave for the limited range of cases 
that the users have to deal with on a regular basis.   (Any user whose 
models predict significantly more behavior than the average user's 
models is indistinguishable (by ordinary users) from a wizard.)     So 
from that perspective, it's not important that users actually understand 
how URIs or URNs work; what's important is that they be able to build 
models that accurately predict how they'll work for common use cases.

I'm not sure whether any of that helps answer the question of 
r-components on the left vs. on the right.   But maybe that's not 
actually the most important thing to settle right now.   My assumption 
all along has been that people are going to want to bundle URNs with 
resolution service queries, and that's why we need r-components.   It 
then seems to me that the natural purpose of r-components is to narrow 
the set of results from such a query, so instead of "everything the 
service knows about this URN" the client only sees a subset of that.   
And this seems to me to imply that r-components need to be able to 
contain relational expressions. But if that makes r-components too 
complex, too error-prone, too lengthy, etc. (and I'm starting to lean 
that way) then maybe any need to narrow or otherwise manipulate 
resolution service query results would be better accomplished by 
invoking the resolution service from an actual programming language 
rather than stuffing a query into a URN.    And that might make the role 
of r-components a fairly minor one, such that even name-value pairs 
might be overkill.

>> As ugly as %-encoding is, I don't think the requirement to
>> encode '?' that appears in r-components is a huge problem,
>> given that (as you point out) it's quite likely that non-ASCII
>> characters will appear in r-components and they'll also need
>> to be encoded.   Given the wide range of characters that
>> require encoding that can reasonably appear in an r-component,
>> what's the cost of having to encode 0x3f in addition to the
>> rest?   But (for reasons which your example makes quite clear)
>> neither would I recommend using '?' (encoded or otherwise) as
>> a separator between portions (name-value-pairs or whatever) of
>> an r-component.
> While I don't like "ugly", I'm not nearly as worried about it as
> I am about the potential of complete confusion about what the
> rules are, especially because I believe that URNs are more
> likely to actually be seen and typed by users than the typical
> multi-line complex URL.   I had occasion last week to review the
> discussions that were a major part of killing IRI work in the
> IETF and it involved exactly the same issues we've been going
> around on for months as well as more recent ones --
> relationships between URIs and fragments; when %-encoding is
> required, optional, or prohibited; and so on.   The IRI
> experience, IMO, was less about the specifics of those
> discussions than that they drove people away until there was
> insufficient participation on the broader issues to get the work
> done.  I think the desire to not repeat more of that discussion
> --and suffer the same fate, which I think is a very real
> possibility given participation on the list-- is a very strong
> argument to avoid more cases of mandatory %-encoding.
>
>> I also like the idea of being able to copy a URN q-component
>> to a URL query component, and a URN f-component to a URL
>> fragment, without having to do any re-encoding (and I'm far
>> from confident that these translations will only ever be
>> needed in one direction).   I strongly suspect that if
>> different encodings are used for queries vs. q-components and
>> fragments vs. f-components that implementations will botch
>> those translation steps and/or behave inconsistently from one
>> another.
> While I agree with the principle you are suggesting, it is not
> clear to me what is has to do with the "where does the
> r-component go" discussion unless it is an argument for putting
> it after the q-component.

Maybe an example will help.

Say there's a desire to submit a query to a resource named by 
urn:example:foo with r-component a=b.   Say also that the user is 
prompted for the query string, and that the client doesn't know what 
query strings are valid for the resource so it has to pass all query 
strings to the resource without verifying them for syntax.

If r-components appear on the left, the client generates 
urn:example:foo??a=b?XXXX where XXXX is a %-encoded version of whatever 
the user typed in.   urn:example:foo is resolved to some URL 
xxx://example.com/bar?XXXX , and the same XXXX that was appended to the 
URN gets transmitted to the resource.

If r-components appear on the right, the client generates 
urn:example:foo?YYYY??a=b where YYYY is a %-encoded version of whatever 
the user typed in, subject to the additional constraint that if the user 
typed in two consecutive '?' characters, at least one of those is also 
percent-encoded so as not to confuse a URN parser.   But once 
urn:example:foo is resolved to some URL, it should result in 
xxx://example.com/bar?XXXX , where XXXX is the query string that the 
user typed in subjected to normal %-encoding rules.    XXXX will 
sometimes be different than YYYY, and it's possible that sending YYYY to 
the resource will produce different behavior than sending XXXX.

Yes, it's an edge case, and maybe a very narrow one.   But having a 
robust protocol requires dealing with edge cases.   And I'm not saying 
that the problem cannot be solved - clearly it can, say, by requiring 
that URN-capable clients first produce XXXX and then encode that to YYYY 
using a distinguished encoding that is strictly reversible.   But I 
suspect it's not likely to be implemented correctly.

(Of course this is just another example of the common problem that 
multiple layers of quoting can be very confusing and result in very 
strange glitches.   We've seen it in text processing, we've seen it when 
trying to embed one kind of email address in another, we've seen it in 
scripting languages, etc.   So it's hardly surprising that it crops up 
here also.   The usual takeaway is to try to avoid designing systems 
that require multiple layers of quoting.)


>
>> Regarding name-value pairs: I started out thinking that
>> r-components should be name-value pairs.   My current thinking
>> is that they're more like expressions in WHERE clauses (and
>> some other portions) of SQL SELECT statements.   In other
>> words, I think they're more likely to be constraints that are
>> imposed on the result set rather than some named attributes.
>> You could of course still express such things with NVPs, e.g.
>>
>> urn:example:foo:bar??svc=u2c;where=revision_date.gt.%222014012
>> 3%22.and.content_type.eq.%22text/plain%22;order=desc;order_by=
>> revision_date;limit=10
>>
>> but to me, NVPs don't look as useful in r-components as I
>> originally assumed they would be.
> I think the SQL analogy is pure speculation, that all of the
> examples we've seen on the list have been much more amenable to
> name-value pairs or other constructions (as is most existing
> multiple-term query usage I've seen in URIs) and that mixing the
> syntax of URIs (which, as suggested above, almost no end user
> understands in detail) with SQL SELECT clauses (which probably
> fewer end users actually understand) is a recipe for total
> confusion.

SQL is just an example of a language for narrowing queries with which I 
thought participants of this discussion might possibly be familiar, and 
I couldn't think of an alternative that might be more familiar.  For 
several reasons, I don't think we'd want to actually embed SQL in 
r-components.   But any other language containing relational expressions 
would be no more familiar to users, no less complex (if it were to be 
effective), and no easier to embed in URNs without confusing encoding.

Basically I think my own examples are convincing me that r-components 
are not an effective way to specify how to narrow search results.

>    In particular, I note that we've seen several real
> examples where qualifying clauses are needed to distinguish
> between "identify object and return information about it" and
> "identify specific metadata and return their values".  And that
> lends itself rather better to name-value pairs or something
> similar than it does to SQL-like constructions, at least unless
> the "target" of the URN is actually a relational database or
> part of it.  I also note that SQL-like constructions are not
> particularly well adapted to non-relational databases, e.g.,
> hierarchical constructions and that we not only have a lot of
> those around but some of them are built into URI design.

Can you provide an example or two to illustrate how you think NVPs would 
be effective at this?

Keith


From nobody Wed May 27 10:05:04 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 723021A86E6 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 10:05:02 -0700 (PDT)
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 fo6oGfLrRQPN for <urn@ietfa.amsl.com>; Wed, 27 May 2015 10:05:00 -0700 (PDT)
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 138B31A8757 for <urn@ietf.org>; Wed, 27 May 2015 10:04:51 -0700 (PDT)
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 1Yxel2-000OTl-Nl; Wed, 27 May 2015 13:04:44 -0400
Date: Wed, 27 May 2015 13:04:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Svensson, Lars" <L.Svensson@dnb.de>, Peter Saint-Andre - &yet <peter@andyet.net>, Melinda Shore <melinda.shore@gmail.com>, urn@ietf.org
Message-ID: <A073FF3F32A20B4DD2513689@JcK-HP8200.jck.com>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010CF6E4F5@dnbf-ex1.AD.DDB.DE>
References: <554FA892.90208@gmail.com> <B75A448A898B521DADE02049@JcK-HP8200.jck.com> <5564EE74.9000805@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6E4F5@dnbf-ex1.AD.DDB.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/ijYjOAgealXMsnx0qHoUjmT4ncw>
Subject: Re: [urn] r-component syntax
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, 27 May 2015 17:05:02 -0000

--On Wednesday, May 27, 2015 14:41 +0000 "Svensson, Lars"
<L.Svensson@dnb.de> wrote:

>...
>> > As a shortcut to save a bit of time, I think that, if we
>> > decide to allow r-components, the syntax for in section 3
>> > of 2141bis-11 would change so that the changed productions
>> > would read:
>> > 
>> >         q-component = "?" query [ "??" r-component ]
>> > 	       Note that <query> in the above cannot contain "??"
>> >         r-component = query
>...
>> >        namestring    = assigned-name
>> >                        [ q-component [r-component] ]
>> >                        [ f-component ]
>> >         q-component = "?" q-string
>> >         r-component = "??" r-string
>> > 
>> > If anyone who thinks we should adopt r-components has a
>> > strong preference among those alternatives, please say so,
>> > otherwise, Peter and I will draw straws or equivalent.
> 
> I feel a bit confused. Is it really meant that the r-component
> can only exist as an appendix to a q-component? The position
> of the square brackets suggest that. I always thought that we
> could pass instructions to a resolver without having a
> q-component.

You are, of course, correct, proving once again that I should
never be allowed to write ABNF, especially when I'm tired.

> My suggestion would be:
> 
> 	namestring	= assigned-name
> 		[q-component]
> 		[r-component]
> 		[f-component]
> 	q-component = "?" q-string
> 	r-component = "??" r-string

Yes, that is, IMO, correct.

>...

>> Yes, text and examples would be appreciated. (Although any
>> examples are quite speculative at this point.)
> 
> I shall discuss with relevant people at my place.

thanks,
   john


From nobody Wed May 27 11:00:04 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 14A531A8956 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 11:00:02 -0700 (PDT)
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 mEVuXJ_WTKxO for <urn@ietfa.amsl.com>; Wed, 27 May 2015 11:00:00 -0700 (PDT)
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 1DDFE1A8955 for <urn@ietf.org>; Wed, 27 May 2015 10:59:59 -0700 (PDT)
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 1YxfcQ-000Ocv-6g; Wed, 27 May 2015 13:59:54 -0400
Date: Wed, 27 May 2015 13:59:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <643A740663746E82B87FCD4E@JcK-HP8200.jck.com>
In-Reply-To: <5565B9FE.90100@network-heretics.com>
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com> <5564F184.7080206@andyet.net> <98F6D08AB5C3B32F6D5D42A0@JcK-HP8200.jck.com> <5565B9FE.90100@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/KI9codcszYLtcytHgkZ1qQEvZdo>
Cc: urn@ietf.org
Subject: Re: [urn] Namespace consensus and registrations
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, 27 May 2015 18:00:02 -0000

--On Wednesday, May 27, 2015 08:35 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> On 05/27/2015 08:27 AM, John C Klensin wrote:
>> On a related note, I think it is entirely reasonable to
>> include space in the template for people to describe how
>> their namespace uses any or all of p-/q-/r-/f-components
>> without getting involved with elaborate standardization
>> attempts or registration models for the syntax and contents
>> of those fields.
> 
> Strongly disagree with this.
> 
> - I thought we had done away with p-components and just
> decided to permit '/' in NSS.

Keith,

This is another example of the reasons why I am finding all of
the theorizing and repetitive threads involving very few people
to be problematic.

What I had understood from trying to follow the various threads
is that we were getting close to agreement on a particular way
to talk about "/".  I hadn't make the leap from there to "done
away with p-components".  More broadly, I don't get from "one or
two people repeated themselves several times" to "we agreed" (or
"we had done away with").  There have been no comments from
anything resembling a diverse group of WG participants and the
number of consensus calls or other comments from the co-chairs
on this subject has been, well, very small.

> - q-components are interpreted by the resource, not by the
> namespace.  It's very important to make this clear, otherwise
> there will be tussles over their use.

I don't see any conflict between "interpreted by the resource"
and a statement of intent about the namespace.  After all,
namespaces are supposed to be managed and relatively
homogeneous.  One of the important changes in 2141bis is that we
are reducing the external documentation requirements in favor of
requiring (in a few cases) and allowing (in most) more
information in the registration templates. 

As an example, if we created a namespace of cattle, I'd expect
the registration to say, somehow, "this is about cattle".  It
might even distinguish between dairy-type cattle and beef-type
cattle.  The NSS might contain names for subspecies of cows.  If
it contained a designation of a farm or ranch and the name of a
specific cow, it would be getting perilously close to a locator
with persistence that might not last beyond the cow's lifetime.
If someone gets past the management process and slips a duck in
there, I can imagine its causing all sorts of problems and would
hope that one of them would not be an attempt to prove that
ducks are really cows by virtue of their being a duck in the cow
namespace.    There is absolutely nothing we can do in the URN
definition to prevent that duck.   We can, however, allow "this
is about cattle" statements in the namespace registration and
even allow "don't bother asking for things with feathers, you
will get misleading results" statements in the query-explanation
part of the registration.

An explanation in the registration about how the namespace
expects queries to be used seems helpful in that regard.
Without it, the odds of meaningless queries rises and, because
of the way URIs are often implemented, meaningless queries tend
to produce meaningless or very confusing responses to users.

The other issue raised by your comment above is that I have no
actual idea what "interpreted by the resource" means.  I have a
better idea when you say "in light of the resource content, not
by the namespace" as you do for f-components, but only a little.
I am more sure what the latter means, and what the "interpreter"
might do, if the result of interpreting/ resolving a URN is a
URL, particularly and HTTP or HTTPS URL, but, coming back to
that URN for a cattle namespace, I'm fairly confident that an
r-component that distinguished between a request for "picture of
object/resource" and one for "example of object/resource" would
be well-defined but I wouldn't relish the notion of having the
cow-object do the resolution.  I also think that a q-component
(or even an f-component) specifying the right haunch would be
well-defined for either the picture or the sample but that it
might not produce good results if that duck were included in the
namespace.

All of that suggests two things to me:

(1) Discouraging people from offering definition and guidance in
registration requests is probably not a good idea, no matter
what ideas we might have about purity of the URN concept.

(2) While I'm comfortable saying general things and offering
general guidance, the distinctions among r-, q-, and
f-components (and maybe p-components if there is such a thing),
what they "mean", and where and by what they are resolved get
very fuzzy very quickly when abstracted to "names", potentially
of classes of things that cannot be rigidly defined with
enforceable boundaries, rather than web-specific locators and
machine readable objects.


> - f-components are interpreted in light of the resource
> content, not by the namespace.  It's very important to make
> this clear, otherwise there will be tussles over their use.

See above.

> - r-components could potentially be namespace-specific, but
> different namespaces shouldn't interpret the same r-components
> in different ways, any more than different email providers or
> user agents interpret different email header fields in
> different ways.

I think that is an attractive idea in principle but, absent a
grand unified theory of everything, it is unattainable as soon
as we accept the fact that different URN namespaces, and the
resources to which they may refer, can be _really_ different.
I believe that even the discussions of the last month fairly
clearly illustrate that either trying to standardize the
internal syntax of r-components (such as to differentiate
between something organized around name-value pairs and
something organized around something SQL-ish) or to create a
registry of assertions or actions would be a WG killer from
which neither we nor URNs would ever recover.

best,
     john


From nobody Wed May 27 12:48:41 2015
Return-Path: <andy@hxr.us>
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 B0A591A87DE for <urn@ietfa.amsl.com>; Wed, 27 May 2015 12:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level: 
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 9dywN5fMamEw for <urn@ietfa.amsl.com>; Wed, 27 May 2015 12:48:37 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.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 2C8CF1A1ACC for <urn@ietf.org>; Wed, 27 May 2015 12:48:37 -0700 (PDT)
Received: by wifw1 with SMTP id w1so35646453wif.0 for <urn@ietf.org>; Wed, 27 May 2015 12:48:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wlyFSiTm8nwvzItDUyhmTaa5W9cMBN8WECNq/xm1ucY=; b=PEKKjCKaT1jpVBWhVNra0CyPGpqBjGwmeWoVoNRdjlxV+uC+lrR/JQAmiuAdPvdCzu I8z7PP5os0cjFIihyPpYcuYmteCiNrYjChExam93Y3rNvlexFzRs52D57Hs5tqVZ37qb J4UPcibWlnKoBNrfMSjm926T9R2uqpuYor4/XxUSg1fgKhojfq26/KRDMJireJ9mfFCf 5mM4FD4Dqb2mxm9oGPTHhSKg/FgR0+YoFbLl3X+5Ey3QHrRNtjEF3ePOaCL0OOSotWFL XfRBpG+dOTY7nMhhAM68ylUpnBKXIg6pZiUcWeBPLnMW1vwoSW/Gj3cQlrtVbbShuB6C xRQQ==
X-Gm-Message-State: ALoCoQmYNKI263cpjq7UIgtF5E7zzA6QKrgAcZstWix7TzHrTvYHnr1T9Oha3ZyV3TPCTUD4Fgg6
MIME-Version: 1.0
X-Received: by 10.194.192.72 with SMTP id he8mr62718710wjc.11.1432756115786; Wed, 27 May 2015 12:48:35 -0700 (PDT)
Received: by 10.194.249.99 with HTTP; Wed, 27 May 2015 12:48:35 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: <D5077E71059E236621C66D15@JcK-HP8200.jck.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net> <55654B15.70102@network-heretics.com> <D5077E71059E236621C66D15@JcK-HP8200.jck.com>
Date: Wed, 27 May 2015 15:48:35 -0400
Message-ID: <CAAQiQRcRqT_vCyXVt085Yo8tNP6r_sApDsvzF5zw5X-wPodVJQ@mail.gmail.com>
From: Andrew Newton <andy@hxr.us>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary=047d7b873a4a54d925051715877c
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/Qnjjy9wskUXHyD229WbT_C4MZj0>
Cc: "urn@ietf.org" <urn@ietf.org>, Keith Moore <moore@network-heretics.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Subject: Re: [urn] Historical URNs, rants, and progress (was: Re: suggested change for -12 of rfc2141bis section 7.3.6)
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, 27 May 2015 19:48:40 -0000

--047d7b873a4a54d925051715877c
Content-Type: text/plain; charset=UTF-8

Well said, John.

-andy

On Wed, May 27, 2015 at 7:57 AM, John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Wednesday, May 27, 2015 00:41 -0400 Keith Moore
> <moore@network-heretics.com> wrote:
>
> > On 05/26/2015 11:53 PM, Peter Saint-Andre - &yet wrote:
> >> On 5/26/15 9:30 PM, Keith Moore wrote:
> >>> On 05/26/2015 07:17 PM, Peter Saint-Andre - &yet wrote:
> >...
>
> >>> Mumble.
> >>>
> >>> 1. I agree that a URN namespace* that assigns its URNs only
> >>> for use as "abstract designators" rather than as resource
> >>> names should state this in the namespace registration.
> >>>
> >>> <rant>
> >>> IMO, such URN namespaces should never have been granted;
> >>> this was and is a misuse of URNs.  But that water has long
> >>> since passed under the bridge at least for some existing
> >>> namespaces.   The only reason that I think this is useful to
> >...
> >>> intended to be Resource Names, not merely "abstract
> >>> designators" no matter how widely URNs have been misused for
> >>> the latter. </rant>
>
> For the record, while I'm picking up on some comments that Keith
> wrote, he is not the only one and this is not specifically about
> him.
>
> Personal opinion/request: I understand the reason for these
> sorts of rants/ comments from those who had (or believed they
> had) a very clear view of URNs years ago (and whether they are
> explicitly identified or not).  They pose two difficulties and I
> wish they would stop.
>
> First, not only is it water under the bridge, but the door has
> closed.  Perhaps early documents should have described several
> types of URNs and identified multiple types with multiple
> schemes (reserving the term "URN" itself as "URL" is effectively
> reserved).  They/we didn't do that and, as Peter points out,
> probably most of the URNs in use today do not conform to those
> early assumptions in one way or another.      While it arguably
> made things worse, the text in RFC 3986 that says that there are
> such things as "URN"s and that only some of them conform to the
> "urn:" scheme, it at least was an attempt to address the issue.
>
> For the same reason, I object to anything resembling a casual
> reference to RFCs 1737, 2276, or the 2915, 2168, and 3401 family
> in 2141bis.  Common, probably dominant, practices have evolved
> past those documents, 3401 and friends have not been broadly
> used and adopted and general-purpose NAPTR records have proven
> problematic, and so on.  We don't add clarity to what URNs are
> about today (and in the likely future) by citing those
> documents, even as examples.  What we do is to add confusion or
> at least fodder for the next rounds of nit-picking arguments and
> moral outrage about certain types of usage.
>
> I think there is a place for a reprise and summary in the form
> of an updated theory of URNs and URN resolution -- a document
> that would presumably obsolete 1737 and 2276 and comment on the
> applicability of DDDS (and hence 3401ff).  But it doesn't appear
> to be to be within scope for this WG.  Even if it were, it is
> fairly clear we don't have the energy for it.
>
> The other problem is that hair-splitting arguments about the
> true nature of URNs (etc.) drives people with more pragmatic
> interests and less time away from  the WG, leading to a
> situation in which we have long-thread discussions, typically
> about esoteric (if not irrelevant) issues among a handful of
> people, losing broader perspectives and review.
>
> Can we just stop?  If we cannot stop, might I encourage the
> co-chairs to start weighing the impact of such discussions on WG
> progress with an eye to identifying them as disruptive?
>
>
> >...
> >> Thus tilting at that particular windmill strikes me as futile.
>
> Worse than futile.  IMO, they are making it much more difficult
> for the WG to make anything resembling progress.
>
> > Those namespaces would be mostly harmless, except that people
> > keep making assumptions about how URNs are supposed to work
> > based on those mistakes.
>
> See comments about "updated theory" above.  If someone wants to
> write that document and discuss it -- but not on this WG's list
> at least until after we get 2141bis published -- I'm willing to
> read it and review.   But I don't think comments about
> "mistakes" in very wide use on this list are helpful unless they
> are also actionable and contain specific proposals for text that
> would fit into 2141bis and that do not involve turning back the
> clock.
>
> >>> 2. I also agree that a namespace* that intends to operate or
> >>> recommend any resolution services should state this in its
> >>> namespace registration.
> >>>
> >>> What I don't think is appropriate is for the registration to
> >>> specify whether resolution mechanisms are "intended or
> >>> anticipated", since that's really not up to the namespace*.
> >>
> >> Well, it is, but see below.
> >
> > No it's not.   It might not matter for the current discussion,
> > but it's really important to understand that the namespace
> > does not control resolution.
>
> Until we provide more resources --and perhaps whips or guns-- to
> the Protocol Police -- nothing we specify controls anything
> else.  "Intended or anticipated" is an intended/expected best
> practices statement, not a statement about "control".     And,
> again, these hair-splitting discussions are hurting us.
>
> And, if we are going to make a distinction between "abstract
> designator" and something else, I hope we can come up with a
> different term than "resource name", if only because "when is a
> Uniform Resource Name not a resource name" is not just a trivia
> contest question but an invitation to precisely the sort of
> historical hair-splitting that I hope we can avoid.
>
> >...
>
> best,
>     john
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

--047d7b873a4a54d925051715877c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well said, John.<div><br></div><div>-andy</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 27, 2015 a=
t 7:57 AM, John C Klensin <span dir=3D"ltr">&lt;<a href=3D"mailto:john-ietf=
@jck.com" target=3D"_blank">john-ietf@jck.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><br>
<br>
--On Wednesday, May 27, 2015 00:41 -0400 Keith Moore<br>
&lt;<a href=3D"mailto:moore@network-heretics.com">moore@network-heretics.co=
m</a>&gt; wrote:<br>
<br>
&gt; On 05/26/2015 11:53 PM, Peter Saint-Andre - &amp;yet wrote:<br>
&gt;&gt; On 5/26/15 9:30 PM, Keith Moore wrote:<br>
&gt;&gt;&gt; On 05/26/2015 07:17 PM, Peter Saint-Andre - &amp;yet wrote:<br=
>
&gt;...<br>
<br>
&gt;&gt;&gt; Mumble.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1. I agree that a URN namespace* that assigns its URNs only<br=
>
&gt;&gt;&gt; for use as &quot;abstract designators&quot; rather than as res=
ource<br>
&gt;&gt;&gt; names should state this in the namespace registration.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &lt;rant&gt;<br>
&gt;&gt;&gt; IMO, such URN namespaces should never have been granted;<br>
&gt;&gt;&gt; this was and is a misuse of URNs.=C2=A0 But that water has lon=
g<br>
&gt;&gt;&gt; since passed under the bridge at least for some existing<br>
&gt;&gt;&gt; namespaces.=C2=A0 =C2=A0The only reason that I think this is u=
seful to<br>
&gt;...<br>
&gt;&gt;&gt; intended to be Resource Names, not merely &quot;abstract<br>
&gt;&gt;&gt; designators&quot; no matter how widely URNs have been misused =
for<br>
&gt;&gt;&gt; the latter. &lt;/rant&gt;<br>
<br>
For the record, while I&#39;m picking up on some comments that Keith<br>
wrote, he is not the only one and this is not specifically about<br>
him.<br>
<br>
Personal opinion/request: I understand the reason for these<br>
sorts of rants/ comments from those who had (or believed they<br>
had) a very clear view of URNs years ago (and whether they are<br>
explicitly identified or not).=C2=A0 They pose two difficulties and I<br>
wish they would stop.<br>
<br>
First, not only is it water under the bridge, but the door has<br>
closed.=C2=A0 Perhaps early documents should have described several<br>
types of URNs and identified multiple types with multiple<br>
schemes (reserving the term &quot;URN&quot; itself as &quot;URL&quot; is ef=
fectively<br>
reserved).=C2=A0 They/we didn&#39;t do that and, as Peter points out,<br>
probably most of the URNs in use today do not conform to those<br>
early assumptions in one way or another.=C2=A0 =C2=A0 =C2=A0 While it argua=
bly<br>
made things worse, the text in RFC 3986 that says that there are<br>
such things as &quot;URN&quot;s and that only some of them conform to the<b=
r>
&quot;urn:&quot; scheme, it at least was an attempt to address the issue.<b=
r>
<br>
For the same reason, I object to anything resembling a casual<br>
reference to RFCs 1737, 2276, or the 2915, 2168, and 3401 family<br>
in 2141bis.=C2=A0 Common, probably dominant, practices have evolved<br>
past those documents, 3401 and friends have not been broadly<br>
used and adopted and general-purpose NAPTR records have proven<br>
problematic, and so on.=C2=A0 We don&#39;t add clarity to what URNs are<br>
about today (and in the likely future) by citing those<br>
documents, even as examples.=C2=A0 What we do is to add confusion or<br>
at least fodder for the next rounds of nit-picking arguments and<br>
moral outrage about certain types of usage.<br>
<br>
I think there is a place for a reprise and summary in the form<br>
of an updated theory of URNs and URN resolution -- a document<br>
that would presumably obsolete 1737 and 2276 and comment on the<br>
applicability of DDDS (and hence 3401ff).=C2=A0 But it doesn&#39;t appear<b=
r>
to be to be within scope for this WG.=C2=A0 Even if it were, it is<br>
fairly clear we don&#39;t have the energy for it.<br>
<br>
The other problem is that hair-splitting arguments about the<br>
true nature of URNs (etc.) drives people with more pragmatic<br>
interests and less time away from=C2=A0 the WG, leading to a<br>
situation in which we have long-thread discussions, typically<br>
about esoteric (if not irrelevant) issues among a handful of<br>
people, losing broader perspectives and review.<br>
<br>
Can we just stop?=C2=A0 If we cannot stop, might I encourage the<br>
co-chairs to start weighing the impact of such discussions on WG<br>
progress with an eye to identifying them as disruptive?<br>
<br>
<br>
&gt;...<br>
&gt;&gt; Thus tilting at that particular windmill strikes me as futile.<br>
<br>
Worse than futile.=C2=A0 IMO, they are making it much more difficult<br>
for the WG to make anything resembling progress.<br>
<br>
&gt; Those namespaces would be mostly harmless, except that people<br>
&gt; keep making assumptions about how URNs are supposed to work<br>
&gt; based on those mistakes.<br>
<br>
See comments about &quot;updated theory&quot; above.=C2=A0 If someone wants=
 to<br>
write that document and discuss it -- but not on this WG&#39;s list<br>
at least until after we get 2141bis published -- I&#39;m willing to<br>
read it and review.=C2=A0 =C2=A0But I don&#39;t think comments about<br>
&quot;mistakes&quot; in very wide use on this list are helpful unless they<=
br>
are also actionable and contain specific proposals for text that<br>
would fit into 2141bis and that do not involve turning back the<br>
clock.<br>
<br>
&gt;&gt;&gt; 2. I also agree that a namespace* that intends to operate or<b=
r>
&gt;&gt;&gt; recommend any resolution services should state this in its<br>
&gt;&gt;&gt; namespace registration.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What I don&#39;t think is appropriate is for the registration =
to<br>
&gt;&gt;&gt; specify whether resolution mechanisms are &quot;intended or<br=
>
&gt;&gt;&gt; anticipated&quot;, since that&#39;s really not up to the names=
pace*.<br>
&gt;&gt;<br>
&gt;&gt; Well, it is, but see below.<br>
&gt;<br>
&gt; No it&#39;s not.=C2=A0 =C2=A0It might not matter for the current discu=
ssion,<br>
&gt; but it&#39;s really important to understand that the namespace<br>
&gt; does not control resolution.<br>
<br>
Until we provide more resources --and perhaps whips or guns-- to<br>
the Protocol Police -- nothing we specify controls anything<br>
else.=C2=A0 &quot;Intended or anticipated&quot; is an intended/expected bes=
t<br>
practices statement, not a statement about &quot;control&quot;.=C2=A0 =C2=
=A0 =C2=A0And,<br>
again, these hair-splitting discussions are hurting us.<br>
<br>
And, if we are going to make a distinction between &quot;abstract<br>
designator&quot; and something else, I hope we can come up with a<br>
different term than &quot;resource name&quot;, if only because &quot;when i=
s a<br>
Uniform Resource Name not a resource name&quot; is not just a trivia<br>
contest question but an invitation to precisely the sort of<br>
historical hair-splitting that I hope we can avoid.<br>
<br>
&gt;...<br>
<br>
best,<br>
=C2=A0 =C2=A0 john<br>
<br>
_______________________________________________<br>
urn mailing list<br>
<a href=3D"mailto:urn@ietf.org">urn@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/urn" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/urn</a><br>
</blockquote></div><br></div>

--047d7b873a4a54d925051715877c--


From nobody Wed May 27 13:01:17 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 6CBEB1A9174 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:01:14 -0700 (PDT)
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 MBGCUvm0GAGw for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:01:13 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0B71A9171 for <urn@ietf.org>; Wed, 27 May 2015 13:01:12 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2963920B6F for <urn@ietf.org>; Wed, 27 May 2015 16:01:12 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 27 May 2015 16:01:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=VsDRtrfRgDVxYnu mACn60mC6LZI=; b=sonn1uxkDXC6t3PxcLE+1xiyGcpUhkP3EKkBWKUT9SNUUyf AVAISwzQc4XPdbf9yKcJ0pUyLTlT3i9+u08wIkNHSZSQuTCGMcmrCOT5oU4B4gqI m6SpPl/Kn2XB1UPDh+DqHLhrAcptpGNilrquDA8r0HimuwSOrtmqd7x7AH8E=
X-Sasl-enc: lo78S3xYutx7PQ+lnwmAJ0rvLhRi3zxUzGzDXGImwXR4 1432756871
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A1AC8C00011; Wed, 27 May 2015 16:01:11 -0400 (EDT)
Message-ID: <55662277.30403@network-heretics.com>
Date: Wed, 27 May 2015 16:00:55 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Peter Saint-Andre - &yet <peter@andyet.net>, urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net> <55654B15.70102@network-heretics.com> <D5077E71059E236621C66D15@JcK-HP8200.jck.com>
In-Reply-To: <D5077E71059E236621C66D15@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/D_6xx7Q_6IDK_JXNup2FG_7H-H0>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 20:01:14 -0000

On 05/27/2015 07:57 AM, John C Klensin wrote:
> Personal opinion/request: I understand the reason for these
> sorts of rants/ comments from those who had (or believed they
> had) a very clear view of URNs years ago (and whether they are
> explicitly identified or not).  They pose two difficulties and I
> wish they would stop.

I agree at least to the extent that we're generally better off focusing 
on the proposed text rather than philosophical arguments. I think 
2141bis is moving in the right direction, and that we're close to having 
some good compromises, and I appreciate that.    I'm just concerned 
because I see potential for some of these misunderstandings about URNs 
to creep into the document text, either explicitly or more likely by 
omission, and I really don't want to see this WG make those problems any 
worse than they already are. If it weren't for that potential, I'd 
happily reserve my discussions on these subjects to bar BOFs and private 
mail.

I also don't think it's either constructive or appropriate to dismiss 
the opinions of those who invested huge amounts of time 20+ years ago 
into forging an understanding of how URNs needed to work, or the 
consensus documents that they produced, as dated, irrelevant, or 
illusory.    Insults such as these demand responses, responses snowball, 
and the tendency is for those discussions to become ugly.   I think 
those discussions are much more of a deterrent to making technical 
progress than discussions about the meaning of URNs - whether or not you 
label them as hair-splitting.

Early uses of URNs should not be taken as an indicator of how URNs will 
or should be used in the long run, any more than early uses of IPv6 
should be taken as an indicator of how IPv6 will or should be used in 
the long run.  I understand the desire to reconcile the intended purpose 
of URN with current practice, even when that practice is peripheral to 
the purpose of URNs.   And that's fine with me as long as we don't 
degrade the ability of URNs to serve their intended purpose.    The 
"millions of URNs" that I keep hearing about that have been produced by 
libraries and archives are very much within the intended purpose of URNs 
(though the intended scope of URNs is somewhat broader than that), but 
abstract designators are not.   So abstract designators shouldn't be 
cited in arguments for how URNs are supposed to work, any more than 
Heartbleed should be used to support an argument that TLS should permit 
hostile attacks.

Keith



From nobody Wed May 27 13:13:16 2015
Return-Path: <andy@hxr.us>
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 24EBD1A9236 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JZHF7szs4fpK for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:13:13 -0700 (PDT)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 2CC871A6FEE for <urn@ietf.org>; Wed, 27 May 2015 13:13:13 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so123898467wic.0 for <urn@ietf.org>; Wed, 27 May 2015 13:13:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EP2n62upUEnXRiPP1vZ76u9kxw6+B44NVYzWGOOHoyY=; b=aP6sdILZqVYzZ6S0ZuwQLTXdBFcrX4JXOzRYWuCOwj2Lk/GZUaazfDeI0LWLVrsKCL 1Q6h+0B6fEkGDQ3YUo0/q7OArcs8iaYjrkeR3CYzfq9ensq3a/tbnK1Ut1WMcuD+Lhb4 qnYwK+3jIRObjqS/uFktLexD+sDOs+uO2f+s4c5HYr1vbpGFrNslBFUlmwhcoycNDTmo ky+b1iLoqiypC7p3W57HVUk+Q4pCAcLubhrKntLyrYgPW8gBOfUH2dDbBKiMQBl243xY 8jeC73D4XzE+lnXz/3uRcFNvKGxdrSlRm1AXn2PTyYgLWcVziPHzdwE0T6QWakHWP0bV FmDw==
X-Gm-Message-State: ALoCoQlzatWKGu91My3rOGaUtivYIa48G4MbpuaXCJC0bHbT0751rNcgdhamOhwP1EoptSPWHLaH
MIME-Version: 1.0
X-Received: by 10.180.106.97 with SMTP id gt1mr8953451wib.37.1432757591931; Wed, 27 May 2015 13:13:11 -0700 (PDT)
Received: by 10.194.249.99 with HTTP; Wed, 27 May 2015 13:13:11 -0700 (PDT)
X-Originating-IP: [2001:500:4:15:6d13:f92f:21d4:d470]
In-Reply-To: <55662277.30403@network-heretics.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net> <55654B15.70102@network-heretics.com> <D5077E71059E236621C66D15@JcK-HP8200.jck.com> <55662277.30403@network-heretics.com>
Date: Wed, 27 May 2015 16:13:11 -0400
Message-ID: <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com>
From: Andrew Newton <andy@hxr.us>
To: Keith Moore <moore@network-heretics.com>
Content-Type: multipart/alternative; boundary=f46d04428066510730051715df88
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/aNnXTTwpZUU9ZacFF5ZBGHLa5Ts>
Cc: "urn@ietf.org" <urn@ietf.org>, Peter Saint-Andre - &yet <peter@andyet.net>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 20:13:15 -0000

--f46d04428066510730051715df88
Content-Type: text/plain; charset=UTF-8

On Wed, May 27, 2015 at 4:00 PM, Keith Moore <moore@network-heretics.com>
wrote:

> I also don't think it's either constructive or appropriate to dismiss the
> opinions of those who invested huge amounts of time 20+ years ago into
> forging an understanding of how URNs needed to work, or the consensus
> documents that they produced, as dated, irrelevant, or illusory.    Insults
> such as these demand responses, responses snowball, and the tendency is for
> those discussions to become ugly.   I think those discussions are much more
> of a deterrent to making technical progress than discussions about the
> meaning of URNs - whether or not you label them as hair-splitting.


I don't think insults were intended.

But when outsiders see 20 year-old arguments being rehashed, they tend to
think "religion" and move on. It makes getting review of our documents more
difficult.

-andy

--f46d04428066510730051715df88
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, May 27, 2015 at 4:00 PM, Keith Moore <span dir=3D"ltr">&lt;<a href=
=3D"mailto:moore@network-heretics.com" target=3D"_blank">moore@network-here=
tics.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I also d=
on&#39;t think it&#39;s either constructive or appropriate to dismiss the o=
pinions of those who invested huge amounts of time 20+ years ago into forgi=
ng an understanding of how URNs needed to work, or the consensus documents =
that they produced, as dated, irrelevant, or illusory.=C2=A0 =C2=A0 Insults=
 such as these demand responses, responses snowball, and the tendency is fo=
r those discussions to become ugly.=C2=A0 =C2=A0I think those discussions a=
re much more of a deterrent to making technical progress than discussions a=
bout the meaning of URNs - whether or not you label them as hair-splitting.=
</blockquote></div><br>I don&#39;t think insults were intended.</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But when outsider=
s see 20 year-old arguments being rehashed, they tend to think &quot;religi=
on&quot; and move on. It makes getting review of our documents more difficu=
lt.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-a=
ndy</div></div>

--f46d04428066510730051715df88--


From nobody Wed May 27 13:17:36 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 41F121A92BA for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 02Ao5FSDd54e for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:17:33 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFABD1A92DC for <urn@ietf.org>; Wed, 27 May 2015 13:17:33 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3BCC020B18 for <urn@ietf.org>; Wed, 27 May 2015 16:17:33 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 27 May 2015 16:17:33 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Bt58wM3TNfvQd4dW5RoM37G8qkY=; b=J8Rej O2jJHxyWm/1Lxm7xynA8fXEILHadga/K64XirQPNAezCTw0rcTgQxovlqypR17ao DynhWQ3pJitS3jkDzIQnjc3EmDXLfUX2T4G8GWNtCvt5KI1VxfdFDTgBMEuzZiFX TabN9IlpJBu5LdIZrPwW8HHWLu3f0942kq8N44=
X-Sasl-enc: 1mszVRMl0/RW1OP7hQxf18zclYrfmDnBnAqdURNyqzls 1432757852
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id BE3C1C00015; Wed, 27 May 2015 16:17:32 -0400 (EDT)
Message-ID: <5566264C.8030007@network-heretics.com>
Date: Wed, 27 May 2015 16:17:16 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Andrew Newton <andy@hxr.us>
References: <55430DDE.5070104@network-heretics.com>	<5564FD3F.9070302@andyet.net>	<5564FF01.70204@andyet.net>	<55653A6D.5040400@network-heretics.com>	<55653FB4.1040800@andyet.net>	<55654B15.70102@network-heretics.com>	<D5077E71059E236621C66D15@JcK-HP8200.jck.com>	<55662277.30403@network-heretics.com> <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com>
In-Reply-To: <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060005060406020109010107"
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/R-iZCy0_FEmJlbFN8G3A0Nsx8bg>
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 20:17:35 -0000

This is a multi-part message in MIME format.
--------------060005060406020109010107
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 05/27/2015 04:13 PM, Andrew Newton wrote:
>
> On Wed, May 27, 2015 at 4:00 PM, Keith Moore 
> <moore@network-heretics.com <mailto:moore@network-heretics.com>> wrote:
>
>     I also don't think it's either constructive or appropriate to
>     dismiss the opinions of those who invested huge amounts of time
>     20+ years ago into forging an understanding of how URNs needed to
>     work, or the consensus documents that they produced, as dated,
>     irrelevant, or illusory.    Insults such as these demand
>     responses, responses snowball, and the tendency is for those
>     discussions to become ugly.   I think those discussions are much
>     more of a deterrent to making technical progress than discussions
>     about the meaning of URNs - whether or not you label them as
>     hair-splitting.
>
>
> I don't think insults were intended.
>
> But when outsiders see 20 year-old arguments being rehashed, they tend 
> to think "religion" and move on. It makes getting review of our 
> documents more difficult.
>
> -andy

So we're basically supposed to ignore all of the history and thinking 
and consensus that went into URNs and just accept whatever the document 
authors say?

Keith


--------------060005060406020109010107
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 05/27/2015 04:13 PM, Andrew Newton
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, May 27, 2015 at 4:00 PM,
            Keith Moore <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:moore@network-heretics.com" target="_blank">moore@network-heretics.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">I also
              don't think it's either constructive or appropriate to
              dismiss the opinions of those who invested huge amounts of
              time 20+ years ago into forging an understanding of how
              URNs needed to work, or the consensus documents that they
              produced, as dated, irrelevant, or illusory.    Insults
              such as these demand responses, responses snowball, and
              the tendency is for those discussions to become ugly.   I
              think those discussions are much more of a deterrent to
              making technical progress than discussions about the
              meaning of URNs - whether or not you label them as
              hair-splitting.</blockquote>
          </div>
          <br>
          I don't think insults were intended.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">But when outsiders see 20 year-old
          arguments being rehashed, they tend to think "religion" and
          move on. It makes getting review of our documents more
          difficult.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">-andy</div>
      </div>
    </blockquote>
    <br>
    So we're basically supposed to ignore all of the history and
    thinking and consensus that went into URNs and just accept whatever
    the document authors say?   <br>
    <br>
    Keith<br>
    <br>
  </body>
</html>

--------------060005060406020109010107--


From nobody Wed May 27 13:29:37 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 DDDE91A8A67 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:29:35 -0700 (PDT)
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 vEAxggvgxY8v for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:29:34 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 AADAF1A005B for <urn@ietf.org>; Wed, 27 May 2015 13:29:34 -0700 (PDT)
Received: by paza2 with SMTP id a2so5988868paz.3 for <urn@ietf.org>; Wed, 27 May 2015 13:29:34 -0700 (PDT)
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=PBEfIwg+25g1zrJvKp6B5ZeifPJansNkmtklNJeiI7g=; b=NxWfkYpBX14PR5MbUz6eZA83SU5moPvjxsYKhLZ7aQx6fvNYJUohRgYoYVEwHLFLWF O9VvTP5HT6uUM7S1geDlQ7Umm4mrFjyuwXn5NEGeg18GLP3H6uljVoaorl6oAgCq0bkf FpSfRXHWlsbIdlGdloAN9Rs/XBF1vWdV9cwJdb511m7IZNl0AUujpyMx6R6ytUJmFrk7 8HDwj1ppVUTAqW0vi5d+LemXQl0fj+c3V5Fyb5oV/+AX/RX9768Dityt8eFUbuh5AVDu wkmYcorOtCXt8WAiXQlhrUvDD7j1R6WYN1p7QRUfYTx3w6yPC7XsvQwAk4xcQbmg72f1 UhRw==
X-Received: by 10.66.63.41 with SMTP id d9mr12825212pas.47.1432758574378; Wed, 27 May 2015 13:29:34 -0700 (PDT)
Received: from spandex.local (216-67-51-67-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.51.67]) by mx.google.com with ESMTPSA id qe9sm33172pbc.62.2015.05.27.13.29.33 for <urn@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 13:29:33 -0700 (PDT)
Message-ID: <5566292B.9090207@gmail.com>
Date: Wed, 27 May 2015 12:29:31 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55430DDE.5070104@network-heretics.com>	<5564FD3F.9070302@andyet.net>	<5564FF01.70204@andyet.net>	<55653A6D.5040400@network-heretics.com>	<55653FB4.1040800@andyet.net>	<55654B15.70102@network-heretics.com>	<D5077E71059E236621C66D15@JcK-HP8200.jck.com>	<55662277.30403@network-heretics.com> <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com> <5566264C.8030007@network-heretics.com>
In-Reply-To: <5566264C.8030007@network-heretics.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/4ZgMrrz49zNlCCOQxaBCX3kCVyI>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 20:29:36 -0000

On 5/27/15 12:17 PM, Keith Moore wrote:
> So we're basically supposed to ignore all of the history and thinking
> and consensus that went into URNs and just accept whatever the document
> authors say?  

No, of course not.  I think the concern here is that discussion
stay rooted in engineering considerations, and that objections
that are raised should be as specific as possible about what would
break and why that's a problem.  In the interest of producing a
usable, useful spec we do need to stay focused on engineering
considerations.

Melinda


From nobody Wed May 27 13:32:01 2015
Return-Path: <andy@hxr.us>
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 98F421AC3A2 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Z2klHxdeQR84 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 13:31:59 -0700 (PDT)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (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 4AE401AC39D for <urn@ietf.org>; Wed, 27 May 2015 13:31:59 -0700 (PDT)
Received: by wgv5 with SMTP id 5so19582854wgv.1 for <urn@ietf.org>; Wed, 27 May 2015 13:31:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cbLuZ+LwXe+88w8iXmUwXpi4cjd0odENvswvPNPMfps=; b=dkA+m7RMqwjxl+lPd/Z/QKZcH55WcwJfO1fR6fIj611UF+3ar1vxKkOon9dXkGzomA iyRrAYewfZPdon/9P6gfZiFgwuCJhfIqoyhnNYoKxh29NTg2HHwrPqPSADk7hC/xwtrg 4TtT8uz6fG8l5aL1l85KNlj/LXUivDuPASWrjqv9ysi8NRdX5sohCEWa3Q58nOMKUN4+ yo8t0DrtLTaONkBOMFUJhl4mvRJUBCkXrA497QIaZrZDxF1NjpVAvx3eLeODQtvYF9pr OAoPwomKyrTeZAUicDnJ1jPjaIqv2JDf5xvlH4jhlZlD/h6geHnlNFq28iA7hr3ruSQf mVXQ==
X-Gm-Message-State: ALoCoQkoWluQhaf509qilxfl0iYAPgiwqGm61NTYycQILwyghltqPDSCA5jMuuwI6+Drtzofwt93
MIME-Version: 1.0
X-Received: by 10.181.13.5 with SMTP id eu5mr52473595wid.37.1432758718101; Wed, 27 May 2015 13:31:58 -0700 (PDT)
Received: by 10.194.249.99 with HTTP; Wed, 27 May 2015 13:31:58 -0700 (PDT)
X-Originating-IP: [2001:500:4:15:6d13:f92f:21d4:d470]
In-Reply-To: <5566264C.8030007@network-heretics.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com> <55653FB4.1040800@andyet.net> <55654B15.70102@network-heretics.com> <D5077E71059E236621C66D15@JcK-HP8200.jck.com> <55662277.30403@network-heretics.com> <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com> <5566264C.8030007@network-heretics.com>
Date: Wed, 27 May 2015 16:31:58 -0400
Message-ID: <CAAQiQRcvFgSfYHHSS0Cww55EEaJPqRu9u-1Ogqf1zs6TcGejpQ@mail.gmail.com>
From: Andrew Newton <andy@hxr.us>
To: Keith Moore <moore@network-heretics.com>
Content-Type: multipart/alternative; boundary=f46d043be04c71100b0517162249
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/CXBAgIjMLpcvp8RHFhgXvddfWLo>
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 20:32:00 -0000

--f46d043be04c71100b0517162249
Content-Type: text/plain; charset=UTF-8

On Wed, May 27, 2015 at 4:17 PM, Keith Moore <moore@network-heretics.com>
wrote:

> So we're basically supposed to ignore all of the history and thinking and
> consensus that went into URNs and just accept whatever the document authors
> say?


Keith,

There is quite a bit of distance between the point I was making and the
conclusion you seem to have drawn.

-andy

--f46d043be04c71100b0517162249
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, May 27, 2015 at 4:17 PM, Keith Moore <span dir=3D"ltr">&lt;<a href=
=3D"mailto:moore@network-heretics.com" target=3D"_blank">moore@network-here=
tics.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So we&#3=
9;re basically supposed to ignore all of the history and
    thinking and consensus that went into URNs and just accept whatever
    the document authors say?</blockquote></div><br>Keith,</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">There is quite a bit =
of distance between the point I was making and the conclusion you seem to h=
ave drawn.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">-andy</div></div>

--f46d043be04c71100b0517162249--


From nobody Wed May 27 14:08:07 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 DA5851A1A60 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:08:06 -0700 (PDT)
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 0bznoFUZkaKj for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:08:05 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9EB1A00F0 for <urn@ietf.org>; Wed, 27 May 2015 14:08:05 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D2BAA20961 for <urn@ietf.org>; Wed, 27 May 2015 17:08:04 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 27 May 2015 17:08:04 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ZvXsA2M42+uKHWT tCIWE+5bkSoI=; b=NjYr5roiwJRz/6o+Rs7ATdorkoe6JhjDF0ch1vC5SyV4vHP dnX467QAYPM4F08QymEGFXkCnyflDko5weHp3lXlVXGq14Q4PUK6Ypy328SrzX3E DNaLK7vib3mYN6JQzPZyqkY3BcOu6F9YgsvhhP9ooy/v86R+Uk9DqW9V2XqA=
X-Sasl-enc: e1p1t6dA+SgIeLK67XEWbr7StXGoKM692njt9FeI3kPU 1432760884
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 77F5E6800C1; Wed, 27 May 2015 17:08:04 -0400 (EDT)
Message-ID: <55663223.1000700@network-heretics.com>
Date: Wed, 27 May 2015 17:07:47 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55430DDE.5070104@network-heretics.com>	<5564FD3F.9070302@andyet.net>	<5564FF01.70204@andyet.net>	<55653A6D.5040400@network-heretics.com>	<55653FB4.1040800@andyet.net>	<55654B15.70102@network-heretics.com>	<D5077E71059E236621C66D15@JcK-HP8200.jck.com>	<55662277.30403@network-heretics.com> <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com> <5566264C.8030007@network-heretics.com> <5566292B.9090207@gmail.com>
In-Reply-To: <5566292B.9090207@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/7316FTjEiCyI1Sn3JxbfBo208Sw>
Subject: Re: [urn] Historical URNs, rants, and progress
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, 27 May 2015 21:08:07 -0000

On 05/27/2015 04:29 PM, Melinda Shore wrote:
> On 5/27/15 12:17 PM, Keith Moore wrote:
>> So we're basically supposed to ignore all of the history and thinking
>> and consensus that went into URNs and just accept whatever the document
>> authors say?
> No, of course not.  I think the concern here is that discussion
> stay rooted in engineering considerations, and that objections
> that are raised should be as specific as possible about what would
> break and why that's a problem.  In the interest of producing a
> usable, useful spec we do need to stay focused on engineering
> considerations.

I'm entirely concerned about things that have the potential to affect 
interoperability and applicability of URNs.   I think those qualify as 
engineering concerns.   But there's a lot of subtlety to URNs, and the 
URN specifications reflect a lot of carefully-considered decisions that 
were made for reasons that are not exposed in those specifications and 
perhaps not obvious.

So whenever some proposal has the potential to affect interoperability 
or applicability of URNs, I think it's reasonable to discuss the 
thinking behind those decisions.   It's not that I want to rehash old 
discussions, but sometimes it seems like the simplest way to explain why 
a particular proposal to change URNs, namespace registration, etc. might 
do harm.

Keith


From nobody Wed May 27 14:10:21 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 F000C1A90CF for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:10:19 -0700 (PDT)
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 lzwcAYl6y25z for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:10:17 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BF21A87E4 for <urn@ietf.org>; Wed, 27 May 2015 14:10:17 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4082B2092C for <urn@ietf.org>; Wed, 27 May 2015 17:10:14 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 27 May 2015 17:10:14 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=oLbCZ0PM09BBH/D vH7jmDCPKODQ=; b=OpaTqZ0ZgBf5TKDk+O+vX+JJsZ4HT3JB88wC+qKJyMXlLmD iR1tm1ieW/OdWyOTYlOKi4VDoc1kCPnGMlCh6UBSX1QhVQdakdebSUtmNWXsC7YF d97IxCOH7deVX3fYTbcn8Vny/0UzfSgpjN+JsiXQBnEemXS52bitZT0Yl0ts=
X-Sasl-enc: MOZTqDsLKfWDTXkZSTh327qdBXqQz/VpmR9t6akm+hSn 1432761013
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B8015680128; Wed, 27 May 2015 17:10:13 -0400 (EDT)
Message-ID: <556632A5.8000608@network-heretics.com>
Date: Wed, 27 May 2015 17:09:57 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  Peter Saint-Andre - &yet <peter@andyet.net>
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com> <5564F184.7080206@andyet.net> <98F6D08AB5C3B32F6D5D42A0@JcK-HP8200.jck.com> <5565B9FE.90100@network-heretics.com> <643A740663746E82B87FCD4E@JcK-HP8200.jck.com>
In-Reply-To: <643A740663746E82B87FCD4E@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/toJLJuiLNt-6GjbTYxC8zVJfFT0>
Cc: urn@ietf.org
Subject: Re: [urn] Namespace consensus and registrations
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, 27 May 2015 21:10:20 -0000

On 05/27/2015 01:59 PM, John C Klensin wrote:
>
> --On Wednesday, May 27, 2015 08:35 -0400 Keith Moore
> <moore@network-heretics.com> wrote:
>
>> On 05/27/2015 08:27 AM, John C Klensin wrote:
>>> On a related note, I think it is entirely reasonable to
>>> include space in the template for people to describe how
>>> their namespace uses any or all of p-/q-/r-/f-components
>>> without getting involved with elaborate standardization
>>> attempts or registration models for the syntax and contents
>>> of those fields.
>> Strongly disagree with this.
>>
>> - I thought we had done away with p-components and just
>> decided to permit '/' in NSS.
> Keith,
>
> This is another example of the reasons why I am finding all of
> the theorizing and repetitive threads involving very few people
> to be problematic.

I share your frustration with the small number of participants. And yet, 
it's hard to escape the impression that it's okay for some people to do 
theorizing and repeat themselves, but not for others.

> What I had understood from trying to follow the various threads
> is that we were getting close to agreement on a particular way
> to talk about "/".  I hadn't make the leap from there to "done
> away with p-components".  More broadly, I don't get from "one or
> two people repeated themselves several times" to "we agreed" (or
> "we had done away with").  There have been no comments from
> anything resembling a diverse group of WG participants and the
> number of consensus calls or other comments from the co-chairs
> on this subject has been, well, very small.

In a very small group of participants, some/most of whom pop in only 
occasionally, it's hard to know how to evaluate consensus.   I thought 
we had moved past p-components into simply allowing '/' to appear in an 
NSS, but others may still be thinking in terms of p-components.   That's 
fine - but I think it is better to state assumptions and let others 
challenge them, than to leave them unstated and assume that everyone 
else is thinking the same way.
>> - q-components are interpreted by the resource, not by the
>> namespace.  It's very important to make this clear, otherwise
>> there will be tussles over their use.
> I don't see any conflict between "interpreted by the resource"
> and a statement of intent about the namespace.  After all,
> namespaces are supposed to be managed and relatively
> homogeneous.

Speaking of theorizing, I'm wondering where that idea came from. I don't 
believe that namespaces are "supposed" to be relatively homogeneous.   I 
might have forgotten but I don't recall seeing that in any of the URN WG 
consensus documents (1737, 2141, etc.) nor do I recall anything 
resembling a consensus on that from URN WG discussion.

(And again, we should be careful about overgeneralizing from early use 
of URNs.   So I don't think existing URN namespaces should be used as an 
argument in favor of dictating policy, unless of course we've identified 
something from early use that's broken and needs to be fixed.)

What I do believe is that it's fairly natural for URN namespaces to be 
aligned with specific user communities, especially communities that 
already have their own namespaces established.    And such communities 
and other pre-existing namespaces have often formed around particular 
kinds of content or media.   So there's an observable tendency for 
existing URN namespaces to be aligned with particular kinds of content 
or media.   But that's not a requirement, and it shouldn't be 
interpreted as one.

Back to q-components.   The first issue I have with documenting them as 
part of URN namespace registration is that this threatens to conflict 
with the notion that when a URN is resolved to a URL, a q-component 
attached to that URN becomes a query attached to that URL.   That's a 
nice, simple way of interpreting q-components that is highly likely to 
be implemented correctly, highly likely to be interoperable between 
different implementations, makes sense across all namespaces, and 
doesn't make resources that accept queries less functional when named by 
URNs.     That's awesome, and I wish we could make everything we do in 
IETF work that well.

But if there's also a namespace-specific interpretation of q-components 
that's specified in that namespace's registration, then there are *two* 
specifications for how to interpret a q-component, and a very high 
probability of conflict between the two.   This is what I want to 
avoid.    I don't want client implementors trying to second-guess 
whether to interpret q-components according to each namespace's 
registration vs. the general rule for handling q-components.   And I 
don't want namespaces to get the idea that they can override 
interpretation of q-components.

Second concern:   Of course, if a namespace wants to decree that it will 
only assign its URNs to resources that implement q-components in one 
particular way, and it wants to document that, it's free to do so.   And 
if that namespace wants to document that information, they should be 
free to do so.   But putting spaces for that in the URN registration 
template is basically encouraging them to nail down their specification 
for q-components.   In addition to the interoperability concerns I 
stated above, I think this is probably shortsighted.   It's basically 
encouraging the namespace to say "we know what q-components are going to 
need to look like for every resource we want to name, for all time, or 
at least until we update our namespace registration".   And I think 
media are changing so quickly these days that it's very hard to 
anticipate what future needs will be.   So I don't think IETF should 
particularly encourage that level of specification in general.   For a 
couple of namespaces it might make sense, but I think those are corner 
cases rather than the general case.

My concerns for f-components are similar.   Again, I thought 
f-components were supposed to map to URL fragments, and fragments are 
(for better or worse) supposed to be independent of the name or service 
used to access the content.    So we don't want to give URN namespaces 
the impression that they can override this in the namespace 
registration.   And again, if a URN namespace elects to refuse to assign 
its URNs to any resources that contain fragment IDs that don't conform 
to its standards for naming fragments, it's free to do so, but I think 
that's probably shortsighted and IETF probably shouldn't encourage it in 
general.   It might make more sense in a couple of corner cases.

As for r-components, I'll address those in a separate message.

Keith


From nobody Wed May 27 14:51:56 2015
Return-Path: <ldaigle@thinkingcat.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 5C1591ACD1E for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.844
X-Spam-Level: 
X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 5XHSzWctzCkb for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:51:52 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6D1ACD04 for <urn@ietf.org>; Wed, 27 May 2015 14:51:52 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id D1B892005DA05; Wed, 27 May 2015 14:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=p NxIE7B1Ow7urNLIgRYImu6NL3E=; b=nJsAA+RUg6MxedKtaxwul6WfIU+bWS1PI BsF4MAfN9Lyx00kQV3cN+8COK/yv56VgPTCpBtXc1RWpsSG9/C24oX8c417r2/OH G61EnDyioKVxUovxbYqHvSf8fxEJOp62zg8d+n1d9NkDa033QOzCeLH83/BgbolC 4U5TkPxr1k=
Received: from [192.168.1.109] (stjhnbsu0nw-142167228175.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.228.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 112542005DA04; Wed, 27 May 2015 14:51:50 -0700 (PDT)
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
To: "Peter Saint-Andre - &yet" <peter@andyet.net>
Date: Wed, 27 May 2015 17:51:49 -0400
Message-ID: <E24BA7DB-ED19-4F98-9D85-C17153B2382C@thinkingcat.com>
In-Reply-To: <55653A44.2070701@andyet.net>
References: <55388B0E.3080806@network-heretics.com> <553FA044.2000206@thinkingcat.com> <55653A44.2070701@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/ESzNIiITkCLXRuJtVCOiJGS8bNQ>
Cc: "urn@ietf.org" <urn@ietf.org>, Keith Moore <moore@network-heretics.com>
Subject: Re: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
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, 27 May 2015 21:51:54 -0000

Hi,

In-line=E2=80=A6

On 26 May 2015, at 23:30, Peter Saint-Andre - &yet wrote:

> On 4/28/15 8:59 AM, Leslie Daigle (ThinkingCat) wrote:
>>
>> I've been chewing on the proposed f-component and q-component text.
>
> Me too. I will chew on it further and try to formulate even clearer=20
> text based on what Keith has so helpfully proposed.
>
>> I
>> think we need to be clear(er) about the overall concept:  how do
>> fragments and queries fit with instance-independent naming of=20
>> resources?
>> I think it was, indeed, progress to focus on their use as applied to
>> resolution to content (via URN or URL), but I don't think the concept=20
>> of
>> composing parts is quite captured in the proposed text.
>
> Could you perhaps describe a bit more what you mean by "the concept of=20
> composing parts"?

What happens when your URN has f-components and q-components and it=20
resolves to a URL with f-components and q-components was the main issue,=20
if memory serves=E2=80=A6

Leslie.

>
>> It reads as a
>> bunch of complex rules, from which people might (or might not) derive=20
>> a
>> shared concept.
>
> Agreed that the shared concept is key here.
>
>> Example:  If I have a URN for a particular article, that could=20
>> resolve
>> to a URL or a URL for a book with a fragment ID for the article's
>> position within the book.   Suppose the f-component on the URN is for=20
>> a
>> particular section of the article.  By the rules outlined below, that
>> resolves correctly IFF the resolution process goes for content or=20
>> gets a
>> URL that is undecorated by fragments.
>
> That's not good.
>
>> Leslie.
>>
>> On 4/23/15 2:02 AM, Keith Moore wrote:
>
> <snip/>
>
>>> (new section.  note: text in brackets/italics about r-components=20
>>> should
>>> only be included if r-component proposal is adopted)
>>>
>>> TBD.A. Use of f- and q-components in URN resolution
>>>
>>> Since a URN, by design, does not contain either explicitly or=20
>>> implicitly
>>> the name or address of a network service which can be used to access=20
>>> the
>>> resource named by the URN, an application wishing to access that
>>> resource must somehow discover one or more "resolution services"=20
>>> which
>>> can, given the URN, either provide the resource content directly, or
>>> provide information to the application to enable it to access the
>>> resource.
>>>
>>> Though f- and q-components may appear in a URN, they are not=20
>>> assigned or
>>> managed by the URN namespace, but instead evaluated in the context=20
>>> of
>>> the named resource.   Specifically, an f-component of a URN refers=20
>>> to a
>>> "fragment" of the resource named by the URN, and a q-component of a=20
>>> URN
>>> is used to specify a "query" to be evaluated by the resource named=20
>>> by
>>> the URN.   This convention ensures consistent use of these=20
>>> components
>>> across all URN namespaces, and preserves the ability to reference
>>> "fragments" of resources named by URNs that have fragments, and to
>>> specify "queries" with resources named by URNs that support queries.
>>> In order to preserve this ability, f-components and q-components=20
>>> MUST
>>> NOT be transmitted to a URN resolution service except when that=20
>>> service
>>> is being requested to provide direct access (or access via proxy) to=20
>>> the
>>> resource itself.   For all other requests, the client MUST transmit=20
>>> only
>>> the "assigned-part" of a URN /[ along with any r-component//, if
>>> specified ]/ to the URN resolution service.
>>>
>>> A resolution service processing a request for a URN MUST ignore any
>>> f-component or q-component of that URN unless the request is to=20
>>> provide
>>> direct access (or access via proxy) to the named resource.   If the
>>> request is to provide access to the named resource (as opposed to,=20
>>> say,
>>> resource locations or resource metadata), the resolution service=20
>>> MUST
>>> ignore the f-component of the URN and SHOULD (if possible) process=20
>>> the
>>> q-component as if it were a query transmitted to the resource,=20
>>> returning
>>> the resource's response to that query.  If the resolution service=20
>>> cannot
>>> provide the requested access to the resource, but instead returns
>>> resource locations, the f-component and q-component of the request=20
>>> URN
>>> MUST be ignored in determining these locations, and MUST NOT be=20
>>> included
>>> as fragment and query (respectively) in the returned locations.
>>>
>>> These rules are intended to impose a layer separation between the=20
>>> URN
>>> resolution service and the content, and to discourage the URN=20
>>> resolution
>>> service from returning different results depending on the presence=20
>>> of f-
>>> and/or q-components in the request.
>>>
>>> If the resource named by a URN that contains an f- and/or=20
>>> q-component is
>>> accessed via an intermediate URI (other than a URN) obtained from a
>>> resolution service, and that intermediate URI contains neither a
>>> fragment nor a query, the q-component (if present) is appended to=20
>>> the
>>> intermediate URI as a query, and the f-component (if present) is
>>> appended to the intermediate URI as a fragment (in that order).  The
>>> resulting URI is then processed according to RFC 3986.
>>>
>>> Example: If the URN urn:example:foo?bar#zot appears in a link, the
>>> client application might transmit the assigned-part of that URN
>>> (urn:example:foo) to a resolution service with a request for=20
>>> resource
>>> locations.   The resolution service might then return the=20
>>> intermediate
>>> URI http://example.com/whatnot/xyzzy as one of those locations.  =20
>>> The
>>> client would then append ?bar#zot to that intermediate URI producing
>>> http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
>>> processed per normal RFC 3986 rules.
>>>
>>> A resolution service MAY return an intermediate URI which contains a
>>> fragment and/or a query.   If the intermediate URI contains a=20
>>> fragment
>>> or a query, any f- or q-component from the URN is ignored.   (This
>>> situation is basically no different than anyone composing a URI from=20
>>> a
>>> base URI plus a fragment and/or query without being aware of what
>>> fragments and/or queries are valid in the context of the named
>>> resource.   Any user or document author may combine URIs with=20
>>> arbitrary
>>> queries and/or fragments, but that doesn't mean that the results=20
>>> will do
>>> what the user or author intended.)
>>>
>>> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
>>> resolution service might be requested to return locations of the URN
>>> urn:example:foo .  If such a service returned an intermediate URI
>>> http://example.com/whatnot/xyzzy?abcde , neither the q-component=20
>>> ?bar
>>> nor the f-component #zot would be appended to the intermediate URI
>>> before processing it.
>>>
>>> If the content of a resource named by a URN containing an=20
>>> f-component is
>>> obtained directly from a resolution service, the f-component SHOULD=20
>>> be
>>> treated as a "fragment" and evaluated with respect to that content,=20
>>> just
>>> as if the content had been obtained from any other service.
>
>
>
> --=20
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Wed May 27 14:52:33 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 8A1581ACD2A for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 I9ohzOZVDHgt for <urn@ietfa.amsl.com>; Wed, 27 May 2015 14:52:26 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5D21ACD04 for <urn@ietf.org>; Wed, 27 May 2015 14:52:26 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 15D5A20BC0 for <urn@ietf.org>; Wed, 27 May 2015 17:52:26 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 27 May 2015 17:52:26 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=A/IBygddRipr2qgD71pcrW1ftK0=; b=t13Pb RunVpSbULxMHoMYoG+coA/rS1kXvz1cFK16U3kW0jviKTj/iQypTysiBYsNPbkYT N4SZonfAK8Amk5I0fbM1AxLyi5xl7rWqcWvBOMDeknD+QCIx+zcjMnwGigwbjzLN OdxkGOAHgyv8n+a4PdJC1tYgExLYoGeZOOP4mo=
X-Sasl-enc: afy8eaiIuYGTnec3kbrnBe56C0TG+PeWK2PBHN61zZJp 1432763545
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C6C4680195; Wed, 27 May 2015 17:52:25 -0400 (EDT)
Message-ID: <55663C88.9000405@network-heretics.com>
Date: Wed, 27 May 2015 17:52:08 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: urn@ietf.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/TkruDW31ONwgLnpfwSFObcYWaA8>
Subject: [urn] rethinking r-components
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, 27 May 2015 21:52:32 -0000

I originally proposed r-components for two reasons:

1) every single discussion of URN resolution I can recall revealed a 
desire to incorporate resolution service requests into URNs
2) somewhat along the same lines, there was expressed interest in using 
q-components / queries to communicate requests to resolution services, 
and I wanted to avoid the potential for this to conflict with use of 
q-components to transmit queries to resources that were capable of 
accepting them.

But now I'm wondering whether r-components are worth the trouble, and if 
they are, whether we can keep them from getting out-of-hand.

Our discussions have revealed several issues:

- Syntax and specification delay.   If we're going to define 
r-components, we need to do it now.   But it's hard to nail down 
r-component syntax if we can't tell what we need, and hard to tell what 
we need if we can't agree on how they're likely to be used.
- Even if we settle on name-value pairs, there's some reluctance to 
create a registry of names for r-components.   Without a registry, there 
seems to be a significant risk of expecting clients to be aware of 
namespace-specific r-components for several different namespaces, and 
that threatens to degrade the long-term utility of URNs that aren't from 
namespaces that are supported by clients.
- In addition to r-components being transmitted to resolution services, 
it appears that clients also have to be aware of r-components.
- If r-components are used to narrow the result set from a resolution 
service (as I originally assumed) it seems that they're likely to be 
both very lengthy and difficult for humans to parse/read, due to the 
necessity of encoding such information in URI syntax.
- The left vs right discussion that John and I have been having is a 
relatively minor concern, but it does highlight the potential for 
q-components to require an extra layer of encoding as a result of 
r-component syntax decisions.

So I'm now back to thinking that narrowing of results from a resolution 
query is perhaps best done in a conventional programming language 
(presumably JavaScript in the web environment) and that perhaps defining 
a standard URN resolution API for use by programming languages will 
result in better interoperability and robustness than trying to cram 
queries and selectors into URN r-components.   And that leaves me 
wondering what's left for r-components to do.   Maybe just service 
requests like  U2C, U2L, U2R?

Also, it seems to me that in most cases of web usage, the service 
desired from the resolution server can be inferred from context. e.g.

<A HREF="urn:example:foo">  is an interactively-clickable link, and a 
browser can reasonably implement a click by presenting the resource, OR 
presenting its metadata and allowing a click-through to the resource, 
and the behavior might even be different for different resources (e.g. 
if some sort of payment or authentication is required).

<IMG SRC="urn:example:foo">  requires that the content be accessed 
without prompting the user, so the browser will need to either get the 
content directly from the resolution service (U2R) or get a location of 
the content (U2L) and download the content from there.

<FORM ACTION="urn:example:foo"> - the browser must do a U2L request and 
submit the form to one of those locations.



So now my questions are:

- should we dispense with r-components entirely, and can we do so 
without inviting overloading of q-components for resolution service 
parameters?  (I think the latter is still important.)
- if we keep r-components, should we try to limit how they're used so 
that people don't try to cram a general purpose query language into them?



From nobody Wed May 27 15:03:46 2015
Return-Path: <ldaigle@thinkingcat.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 15F8F1AC3ED for <urn@ietfa.amsl.com>; Wed, 27 May 2015 15:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 oj20s1ISHxzo for <urn@ietfa.amsl.com>; Wed, 27 May 2015 15:03:45 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8F1AC3EA for <urn@ietf.org>; Wed, 27 May 2015 15:03:44 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C9FE31B407B; Wed, 27 May 2015 15:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=7 Mw9psc6VP9hBks/qLGYasmWNpo=; b=GCA153L8i9C+kQkseeEQGcMOJ6fgSrbX0 fAgzuv1qz4Ae02lwCIhXUtTpK3DYnjGB4UIORqSLrxt0lVmPp5wA0Du0/2S6QBS4 0P8urp3tWSWmUyOm0Hgbgf9MS4z2339kphxSB2reqh9HJc1S+AsTj8yf37XT45BJ TpcpNCL71g=
Received: from [192.168.1.109] (stjhnbsu0nw-142167228175.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.228.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 238021B4056; Wed, 27 May 2015 15:03:44 -0700 (PDT)
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
To: "Peter Saint-Andre - &yet" <peter@andyet.net>
Date: Wed, 27 May 2015 18:03:42 -0400
Message-ID: <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com>
In-Reply-To: <55652D6F.3050506@andyet.net>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/MQWRtiHGf2M4Wx4mBOzQ_i5g2ew>
Cc: urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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, 27 May 2015 22:03:46 -0000

My recollection aligned with Keith=E2=80=99s =E2=80=94 that we agreed to =
do away=20
with p-components.   Digging back, have a look at the thread that=20
started with Keith=E2=80=99s message with subject =E2=80=9Csuggested text=
 changes=20
for -12 on p-components, f- and q-components in URN resolution, and=20
relative references=E2=80=9D.

It made sense to Keith, me, Juha and Sven at the time, it seems.  (And=20
it still makes sense to me, FWIW :^) ).

Leslie.

--=20

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------
On 26 May 2015, at 22:35, Peter Saint-Andre - &yet wrote:

> On 4/17/15 10:01 AM, Leslie Daigle (ThinkingCat) wrote:
>>
>>
>> I think this is a rational, if hypothetical, reason for p-components,
>> and my requirement would be for the document to be clear about the=20
>> use:
>>
>>> For those namespaces that need additional qualification (beyond
>>> the traditional NSS) that still participates in equality
>>> checking, that has so far left p-components as the only logical
>>> option.  Perhaps there is some other syntax that would do the
>>> job --a hypothetical X-component -- but, so far, no one has
>>> proposed one and the logic of 3986 is such that I think we can
>>> expect any such syntax proposal to produce cries of pain about
>>> generic URI parsers and related topics.
>>
>>
>> IMO, that can be achieved by being clear about what the NSS is,=20
>> assert
>> that relative URNs are not expected/permitted, and attest that "/"
>> should not be used in a URN simply because one is importing a=20
>> namespace
>> that happens to use them and it's a matter of syntactic convenience=20
>> not
>> to escape them with %-encoding.
>
> How is this for proposed text?
>
>  The namespace specific string (NSS) is a unique identifier that is
>  assigned in a consistent way and that conforms to the definition of
>  the relevant namespace.  The combination of the NID (unique across
>  the entire "urn" scheme) and the NSS (unique within the namespace)
>  ensures that the resulting URN is a globally unique URI.
>
>  This document modifies the syntax of the NSS to allow the following
>  characters: "/", "~", and "&".
>
>  In particular, allowing the "/" character effectively makes it
>  possible to encapsulate hierarchical identifiers from other naming
>  systems.  For instance, consider the hypothetical example of a
>  hierarchical naming system in which the identifiers take the form of
>  a series of numbers separated by the "/" character, such as "1/406/
>  47452/2".  If the naming authority for such identifiers were to use
>  URNs, it would be natural to place the existing identifiers in the
>  NSS, resulting in URNs such as "urn:example:1/406/47452/2".
>  Nevertheless, it is not appropriate the "/" character be used in a
>  URN merely because the URN namespace is importing a naming system
>  that happens to use the character; it is simply a matter of syntactic
>  convenience not to escape the character with percent-encoding.
>
> Peter
>
> --=20
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Wed May 27 15:07:33 2015
Return-Path: <ldaigle@thinkingcat.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 920C71ACD1D for <urn@ietfa.amsl.com>; Wed, 27 May 2015 15:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 nhk3Toxa3Yzq for <urn@ietfa.amsl.com>; Wed, 27 May 2015 15:07:29 -0700 (PDT)
Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 920321ACD11 for <urn@ietf.org>; Wed, 27 May 2015 15:07:29 -0700 (PDT)
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 51CD02640B6; Wed, 27 May 2015 15:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=W lSQmLEDRtZCiVyrbY2zqF/kIB0=; b=qEUsRTuUoNa7JKPCxhJHYwBuqHPhnfJub MWXeluYft6n5EnR22qaKleCfpHLOXa+Z1VSmK39Inw2Ry9j+CBRXjikxwUkhLf1H mcTFTVZomwsM/eNAScfAa9FR7hRhGk7mT+o+jsYUEP1m/1Nq6jtzHamfywTbSfTs yJ/+3rvvkg=
Received: from [192.168.1.109] (stjhnbsu0nw-142167228175.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.228.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 64A3226408B; Wed, 27 May 2015 15:07:28 -0700 (PDT)
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
To: "Peter Saint-Andre - &yet" <peter@andyet.net>
Date: Wed, 27 May 2015 18:07:27 -0400
Message-ID: <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com>
In-Reply-To: <5564FD3F.9070302@andyet.net>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/PGxwWSZUhbWBWgbCCkcBbWnoOIo>
Cc: "urn@ietf.org" <urn@ietf.org>, Keith Moore <moore@network-heretics.com>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 27 May 2015 22:07:31 -0000

FWIW, I=E2=80=99m not just worried about =E2=80=9Crogue=E2=80=9D, I=E2=80=
=99m worried about=20
having a plethora of available tools to apply to URNs and no way to=20
determine what the minter of the URN intended.

And, I believe that=E2=80=99s a change of the spec.

Leslie.

--=20

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------
On 26 May 2015, at 19:09, Peter Saint-Andre - &yet wrote:

> On 4/30/15 11:23 PM, Keith Moore wrote:
>> For reference, the current (-11) text of section 7.3.6:
>>
>> 7.3.6.  Resolution
>>
>> The "Resolution" section MUST specify whether resolution mechanisms
>> are supported or anticipated for URNs assigned within the namespace,
>> and if so SHOULD specify or reference the rules governing those
>> mechanisms.
>>
>> In particular, if resolution is anticipated and resolver registration
>> of some kind is required, for example via a Resolution Discovery
>> System [RFC2276], this section SHOULD list the requirements for
>> becoming a recognized resolver of URNs in the relevant namespace.
>>
>> I believe this section needs work for multiple reasons:
>>
>> * resolution is, fundamentally, not a per-namespace operation. A
>> namespace can support a resolution service for URNs that it assigns
>> if it chooses to do so (and it will likely have high quality
>> information), but any other party can also provide a service to look
>> up URNs from any namespace.   Tying resolution services to any
>> specific party degrades the persistence of URNs, because a URN
>> should remain valid and potentially resolvable even if its namespace
>> (or the organization operating it) ceases to exist, or even if its
>> namespace imposes barriers to use of its resolution services.
>
> URNs from many NIDs are not intended to be resolvable at all, i.e.,=20
> they are what we have termed "abstract designators". Most or all of=20
> the URNs used as XML namespace names are abstract designators.
>
>> * Rules for resolution should not be namespace-specific, because this
>> discourages general-purpose resolution services.   (A namespace can
>> of course recommend specific resolution services and/or specific
>> protocols for use with those services, but this section is worded as
>> if resolution itself were some sort of fundamentally
>> namespace-specific operation)
>>
>> Here's a stab at alternate text:
>>
>> 7.3.6. Resolution
>>
>> The "Resolution" section is optional.
>
> It seems safer for all sections of the template to be mandatory. If no=20
> resolution is envisioned (primarily because the URNs for a given=20
> namespace are intended to be abstract designators), then it's good to=20
> make that explicit here.
>
>> If included, it SHOULD
>> specify whether the namespace intends to operate or recommend any
>> resolution services for URNs using that namespace.
>
> I don't think a namespace can operate a resolution service! :-) But I=20
> suppose you meant something like "the organization responsible for a=20
> namespace".
>
>> In addition, if the
>> namespace intends to implement registration for publicly-advertised
>> resolution services (for example using a system like that described=20
>> in
>> [RFC2276]) the Resolution section SHOULD list the requirements for=20
>> being
>> publicly-advertised using that mechanism.
>
> I think that's acceptable. I know Leslie is concerned about rogue=20
> resolution services, but if the organization that assigns URNs in a=20
> namespace is able to specify its requirements for appropriate=20
> resolution of those URNs, then we have some mechanism for determining=20
> if a service is resolving those URNs in a way that is consistent with=20
> the assigning organization's intent.
>
> Peter
>
> --=20
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Wed May 27 20:02:29 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 A9EF01A1A25 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:02:28 -0700 (PDT)
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 QPiGu7Xnf8Nw for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:02:27 -0700 (PDT)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.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 6739A1A1A15 for <urn@ietf.org>; Wed, 27 May 2015 20:02:27 -0700 (PDT)
Received: by iepj10 with SMTP id j10so28519402iep.3 for <urn@ietf.org>; Wed, 27 May 2015 20:02:26 -0700 (PDT)
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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MWqLoFqD0IcRjcam2g8uIzbKmhTDTVXFJ/ZpyXrDYRs=; b=fUQt41RlnbrqYDUKoI1W8N0R7Ub/xLkmfORN6FwJR3vTuJx6sPHUdkhVRiecADiaaB NNhJIpSoevfL9E4a9eqRHwkkZFRjM73dY+oF9kz8++bTPTfnKzwi9iCkW3Fu+YRN7Ymi ZvBLZ5hIUJnbanPskRAuvx/t9qonSVUk5bFKxxrZgPT/lqxOiQYL6qyii3X67BThZenY y6zUAyGolLCirbtZhN0M0SMwhTQMGk1Y5PUK1w15U7JDujPdXsVuCNDIrxl7xg4ZWjyN FSlmNvguZEbzk0JakWYhUYdqqiTAsPcQehtUfUprbeFvY3oWhYu0AnbuSZOQDqn1TvKp 15pg==
X-Gm-Message-State: ALoCoQlQONQIgnpuIhOyU57Hggch7kDFudE2y+c9xijgiQck0+NtU2UT8qrfz0sLe6KZI5oA6NZA
X-Received: by 10.50.2.3 with SMTP id 3mr16504355igq.34.1432782146594; Wed, 27 May 2015 20:02:26 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qt1sm1101097igb.5.2015.05.27.20.02.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 20:02:25 -0700 (PDT)
Message-ID: <55668540.90804@andyet.net>
Date: Wed, 27 May 2015 21:02:24 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com>
In-Reply-To: <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/WtaNPR9-oIuMIb1IdxlEpID1FQ0>
Cc: "urn@ietf.org" <urn@ietf.org>, Keith Moore <moore@network-heretics.com>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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: Thu, 28 May 2015 03:02:28 -0000

On 5/27/15 4:07 PM, Leslie Daigle (ThinkingCat) wrote:
>
> FWIW, I’m not just worried about “rogue”, I’m worried about having a
> plethora of available tools to apply to URNs and no way to determine
> what the minter of the URN intended.
>
> And, I believe that’s a change of the spec.

I seem to be in the rough about my desire to remove all discussion of 
resolution from the syntax and registration specification. Every time we 
talk about resolution, we seem to fall down a rat hole of unusual size. 
Since we're not replacing RFC 2276 in parallel with replacing RFC 2141 
and RFC 3406, I feel like we're flying blind with respect to all 
resolution-related topics.

Just my $0.02.

Peter



From nobody Wed May 27 20:05:26 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 E8B901A1A56 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:05:24 -0700 (PDT)
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 82-L87__rudK for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:05:23 -0700 (PDT)
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 6B8371A1A4F for <urn@ietf.org>; Wed, 27 May 2015 20:05:23 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so103774411igb.1 for <urn@ietf.org>; Wed, 27 May 2015 20:05:22 -0700 (PDT)
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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b8EpUSHQGzssrUkezVdPaO+9t7UhSWD0qZIIEIpnQWE=; b=PYZ7u9Uf+kVH8Pm6Wgw7fy55f/IK+F2yGoMIRlXGZDdC6fnk0k8wiWjoj/SgqKAYGi vHF7846f90P1bxD6de7MxpRreFrON3gaO9757ATdSiCreBfZx5iLrMuVBbbB8mj9DW2Y zKBvE5OB4xJvn0XH8ObdBfmjy0Uw6zHY5HcyOWALo2wba/LNWvet7CKzLdIKxhAcPD6c bawLc1yxob2TLW8xtX10WW60/kRPo6gAjPnJHUUCfSuNyp+jBgwqAzEq+J+re9DaJE/m h2XPPKiFrKTePZs7qkTyhZMq/irz0MLce3ib1BzQYgaVXm5Ci8M/FZ1lnJthwb/ZY/VT ff+g==
X-Gm-Message-State: ALoCoQnDNVf2x5ZqeHvO+NWccR7uL7XiHxe5BvqfkZAB16Y/iswbbbJZKI89lrbhOaHd8xj10jt0
X-Received: by 10.43.92.199 with SMTP id br7mr7177300icc.43.1432782322827; Wed, 27 May 2015 20:05:22 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id k186sm751965ioe.37.2015.05.27.20.05.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 20:05:21 -0700 (PDT)
Message-ID: <556685EF.206@andyet.net>
Date: Wed, 27 May 2015 21:05:19 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
References: <55388B0E.3080806@network-heretics.com> <553FA044.2000206@thinkingcat.com> <55653A44.2070701@andyet.net> <E24BA7DB-ED19-4F98-9D85-C17153B2382C@thinkingcat.com>
In-Reply-To: <E24BA7DB-ED19-4F98-9D85-C17153B2382C@thinkingcat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/mLbwz8ia5RtN3kpmug_63lU53ks>
Cc: "urn@ietf.org" <urn@ietf.org>, Keith Moore <moore@network-heretics.com>
Subject: Re: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references
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: Thu, 28 May 2015 03:05:25 -0000

On 5/27/15 3:51 PM, Leslie Daigle (ThinkingCat) wrote:
> Hi,
>
> In-line…
>
> On 26 May 2015, at 23:30, Peter Saint-Andre - &yet wrote:
>
>> On 4/28/15 8:59 AM, Leslie Daigle (ThinkingCat) wrote:
>>>
>>> I've been chewing on the proposed f-component and q-component text.
>>
>> Me too. I will chew on it further and try to formulate even clearer
>> text based on what Keith has so helpfully proposed.
>>
>>> I
>>> think we need to be clear(er) about the overall concept:  how do
>>> fragments and queries fit with instance-independent naming of resources?
>>> I think it was, indeed, progress to focus on their use as applied to
>>> resolution to content (via URN or URL), but I don't think the concept of
>>> composing parts is quite captured in the proposed text.
>>
>> Could you perhaps describe a bit more what you mean by "the concept of
>> composing parts"?
>
> What happens when your URN has f-components and q-components and it
> resolves to a URL with f-components and q-components was the main issue,
> if memory serves…

Thanks for the clarification. That is indeed a conundrum.

Peter



From nobody Wed May 27 20:06:36 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 363F71A1A4F for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:06:35 -0700 (PDT)
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 wdPfsUf97XiW for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:06:34 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 03CA01A1A6D for <urn@ietf.org>; Wed, 27 May 2015 20:06:34 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so101338170igb.1 for <urn@ietf.org>; Wed, 27 May 2015 20:06:33 -0700 (PDT)
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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=keAyVaDzYSGVXGgCg+A7zLkjs0+qufaDNQ7f2kAkBKI=; b=UL8Kitl3dBRgi14oPXtP+KyqgNPjG4NEzeDBIc817dvPsUb/wdDpeodwE7XdGn6ekl aLgZu/xxfSHRKgDka23fMpRaGCOU5H1QVroqPnKoU84ICbCWOjw9wt5GiMvTKGRHTvm5 okcpfx8FkUSQ5PZtd5bsvqFKrNfZunYg1XXUk8JfjmsTqOrCBtyRgwqVhUwA9/aPUtD8 +HKxTsrGo9k8h3GNAGfogujILE+/ooS/31GyB6bfuerjhUTySLvlHSwnjardgaPuqtce 2URMgG68J150drBr2E6bkeU4I8END6NxC87Eut5q9b6OiwvJDvWlsY2wJw80y1vHqpDB 70cA==
X-Gm-Message-State: ALoCoQlOhGKbDppO2VaYdjqMjepcm8vIAKlyrICJbmrN3QRo47snZipGET/cNLafDS29lxpUNup6
X-Received: by 10.107.10.146 with SMTP id 18mr708629iok.40.1432782393199; Wed, 27 May 2015 20:06:33 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id z195sm756357iod.33.2015.05.27.20.06.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 20:06:31 -0700 (PDT)
Message-ID: <55668636.5030604@andyet.net>
Date: Wed, 27 May 2015 21:06:30 -0600
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.6.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com>
In-Reply-To: <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/j4DCv6h9dvVqBbfRexST6QX_NkU>
Cc: urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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: Thu, 28 May 2015 03:06:35 -0000

On 5/27/15 4:03 PM, Leslie Daigle (ThinkingCat) wrote:
>
> My recollection aligned with Keith’s — that we agreed to do away with
> p-components.   Digging back, have a look at the thread that started
> with Keith’s message with subject “suggested text changes for -12 on
> p-components, f- and q-components in URN resolution, and relative
> references”.
>
> It made sense to Keith, me, Juha and Sven at the time, it seems.  (And
> it still makes sense to me, FWIW :^) ).

As I recall, we got rid of p-components but didn't disallow "/" in the 
NSS. A rose by any other name...

Peter



From nobody Wed May 27 20:07:52 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 A825C1A1A70 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:07:50 -0700 (PDT)
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 ctdbp2LyGb99 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:07:49 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 846311A1A6D for <urn@ietf.org>; Wed, 27 May 2015 20:07:49 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so103149290igb.0 for <urn@ietf.org>; Wed, 27 May 2015 20:07:48 -0700 (PDT)
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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vv12OHK7LKeMEXYyBmbPwqd8StljRMZLte9pyXVDrJs=; b=YxwKRuOPlWWuNAw01xT0OHW2WNeb9g+yN42Ty6iMJ+Gu8BOrBrZNMVQbQ9Mibg2OpR rsn9KVNOwmKl0HbFmCRWhFSSJuRvsYMgVRSBTMHNJn+SAUxFzWM41+LHxmfRQEeyvjbN 97WW2QN0js773tVBMn76pqt7GBVPg3dy5V0QbHeYxMhrPuqXVvT3GStronxxwx44qxN8 kMeNzycmLdX1R+wOAUXLwVyN4qcNt5NRSwh+pL+zvaUn9AWqyf0MI9a4vqA3BjevYUGa XTWjuu5lmID6OfYXhq7izg0f2EuMA6w0qdddsmSihTTZIFnVCw5mQshuYWKKH13grwUA 95Ng==
X-Gm-Message-State: ALoCoQmineS5iD0GUgh7TpFskEJWi8ThGfBAY/rYLc6K6TP9kOrrCztUyqztg15+9X29QVIgN7iE
X-Received: by 10.107.19.104 with SMTP id b101mr679204ioj.39.1432782467970; Wed, 27 May 2015 20:07:47 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g32sm768377ioj.20.2015.05.27.20.07.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 20:07:47 -0700 (PDT)
Message-ID: <55668681.4010805@andyet.net>
Date: Wed, 27 May 2015 21:07:45 -0600
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.6.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <69987EDAF5C813D15ADB184D@JcK-HP8200.jck.com>
In-Reply-To: <69987EDAF5C813D15ADB184D@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/QAOc_55j3YSGxC6PrWqK4T6nl08>
Cc: "Leslie Daigle \(ThinkingCat\)" <ldaigle@thinkingcat.com>, urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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: Thu, 28 May 2015 03:07:50 -0000

On 5/27/15 5:05 AM, John C Klensin wrote:
>
>
> --On Tuesday, May 26, 2015 20:35 -0600 Peter Saint-Andre - &yet
> <peter@andyet.net> wrote:
>
>> ...
>>      In particular, allowing the "/" character effectively
>> makes it
>>      possible to encapsulate hierarchical identifiers from
>> other naming
>>      systems.  For instance, consider the hypothetical example
>> of a
>>      hierarchical naming system in which the identifiers take
>> the form of
>>      a series of numbers separated by the "/" character, such
>> as "1/406/
>>      47452/2".  If the naming authority for such identifiers
>> were to use
>>      URNs, it would be natural to place the existing
>> identifiers in the
>>      NSS, resulting in URNs such as "urn:example:1/406/47452/2".
>>      Nevertheless, it is not appropriate the "/" character be
>> used in a
>>      URN merely because the URN namespace is importing a naming
>> system
>>      that happens to use the character; it is simply a matter
>> of syntactic
>>      convenience not to escape the character with
>> percent-encoding.
>
> Peter,
>
> Up to the last sentence (and including the parts not quoted
> above, this seems ok to me.  But I can't quite parse that last
> sentence or figure out what it means -- it seems to be
> contradicting the text above it.

Hmm, yes. I'd be fine with removing that final sentence (this is one of 
the problems with trying to stitch together proposed text from different 
contributors).

Peter



From nobody Wed May 27 20:47: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 0BC1A1A1BB0 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:47:05 -0700 (PDT)
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 G6N_qy6cmwOX for <urn@ietfa.amsl.com>; Wed, 27 May 2015 20:47:03 -0700 (PDT)
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 A3E101A1BA9 for <urn@ietf.org>; Wed, 27 May 2015 20:47:03 -0700 (PDT)
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 1Yxoma-000Pvq-LN; Wed, 27 May 2015 23:47:00 -0400
Date: Wed, 27 May 2015 23:46:55 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <B8175205C9A10B5093A056A2@JcK-HP8200.jck.com>
In-Reply-To: <55668681.4010805@andyet.net>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <69987EDAF5C813D15ADB184D@JcK-HP8200.jck.com> <55668681.4010805@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/_PgoIWbPFS7KxJRP7Z3riIGBOO4>
Cc: "Leslie Daigle \(ThinkingCat\)" <ldaigle@thinkingcat.com>, urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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: Thu, 28 May 2015 03:47:05 -0000

--On Wednesday, May 27, 2015 21:07 -0600 Peter Saint-Andre -
&yet <peter@andyet.net> wrote:

>>>      In particular, allowing the "/" character effectively
>>> makes it
>>>      possible to encapsulate hierarchical identifiers from
>>> other naming
>>>      systems.  For instance, consider the hypothetical
>>>      example of a
>>>      hierarchical naming system in which the identifiers take
>>> the form of
>>>      a series of numbers separated by the "/" character, such
>>> as "1/406/
>>>      47452/2".  If the naming authority for such identifiers
>>> were to use
>>>      URNs, it would be natural to place the existing
>>> identifiers in the
>>>      NSS, resulting in URNs such as
>>>      "urn:example:1/406/47452/2". Nevertheless, it is not
>>>      appropriate the "/" character be used in a
>>>      URN merely because the URN namespace is importing a
>>>      naming system
>>>      that happens to use the character; it is simply a matter
>>> of syntactic
>>>      convenience not to escape the character with
>>> percent-encoding.
>> 
>> Peter,
>> 
>> Up to the last sentence (and including the parts not quoted
>> above, this seems ok to me.  But I can't quite parse that last
>> sentence or figure out what it means -- it seems to be
>> contradicting the text above it.
> 
> Hmm, yes. I'd be fine with removing that final sentence (this
> is one of the problems with trying to stitch together proposed
> text from different contributors).

Simply removing it works for me.
   john




From nobody Wed May 27 21:01:57 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 1B5A11A6EF4 for <urn@ietfa.amsl.com>; Wed, 27 May 2015 21:01:57 -0700 (PDT)
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 kfmNLO4wVYFk for <urn@ietfa.amsl.com>; Wed, 27 May 2015 21:01:56 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FF11A6EED for <urn@ietf.org>; Wed, 27 May 2015 21:01:56 -0700 (PDT)
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 1Yxp10-000PyQ-18; Thu, 28 May 2015 00:01:54 -0400
Date: Thu, 28 May 2015 00:01:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
Message-ID: <8974ECB12DBFCD57CF72D435@JcK-HP8200.jck.com>
In-Reply-To: <55668636.5030604@andyet.net>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com> <55668636.5030604@andyet.net>
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/cPD5VRK8yKOINa_VH41GYFeP0I8>
Cc: urn@ietf.org
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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: Thu, 28 May 2015 04:01:57 -0000

--On Wednesday, May 27, 2015 21:06 -0600 Peter Saint-Andre -
&yet <peter@andyet.net> wrote:

> On 5/27/15 4:03 PM, Leslie Daigle (ThinkingCat) wrote:
>>=20
>> My recollection aligned with Keith's =E2=80=94 that we agreed =
to
>> do away with p-components.   Digging back, have a look at the
>> thread that started with Keith's message with subject
>> "suggested text changes for -12 on p-components, f- and
>> q-components in URN resolution, and relative references".
>>=20
>> It made sense to Keith, me, Juha and Sven at the time, it
>> seems.  (And it still makes sense to me, FWIW :^) ).
>=20
> As I recall, we got rid of p-components but didn't disallow
> "/" in the NSS. A rose by any other name...

So, we allow "/", we don't treat it in any way as a special
delimiter that serves the delimiter function described in
Section 1.2.3 of RFC 3986, breaks the opacity discussed in the
last paragraph of that section and breaks the path into segments
regardless of whether we interpret those separately.=20

It also takes us into relative reference territory.  The only
thing 2141bis says on that subject right now is the second
paragraph of Section 5,=20

I'm ok with all of the above, but want to check and make sure
everyone else is too because this is pushing the boundaries of
"conform to 3986 syntax".

   john




From nobody Thu May 28 04:10:07 2015
Return-Path: <ldaigle@thinkingcat.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 D0A0C1A89C6 for <urn@ietfa.amsl.com>; Thu, 28 May 2015 04:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.456
X-Spam-Level: 
X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=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 YAq6B-jJtVVl for <urn@ietfa.amsl.com>; Thu, 28 May 2015 04:10:04 -0700 (PDT)
Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7A1A8963 for <urn@ietf.org>; Thu, 28 May 2015 04:10:04 -0700 (PDT)
Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id A1C0226C096; Thu, 28 May 2015 04:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=S 86T9Ip6H8LOBt0YIIAUfCJnGo4=; b=RugJESRssM2lmxF7DGR/PS/9FQvYclxsf WD2uXY3cSY4mubsZEwhpx9vQPkGcN0Jqydg5ffybP62YT16QuV8LrkbjdaodckvU /db6NgxnFPMzuKgo+txYSRqqmKPf6kUoBmsxoj80Nfyi2ZUX5/g7zdU7HGZi1b7F kr75qx9kXU=
Received: from [192.168.1.109] (stjhnbsu0nw-142167228175.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.228.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id E6EAD26C095; Thu, 28 May 2015 04:10:02 -0700 (PDT)
From: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>
To: "John C Klensin" <john-ietf@jck.com>
Date: Thu, 28 May 2015 07:09:59 -0400
Message-ID: <1730CA74-D57F-4D25-A3A0-0183EBB8D860@thinkingcat.com>
In-Reply-To: <8974ECB12DBFCD57CF72D435@JcK-HP8200.jck.com>
References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com> <55668636.5030604@andyet.net> <8974ECB12DBFCD57CF72D435@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/khu0kkkiuVO8Ldco2HsVpEVMqak>
Cc: urn@ietf.org, Peter Saint-Andre - &yet <peter@andyet.net>
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)
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: Thu, 28 May 2015 11:10:06 -0000

As I understand it (which may be wrong), the real desire in URNBIS has=20
been to be able to have =E2=80=9C/=E2=80=9C, not a belief in the need for=
=20
=E2=80=9Cp-components=E2=80=9D or relative URNs (which are, as you note, =
different).

With that:

On 28 May 2015, at 0:01, John C Klensin wrote:

> --On Wednesday, May 27, 2015 21:06 -0600 Peter Saint-Andre -
> &yet <peter@andyet.net> wrote:
>
>> On 5/27/15 4:03 PM, Leslie Daigle (ThinkingCat) wrote:
>>>
>>> My recollection aligned with Keith's =E2=80=94 that we agreed to
>>> do away with p-components.   Digging back, have a look at the
>>> thread that started with Keith's message with subject
>>> "suggested text changes for -12 on p-components, f- and
>>> q-components in URN resolution, and relative references".
>>>
>>> It made sense to Keith, me, Juha and Sven at the time, it
>>> seems.  (And it still makes sense to me, FWIW :^) ).
>>
>> As I recall, we got rid of p-components but didn't disallow
>> "/" in the NSS. A rose by any other name...
>
> So, we allow "/", we don't treat it in any way as a special
> delimiter that serves the delimiter function described in
> Section 1.2.3 of RFC 3986, breaks the opacity discussed in the
> last paragraph of that section and breaks the path into segments
> regardless of whether we interpret those separately.

I don=E2=80=99t believe that is the case in what we discussed on that thr=
ead=20
=E2=80=94 because the belief and expectation is that =E2=80=9C/=E2=80=9C =
appears in single=20
instances within the NSS, and the whole string is treated as=20
=E2=80=9Cpath-rootless=E2=80=9D.

As I wrote at the time =E2=80=94 I am not a URI parser and I still wouldn=
't=20
object to hearing confirmation from someone who does deal in non-URN URI=20
parsing for a living.

If that=E2=80=99s a mis-understanding, then, indeed, we=E2=80=99re not wh=
ere I (at=20
least) thought we were.

Leslie.
>
> It also takes us into relative reference territory.  The only
> thing 2141bis says on that subject right now is the second
> paragraph of Section 5,
>
> I'm ok with all of the above, but want to check and make sure
> everyone else is too because this is pushing the boundaries of
> "conform to 3986 syntax".
>
>  john
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


From nobody Thu May 28 07:33:31 2015
Return-Path: <L.Svensson@dnb.de>
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 41B081ACDE8 for <urn@ietfa.amsl.com>; Thu, 28 May 2015 07:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 JKnW_t81TwHV for <urn@ietfa.amsl.com>; Thu, 28 May 2015 07:33:28 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02A1ACDBB for <urn@ietf.org>; Thu, 28 May 2015 07:32:44 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 588788AD4A; Thu, 28 May 2015 16:32:43 +0200 (CEST)
X-AuditID: 0a453fe7-f79136d0000011d7-85-5567270ae479
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 40.0C.04567.A0727655; Thu, 28 May 2015 16:32:43 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Thu, 28 May 2015 16:32:42 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Keith Moore <moore@network-heretics.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Historical URNs, rants, and progress
Thread-Index: AQHQmLflk8WNq0QF+USsMIZUX89IuJ2QICSAgAABJACAAANtgIAACrGAgAFDntA=
Date: Thu, 28 May 2015 14:32:41 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF6EF9D@dnbf-ex1.AD.DDB.DE>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net>	<5564FF01.70204@andyet.net> <55653A6D.5040400@network-heretics.com>	<55653FB4.1040800@andyet.net> <55654B15.70102@network-heretics.com> <D5077E71059E236621C66D15@JcK-HP8200.jck.com> <55662277.30403@network-heretics.com> <CAAQiQRduarovPGsGbi+kwcw_Z_-Wa8Y41Su9nEgQ3jRWB7=yPA@mail.gmail.com> <5566264C.8030007@network-heretics.com> <5566292B.9090207@gmail.com> <55663223.1000700@network-heretics.com>
In-Reply-To: <55663223.1000700@network-heretics.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.195]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12TbUhTURzGO7vXeTd37DqnO60Mm9mL4VKSEszqg4VlZFSLyg/r6r1tw+nk 3s1m4Ev4oVpRFgQ1ejExlai0ojR6H0VNSqPog0EKlUn1YZlMkSC7b7Or3/78nvM85/lzOASm H4o1Ec5KD8NWUi6zWotrN66PZMYttVuzuvzxuWcifercs42/VBtUha2tk6rCM692b1ft066l GZezmmFXrtuvdfgvfVRX3dL6vvefwBvAVcIPNAQic1Dk1QVMmpPR28FOtR9oCT35HKDI/Zu4 IOjJboAet9v9IJZQkxko7BCogSxCQ0c6gTAnkmvQh9GTaonnorHBGzHSvA0FLraJZ3AyHbU8 6Bc55L0toaPyVWEMhYNTolnD9xk/3ST2AWQK6urqF2eMNKLb3yZipJ4kan3YL3dOQt+//OU5 wc+pqPGqRTqehcJ9l2XrCtR25Scm3ZuAQue/4k0gKaBIDSgsAYUloLA0A/waiOcq7NkWirbQ dKmFZm4D6SVGesDJdwVBQBLArIOvod2qj6GquZqKICgmVOYkSKTxKL7UTdc4KM5hY70uhjMb 4MvFPIbTuNTrKjcvhO21jFVvnKacl6tyljndXs7mZV1BgAiMt54wClaaqjnEsG4pMAjmE7jZ CE8/OLxLT9opD1POMFUMG1X3EIQZwePpvDGBZeyM74DT5YnKvI8RFFKpiIUWwRGhkEkpzO6k IjRBsJXQ8cUeCSmQq6IqOKddzk6ElcKmuigVc1PgayE3OQpnZvaCnSYjPC9WEk44vJXTXU3J cFUdb52rEIRIUyoc+HTAqp+n4DNTf4DN/BMlwjlLhDr8f/rfUQ+7hcviZChWXCBVTJLZ7Kyt /Nsa4OoXtLCwh/IoF94iFNRFqbzwxjpxYRnOjDM1gO1jE79HM0+90JB783c0YT3HYpPjuosf ns2umxPIGO9rLnJzA5mxNy93kPc+z09NL/Qd6132hC4r2VcyVVTf6wunnRpraWjz3H1fEOpI uZM5bMhvZmt2Xw8N47hu6MrjPwNP80rKnkVynJMFkfblm37aNP5bB988s9VesFrr884ZzTjn oLIzMJaj/gFuEu1TcgQAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/ExC8MEUjwYHK8czACRGX_MhhSlA>
Subject: Re: [urn] Historical URNs, rants, and progress
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: Thu, 28 May 2015 14:33:30 -0000

Keith,

On Wednesday, May 27, 2015 11:08 PM, Keith Moore wrote:
>=20
> On 05/27/2015 04:29 PM, Melinda Shore wrote:
> > On 5/27/15 12:17 PM, Keith Moore wrote:
> >> So we're basically supposed to ignore all of the history and thinking
> >> and consensus that went into URNs and just accept whatever the documen=
t
> >> authors say?
> > No, of course not.  I think the concern here is that discussion
> > stay rooted in engineering considerations, and that objections
> > that are raised should be as specific as possible about what would
> > break and why that's a problem.  In the interest of producing a
> > usable, useful spec we do need to stay focused on engineering
> > considerations.
>=20
> I'm entirely concerned about things that have the potential to affect
> interoperability and applicability of URNs.   I think those qualify as
> engineering concerns.   But there's a lot of subtlety to URNs, and the
> URN specifications reflect a lot of carefully-considered decisions that
> were made for reasons that are not exposed in those specifications and
> perhaps not obvious.

Then we should ensure that those considerations and their raisons-d'=EAtre =
are exposed in future specifications. I think that would help future review=
ers to go down the same ratholes that we seem to do.

/Lars


From nobody Thu May 28 07:49:49 2015
Return-Path: <L.Svensson@dnb.de>
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 A2BB11AD0B0 for <urn@ietfa.amsl.com>; Thu, 28 May 2015 07:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 Vn22YnTJJl8g for <urn@ietfa.amsl.com>; Thu, 28 May 2015 07:49:40 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 181951AD0B1 for <urn@ietf.org>; Thu, 28 May 2015 07:49:35 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 778798AD88 for <urn@ietf.org>; Thu, 28 May 2015 16:49:34 +0200 (CEST)
X-AuditID: 0a453fe7-f79136d0000011d7-45-55672afe95ec
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id DA.1C.04567.EFA27655; Thu, 28 May 2015 16:49:34 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Thu, 28 May 2015 16:49:33 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
Thread-Index: AQHQmAkXI5nwTFWGZ02NBTxQLrEV8J2QQW+AgABSaACAAOSnsA==
Date: Thu, 28 May 2015 14:49:33 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55668540.90804@andyet.net>
In-Reply-To: <55668540.90804@andyet.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.195]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLsWRmVeSWpSXmKPExsXC5Wr/VfefVnqowesXEhZTmz8wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr493vbcwFbfwVf1qbmBoYr/B1MXJySAiYSPR0P2WFsMUkLtxb z9bFyMUhJHCEUWLt3g9MEM52Rold7zpYuhjZOdgEtCTeZ4DUiwgoSux71sQOYgsLeEhs3v+c GSLuKfF+5V6gmRxAtpPEiQWSIGEWAVWJa6segZXwCnhL7Hw1mxFi+iqg6YfaWEASnAIaEu+u zgIrYhSQldiw4TyYzSwgLrHp2XeoOwUkluyBiEsIiEq8fPwPbJeEgIJE81I9EJNZQFNi/S59 iE5FiSndD9kh1gpKnJz5hGUCo+gsJENnIXTMQtIxC0nHAkaWVYx8xbnphnqJKXopKUl6Kamb GCHB/3wHY98ll0OMAhyMSjy8Z3jTQ4VYE8uKK3MPMfpzMCmJ8nIoA4X4kvJTKjMSizPii0pz UouVRHgDNIDCvHDhpNKcbCU53uW1qaFC4nDR4tLigszkzPzS4vjSopxDjBIczECtPeIgrSmJ lVWpRfkQAw8xSnOwKInzTtzdGCIkkJ5YkpqdmlqQWgSTjeDgUJLgXasJ1ChYlJqeWpGWmVMC kwbqMwAmISEBZBmwgxR5n4McJIUsge4mJg7OQ4w+HDxAh30Bmc9bXJCYW5yZDjVbmPedOlCU ByYKNleW9wzIXDGYIKqZpxiDpcR5Z4IMEwCpyCjNg7tVSozXuA6olR9JAmSklALvzbtpoUKS SOKopr5i9ARGkTDvf5C5PMBMhHCjEK8jSJAbKgh2ogzEiaJQMXSzfIBxK8JrdjQF5OGSxBJk D3uBHMgDE4V62LUO7GGoIKpxUg2MVdtfnHZZqmkosIBpxktDmYP7nixhuMCUd3rGDNflnz7M Dj9uxX7xoua0JXluOh9YN4eHHZ5mfVlsvS6j1ZzANcFrf8897Vsau932yA21lLzrazsfOfVu +nLQJun437O5PfXzv8mduxRRFWZbWt2qHXw1bmKB34+PH7cLcQUJVr5bkfBTX/LnViWW4oxE Qy3mouJEANH+KlBnBAAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/r0GZHFK9NgcGqwWTE5sYMRUAWCc>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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: Thu, 28 May 2015 14:49:43 -0000

UGV0ZXIsDQoNCk9uIFRodXJzZGF5LCBNYXkgMjgsIDIwMTUgNTowMiBBTSwgUGV0ZXIgU2FpbnQt
QW5kcmUgLSAmeWV0IHdyb3RlOg0KIA0KPiBPbiA1LzI3LzE1IDQ6MDcgUE0sIExlc2xpZSBEYWln
bGUgKFRoaW5raW5nQ2F0KSB3cm90ZToNCj4gPg0KPiA+IEZXSVcsIEnigJltIG5vdCBqdXN0IHdv
cnJpZWQgYWJvdXQg4oCccm9ndWXigJ0sIEnigJltIHdvcnJpZWQgYWJvdXQgaGF2aW5nIGENCj4g
PiBwbGV0aG9yYSBvZiBhdmFpbGFibGUgdG9vbHMgdG8gYXBwbHkgdG8gVVJOcyBhbmQgbm8gd2F5
IHRvIGRldGVybWluZQ0KPiA+IHdoYXQgdGhlIG1pbnRlciBvZiB0aGUgVVJOIGludGVuZGVkLg0K
PiA+DQo+ID4gQW5kLCBJIGJlbGlldmUgdGhhdOKAmXMgYSBjaGFuZ2Ugb2YgdGhlIHNwZWMuDQo+
IA0KPiBJIHNlZW0gdG8gYmUgaW4gdGhlIHJvdWdoIGFib3V0IG15IGRlc2lyZSB0byByZW1vdmUg
YWxsIGRpc2N1c3Npb24gb2YNCj4gcmVzb2x1dGlvbiBmcm9tIHRoZSBzeW50YXggYW5kIHJlZ2lz
dHJhdGlvbiBzcGVjaWZpY2F0aW9uLiBFdmVyeSB0aW1lIHdlDQo+IHRhbGsgYWJvdXQgcmVzb2x1
dGlvbiwgd2Ugc2VlbSB0byBmYWxsIGRvd24gYSByYXQgaG9sZSBvZiB1bnVzdWFsIHNpemUuDQo+
IFNpbmNlIHdlJ3JlIG5vdCByZXBsYWNpbmcgUkZDIDIyNzYgaW4gcGFyYWxsZWwgd2l0aCByZXBs
YWNpbmcgUkZDIDIxNDENCj4gYW5kIFJGQyAzNDA2LCBJIGZlZWwgbGlrZSB3ZSdyZSBmbHlpbmcg
YmxpbmQgd2l0aCByZXNwZWN0IHRvIGFsbA0KPiByZXNvbHV0aW9uLXJlbGF0ZWQgdG9waWNzLg0K
DQpJZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwgeW91ciBzdWdnZXN0aW9uIGlzIGNvbmNl
bnRyYXRlIG9uIHN5bnRheCAoYW5kIGFzIGxpdHRsZSBzZW1hbnRpY3MgYXMgcG9zc2libGUpIG1h
a2luZyAyMTQxYmlzIGZseSBhcyBzb29uIGFzIHBvc3NpYmxlLiBPbmNlIHRoYXQgaXMgZG9uZSwg
d2UgZ28gb24gdG8gcmV2aXNlIDM0MDYuIFdGTS4gVGhhdCBzYWlkLCBJIGRvbid0IHRoaW5rIHdl
IGNhbiBzcGVjaWZ5IHJlZ2lzdHJhdGlvbnMgcHJvY2VkdXJlcyB3aXRob3V0IGRpc2N1c3Npb24g
cmVzb2x1dGlvbiBzaW5jZSBvbmUgaW1wb3J0YW50IGFzcGVjdCBvZiBwZXJzaXN0ZW50IG5hbWlu
ZyBpcyB0aGUgYWJpbGl0eSB0byBmaW5kIHRoZSBuYW1lZCBvYmplY3QgdGhyb3VnaCBpdHMgbmFt
ZS4gQW5kIGluIG1vc3QgY2FzZXMgdGhpcyBpcyBkb25lIHRocm91Z2ggc29tZSBraW5kIG9mIGxv
b2t1cCBzZXJ2aWNlIGFuZCBpdCBpcyBpbmRlZWQgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIHdobyBo
YXMgdGhlIGNhbm9uaWNhbCByZWdpc3RyeS4gSSBkb24ndCB0aGluayB3ZSBjYW4gb2ZmbG9hZCB0
aGF0IG9uIHRvIElBTkEuLi4NCg0KQmVzdCwNCg0KTGFycyANCg0K


From nobody Thu May 28 08:14:55 2015
Return-Path: <L.Svensson@dnb.de>
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 2E1BE1B2B37 for <urn@ietfa.amsl.com>; Thu, 28 May 2015 08:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 Tlo46OQEzznq for <urn@ietfa.amsl.com>; Thu, 28 May 2015 08:14:52 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 834061A911E for <urn@ietf.org>; Thu, 28 May 2015 08:14:51 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id D24EE8AD4A for <urn@ietf.org>; Thu, 28 May 2015 17:14:50 +0200 (CEST)
X-AuditID: 0a453fe7-f79136d0000011d7-2d-556730ea3cee
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 88.3C.04567.AE037655; Thu, 28 May 2015 17:14:50 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Thu, 28 May 2015 17:14:50 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Namespace consensus and registrations
Thread-Index: AQHQmAIZREOlQZ5sOUK/ePoKlu7xdp2Pn2EAgAACNwCAAFq1gIAANR+AgAFKinA=
Date: Thu, 28 May 2015 15:14:49 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF6F0CC@dnbf-ex1.AD.DDB.DE>
References: <55142CA1.2000509@network-heretics.com> <587F32051FF797206A169FC6@JcK-HP8200.jck.com> <551B0E58.3010709@network-heretics.com> <552F262E.1040602@andyet.net> <552FAB04.1040205@network-heretics.com> <5564F184.7080206@andyet.net> <98F6D08AB5C3B32F6D5D42A0@JcK-HP8200.jck.com> <5565B9FE.90100@network-heretics.com> <643A740663746E82B87FCD4E@JcK-HP8200.jck.com> <556632A5.8000608@network-heretics.com>
In-Reply-To: <556632A5.8000608@network-heretics.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.195]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTYRjG+3bR49ynx3nZ18rQSUWat4zSsAuklWkm5OgCYkd33Jabys4m miaWmiQiGlk0pBtTqbSmlEVmf8zuiYoIYqRQedfQkjIjpHN2Njv633t+7/s83/PycjC+ZMBZ hmmyDKQ+i9DKnUQCUezen8FTYSpF2FzzlsjakjnePnDIbF7kJYFTomglqdXkkvrQPadF6rq3 fYKclgN5TVcvCovBtcgK4IIhfDuqtrY4sbUP6h1+SNciTIK/BOjxm1L7xxOAasutoAI4Y054 IJpVM/NeuD96MXbBmak98Uh0qdgiZHkUmv/4i8/Wiaj094SNC/CNqLe9AjA1xOPR9KMRIWtf z0d/vj3jMQ0XOtDnH522IYD7Ioulx2bEx6WodWxByAbFkfk5yxHujSa/LtEco2s/VFIfwo6H odnum3ZpEGq4Pc1n3/VA766PCKqBt4njauJITByJiSO5BQT3gBulU4WHEMoQpTItREm2AvYC 409BVV+MFeAYkIthF1QpJEIil8rXWcFRjCf3hlgAjdzSspX5aoJSp+qNWpKSe0FeMI3hMk4z ajPlG2DjOVIhkS5TykjlaNI12UYq1ajXWgHC+LS0UspIlUT+WVKfzRpawTpMIJfCmvbzyRJc RRjITJLMIfWO7gkMkyN4PJQWeuhJFZmXodEaHG1a5xpEd3BuxxbIH44zgWTcxupMPMzFChIw MR0slfGHVA6hozQqu7cnvLOVpmIHtfn6wi7G18cBV3q+B8dkUniQMcOZCbUxazmrzAdGFNFS d06DsZT5wcGhDIVkLYevdJ0CcfSJPOEI4yum/6P/GSVwgrmGqx3aIq5nI3rb2WqvBPq2XnDH KyWzsIEwcBc+zAQUO6h94dgi28J2uNJOVgzMA+UPGiOGdIWWv21fugyKPg2OTZ1Z8F9MEaL5 k5G5R153X+HdMA3v1I2aPvW7tRXMRY2PaHclZS7dT+7wCHSKKYsIoOIMPbtrChPjOtaMNqKq bZMf3DtK6jZ0TU8V3K3p7E8YjNu8qTlrf+lMekpDkjk673vvjKTMEn85XtBUKRdQaiI8kK+n iH8Wvlz3agQAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/dm9bKkl1POmG7X584XRCw0t3_SE>
Subject: Re: [urn] Namespace consensus and registrations
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: Thu, 28 May 2015 15:14:54 -0000

All,

On Wednesday, May 27, 2015 11:10 PM, Keith Moore wrote:
>=20
> On 05/27/2015 01:59 PM, John C Klensin wrote:
> >
> > --On Wednesday, May 27, 2015 08:35 -0400 Keith Moore
> > <moore@network-heretics.com> wrote:
> >
> >> On 05/27/2015 08:27 AM, John C Klensin wrote:
> >>> On a related note, I think it is entirely reasonable to
> >>> include space in the template for people to describe how
> >>> their namespace uses any or all of p-/q-/r-/f-components
> >>> without getting involved with elaborate standardization
> >>> attempts or registration models for the syntax and contents
> >>> of those fields.
> >> Strongly disagree with this.
> >>
> >> - I thought we had done away with p-components and just
> >> decided to permit '/' in NSS.
> > Keith,
> >
> > This is another example of the reasons why I am finding all of
> > the theorizing and repetitive threads involving very few people
> > to be problematic.
>=20
> I share your frustration with the small number of participants. And yet,
> it's hard to escape the impression that it's okay for some people to do
> theorizing and repeat themselves, but not for others.

I can only speak for myself, but I'm not always in a position to fully unde=
rstand the consequences of certain engineering decisions and I certainly ca=
nnot fully appreciate all the decisions taken 20 years ago. My contribution=
s are more from the pow of a memory organisation having a large base of dep=
loyed URNs but also see that the current specifications are extremely limit=
ing and that we need to move forward. Since our job is to ensure that certa=
in classes of resources that we manage (aka "documents") are still availabl=
e and -- more importantly -- addressable in 500 years (or more). This perha=
ps boils down to three requirements:
1) persistence of coupling between name and object
2) possibility to resolve a name to an object, its metadata or a tombstone =
(if the object is not available any more).
3) backward compatibility: we must not break existing URNs

1) and 2) are about registration and resolution. 3) is about syntax, and si=
nce we do have some URNs with '/' in them (minted by mistakes several years=
 ago before we had proper quality control in place) I'm actively advocating=
 the '/' be permitted in the NSS. If we decide to call it "p-component" or =
not is of minor importance...

> > What I had understood from trying to follow the various threads
> > is that we were getting close to agreement on a particular way
> > to talk about "/".  I hadn't make the leap from there to "done
> > away with p-components".  More broadly, I don't get from "one or
> > two people repeated themselves several times" to "we agreed" (or
> > "we had done away with").  There have been no comments from
> > anything resembling a diverse group of WG participants and the
> > number of consensus calls or other comments from the co-chairs
> > on this subject has been, well, very small.
>=20
> In a very small group of participants, some/most of whom pop in only
> occasionally, it's hard to know how to evaluate consensus.   I thought
> we had moved past p-components into simply allowing '/' to appear in an
> NSS, but others may still be thinking in terms of p-components.   That's
> fine - but I think it is better to state assumptions and let others
> challenge them, than to leave them unstated and assume that everyone
> else is thinking the same way.

OK, I speak up. It might matter if we have a p-component since there might =
be namespaces that will not allow '/' for backward compatibility. That is, =
however, the only use case I can think of. For me it would work to say that=
 we simply allow '/' in the NSS.

> >> - q-components are interpreted by the resource, not by the
> >> namespace.  It's very important to make this clear, otherwise
> >> there will be tussles over their use.
> > I don't see any conflict between "interpreted by the resource"
> > and a statement of intent about the namespace.  After all,
> > namespaces are supposed to be managed and relatively
> > homogeneous.
>=20
> Speaking of theorizing, I'm wondering where that idea came from. I don't
> believe that namespaces are "supposed" to be relatively homogeneous.   I
> might have forgotten but I don't recall seeing that in any of the URN WG
> consensus documents (1737, 2141, etc.) nor do I recall anything
> resembling a consensus on that from URN WG discussion.

The namespace NBN is in so far homogeneous in that it deals (mostly) with d=
ocuments. The homogeneity ends there since the documents can be of almost a=
ny existing or future media type, some perhaps accepting q- or f-components=
, others not.

> (And again, we should be careful about overgeneralizing from early use
> of URNs.   So I don't think existing URN namespaces should be used as an
> argument in favor of dictating policy, unless of course we've identified
> something from early use that's broken and needs to be fixed.)

WFM as long as we don't break backward compatibility.

> What I do believe is that it's fairly natural for URN namespaces to be
> aligned with specific user communities, especially communities that
> already have their own namespaces established.    And such communities
> and other pre-existing namespaces have often formed around particular
> kinds of content or media.   So there's an observable tendency for
> existing URN namespaces to be aligned with particular kinds of content
> or media.   But that's not a requirement, and it shouldn't be
> interpreted as one.

I think at least some namespaces are extremely heterogeneous (see above) an=
d my guess is that those have the largest number of deployed URNs...

> Back to q-components.   The first issue I have with documenting them as
> part of URN namespace registration is that this threatens to conflict
> with the notion that when a URN is resolved to a URL, a q-component
> attached to that URN becomes a query attached to that URL.   That's a
> nice, simple way of interpreting q-components that is highly likely to
> be implemented correctly, highly likely to be interoperable between
> different implementations, makes sense across all namespaces, and
> doesn't make resources that accept queries less functional when named by
> URNs.     That's awesome, and I wish we could make everything we do in
> IETF work that well.
>=20
> But if there's also a namespace-specific interpretation of q-components
> that's specified in that namespace's registration, then there are *two*
> specifications for how to interpret a q-component, and a very high
> probability of conflict between the two.   This is what I want to
> avoid.    I don't want client implementors trying to second-guess
> whether to interpret q-components according to each namespace's
> registration vs. the general rule for handling q-components.   And I
> don't want namespaces to get the idea that they can override
> interpretation of q-components.
>=20
> Second concern:   Of course, if a namespace wants to decree that it will
> only assign its URNs to resources that implement q-components in one
> particular way, and it wants to document that, it's free to do so.   And
> if that namespace wants to document that information, they should be
> free to do so.   But putting spaces for that in the URN registration
> template is basically encouraging them to nail down their specification
> for q-components.   In addition to the interoperability concerns I
> stated above, I think this is probably shortsighted.   It's basically
> encouraging the namespace to say "we know what q-components are going to
> need to look like for every resource we want to name, for all time, or
> at least until we update our namespace registration".   And I think
> media are changing so quickly these days that it's very hard to
> anticipate what future needs will be.   So I don't think IETF should
> particularly encourage that level of specification in general.   For a
> couple of namespaces it might make sense, but I think those are corner
> cases rather than the general case.
>=20
> My concerns for f-components are similar.   Again, I thought
> f-components were supposed to map to URL fragments, and fragments are
> (for better or worse) supposed to be independent of the name or service
> used to access the content.    So we don't want to give URN namespaces
> the impression that they can override this in the namespace
> registration.   And again, if a URN namespace elects to refuse to assign
> its URNs to any resources that contain fragment IDs that don't conform
> to its standards for naming fragments, it's free to do so, but I think
> that's probably shortsighted and IETF probably shouldn't encourage it in
> general.   It might make more sense in a couple of corner cases.
>=20
> As for r-components, I'll address those in a separate message.

Best,

Lars=20


From nobody Thu May 28 14:16:03 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 069AF1A8A15 for <urn@ietfa.amsl.com>; Thu, 28 May 2015 14:16:02 -0700 (PDT)
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 M4kmTZyRQnHu for <urn@ietfa.amsl.com>; Thu, 28 May 2015 14:15:55 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8565A1A89FD for <urn@ietf.org>; Thu, 28 May 2015 14:15:37 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9A1C020C0E for <urn@ietf.org>; Thu, 28 May 2015 17:15:36 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 28 May 2015 17:15:36 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=4RCnWbI23C2ZAU8 +QE+i4dy7mh4=; b=h7FYqTR/k+3k0i0h80qR0RUqIQBzwVVwCd4l7agGIVCBJ99 yBHbo2RErq54RC5itaPob4oxNo6wQK7CJMmjwIioHo7VJXyEcWGm9prYOebNLjpK qEKoCHBtvunill9YPq9YnhPdG51iQafDhoPi4xaKqBA04uzfUTkxrlGLQxbQ=
X-Sasl-enc: KBDNH1IKCePR6w5YNlsE2sQ74+zW9+aVTA8Id5/QQ95k 1432847736
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 1836AC00011; Thu, 28 May 2015 17:15:36 -0400 (EDT)
Message-ID: <55678564.2050901@network-heretics.com>
Date: Thu, 28 May 2015 17:15:16 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>,  Peter Saint-Andre - &yet <peter@andyet.net>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com>
In-Reply-To: <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/gV6UOMprAkm4BBCfrDxw374wsLc>
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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: Thu, 28 May 2015 21:16:02 -0000

On 05/27/2015 06:07 PM, Leslie Daigle (ThinkingCat) wrote:
>
> FWIW, I’m not just worried about “rogue”, I’m worried about having a 
> plethora of available tools to apply to URNs and no way to determine 
> what the minter of the URN intended.

I think we absolutely need a plethora of available tools to apply to URNs.

I also think we need a way to determine what the minter of the URN 
intended.   However, for security reasons I suspect this needs to rely 
at least as much on digital signatures and a certificate hierarchy, as 
it relies on a registry of resolution services.

I'm happy to try to sort this stuff out as part of a discussion of 
resolution and associated registries.   I don't see offhand how any of 
this affects a discussion of URN namespace registration, unless we want 
2414bis to ask namespaces to supply their public keys as part of 
registration.

Keith


From nobody Thu May 28 17:17:45 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 3B6621A8AFB for <urn@ietfa.amsl.com>; Thu, 28 May 2015 17:17:44 -0700 (PDT)
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 xVncLpRrkn1f for <urn@ietfa.amsl.com>; Thu, 28 May 2015 17:17:42 -0700 (PDT)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 939811A89FC for <urn@ietf.org>; Thu, 28 May 2015 17:17:42 -0700 (PDT)
Received: by pacwv17 with SMTP id wv17so35118013pac.2 for <urn@ietf.org>; Thu, 28 May 2015 17:17:42 -0700 (PDT)
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=/wvum/WyR09ha6JSUwPyovvpkXseZRSzzhYjpw19hmU=; b=WPMZhS8Fx1WdwOsSBCncR0AxUG//vVUs5rodYu4zN5GsblIqlmAGQX6qx/G9f2fBU3 z0ecK2C1J7eU/+o6nzvSmyR0D5tzJvo+PKV3eEFralBuLHEpwjjOWPnFd1Lo/LhlwIu0 vVtc6O5OTAtqgXJG4ClkNhnbY82Wnq3YI0dqKf+8YHEcV6veAwJSQThFsPbRBECuCb/z YtKQk/SEP+Ax0+La4nOpZG+Q6+wp3CDLtOW7gpjoxO5w1OQfhxWThc8bqAu44Bu69You HxliuVEmNdxPFW3vZIGFf4NbZdyicYfwellHCE+q6g3myUk1wL+e8kjSpCk2l1tUaU28 lX2Q==
X-Gm-Message-State: ALoCoQkwqyxxy5Mlq+5s5C4/nz7RUy88J2XDzfjYqq08g+/StMoeDRLYR/IXd196dHdNlTY4Ib9i
X-Received: by 10.68.221.164 with SMTP id qf4mr10235342pbc.1.1432858662300; Thu, 28 May 2015 17:17:42 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l8sm3544050pdj.80.2015.05.28.17.17.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 17:17:40 -0700 (PDT)
Message-ID: <5567B021.3060401@andyet.net>
Date: Thu, 28 May 2015 18:17:37 -0600
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.6.0
MIME-Version: 1.0
To: "Svensson, Lars" <L.Svensson@dnb.de>, "urn@ietf.org" <urn@ietf.org>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/HbLBWw1wJKGM3O0_CV39WdaCcxg>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 29 May 2015 00:17:44 -0000

On 5/28/15 8:49 AM, Svensson, Lars wrote:
> Peter,
>
> On Thursday, May 28, 2015 5:02 AM, Peter Saint-Andre - &yet wrote:
>
>> On 5/27/15 4:07 PM, Leslie Daigle (ThinkingCat) wrote:
>>>
>>> FWIW, I’m not just worried about “rogue”, I’m worried about having a
>>> plethora of available tools to apply to URNs and no way to determine
>>> what the minter of the URN intended.
>>>
>>> And, I believe that’s a change of the spec.
>>
>> I seem to be in the rough about my desire to remove all discussion of
>> resolution from the syntax and registration specification. Every time we
>> talk about resolution, we seem to fall down a rat hole of unusual size.
>> Since we're not replacing RFC 2276 in parallel with replacing RFC 2141
>> and RFC 3406, I feel like we're flying blind with respect to all
>> resolution-related topics.
>
> If I understand you correctly, your suggestion is concentrate on syntax (and as little semantics as possible) making 2141bis fly as soon as possible. Once that is done, we go on to revise 3406. WFM. That said, I don't think we can specify registrations procedures without discussion resolution since one important aspect of persistent naming is the ability to find the named object through its name. And in most cases this is done through some kind of lookup service and it is indeed an important question who has the canonical registry. I don't think we can offload that on to IANA...

I'm suggesting that we concentrate on syntax (2141bis) and namespace 
registrations (3406bis) - those are easier to specify because we have 
more experience with them. We don't have experience with URN resolution 
or at least those folks haven't been involved here, so I suggest that we 
updated RFC 2276 separately and address the resolution-related topics then.

Peter

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


From nobody Fri May 29 00:35:08 2015
Return-Path: <L.Svensson@dnb.de>
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 A2F2B1B2A64 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 00:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] 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 yQBgDTnwzVaG for <urn@ietfa.amsl.com>; Fri, 29 May 2015 00:35:03 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 558621B2A61 for <urn@ietf.org>; Fri, 29 May 2015 00:35:02 -0700 (PDT)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 68DE88AE22; Fri, 29 May 2015 09:35:01 +0200 (CEST)
X-AuditID: 0a453fe7-f79136d0000011d7-30-556816a5319f
Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id BE.4D.04567.5A618655; Fri, 29 May 2015 09:35:01 +0200 (CEST)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Fri, 29 May 2015 09:35:00 +0200
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Peter Saint-Andre - &yet <peter@andyet.net>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
Thread-Index: AQHQmAkXI5nwTFWGZ02NBTxQLrEV8J2QQW+AgABSaACAAOSnsIAAf6SAgACa2rA=
Date: Fri, 29 May 2015 07:35:00 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF6F30D@dnbf-ex1.AD.DDB.DE>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE> <5567B021.3060401@andyet.net>
In-Reply-To: <5567B021.3060401@andyet.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.98]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLsWRmVeSWpSXmKPExsXC5Wr/VXepWEaowdM/AhanHh1htpja/IHJ gcnj3J1r7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr43r2PrWCdWMX21++YGhifiHYxcnJICJhI vJv7lwnCFpO4cG89WxcjF4eQwBFGiQ13/jNBONsZJR4/38PcxcjOwSagJfE+A6ReRMBP4tir xywgtrCAh8Tm/c+ZIeKeEu9X7mWFqVn5egMjiM0ioCqxvX822C5eAW+JvjMQ9UICPUwSEyZz g9icQNM/b57ADmIzCshKbNhwHqyGWUBcYtOz76wQdwpILNkDEZcQEJV4+fgfVFxBYtGLU0D3 cwDVa0qs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiyipGvODfdUC8x RS8lJUkvJXUTIyQmnu9g7LvkcohRgINRiYd3y830UCHWxLLiytxDjP4cTEqivO3XgUJ8Sfkp lRmJxRnxRaU5qcVKIrx7RTJChXjhwkmlOdlKcrzLa1NDhcThosWlxQWZyZn5pcXxpUU5hxgl OJiBWne+BZrIm5JYWZValA8x8BCjNAeLkjjvxN2NIUIC6YklqdmpqQWpRTDZCA4OJQnemSA7 BYtS01Mr0jJzSmDSQH2zQTICyDJgBynyPgc5SApZAt1NTBychxh9OHiADvMF+6m4IDG3ODMd arYwr7YAUJQHJgo2V5b3DMhcMZggqpmnGIOlxHk7wE4CqcgozYO7VUqM17gOqJUfSQJkpJQC 7827aaFCkkjiqKa+YvQERpEwr6goyDnA/IRwoxDvHmGgIDdUEOxEGYgTRaFi6Gb5AONWhNfs aArIwyWJJcge9gI5kAcmCvWwax3Yw1BBVOOkGhhdfHuN70a3BZ97aVO7hpfnWKllx7TV6YGy Bvu0dtnI/I4qbJs0m/921ZFfS6SKYs6XpVdkHO78PH3fs9f1HU8O/d38uHkH21exlo4X/3f8 cfgQlJlQoRN91sdFP+EIV3q6qdGUt98bZrbOmZTru9a0TLbz1MLPd6WebHrucNxkzid5vYeS 37qUWIozEg21mIuKEwGhcFxxcgQAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/XsTzyQXjngl5ZdGkv8_KJStOPII>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 29 May 2015 07:35:05 -0000

T24gRnJpZGF5LCBNYXkgMjksIDIwMTUgMjoxOCBBTSwgUGV0ZXIgU2FpbnQtQW5kcmUgLSAmeWV0
IHdyb3RlDQo+IE9uIDUvMjgvMTUgODo0OSBBTSwgU3ZlbnNzb24sIExhcnMgd3JvdGU6DQo+ID4g
UGV0ZXIsDQo+ID4NCj4gPiBPbiBUaHVyc2RheSwgTWF5IDI4LCAyMDE1IDU6MDIgQU0sIFBldGVy
IFNhaW50LUFuZHJlIC0gJnlldCB3cm90ZToNCj4gPg0KPiA+PiBPbiA1LzI3LzE1IDQ6MDcgUE0s
IExlc2xpZSBEYWlnbGUgKFRoaW5raW5nQ2F0KSB3cm90ZToNCj4gPj4+DQo+ID4+PiBGV0lXLCBJ
4oCZbSBub3QganVzdCB3b3JyaWVkIGFib3V0IOKAnHJvZ3Vl4oCdLCBJ4oCZbSB3b3JyaWVkIGFi
b3V0IGhhdmluZyBhDQo+ID4+PiBwbGV0aG9yYSBvZiBhdmFpbGFibGUgdG9vbHMgdG8gYXBwbHkg
dG8gVVJOcyBhbmQgbm8gd2F5IHRvIGRldGVybWluZQ0KPiA+Pj4gd2hhdCB0aGUgbWludGVyIG9m
IHRoZSBVUk4gaW50ZW5kZWQuDQo+ID4+Pg0KPiA+Pj4gQW5kLCBJIGJlbGlldmUgdGhhdOKAmXMg
YSBjaGFuZ2Ugb2YgdGhlIHNwZWMuDQo+ID4+DQo+ID4+IEkgc2VlbSB0byBiZSBpbiB0aGUgcm91
Z2ggYWJvdXQgbXkgZGVzaXJlIHRvIHJlbW92ZSBhbGwgZGlzY3Vzc2lvbiBvZg0KPiA+PiByZXNv
bHV0aW9uIGZyb20gdGhlIHN5bnRheCBhbmQgcmVnaXN0cmF0aW9uIHNwZWNpZmljYXRpb24uIEV2
ZXJ5IHRpbWUgd2UNCj4gPj4gdGFsayBhYm91dCByZXNvbHV0aW9uLCB3ZSBzZWVtIHRvIGZhbGwg
ZG93biBhIHJhdCBob2xlIG9mIHVudXN1YWwgc2l6ZS4NCj4gPj4gU2luY2Ugd2UncmUgbm90IHJl
cGxhY2luZyBSRkMgMjI3NiBpbiBwYXJhbGxlbCB3aXRoIHJlcGxhY2luZyBSRkMgMjE0MQ0KPiA+
PiBhbmQgUkZDIDM0MDYsIEkgZmVlbCBsaWtlIHdlJ3JlIGZseWluZyBibGluZCB3aXRoIHJlc3Bl
Y3QgdG8gYWxsDQo+ID4+IHJlc29sdXRpb24tcmVsYXRlZCB0b3BpY3MuDQo+ID4NCj4gPiBJZiBJ
IHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwgeW91ciBzdWdnZXN0aW9uIGlzIGNvbmNlbnRyYXRl
IG9uIHN5bnRheCAoYW5kIGFzDQo+IGxpdHRsZSBzZW1hbnRpY3MgYXMgcG9zc2libGUpIG1ha2lu
ZyAyMTQxYmlzIGZseSBhcyBzb29uIGFzIHBvc3NpYmxlLiBPbmNlIHRoYXQgaXMNCj4gZG9uZSwg
d2UgZ28gb24gdG8gcmV2aXNlIDM0MDYuIFdGTS4gVGhhdCBzYWlkLCBJIGRvbid0IHRoaW5rIHdl
IGNhbiBzcGVjaWZ5DQo+IHJlZ2lzdHJhdGlvbnMgcHJvY2VkdXJlcyB3aXRob3V0IGRpc2N1c3Np
b24gcmVzb2x1dGlvbiBzaW5jZSBvbmUgaW1wb3J0YW50DQo+IGFzcGVjdCBvZiBwZXJzaXN0ZW50
IG5hbWluZyBpcyB0aGUgYWJpbGl0eSB0byBmaW5kIHRoZSBuYW1lZCBvYmplY3QgdGhyb3VnaCBp
dHMNCj4gbmFtZS4gQW5kIGluIG1vc3QgY2FzZXMgdGhpcyBpcyBkb25lIHRocm91Z2ggc29tZSBr
aW5kIG9mIGxvb2t1cCBzZXJ2aWNlIGFuZCBpdA0KPiBpcyBpbmRlZWQgYW4gaW1wb3J0YW50IHF1
ZXN0aW9uIHdobyBoYXMgdGhlIGNhbm9uaWNhbCByZWdpc3RyeS4gSSBkb24ndCB0aGluayB3ZQ0K
PiBjYW4gb2ZmbG9hZCB0aGF0IG9uIHRvIElBTkEuLi4NCj4gDQo+IEknbSBzdWdnZXN0aW5nIHRo
YXQgd2UgY29uY2VudHJhdGUgb24gc3ludGF4ICgyMTQxYmlzKSBhbmQgbmFtZXNwYWNlDQo+IHJl
Z2lzdHJhdGlvbnMgKDM0MDZiaXMpIC0gdGhvc2UgYXJlIGVhc2llciB0byBzcGVjaWZ5IGJlY2F1
c2Ugd2UgaGF2ZQ0KPiBtb3JlIGV4cGVyaWVuY2Ugd2l0aCB0aGVtLiBXZSBkb24ndCBoYXZlIGV4
cGVyaWVuY2Ugd2l0aCBVUk4gcmVzb2x1dGlvbg0KPiBvciBhdCBsZWFzdCB0aG9zZSBmb2xrcyBo
YXZlbid0IGJlZW4gaW52b2x2ZWQgaGVyZSwgc28gSSBzdWdnZXN0IHRoYXQgd2UNCj4gdXBkYXRl
ZCBSRkMgMjI3NiBzZXBhcmF0ZWx5IGFuZCBhZGRyZXNzIHRoZSByZXNvbHV0aW9uLXJlbGF0ZWQg
dG9waWNzIHRoZW4uDQoNCkJ1dCBjYW4gd2UgcmVhbGx5IHNwZWNpZnkgdGhlIHJlZ2lzdHJhdGlv
biBwcm9jZWR1cmUgd2l0aG91dCBhc2tpbmcgdGhlIHJlZ2lzdHJhbnRzIHRvIHNheSBhbnl0aGlu
ZyBhYm91dCByZXNvbHV0aW9uIHNlcnZpY2VzPw0KDQpMYXJzDQo=


From nobody Fri May 29 03:33:16 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 E66901A87C6 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 03:33:14 -0700 (PDT)
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 dzfW95P9wb8v for <urn@ietfa.amsl.com>; Fri, 29 May 2015 03:33:14 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5251B2A69 for <urn@ietf.org>; Fri, 29 May 2015 03:33:13 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AC90120D33 for <urn@ietf.org>; Fri, 29 May 2015 06:33:12 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 29 May 2015 06:33:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Sqji5SFnm6rshIE xjuA9MNc9RoM=; b=tCvrXLZsaxEHQ4gYp+IkKH3xmr/t0EFX/fbr5VkqE+sdZIL P+nsWi4r30sfFSiEKWhQlLZ5+NSWHh3vJ1S7UxhqM+2kqPM8DFHW3XJw6XAult9N oMIqhH09LOPlpg6DR0QXEkN+EMcB6Hlntd58rPCXwfuUkNMJME5XZf7ol52E=
X-Sasl-enc: TRT8gnLQdENfT7hdPAjFYEeNyLtVEha6A9/qNT4DKzFB 1432895592
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 51B85C00011; Fri, 29 May 2015 06:33:12 -0400 (EDT)
Message-ID: <55684066.3020104@network-heretics.com>
Date: Fri, 29 May 2015 06:33:10 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: urn@ietf.org
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE> <5567B021.3060401@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F30D@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010CF6F30D@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/0bDwRVd_XoHuiZnwtDaPEoU3F4I>
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 29 May 2015 10:33:15 -0000

On 05/29/2015 03:35 AM, Svensson, Lars wrote:
> But can we really specify the registration procedure without asking the registrants to say anything about resolution services?
I don't think we can effectively bundle the namespace registration 
procedure with the procedure for registering namespace-specified 
resolution services, for several reasons, e.g.:  the information 
required to access such services isn't defined yet, won't be defined 
until we know something about resolution protocols and security models, 
and is likely to change more frequently than namespace registration.   
So I think we will end up with separate procedures for namespace 
registration and for registration of resolution services, and there's no 
need to try to specify the latter in 2141bis.

Keith


From nobody Fri May 29 05:32:54 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 BBA101A884E for <urn@ietfa.amsl.com>; Fri, 29 May 2015 05:32:52 -0700 (PDT)
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 mxm-xVznrqV4 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 05:32:50 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CE11A884C for <urn@ietf.org>; Fri, 29 May 2015 05:32:49 -0700 (PDT)
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 1YyJSw-000FdE-1C; Fri, 29 May 2015 08:32:46 -0400
Date: Fri, 29 May 2015 08:32:40 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, "Svensson, Lars" <L.Svensson@dnb.de>
Message-ID: <08B0499456635B130B203DEE@JcK-HP8200.jck.com>
In-Reply-To: <5567B021.3060401@andyet.net>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE> <5567B021.3060401@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/NNgZhd12vsyef7WsFE5Q_O_Km44>
Cc: urn@ietf.org
Subject: [urn] Resolution services (was: Re: suggested change for -12 of rfc2141bis section 7.3.6)
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, 29 May 2015 12:32:52 -0000

Hi.

It is possible that we are arguing about an already-solved
problem here.  Or not... see below.

--On Thursday, May 28, 2015 18:17 -0600 Peter Saint-Andre - &yet
<peter@andyet.net> wrote:

>>> I seem to be in the rough about my desire to remove all
>>> discussion of resolution from the syntax and registration
>>> specification. Every time we talk about resolution, we seem
>>> to fall down a rat hole of unusual size. Since we're not
>>> replacing RFC 2276 in parallel with replacing RFC 2141 and
>>> RFC 3406, I feel like we're flying blind with respect to all
>>> resolution-related topics.
>> 
>> If I understand you correctly, your suggestion is concentrate
>> on syntax (and as little semantics as possible) making
>> 2141bis fly as soon as possible. Once that is done, we go on
>> to revise 3406. WFM. That said, I don't think we can specify
>> registrations procedures without discussion resolution since
>> one important aspect of persistent naming is the ability to
>> find the named object through its name. And in most cases
>> this is done through some kind of lookup service and it is
>> indeed an important question who has the canonical registry.
>> I don't think we can offload that on to IANA...
> 
> I'm suggesting that we concentrate on syntax (2141bis) and
> namespace registrations (3406bis) - those are easier to
> specify because we have more experience with them. We don't
> have experience with URN resolution or at least those folks
> haven't been involved here, so I suggest that we updated RFC
> 2276 separately and address the resolution-related topics then.

Let me try this a slightly different way, but reaching the same
conclusion.  As Peter points out, we know, or are close to
knowing, how to update and replace 2141 and 3406.  We also have
very specific problems that we are trying to solve.  In the case
of 2141, allowing, for various reasons and in response to
various requirements, more syntax than 2141 permits: the things
we've been calling q-components and r-components; the
f-components / fragments that some of the opinions on RFC 3986
claim that 2141 could not disallow if it wanted to; and either
the use of the "/" within the NSS or p-components.  In the case
of 3406, it establishes a registration procedure for namespaces
that has been perceived as sufficiently onerous to discourage
namespaces from being registered, something I think we've
concluded is a bad idea.

Now, if we start looking at resolution, we end up not only in
the territory of 2276 but also 3401ff.  There are some
historical issues with 2277 related to how much consensus it
represented at the time and how informed that consensus was.  It
is an Informational, rather than a Standards Track, document,
which may or may not mean much.    More important today, 3401
(and 3402-3405) claim to be a more or less consistent
implementation spec for the ideas in 2276, modifying those ideas
slightly in the process.  With the exception of one, non-URN,
application, DDDS has not been broadly adopted or used.
Anything that was proposed today and based on any of those specs
would almost certainly have to include specific analysis of the
architecture and implementations and what had and had not
succeeded.  To the best of my knowledge, no one has started that
work or even volunteered to do it.

At the same time, most of the URNs we have seen in active use
either don't need resolution services or use resolution
mechanisms intrinsic in other standards or protocols.  URNs used
in XMPP, ISBN and ISSN, and XML all come immediately to mind as
examples.

I think Keith's most recent comments
(http://www.ietf.org/mail-archive/web/urn/current/msg03076.html)
are largely consistent with the above although his perspective
is different.

Briefly addressing a more recent note:

--On Friday, May 29, 2015 07:35 +0000 "Svensson, Lars"
<L.Svensson@dnb.de> wrote:

> But can we really specify the registration procedure without
> asking the registrants to say anything about resolution
> services?

I think we have little choice, for the reasons outlined above
and in Keith's and Peter's notes.   However, we provided some
time ago for comments about resolution when those are
appropriate and I haven't seen proposals to remove those
provisions.  See in particular (in
draft-ietf-urnbis-rfc2141bis-urn-11):

	Section 7.1, numbered item 6     and
	Section 7.3.6

I've expressed some concerns earlier about the second paragraph
of the latter because of the interaction and reference to 2276
(for the reasons above), but don't recall anyone else expressing
interest in that issue.  However, it seems to me that this text
provides mechanisms that allow a registration to say any of the
following in the registration specification:

 (i) This namespace is indicator-only and unlikely to be
	resolved (or resolution would be meaningless).
 (ii) Resources associated with this namespace are
	located and resolved according to the mechanism
	specified in ...
 (iii) While the identifier is universal and persistent,
	registration is likely to be a local matter.
 (iv) We know what these are, aren't ready to say
	anything general about resolution yet, but will update
	the registration when we figure that out.
 (v0 ... and so on

It seems to me that provides a way to record whatever
information is known and which the registrants think is
appropriate to supply while avoiding  unrealistic requirements
to specific things that neither we nor the registrant knows or
requiring that all URNs be resolvable or resolvable in one of an
enumerated set of ways.

What else do you think is both useful and feasible?   Is the
current text ok or would you suggest improvements, particularly
to say either more or less?

	    john



From nobody Fri May 29 08:02:26 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 DB0F61A924A for <urn@ietfa.amsl.com>; Fri, 29 May 2015 08:02:24 -0700 (PDT)
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 44gRZRrTjVAh for <urn@ietfa.amsl.com>; Fri, 29 May 2015 08:02:21 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C051A9231 for <urn@ietf.org>; Fri, 29 May 2015 08:02:21 -0700 (PDT)
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 1YyLnW-000FwH-JC; Fri, 29 May 2015 11:02:10 -0400
Date: Fri, 29 May 2015 11:02:05 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <A583F55F28DEC2E01FE8C8F4@JcK-HP8200.jck.com>
In-Reply-To: <55678564.2050901@network-heretics.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55678564.2050901@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/qZPEotrJF2qPQzjLx38i7kUMy2s>
Cc: urn@ietf.org
Subject: Re: [urn] suggested change for -12 of rfc2141bis  section 7.3.6
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, 29 May 2015 15:02:25 -0000

--On Thursday, May 28, 2015 17:15 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> On 05/27/2015 06:07 PM, Leslie Daigle (ThinkingCat) wrote:
>> 
>> FWIW, I'm not just worried about "rogue", I'm worried
>> about having a  plethora of available tools to apply to URNs
>> and no way to determine  what the minter of the URN intended.
> 
> I think we absolutely need a plethora of available tools to
> apply to URNs.

I think we already have them and have no hope of either getting
rid of some or preventing more.  I also don't think the latter
would be desirable even if we could somehow do it.

> I also think we need a way to determine what the minter of the
> URN intended.

The referenced section 7.3.6 of -11 (see prior note) seems to me
to allow the registrant to provide whatever intent is
appropriate (or, if appropriate, to not do so).   I think the
discussion between Keith and Leslie starting on 1 May provides
pointers toward better text for that subsection (see below), but
does not significantly change the intent of leaving decisions
largely up to the registrant about what it is appropriate to say
and how much specific detail to provide.  See below.

>  However, for security reasons I suspect this
> needs to rely at least as much on digital signatures and a
> certificate hierarchy, as it relies on a registry of
> resolution services.

Speaking personally, I believe that a comprehensive reprise of
issues in URN resolution, including issues about data integrity
guarantees and other security topics, would be desirable.  But I
think that opening those topics on this list at this time is not
only off-charter but distracting and a significant impediment to
getting the WG's work done.

I do note that the belief that solutions lie in the direction of
"digital signatures and a certificate hierarchy" invokes
problems that the Internet community has been unable to sort out
and get generally deployed and in effective use for _any_
protocol or application I'm aware of so, at best, this is not an
easily-resolved short-term problem.

Similarly, I am not (as one of Leslie's notes suggested)
inclined to discard DDDS on the basis of issues with the
"implementation in DNS".  However, we know there are issues with
that DNS implementation and, AFAIK, the number of other
widely-deployed implementations is around zero, so a strong
reference to DDDS that seems to hold it up as a good example
seems inappropriate in the absence of some serious analysis and
writing ... about DDDS and the 2276 architecture, not URNs.

> I'm happy to try to sort this stuff out as part of a
> discussion of resolution and associated registries.   I don't
> see offhand how any of this affects a discussion of URN
> namespace registration, unless we want 2414bis to ask
> namespaces to supply their public keys as part of registration.

For the reasons above, I'm opposed to any requirements that
would be specific enough to use words like "supply their public
keys", probably even as examples.  Independent of how we say it,
I think the registration template should encourage registrants
to say whatever they think it appropriate about registration for
that particular namespace and that it should stop there.   I
believe the existing text in 7.3.6 does that.  I believe Keith's
original 1 May text (to save readers time, it was:

> The "Resolution" section is optional.  If included, it SHOULD
> specify whether the namespace intends to operate or recommend
> any resolution services for URNs using that namespace.   In
> addition, if the namespace intends to implement registration
> for publicly-advertised resolution services (for example using
> a system like that described in [RFC2276]) the Resolution
> section SHOULD list the requirements for being
> publicly-advertised using that mechanism.
> 
> Note: The above is not intended to restrict URN resolution to
> services provided by or recommended by the namespace operator.
> In principle, any party may operate a resolution service for
> any set of URNs.

) does that.  I think it does so a bit better with Peter's
suggested modifications, e.g., making the "Resolution" section
mandatory even if it ends up saying "not intended to be
resolved", "you are on your own", or "this section should be
updated when appropriate time machines are in use" (see Homeric
example below).  

Suggested modified text, cleaning up the language Peter
questioned and removing the reference to 2276 because it is not
"a system" but a proposed architecture for one (this is a little
more passive and vague about who or what is doing the
specifying, but probably that is appropriate).  I also think we
need to not try to tie things to generic resolution services --
if there are namespace-specific preferred ones, the registration
should identify them:

	If included, it SHOULD specify whether there are
	specific recommended resolution services, operational
	mechanisms, or ways of finding either for URNs using
	that namespace.  In addition, if implementation of
	registration for publicly-advertised resolution services
	(for example using a system such as DDDS [RFC3401] or
	one associated with an external standard) is
	anticipated, this section SHOULD supply the information
	required for being publicly-advertised or otherwise
	using that mechanism.

 ----------

However, I believe that the discussion about text has obscured
two more fundamental issues...

(1) Keith has asserted repeatedly (cf.
http://www.ietf.org/mail-archive/web/urn/current/msg03012.html)
that 

> resolution is, fundamentally, not a per-namespace operation.

I'm not clear as to what that means.  Certainly, in the general
case, a resolution service for one namespace is likely to differ
in more or less significant ways from a resolution service for
another one.  Even a "find the resolution service" model such as
DDDS merely moves the namespace-specific characteristics out one
level of abstraction.

The text later in that note suggests to me that the problem
isn't whether resolution is per-namespace but whether a
particular resolution mechanism or provider is sufficiently
tightly bound to a namespace that no other (or replacement)
registration mechanisms are possible.  I don't think anyone has
suggested that, although it does imply that we need to be
careful about what statements are made and that we carefully
distinguish between stability/ persistence of a URN and
stability/persistence of an associated resource and how it is
found.  


(2)  Leslie, and probably others, have noted that not having a
tight and required binding to resolution services allows

> 2/ Me standing up a completely independent URN resolution
> service for all registered URN namespaces and resolving them
> any way I choose -- i.e., not necessarily to the resources
> intended by the namespace creator and/or assigner. And it's
> not clear to me how others would be able to determine the
> intended resolution service outcome.

I think the response to that has got to be "yes".  It is a risk
for almost any Internet protocol that references or
de-references objects.  For example even with simple URLs, if
http://resource.example.com/ is referenced, nothing prevents
some immediate or intermediate system from converting it into
http://resource.somewhere-near-me.example.com/ (something often
considered a good thing) or http://resource.example.evil-doer/
(something usually consider a bad thing).  Using bad words
(including "hijacking") to describe what we believe are bad
practices doesn't seem to make them less prevalent, nor does it
help distinguish practices, including object-owner-controlled
DNS diversion techniques that are widely deployed and some
vendors (in bad and exceptionally candid moods) would claim have
saved the Internet from stupidity in the DNS, linkages between
URLs and DNS, and wrong-headed ideas in the routing system.   

We claim we know how to let the client interpreting the URL
distinguish between "example.com" and "example.evildoer", but,
for a variety of reasons, that mechanism has been largely
unsuccessful in practice.   And we claim that we know how to at
least verify the integrity of the data retrieved, but we've been
unsuccessful in deploying those mechanisms, especially without
introducing circular dependencies on the DNS.

If a statement is needed in Security Considerations that says
that nothing about a URN guarantees that an attempt to resolve
it will obtain the intended resource, please supply text, but
please remember that this is an extremely general problem and
not unique to URNs.

However, I also suggest that something like
    urn:important-ancient-texts:homer:Illiad-original-version

is a perfectly good URN.  It is about as persistent as anything
in western literary culture can be.  The reference is
unambiguous in the sense that likely users of the URN are going
to agree on what, conceptually, is being referenced.   It is
definitely not an "indicator".  I don't think it is an "abstract
designator" either, but this example illustrates why I'm a
little hesitant about that terminology.   It is not resolvable
in any practical way and there are deep historical questions
(rooted, among other things, in assumptions about texts that may
have existed for a long time in oral form only and even about
whether "Homer" is a historical figure).    Whether such a URN
is useful or not presumably depends on what a possible
registrant wants to use it for -- that isn't a question on which
the IETF should take a position or expect folks to pay attention
if we did.

best,
    john










From nobody Fri May 29 08:54:17 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 2E3C81ACD86 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 08:54:14 -0700 (PDT)
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 ntOKKCnUikB9 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 08:54:12 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D031ACD7D for <urn@ietf.org>; Fri, 29 May 2015 08:54:12 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9B3D920688 for <urn@ietf.org>; Fri, 29 May 2015 11:54:11 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 29 May 2015 11:54:11 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=r5+T0FAzJAqClOl +9IeljD11xjc=; b=uPrDFRQBCA6koDdiSq+jM4LSMqqm1P6T7VrK9CPwPjCNAn8 RptzXhqmnq1uXeXpu0hsn6ETBdg36geNuW5+q+i5jY+E2BAWL48ahdeKkV4Y8rBC WKBqGmHIIOUVxViasJm/7812v4Mu/IVAWEk+8G0ey4yMCZ6oam/iaES776u8=
X-Sasl-enc: bj59XwMHg3MEaGRiWkOW8oBrGq5ZIBLM21IGefYnjRAP 1432914851
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 18988680113; Fri, 29 May 2015 11:54:11 -0400 (EDT)
Message-ID: <55688BA0.3070803@network-heretics.com>
Date: Fri, 29 May 2015 11:54:08 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>, Peter Saint-Andre - &yet <peter@andyet.net>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55678564.2050901@network-heretics.com> <A583F55F28DEC2E01FE8C8F4@JcK-HP8200.jck.com>
In-Reply-To: <A583F55F28DEC2E01FE8C8F4@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/Kak6hZyQxKxObrLDjlpoNZTcIqw>
Cc: urn@ietf.org
Subject: Re: [urn] suggested change for -12 of rfc2141bis section 7.3.6
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, 29 May 2015 15:54:14 -0000

On 05/29/2015 11:02 AM, John C Klensin wrote:
> However, I believe that the discussion about text has obscured two 
> more fundamental issues... (1) Keith has asserted repeatedly (cf. 
> http://www.ietf.org/mail-archive/web/urn/current/msg03012.html) that
>> resolution is, fundamentally, not a per-namespace operation.
> I'm not clear as to what that means.  Certainly, in the general
> case, a resolution service for one namespace is likely to differ
> in more or less significant ways from a resolution service for
> another one.

I don't believe this is at all certain, nor do I believe that it is 
desirable in general.  The whole point of having URNs is to permit some 
degree of common processing that is independent of namespace, including 
the ability to obtain metadata (if available) and/or access the resource 
(if the resource is available and the operation makes any sense for that 
resource).

That said, neither do I want to force a "one size fits all" model on URN 
resolution.   I have several reasons for this, the most important 
probably being that such services need to be able to evolve over time, 
perhaps especially in the near term, and therefore it is necessary that 
it be possible to have different and even competing services.   But 
promoting the idea that resolution is inherently something for each 
namespace to determine on its own, IMO, would harm interoperability.   
Sure, namespaces can offer any resolution services that they want for 
their URNs (or not), but so can anybody else.     And it's extremely 
important that this be possible.

(I also agree that trying to define a resolution service is beyond this 
group's charter, though I think it's reasonable to discuss such issues 
to the extent necessary to nail down text in 2141bis.)

>   Even a "find the resolution service" model such as
> DDDS merely moves the namespace-specific characteristics out one
> level of abstraction.
>
> The text later in that note suggests to me that the problem
> isn't whether resolution is per-namespace but whether a
> particular resolution mechanism or provider is sufficiently
> tightly bound to a namespace that no other (or replacement)
> registration mechanisms are possible.  I don't think anyone has
> suggested that, although it does imply that we need to be
> careful about what statements are made and that we carefully
> distinguish between stability/ persistence of a URN and
> stability/persistence of an associated resource and how it is
> found.

Indeed, we need to be careful about what statements are made.

>
>
> (2)  Leslie, and probably others, have noted that not having a
> tight and required binding to resolution services allows
>
>> 2/ Me standing up a completely independent URN resolution
>> service for all registered URN namespaces and resolving them
>> any way I choose -- i.e., not necessarily to the resources
>> intended by the namespace creator and/or assigner. And it's
>> not clear to me how others would be able to determine the
>> intended resolution service outcome.
> I think the response to that has got to be "yes".

Again, I think the mechanism for ensuring authenticity of metadata 
and/or resources associated with URNs cannot rely on "a tight and 
required binding to resolution services".    Being able to determine 
authenticity of such metadata and resources is very important, but it's 
also very important that there not be a single point of control for 
access to resources named by URNs.   We don't want to build an 
information architecture that facilitates Orwellian "memory holes" - as 
the US government, as well as probably several others, would certainly 
like to do.

And while I agree that IETF in the past has not had a stellar record at 
developing trust delegation systems, that's not a good argument for 
giving up.   IETF is currently revisiting those issues on several 
fronts, out of perhaps-reluctant necessity, due to the realization that 
both passive surveillance and active attacks on Internet traffic by 
various parties, some with near-limitless resources, are now commonplace 
and widespread.   We should all realize by now that simply trusting the 
authoritative servers for DNS or whatever, is now no longer sufficient.

> If a statement is needed in Security Considerations that says
> that nothing about a URN guarantees that an attempt to resolve
> it will obtain the intended resource, please supply text, but
> please remember that this is an extremely general problem and
> not unique to URNs.
>
> However, I also suggest that something like
>      urn:important-ancient-texts:homer:Illiad-original-version
>
> is a perfectly good URN.  It is about as persistent as anything
> in western literary culture can be.  The reference is
> unambiguous in the sense that likely users of the URN are going
> to agree on what, conceptually, is being referenced.   It is
> definitely not an "indicator".  I don't think it is an "abstract
> designator" either, but this example illustrates why I'm a
> little hesitant about that terminology.   It is not resolvable
> in any practical way and there are deep historical questions
> (rooted, among other things, in assumptions about texts that may
> have existed for a long time in oral form only and even about
> whether "Homer" is a historical figure).    Whether such a URN
> is useful or not presumably depends on what a possible
> registrant wants to use it for -- that isn't a question on which
> the IETF should take a position or expect folks to pay attention
> if we did.

I probably agree with that, or at least agree that it should be 
reasonable to assign a URN to Homer's original text of the Illiad, even 
if such a document has never been found and is believed to no longer 
exist.   I certainly would not want to declare such uses out-of-scope.

Keith


From nobody Fri May 29 11:49:38 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 B1E1E1B2C1A for <urn@ietfa.amsl.com>; Fri, 29 May 2015 11:49:36 -0700 (PDT)
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 1FBkSqGS-TF2 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 11:49:34 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BD41B2C18 for <urn@ietf.org>; Fri, 29 May 2015 11:49:34 -0700 (PDT)
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 1YyPLT-000GO5-HE; Fri, 29 May 2015 14:49:27 -0400
Date: Fri, 29 May 2015 14:49:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>, Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <F75C6E20DB873B285EEE9A85@JcK-HP8200.jck.com>
In-Reply-To: <55688BA0.3070803@network-heretics.com>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55678564.2050901@network-heretics.com> <A583F55F28DEC2E01FE8C8F4@JcK-HP8200.jck.com> <55688BA0.3070803@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/3JAWqHMa2tVQaHBhN5o4jeSUBwo>
Cc: urn@ietf.org
Subject: Re: [urn] suggested change for -12 of rfc2141bis section 7.3.6
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, 29 May 2015 18:49:36 -0000

--On Friday, May 29, 2015 11:54 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> On 05/29/2015 11:02 AM, John C Klensin wrote:
>> However, I believe that the discussion about text has
>> obscured two  more fundamental issues... (1) Keith has
>> asserted repeatedly (cf. 
>> http://www.ietf.org/mail-archive/web/urn/current/msg03012.htm
>> l) that
>>> resolution is, fundamentally, not a per-namespace operation.
>> I'm not clear as to what that means.  Certainly, in the
>> general case, a resolution service for one namespace is
>> likely to differ in more or less significant ways from a
>> resolution service for another one.
> 
> I don't believe this is at all certain, nor do I believe that
> it is desirable in general.  The whole point of having URNs is
> to permit some degree of common processing that is independent
> of namespace, including the ability to obtain metadata (if
> available) and/or access the resource (if the resource is
> available and the operation makes any sense for that resource).

Keith, I may even agree with what I think you are trying to say,
but I believe that statements based on "the whole point of
having URNs" really gets in our way at this point.   At least
one of the reasons for that is that I think it drives us
inevitably toward a conclusion that a "urn:" scheme was a
mistake and that, instead, "URN" should have been an abstract
category of URI, just like "URL" and schemes should have been
tied to classes of resolution (or non-resolution) approaches and
methods (or abstractions of them).  Then one could have really
interesting conversations about whether the set of "URLs" and
the set of "URNs" should be lexically distinguishable (and
distinguishable from "URC" and any other sets of URIs that might
show up in the future).    Unless we are prepared to suggest
deprecating the "urn:" scheme and starting over, let's not go
there.

The following is a lot more relevant, at least IMO...

> That said, neither do I want to force a "one size fits all"
> model on URN resolution.   I have several reasons for this,
> the most important probably being that such services need to
> be able to evolve over time, perhaps especially in the near
> term, and therefore it is necessary that it be possible to
> have different and even competing services.

Operationally and in terms of 2141bis, I think that leaves us in
exactly the same place, independent of our assumptions,
predictions, or religious beliefs about the future.  I think the
registrations of namespaces need to have the capability of
specifying separate resolution models even though I hope they
were evolve in similar ways.  You think there have to be
arrangements for different registration models for different
namespaces because, which you hope and expect to see
commonality, things might evolve in different ways, or new
technologies be introduced, in the future.  In practical terms
as applied to 2141bis, I don't see a difference.

>   But promoting
> the idea that resolution is inherently something for each
> namespace to determine on its own, IMO, would harm
> interoperability.   Sure, namespaces can offer any resolution
> services that they want for their URNs (or not), but so can
> anybody else.     And it's extremely important that this be
> possible.

Agreed, I think.  See above.

> (I also agree that trying to define a resolution service is
> beyond this group's charter, though I think it's reasonable to
> discuss such issues to the extent necessary to nail down text
> in 2141bis.)

Ok.  What else do you think we need to talk about to get
acceptable text into 2141bis in general and what is in 7.3.6 in
particular?

>...

>> (2)  Leslie, and probably others, have noted that not having a
>> tight and required binding to resolution services allows
>> 
>>> 2/ Me standing up a completely independent URN resolution
>>> service for all registered URN namespaces and resolving them
>>> any way I choose -- i.e., not necessarily to the resources
>>> intended by the namespace creator and/or assigner. And it's
>>> not clear to me how others would be able to determine the
>>> intended resolution service outcome.
>> I think the response to that has got to be "yes".
> 
> Again, I think the mechanism for ensuring authenticity of
> metadata and/or resources associated with URNs cannot rely on
> "a tight and required binding to resolution services".
> Being able to determine authenticity of such metadata and
> resources is very important, but it's also very important that
> there not be a single point of control for access to resources
> named by URNs.   We don't want to build an information
> architecture that facilitates Orwellian "memory holes" - as
> the US government, as well as probably several others, would
> certainly like to do.

I'd like to skip the hyperbole, including claims about what
various governments would like to do (I don't see as much
intra-government homogeneity as I would infer from the above), I
don't think we disagree.   If you do, I'd appreciate your help
in understand how and why.

> And while I agree that IETF in the past has not had a stellar
> record at developing trust delegation systems, that's not a
> good argument for giving up.   IETF is currently revisiting
> those issues on several fronts, out of perhaps-reluctant
> necessity, due to the realization that both passive
> surveillance and active attacks on Internet traffic by various
> parties, some with near-limitless resources, are now
> commonplace and widespread.   We should all realize by now
> that simply trusting the authoritative servers for DNS or
> whatever, is now no longer sufficient.

Again, no disagreement at all.  I just don't consider resolving
the above issues to be critical path for the WG generally and
2141bis in particular.  I consider it an advantage because the
topics involve, to paraphrase an earlier on-list comment about
something else, can constitute a rathole of considerable size.

Also, FWIW, if I wanted to dive deeply into those issues, there
is a case to be made that the URN, and possibly the entire URI,
architecture are bad news because it tends to expose the
namespaces in which one is interested to a greater degree than
might be desired.

>...
>> However, I also suggest that something like
>>      urn:important-ancient-texts:homer:Illiad-original-version
>> 
>> is a perfectly good URN.  It is about as persistent as
>> anything in western literary culture can be.  The reference is
>> unambiguous in the sense that likely users of the URN are
>> going to agree on what, conceptually, is being referenced.
>> It is definitely not an "indicator".  I don't think it is an
>> "abstract designator" either, but this example illustrates
>> why I'm a little hesitant about that terminology.   It is not
>> resolvable in any practical way and there are deep historical
>> questions (rooted, among other things, in assumptions about
>> texts that may have existed for a long time in oral form only
>> and even about whether "Homer" is a historical figure).
>> Whether such a URN is useful or not presumably depends on
>> what a possible registrant wants to use it for -- that isn't
>> a question on which the IETF should take a position or expect
>> folks to pay attention if we did.
 
> I probably agree with that, or at least agree that it should
> be reasonable to assign a URN to Homer's original text of the
> Illiad, even if such a document has never been found and is
> believed to no longer exist.   I certainly would not want to
> declare such uses out-of-scope.

Part of that comment is that there is no conclusive evidence
that such a text ever existed, at least in written form, and
some evidence to the contrary.   I hope that does not change
your answer.

best,
    john




From nobody Fri May 29 13:54:07 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 F16DA1B2D45 for <urn@ietfa.amsl.com>; Fri, 29 May 2015 13:54:05 -0700 (PDT)
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 f9JzYcIIkJYy for <urn@ietfa.amsl.com>; Fri, 29 May 2015 13:54:03 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356BD1B2D42 for <urn@ietf.org>; Fri, 29 May 2015 13:54:03 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 92038207BB for <urn@ietf.org>; Fri, 29 May 2015 16:54:02 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 29 May 2015 16:54:02 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=W82MCPmmRHhIAVx 3KhHghOVNvZ8=; b=U9HoG4ydkV7ypdOOt2jn6+QI24boFFoXdCsAOsxAsfhWA+u l0HdEAloG89hClTPZK1gaGfrRCC2HtRIYuKywaOW6xQVmxeF90yrXzNxUjHHfNBw JE/Tk+ocroOJGB9o+MWOLBKB1c+X1Xc1MbYJ1gvomCpvYG/nOnTREbi2NwOc=
X-Sasl-enc: M2muxwkK/9tbHcYZ1+LqXkRAXZU2jWkB16AgCL+rLqAv 1432932842
Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id EBF77C00019; Fri, 29 May 2015 16:54:01 -0400 (EDT)
Message-ID: <5568D1E7.5070200@network-heretics.com>
Date: Fri, 29 May 2015 16:53:59 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>,  "Leslie Daigle (ThinkingCat)" <ldaigle@thinkingcat.com>, Peter Saint-Andre - &yet <peter@andyet.net>
References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <EEBCBEE8-1102-48B1-AEB7-4E05E043F618@thinkingcat.com> <55678564.2050901@network-heretics.com> <A583F55F28DEC2E01FE8C8F4@JcK-HP8200.jck.com> <55688BA0.3070803@network-heretics.com> <F75C6E20DB873B285EEE9A85@JcK-HP8200.jck.com>
In-Reply-To: <F75C6E20DB873B285EEE9A85@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/WYBjwTTgPxP4npLO2pAvB21Paz0>
Cc: urn@ietf.org
Subject: Re: [urn] suggested change for -12 of rfc2141bis section 7.3.6
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, 29 May 2015 20:54:06 -0000

On 05/29/2015 02:49 PM, John C Klensin wrote:
>
> --On Friday, May 29, 2015 11:54 -0400 Keith Moore
> <moore@network-heretics.com> wrote:
>
>> On 05/29/2015 11:02 AM, John C Klensin wrote:
>>> However, I believe that the discussion about text has
>>> obscured two  more fundamental issues... (1) Keith has
>>> asserted repeatedly (cf.
>>> http://www.ietf.org/mail-archive/web/urn/current/msg03012.htm
>>> l) that
>>>> resolution is, fundamentally, not a per-namespace operation.
>>> I'm not clear as to what that means.  Certainly, in the
>>> general case, a resolution service for one namespace is
>>> likely to differ in more or less significant ways from a
>>> resolution service for another one.
>> I don't believe this is at all certain, nor do I believe that
>> it is desirable in general.  The whole point of having URNs is
>> to permit some degree of common processing that is independent
>> of namespace, including the ability to obtain metadata (if
>> available) and/or access the resource (if the resource is
>> available and the operation makes any sense for that resource).
> Keith, I may even agree with what I think you are trying to say,
> but I believe that statements based on "the whole point of
> having URNs" really gets in our way at this point.   At least
> one of the reasons for that is that I think it drives us
> inevitably toward a conclusion that a "urn:" scheme was a
> mistake and that, instead, "URN" should have been an abstract
> category of URI, just like "URL" and schemes should have been
> tied to classes of resolution (or non-resolution) approaches and
> methods (or abstractions of them).

I don't think that makes sense.   What you seem to be saying is that 
there should be no effort to build a common framework for handling 
stable resource names, and that instead, each different type of stable 
resource name should have its own resolution protocols. This in turn 
would appear to make it likely that only a few different kinds of stable 
resource names would be supported by clients, and the organizations 
maintaining such resource names would have a tremendous degree of 
control over not only naming but also access to all resources named 
using their schemes.    And I don't see why anything that I said "drives 
us inevitably toward" such a conclusion.

Fortunately, we didn't go in that direction.
>> That said, neither do I want to force a "one size fits all"
>> model on URN resolution.   I have several reasons for this,
>> the most important probably being that such services need to
>> be able to evolve over time, perhaps especially in the near
>> term, and therefore it is necessary that it be possible to
>> have different and even competing services.
> Operationally and in terms of 2141bis, I think that leaves us in
> exactly the same place, independent of our assumptions,
> predictions, or religious beliefs about the future.  I think the
> registrations of namespaces need to have the capability of
> specifying separate resolution models even though I hope they
> were evolve in similar ways.

They can provide whatever resolution services they wish.  Nothing is 
stopping them.   I just don't want us to promote the idea that 
namespaces are somehow axiomatically either authoritative or sole 
sources for such information.   In general, they're not.   To the extent 
that this model makes sense for some URN namespaces of limited scope, 
this is a corner case, not the general case.

> You think there have to be
> arrangements for different registration models for different
> namespaces because, which you hope and expect to see
> commonality, things might evolve in different ways, or new
> technologies be introduced, in the future.  In practical terms
> as applied to 2141bis, I don't see a difference.

One difference is that namespaces should not be set up to be the 
gatekeepers for access to resources or metadata associated with their 
URNs.    Another difference is that evolution of resolution services 
should not be entirely up to namespaces.   Anyone should be able to 
provide resolution services.   Ideally, there would be a means of 
signing metadata, content, and/or public keys of resources so that the 
authenticity of a resource's or metadata's association with a URN could 
be verified independently of the resolution service used to obtain that 
metadata or access that resource.
>> (I also agree that trying to define a resolution service is
>> beyond this group's charter, though I think it's reasonable to
>> discuss such issues to the extent necessary to nail down text
>> in 2141bis.)
> Ok.  What else do you think we need to talk about to get
> acceptable text into 2141bis in general and what is in 7.3.6 in
> particular?

Very reasonable question.    I'll probably have to get back to you on 
that after the weekend.

>
>> Again, I think the mechanism for ensuring authenticity of
>> metadata and/or resources associated with URNs cannot rely on
>> "a tight and required binding to resolution services".
>> Being able to determine authenticity of such metadata and
>> resources is very important, but it's also very important that
>> there not be a single point of control for access to resources
>> named by URNs.   We don't want to build an information
>> architecture that facilitates Orwellian "memory holes" - as
>> the US government, as well as probably several others, would
>> certainly like to do.
> I'd like to skip the hyperbole, including claims about what
> various governments would like to do (I don't see as much
> intra-government homogeneity as I would infer from the above), I
> don't think we disagree.   If you do, I'd appreciate your help
> in understand how and why.

I don't know whether we disagree about that or not.   I'm just stating 
what I believe to be an important security concern.

(FWIW, I don't see that much intra-government homogeneity either. It 
just seemed better to say "the US government" than to name specific names.)

>
>> And while I agree that IETF in the past has not had a stellar
>> record at developing trust delegation systems, that's not a
>> good argument for giving up.   IETF is currently revisiting
>> those issues on several fronts, out of perhaps-reluctant
>> necessity, due to the realization that both passive
>> surveillance and active attacks on Internet traffic by various
>> parties, some with near-limitless resources, are now
>> commonplace and widespread.   We should all realize by now
>> that simply trusting the authoritative servers for DNS or
>> whatever, is now no longer sufficient.
> Again, no disagreement at all.  I just don't consider resolving
> the above issues to be critical path for the WG generally and
> 2141bis in particular.  I consider it an advantage because the
> topics involve, to paraphrase an earlier on-list comment about
> something else, can constitute a rathole of considerable size.

Mostly agree.   I just think that for now we need to very carefully 
choose the words in the small portion of 2141bis that mentions resolution.

>
> Also, FWIW, if I wanted to dive deeply into those issues, there
> is a case to be made that the URN, and possibly the entire URI,
> architecture are bad news because it tends to expose the
> namespaces in which one is interested to a greater degree than
> might be desired.

Yet another reason why, even though there's nothing stopping people from 
setting them up, having namespaces be closely tied to any specific kind 
of content is not a good idea.

>
>> ...
>>> However, I also suggest that something like
>>>       urn:important-ancient-texts:homer:Illiad-original-version
>>>
>>> is a perfectly good URN.  It is about as persistent as
>>> anything in western literary culture can be.  The reference is
>>> unambiguous in the sense that likely users of the URN are
>>> going to agree on what, conceptually, is being referenced.
>>> It is definitely not an "indicator".  I don't think it is an
>>> "abstract designator" either, but this example illustrates
>>> why I'm a little hesitant about that terminology.   It is not
>>> resolvable in any practical way and there are deep historical
>>> questions (rooted, among other things, in assumptions about
>>> texts that may have existed for a long time in oral form only
>>> and even about whether "Homer" is a historical figure).
>>> Whether such a URN is useful or not presumably depends on
>>> what a possible registrant wants to use it for -- that isn't
>>> a question on which the IETF should take a position or expect
>>> folks to pay attention if we did.
>   
>> I probably agree with that, or at least agree that it should
>> be reasonable to assign a URN to Homer's original text of the
>> Illiad, even if such a document has never been found and is
>> believed to no longer exist.   I certainly would not want to
>> declare such uses out-of-scope.
> Part of that comment is that there is no conclusive evidence
> that such a text ever existed, at least in written form, and
> some evidence to the contrary.   I hope that does not change
> your answer.

It does not.

Keith