From nobody Fri May  2 08:07:00 2014
Return-Path: <jehakala@mappi.helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB311A6FB4; Fri,  2 May 2014 08:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.303
X-Spam-Level: 
X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 2FtR4P2LWEhU; Fri,  2 May 2014 08:06:55 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 308C31A6F27; Fri,  2 May 2014 08:06:54 -0700 (PDT)
Received: from webmail-4.mappi.helsinki.fi (webmail-4.mappi.helsinki.fi [128.214.20.218]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s42F6gje022186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 May 2014 18:06:43 +0300
Received: from a88-114-107-213.elisa-laajakaista.fi (a88-114-107-213.elisa-laajakaista.fi [88.114.107.213]) by webmail.helsinki.fi (Horde Framework) with HTTP; Fri, 02 May 2014 18:06:42 +0300
Date: Fri, 02 May 2014 18:06:42 +0300
Message-ID: <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi>
From: jehakala@mappi.helsinki.fi
To: John C Klensin <john-ietf@jck.com>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10>
In-Reply-To: <952E89C207E59D25CD5953D6@JCK-EEE10>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.6)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/073NpXZ2r1j7_D3xueX2sa1HsB4
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>, apps-discuss@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 02 May 2014 15:06:58 -0000

Hello,


Quoting John C Klensin <john-ietf@jck.com>:

> Hi.
> <snip> ... one very quick observation in response to part of
> Larry's note...
>
> --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter
> <masinter@adobe.com> wrote:
>
>> The only thing that makes something a name 'persistsent' is
>> the existence of a name resolution service or method which
>> persists. The syntax or namespace is irrelevant.  'persistent'
>> isn't binary, it's just "how long". Everything has a life-time.
>>
>> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
>
> I think the above largely misses the point and that, in a sense,
> your blog posting illustrates the point although not in the way
> you probably intend.   "Persistent identifier" entered the IETF
> vocabulary a long time ago but may not be very look terminology.
>
> Some objects -- like stone statues if one doesn't care whether
> they remain intact and standing-- have very long life
> expectancies.  Others, like people, have shorter ones.

The library point of view to this is that Shelley's Ozymandias has an  
extremely long life expectancy as a work. It will exist at least as  
long as there is at least one copy left of it, in some physical  
(printed or digital) form. In principle the work itself may survive  
even longer, if 1-n people have memorized it before the last copy  
vanishes (which will inevitably happen).

Persistence of works, their manifestations and identifiers assigned to  
them is primarily an organizational issue. For instance, publications  
will survive a long time because national libraries look after them.  
Some of us are also busy harvesting web pages, using the same  
technologies as the Internet Archive. Likewise archives and museums  
will keep some materials for hundreds of years. This is the community  
which needs persistent identifiers and is already actively using them  
(and understands pretty well how to do it).

Now, in order to identify Ozymandias, the following steps are needed:

1. Give an identifier to the (immaterial) work, and provide metadata  
about the poem.

2. Give identifier to a manifestation of the work. The identifier  
system used can be an ISBN, if Ozymandias is published in a collection  
of Shelley's poems. Once the identifier has been assigned, provide  
metadata about the book. If the resource is not a book, use other  
identifier system such as NBN.

3. If the resource is digital, provide a link (using the existing  
identifier) from the metadata record to the resource. Traditional  
identifiers can be made actionable in the Internet as URNs, but other  
PID systems such as DOI, Handle, ARK et cetera can also be used. As an  
aside, new features which URNbis has built are not in conflict with  
other PIDs; on the contrary, they can use them as well. The only  
slightly problematic case is ARK since it has its own established  
practice for using query.

The essential difference between this PID-driven approach and that of  
some people on this list is that for me, URLs like this

http://www.poemhunter.com/poem/ozymandias/

or even this

http://ozymandias.perm

are not identifiers, first and foremost because their assignment  
process is not managed.

One may argue that sometimes there are no proper identifier system to  
use but this is not true; Handles, DOIs and URNs can be applied to  
anything out there). Second, there is a problem that URLs are not  
persistent, since they are technology dependent. Even if they had the  
same organizational support than the URN-based link supported by the  
national library (which is very unlikely) it may become very difficult  
to support these URLs long before reading the resources requires  
digital archaeology.

Some people on this list have argued that  
http://urn.fi/URN:ISBN:978-952-10-9658-7 or other PID with embedded  
resolver address is no different from e.g. http://ozymandias.perm. But  
in this case the syntactical similarity is deceptive; URN and other  
PIDs must be resolved before the current URL (URLs) of the resource is  
found, so all kinds of interesting stuff can be done in the resolution  
process before the result is passed to HTTP. And once Resolver  
Discovery Service is in place, it will be possible to drop the  
resolver URL from the URN string, and make the difference between URLs  
and URNs more clear.


But URIs
> (with or within including URNs) aren't objects, they are object
> reference that, like most good references, involve some degree
> of abstraction.  Now, "Ozymandias" is a very long-persistent
> reference.  It isn't the object.  It is a somewhat ambiguous
> reference because it can refer to the statue, the poem, your
> blog posting, and probably several other things, but has a long
> duration, perhaps one that is long enough to survive the objects
> it references (just like titles of long-lost books).   But, as a
> reference, it is that persistent because it is not bound to a
> retrieval mechanism that has its own persistence properties.

References to immaterial objects (works and expressions, the latter  
meaning for instance translations of works) are persistent, but they  
do require metadata since otherwise they may be ambiguous. For  
instance, we are talking about Shelley's poem, first published in The  
Examiner, 11 January 1818, along with Hymn to intellectual beauty.  
There is also book by Thomas Monteleone which has the same name.

>
> Whatever its other properties,
> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
> is lousy as a persistent identifier.

URLs really should not be called identifiers. There is a fundamental  
difference between assigning a persistent identifier using a managed  
process (which includes creation of descriptive metadata about the  
resource) and getting a URL to a web page.

One problem I and others have with the concept of URI is that it blurs  
what should be a clear difference between locations and proper  
identifiers. Anyone should be allowed to give the former, but  
identifier assignment for resources that are to be kept for centuries  
is not something anyone is allowed do. Of course even people assigning  
proper identifiers such as ISBNs and ISSNs make mistakes, and there  
are pressures to use these systems in less than optimal manner, but  
that is not the key issue here. What is important is that any digital  
resource that will be preserved for future generations will require a  
persistent identifier. Millions and millions of them - Handles, DOIs,  
URNs, ARKs) have been assigned already by libraries, publishers,  
universities, archives and museums. In order to optimize the tools  
used for generating and resolving URNs and other PIDs, we need some  
new functionalities such as the possibility of using fragments and  
queries.


It depends on the
> availability of "http" (or something called that) as a retrieval
> mechanism.  It depends on there being a DNS, on there being a
> TLD named "com" an SLD named "blogspot", and both of them having
> certain properties of which HTTP can take advantage.

It seems that the extent to which URLs are dependent on underlying  
technologies and the impact this will have on URLs in the long run  
(after, say, a few decades) is not properly understood yet even by  
those communities which must preserve things for extended periods. It  
might be useful to explain where the problems are, and make a  
guesstimate of when each of these issues might emerge.

> "Ozymandias", and even the potential URN
> urn:poems:Shelley/Ozymandias are more persistent because they
> represent a higher level of abstraction and are not tied to
> either a location or a retrieval/access method.  Use of a
> hypothetical ISPN (International Standard Poem Identifier) in
> the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or
> might not be more persistent: it would be an exact identifier of
> something and makes equivalence comparison more feasible and
> less ambiguous, but it is probably tied to a database to
> actually identify an object and such databases may be more or
> less available and persistent than access methods and/or the DNS
> (which is, after all, just another database).

In practice there will be ISTC (International Standard Text Code)  
assigned to the poem. ISTC can be expressed as URN  
(urn:istc:xxxx-xxxx-xxxx-xxxx). Library databases all over the world  
will have work metadata about the poem (once one library has  
catalogued it, it can be copied to the OPAC of every other library in  
the world). From the work record there will be persistent links to  
manifestation records, which in turn will contain the locations of the  
manifestations - physical shelf locations for printed stuff, and links  
using persistent identifiers to electronic resources. When thousands  
of library OPACs have the same metadata record, it is important to  
have just persistent identifier -based links in them; resolving these  
URNs / Handles / etc. to URLs must be centralized. Then it is not  
necessary to modify every OPAC when URLs change.

Naming / identification has at times been discussed on this list in a  
very abstract level. For most resources that will be preserved for  
long term, things are not that complex. There are guidebooks for using  
ISTCs, ISBNs, ISSNs, NBNs and so on. In those namespaces at least it  
is not necessary to be familiar with Heidegger in order to be able to  
assign identifiers for things. On the other hand, it is these existing  
practices which are in conflict with some of the principles expressed  
in RFC 3986. If fragment were to identify something (instead of just  
pinpointing a location within the identified resource) the new URN  
syntax would not be OK of most identifiers used in libraries and  
publishing sector. The same applies for query.

Juha

>
> Regardless of what one calls them, I suggest that
> access-method-dependent identifiers (http:...,
> NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?"
> represents one or more carefully-chosen delimiters that may not
> have RFC 3986 semantics), ...) are different kinds of creatures
> than either the objects to which they refer or names of those
> objects that are not, in the sense of the above, method or
> location-model dependent.
>
> More soon.
>
>     john
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn




From nobody Fri May  2 10:16:48 2014
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 095401A6FD8 for <urn@ietfa.amsl.com>; Fri,  2 May 2014 10:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 JCSz2SLrqkUs for <urn@ietfa.amsl.com>; Fri,  2 May 2014 10:16:46 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B32871A6F8F for <urn@ietf.org>; Fri,  2 May 2014 10:16:46 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WgH4S-000Fak-OE; Fri, 02 May 2014 13:16:24 -0400
Date: Fri, 02 May 2014 13:16:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: jehakala@mappi.helsinki.fi
Message-ID: <86412DCF67470AFC510CD4F4@JcK-HP8200.jck.com>
In-Reply-To: <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tO4JorCVFZymufdUvCZSnNQxC7M
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 02 May 2014 17:16:48 -0000

(apps-discuss list dropped)

Juha,

I found this (both the part quoted below and the rest of your
note) very helpful.  Thanks.  One question below...

--On Friday, May 02, 2014 18:06 +0300 jehakala@mappi.helsinki.fi
wrote:

>...
> The library point of view to this is that Shelley's Ozymandias
> has an extremely long life expectancy as a work. It will exist
> at least as long as there is at least one copy left of it, in
> some physical (printed or digital) form. In principle the work
> itself may survive even longer, if 1-n people have memorized
> it before the last copy vanishes (which will inevitably
> happen).
>...
> Now, in order to identify Ozymandias, the following steps are
> needed:
> 
> 1. Give an identifier to the (immaterial) work, and provide
> metadata about the poem.
> 
> 2. Give identifier to a manifestation of the work. The
> identifier system used can be an ISBN, if Ozymandias is
> published in a collection of Shelley's poems. Once the
> identifier has been assigned, provide metadata about the book.

I would assume that, if the poem is published as part of a
collection, the collection appears in a book, and the book is
identified with an ISBN, the mechanism for finding the poem
within the book becomes part of a specification about the book
and its identifier.  That is an instruction about the component
of the book, not what I think would normally be considered
"metadata about the book".  And depending on other conventions
or protocols (in the traditional, not computer sense), that
mechanism might be shown as "page 57ff", "Chapter 5", or
something else.   Some introducing (or surrounding) syntax would
be needed for that sort of mechanism description and one would
probably want it to be different from the mechanisms used to
query, or extract information from, the "metadata about the
book".  

While the distinctions are real, the details may be a matter of
convention.  For example, if the book's table of contents were
considered metadata about the book, the poem might also be found
within the book by asking a question of that metadata and then
using the result.

Is that just about right?  If not, where am I confused?

thanks,
    john


From nobody Fri May  2 12:56:43 2014
Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB31A6F68 for <urn@ietfa.amsl.com>; Fri,  2 May 2014 12:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 4C2mwRZPxwR1 for <urn@ietfa.amsl.com>; Fri,  2 May 2014 12:56:38 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 67A901A093A for <urn@ietf.org>; Fri,  2 May 2014 12:56:36 -0700 (PDT)
Received: from [192.168.100.30] (a88-114-107-213.elisa-laajakaista.fi [88.114.107.213]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s42JuMDb011843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 22:56:23 +0300
Message-ID: <5363F867.60503@helsinki.fi>
Date: Fri, 02 May 2014 22:56:23 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, jehakala@mappi.helsinki.fi
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> <86412DCF67470AFC510CD4F4@JcK-HP8200.jck.com>
In-Reply-To: <86412DCF67470AFC510CD4F4@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/37Oi4fd1PoYgOboKZrPIRJhCkKM
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 02 May 2014 19:56:42 -0000

Hello,

On 2.5.2014 20:16, John C Klensin wrote:
> (apps-discuss list dropped)
>
> Juha,
>
> I found this (both the part quoted below and the rest of your
> note) very helpful.  Thanks.  One question below...
>
> --On Friday, May 02, 2014 18:06 +0300 jehakala@mappi.helsinki.fi
> wrote:
>
> I would assume that, if the poem is published as part of a
> collection, the collection appears in a book, and the book is
> identified with an ISBN, the mechanism for finding the poem
> within the book becomes part of a specification about the book
> and its identifier.
Sort of. I left out some details from my description, but add them here 
because similar techniques are being put into use not only in libraries 
but in other organizations as well.

In our slang, there is a host record describing the book, and component 
part records describing the poem, article, image or any other thing in 
the book. There is a bidirectional link between host and component part 
records. Similar linking techniques are in use when libraries describe 
for instance serials and serial articles and CDs & tracks in them. The 
work level record of a poem, track, article or any other component part 
will be linked directly to the the component part record. Persistent 
identifiers are required in all levels, and there can be several of them 
- for instance, a periodical articles often have embedded images.

These component parts are sometimes components only in logical sense. 
Each track or article may be available as a separate file. But if a file 
contains many component resources, the file syntax may reveal this 
internal structure. For instance, when the National Library of Finland 
digitizes serials we often create structured METS/ALTO XML files where 
encoding shows the logical structure of the issue.
> That is an instruction about the component
> of the book, not what I think would normally be considered
> "metadata about the book".  And depending on other conventions
> or protocols (in the traditional, not computer sense), that
> mechanism might be shown as "page 57ff", "Chapter 5", or
> something else.   Some introducing (or surrounding) syntax would
> be needed for that sort of mechanism description and one would
> probably want it to be different from the mechanisms used to
> query, or extract information from, the "metadata about the
> book".

METS/ALTO encoding commonly used for digitized textual resources can do 
a lot. Not only can we encode articles, but also chapters, pages, 
paragraphs etc.; it is also possible to describe the font and size of 
each OCR'd character - and provide the probability of the correctness of 
the OCR result for each character.
>   
>
> While the distinctions are real, the details may be a matter of
> convention.  For example, if the book's table of contents were
> considered metadata about the book, the poem might also be found
> within the book by asking a question of that metadata and then
> using the result.
Table of contents (and abstract) is often provided as metadata for 
non-fiction books. So it is possible to find for instance an article 
within a book even if there is no separate metadata record for it. 
Whether it is possible to provide a direct link to such article depends 
on the encoding of the (text) file. Rich encoding takes time, but serves 
the users well.

>
> Is that just about right?  If not, where am I confused?

I don't think you are  ;-).

  Juha
>
> thanks,
>      john
>


From nobody Mon May  5 02:58:09 2014
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 865BF1A02A1 for <urn@ietfa.amsl.com>; Mon,  5 May 2014 02:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Level: 
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, 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 L0R9k7l88dXh for <urn@ietfa.amsl.com>; Mon,  5 May 2014 02:58:04 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id A83B61A02A0 for <urn@ietf.org>; Mon,  5 May 2014 02:58:03 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id EE3B07F397; Mon,  5 May 2014 11:57:58 +0200 (CEST)
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Juha Hakala <juha.hakala@helsinki.fi>, John C Klensin <john-ietf@jck.com>,  "jehakala@mappi.helsinki.fi" <jehakala@mappi.helsinki.fi>
Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
Thread-Index: AQHPZkCr8vJIUWRXmE693mS+C8u215sxsG8A
Date: Mon, 5 May 2014 09:57:58 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA43FFFAC@dnbf-ex1.AD.DDB.DE>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> <86412DCF67470AFC510CD4F4@JcK-HP8200.jck.com> <5363F867.60503@helsinki.fi>
In-Reply-To: <5363F867.60503@helsinki.fi>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.173]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LXIjdu_4yJbF9F9aassJ7G8zwiQ
Cc: "julian.reschke@gmx.de" <julian.reschke@gmx.de>, "urn@ietf.org" <urn@ietf.org>, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 05 May 2014 09:58:07 -0000

All,

This discussion has been very helpful to me since it has forced me to refle=
ct on my own views on persistent identification, managed processes, resolut=
ion services and other features of urn:s (the lower-case rfc 2141 ones). I =
have tried to follow the discussion closely as I work for a memory organisa=
tion offering urn services, but I cannot deny that I often have had the imp=
ression that any attempt to find consensus would be futile and that I often=
 felt that I had completely lost track of in what direction this WG is goin=
g. Many thanks to John and Juha for getting the discussion more focused on =
what features we expect from urn:s. This mail was triggered by the discussi=
on from Friday, May 2nd, 2014 and I use it both to comment and to check if =
I have understood the arguments correctly.

On May 2nd, 9:56 PM, Juha Hakala wrote:

> Hello,
>=20
> On 2.5.2014 20:16, John C Klensin wrote:
> > (apps-discuss list dropped)
> >
> > Juha,
> >
> > I found this (both the part quoted below and the rest of your
> > note) very helpful.  Thanks.  One question below...
> >
> > --On Friday, May 02, 2014 18:06 +0300 jehakala@mappi.helsinki.fi
> > wrote:
> >
> > I would assume that, if the poem is published as part of a
> > collection, the collection appears in a book, and the book is
> > identified with an ISBN, the mechanism for finding the poem
> > within the book becomes part of a specification about the book
> > and its identifier.
> Sort of. I left out some details from my description, but add them here
> because similar techniques are being put into use not only in libraries
> but in other organizations as well.
>=20
> In our slang, there is a host record describing the book, and component
> part records describing the poem, article, image or any other thing in
> the book. There is a bidirectional link between host and component part
> records.

Yes, that is the model we envision, although it will take some time before =
we reach that stage. Traditionally, libraries have only catalogued the phys=
ical item at hand, so that there usually would be metadata available about =
the book (e. g. an anthology of poems by different authors) but not about t=
he individual parts (i. e. individual poems or illustrations). So it might =
be more correct to rewrite the above statement as (emphasis added):

[[
In our slang, there is a host record describing the book, and there *might =
be* component part records describing the poem, article, image or any other=
 thing in the book. *In that case*, there is a bidirectional link between h=
ost and component part records.
]]

We must keep in mind that cataloguing in libraries is extremely heterogeneo=
us and that often only very coarse data is available. We're getting better,=
 though.

> Similar linking techniques are in use when libraries describe
> for instance serials and serial articles and CDs & tracks in them. The
> work level record of a poem, track, article or any other component part
> will be linked directly to the the component part record. Persistent
> identifiers are required in all levels, and there can be several of them
> - for instance, a periodical articles often have embedded images.
>=20
> These component parts are sometimes components only in logical sense.
> Each track or article may be available as a separate file. But if a file
> contains many component resources, the file syntax may reveal this
> internal structure. For instance, when the National Library of Finland
> digitizes serials we often create structured METS/ALTO XML files where
> encoding shows the logical structure of the issue.

Yes. And we must be careful when and how we use that as a basis for creatin=
g (persistent) identifiers. Do you suggest that we specify in some RFC that=
 we use specific syntaxes (in this case METS/ALTO) to describe the (interna=
l) structure of resource? If yes, I must say that I consider it a mistake a=
 to depend on a certain technology to represent things considering that tha=
t technology might be obsolete in 500 years...=20

[...]
> > While the distinctions are real, the details may be a matter of
> > convention.  For example, if the book's table of contents were
> > considered metadata about the book, the poem might also be found
> > within the book by asking a question of that metadata and then
> > using the result.
> Table of contents (and abstract) is often provided as metadata for
> non-fiction books. So it is possible to find for instance an article
> within a book even if there is no separate metadata record for it.
> Whether it is possible to provide a direct link to such article depends
> on the encoding of the (text) file. Rich encoding takes time, but serves
> the users well.

Perhaps one of the most important questions is how we handle resources that=
 have not reached their ideal state yet...

On May 2nd, 5:07 PM, Juha wrote:

> Quoting John C Klensin <john-ietf@jck.com>:
>=20
[skipping Ozymandias]

> > Whatever its other properties,
> > http://masinter.blogspot.com/2010/03/ozymandias-uri.html
> > is lousy as a persistent identifier.
>=20
> URLs really should not be called identifiers. There is a fundamental
> difference between assigning a persistent identifier using a managed
> process (which includes creation of descriptive metadata about the
> resource) and getting a URL to a web page.
[...]
> Naming / identification has at times been discussed on this list in a
> very abstract level. For most resources that will be preserved for
> long term, things are not that complex. There are guidebooks for using
> ISTCs, ISBNs, ISSNs, NBNs and so on. In those namespaces at least it
> is not necessary to be familiar with Heidegger in order to be able to
> assign identifiers for things. On the other hand, it is these existing
> practices which are in conflict with some of the principles expressed
> in RFC 3986. If fragment were to identify something (instead of just
> pinpointing a location within the identified resource) the new URN
> syntax would not be OK of most identifiers used in libraries and
> publishing sector. The same applies for query.

Thanks Juha for mentioning the managed process again. If we require that ur=
n:s (identifers) be assigned according to a formal process, that implies th=
at *all parts* of the string are created according to that process. So if w=
e decide to allow queries and fragment *identifiers* in urn:s, any institut=
ion assigning identifiers need to document according to what rules those ar=
e created. Is this correct?

And if we say that fragment identifiers are not identifiers (in the above s=
ense), then we should not allow them. This just as a further argument why R=
FC 3986 FIs are a problem in URNs...

On April 29th, 10:46 PM, John C. Klensin wrote:

> For an http-style URL, the query is addressed to
> the store in which the object is located and may be used to
> select the object, to select within it, etc.  In a two (or more)
> fork environment, queries can, in principle, be addressed to
> information about the object (aka "metadata"), to the selection
> of the object or subsets of it, and so on.  They may specify if
> retrieval is actually wanted and, if so, in which fork.  For
> some types of objects (types presumably identified by NID) there
> may be one fork, two forks, or more forks and actual retrieval
> may be meaningful (or not) for each other them.  In principle,
> one could have an NID (or NID NSS pair) that did not identify an
> object at all but was a pure string for comparison purposes
> (that is allowed by 2141 as I read it).
>
> Because of those combinations, it is desirable to be able to
> identify where a query is intended to be processed and/or what
> sort of query it is on a basis that applies to all urn-method
> URNs and maybe to have abstractions about what happens when
> queries cannot be satisfied that goes somewhat beyond what 3986
> specifies (or allows other things to specify).  Because the
> query model of 3986 is, at least IMO, pretty closely tied to the
> interpretation of queries in http-style URLs, it is hard to make
> those distinctions except, perhaps, by kludge.
>=20
> And, if we are really trying to construct identifiers that will
> be useful (or at least accurately interpretable) for centuries,
> even if the presumed associated retrieval methods go away,
> kludges that can be avoided are probably an extra-bad idea.

Until now I had been pretty certain that queries only make sense in the con=
text of resolution services and thus argued that we should disallow them in=
 the urn: syntax and defer them to RFC 2483bis, but the above comment toget=
her with Juha's hint that we might in future have urn:- based resolving (wi=
thout relying on http:) has made me think about that again. One way to stay=
 within the narrow query syntax of 3986 could be to specify a list of keywo=
rds (or perhaps better a prefix like "urnrs-" (urn resolution service)) tha=
t -- when used in queries -- are *only* to be interpreted by resolvers and =
MUST be ignored by other processors. Since creating the query part of the u=
rn: is part of the managed process, that should be feasible. (I think Juha =
has mentioned similar thoughts earlier on this list, but I cannot find the =
reference right now).

Please let me know if I'm totally off on this.

Best,

Lars

*** Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek ***=20
--=20
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationstechnologie
Telefon: +49-69-1525-1752
mailto:l.svensson@dnb.de=20
http://www.dnb.de



From nobody Mon May  5 15:40:51 2014
Return-Path: <sm@resistor.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 CF42E1A044C for <urn@ietfa.amsl.com>; Mon,  5 May 2014 15:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 JJV2Lo6gUKcr for <urn@ietfa.amsl.com>; Mon,  5 May 2014 15:40:47 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E6C1A01CB for <urn@ietf.org>; Mon,  5 May 2014 15:40:47 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s45MeRjo010314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2014 15:40:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399329637; bh=fEu9SNIN3IJJ1zF4u9j0sVRQFL79mtHbSOtIGQqUzAU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HSNvx3IRN9NXBSCL8cgX6ufYjjMoUyLVOAVAFtZp22GL+gmhpvl9s0HKkbrYNhkSl NPQWmgJFlRaPMSzw/t4vUesbrHRfIdBwIavQ5BPATpCX60A7aD0NxaL47YUqTRnfFj h38B2MsDFJSiAaZKF5P8cvO9gqnL7PmY9T569eUc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1399329637; i=@resistor.net; bh=fEu9SNIN3IJJ1zF4u9j0sVRQFL79mtHbSOtIGQqUzAU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uamQwcGxTBEFRU2EwrgOsfunnNLs30WxiGsBumVt/o5x3QODd9R0C0Tf+xzhn7ATi ewyw6th35Fcpe/HLzL1AB+pIga2divhdPbEtSuvGIXR95z3FlZTvpDSdZ/teQigHgm afamwTS0B3W8f/WeG4YPDwGygLtHlYRsPOQis7mg=
Message-Id: <6.2.5.6.2.20140505145214.0e626308@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 05 May 2014 15:24:28 -0700
To: jehakala@mappi.helsinki.fi, John C Klensin <john-ietf@jck.com>
From: SM <sm@resistor.net>
In-Reply-To: <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsi nki.fi>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FMNuFwtiiTLdjCof-RBuk45dndo
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 05 May 2014 22:40:49 -0000

Hi Juha,

[apps-discuss@ removed from the Cc]

At 08:06 02-05-2014, jehakala@mappi.helsinki.fi wrote:
>Persistence of works, their manifestations and identifiers assigned to
>them is primarily an organizational issue. For instance, publications
>will survive a long time because national libraries look after them.
>Some of us are also busy harvesting web pages, using the same
>technologies as the Internet Archive. Likewise archives and museums
>will keep some materials for hundreds of years. This is the community
>which needs persistent identifiers and is already actively using them
>(and understands pretty well how to do it).

[snip]

>Some people on this list have argued that
>http://urn.fi/URN:ISBN:978-952-10-9658-7 or other PID with embedded
>resolver address is no different from e.g. http://ozymandias.perm. But
>in this case the syntactical similarity is deceptive; URN and other
>PIDs must be resolved before the current URL (URLs) of the resource is
>found, so all kinds of interesting stuff can be done in the resolution
>process before the result is passed to HTTP. And once Resolver
>Discovery Service is in place, it will be possible to drop the
>resolver URL from the URN string, and make the difference between URLs
>and URNs more clear.

There seems to be different groups interested in URNs.  The national 
library group, for example, consider persistence as a matter of 
decades or more.  I don't know whether the other groups (excluding 
people who usually participate in the IETF) share the same view.  I 
agree that the similarity of the syntax is deceptive.

>In practice there will be ISTC (International Standard Text Code)
>assigned to the poem. ISTC can be expressed as URN
>(urn:istc:xxxx-xxxx-xxxx-xxxx). Library databases all over the world
>will have work metadata about the poem (once one library has
>catalogued it, it can be copied to the OPAC of every other library in
>the world). From the work record there will be persistent links to
>manifestation records, which in turn will contain the locations of the
>manifestations - physical shelf locations for printed stuff, and links
>using persistent identifiers to electronic resources. When thousands
>of library OPACs have the same metadata record, it is important to
>have just persistent identifier -based links in them; resolving these
>URNs / Handles / etc. to URLs must be centralized. Then it is not
>necessary to modify every OPAC when URLs change.

If I understood correctly the above point is about not being 
dependent upon the technical infrastructure.  I am skipping the 
explanation about "technical infrastructure" as it would take some 
time to discuss about that in this quiet group. :-)

Thanks for the explanations you have provided.  I found them highly 
informative.

Regards,
-sm  


From nobody Mon May  5 15:48:19 2014
Return-Path: <jehakala@mappi.helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DC31A049C for <urn@ietfa.amsl.com>; Mon,  5 May 2014 15:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.252
X-Spam-Level: 
X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 s4Jbloovn_A6 for <urn@ietfa.amsl.com>; Mon,  5 May 2014 15:48:14 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id AF2C31A0496 for <urn@ietf.org>; Mon,  5 May 2014 15:48:13 -0700 (PDT)
Received: from webmail-5.mappi.helsinki.fi (webmail-5.mappi.helsinki.fi [128.214.20.189]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s45Ml1DO028217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 May 2014 01:47:01 +0300
Received: from host2.citi-us.com (host2.citi-us.com [38.100.20.80]) by webmail.helsinki.fi (Horde Framework) with HTTP; Tue, 06 May 2014 01:47:01 +0300
Date: Tue, 06 May 2014 01:47:01 +0300
Message-ID: <20140506014701.Horde.uMyXim2GMU5VjqR2gaG_gw8@webmail.helsinki.fi>
From: jehakala@mappi.helsinki.fi
To: "Svensson, Lars" <L.Svensson@dnb.de>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> <86412DCF67470AFC510CD4F4@JcK-HP8200.jck.com> <5363F867.60503@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFA43FFFAC@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43FFFAC@dnbf-ex1.AD.DDB.DE>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.6)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bwTAvU9U6S6Bu1t-UQ02FqBtfaw
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 05 May 2014 22:48:18 -0000

Hello Lars,

Some comments below.

Quoting "Svensson, Lars" <L.Svensson@dnb.de>:

>
>>
>> In our slang, there is a host record describing the book, and component
>> part records describing the poem, article, image or any other thing in
>> the book. There is a bidirectional link between host and component part
>> records.
>
> Yes, that is the model we envision, although it will take some time  
> before we reach that stage. Traditionally, libraries have only  
> catalogued the physical item at hand, so that there usually would be  
> metadata available about the book (e. g. an anthology of poems by  
> different authors) but not about the individual parts (i. e.  
> individual poems or illustrations).

For digital resources this policy must change. No manifestation of a  
digital resource (such as PDF version of a doctoral dissertation) will  
ever be persistent in the national library sense of the word. What we  
need is description of the work (which will never change) and linked  
to it, successive versions (manifestations) of the resource, with  
preservation metadata which describes the differences between these  
versions.


So it might be more correct to
> rewrite the above statement as (emphasis added):
>
> [[
> In our slang, there is a host record describing the book, and there  
> *might be* component part records describing the poem, article,  
> image or any other thing in the book. *In that case*, there is a  
> bidirectional link between host and component part records.
> ]]
>
> We must keep in mind that cataloguing in libraries is extremely  
> heterogeneous and that often only very coarse data is available.  
> We're getting better, though.

Yes - we can't manage digital content properly without getting better.  
Of course, most libraries do not have the burden of preserving digital  
resources for long term, but for those libraries that do, there is no  
alternative. And any organization which intends to preserve digital  
resources for long term must have a fairly sophisticated data model to  
support that activity. Persistent identifiers are just a small, but  
essential, part of this.


>>
>> These component parts are sometimes components only in logical sense.
>> Each track or article may be available as a separate file. But if a file
>> contains many component resources, the file syntax may reveal this
>> internal structure. For instance, when the National Library of Finland
>> digitizes serials we often create structured METS/ALTO XML files where
>> encoding shows the logical structure of the issue.
>
> Yes. And we must be careful when and how we use that as a basis for  
> creating (persistent) identifiers. Do you suggest that we specify in  
> some RFC that we use specific syntaxes (in this case METS/ALTO) to  
> describe the (internal) structure of resource? If yes, I must say  
> that I consider it a mistake a to depend on a certain technology to  
> represent things considering that that technology might be obsolete  
> in 500 years...

In this particular case I am talking about internal structure of a  
single version / manifestation of the resource and the identifiers  
needed for that. The next manifestation may have the same logical  
components but different encoding and identifiers (only the identifier  
of the work itself never changes). When migration is applied as the  
preservation policy the aim is usually to preserve the intellectual  
content. Trying to preserve the original look and feel is not likely  
to succeed.



> Thanks Juha for mentioning the managed process again. If we require  
> that urn:s (identifers) be assigned according to a formal process,  
> that implies that *all parts* of the string are created according to  
> that process. So if we decide to allow queries and fragment  
> *identifiers* in urn:s, any institution assigning identifiers need  
> to document according to what rules those are created. Is this  
> correct?

According to the current URN syntax I-D specification, fragment and  
query are not part of the namespace specific string and therefore do  
not identify anything. If we change our minds, we would need to decide  
what they actually identify, and try to convince the people who  
maintain traditional identifier systems that extending the scope of  
their identifiers with fragment identification and whatever queries  
can be applied to is OK. I don't believe that that would be easy.


>
> And if we say that fragment identifiers are not identifiers (in the  
> above sense), then we should not allow them. This just as a further  
> argument why RFC 3986 FIs are a problem in URNs...

Well, we do allow the use of URI fragments but for us they just  
indicate a location within the document identified by the namespace  
specific string.

Juha

>
> On April 29th, 10:46 PM, John C. Klensin wrote:
>
>> For an http-style URL, the query is addressed to
>> the store in which the object is located and may be used to
>> select the object, to select within it, etc.  In a two (or more)
>> fork environment, queries can, in principle, be addressed to
>> information about the object (aka "metadata"), to the selection
>> of the object or subsets of it, and so on.  They may specify if
>> retrieval is actually wanted and, if so, in which fork.  For
>> some types of objects (types presumably identified by NID) there
>> may be one fork, two forks, or more forks and actual retrieval
>> may be meaningful (or not) for each other them.  In principle,
>> one could have an NID (or NID NSS pair) that did not identify an
>> object at all but was a pure string for comparison purposes
>> (that is allowed by 2141 as I read it).
>>
>> Because of those combinations, it is desirable to be able to
>> identify where a query is intended to be processed and/or what
>> sort of query it is on a basis that applies to all urn-method
>> URNs and maybe to have abstractions about what happens when
>> queries cannot be satisfied that goes somewhat beyond what 3986
>> specifies (or allows other things to specify).  Because the
>> query model of 3986 is, at least IMO, pretty closely tied to the
>> interpretation of queries in http-style URLs, it is hard to make
>> those distinctions except, perhaps, by kludge.
>>
>> And, if we are really trying to construct identifiers that will
>> be useful (or at least accurately interpretable) for centuries,
>> even if the presumed associated retrieval methods go away,
>> kludges that can be avoided are probably an extra-bad idea.
>
> Until now I had been pretty certain that queries only make sense in  
> the context of resolution services and thus argued that we should  
> disallow them in the urn: syntax and defer them to RFC 2483bis, but  
> the above comment together with Juha's hint that we might in future  
> have urn:- based resolving (without relying on http:) has made me  
> think about that again. One way to stay within the narrow query  
> syntax of 3986 could be to specify a list of keywords (or perhaps  
> better a prefix like "urnrs-" (urn resolution service)) that -- when  
> used in queries -- are *only* to be interpreted by resolvers and  
> MUST be ignored by other processors. Since creating the query part  
> of the urn: is part of the managed process, that should be feasible.  
> (I think Juha has mentioned similar thoughts earlier on this list,  
> but I cannot find the reference right now).
>
> Please let me know if I'm totally off on this.
>
> Best,
>
> Lars
>
> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
> --
> Dr. Lars G. Svensson
> Deutsche Nationalbibliothek
> Informationstechnologie
> Telefon: +49-69-1525-1752
> mailto:l.svensson@dnb.de
> http://www.dnb.de




From nobody Tue May  6 04:10:08 2014
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 C813F1A02A8 for <urn@ietfa.amsl.com>; Tue,  6 May 2014 04:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 xNfDeUo57tLz for <urn@ietfa.amsl.com>; Tue,  6 May 2014 04:10:06 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 414C11A07B2 for <urn@ietf.org>; Tue,  6 May 2014 04:10:06 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WhdFp-0000DV-66; Tue, 06 May 2014 07:09:45 -0400
Date: Tue, 06 May 2014 07:09:44 -0400
From: John C Klensin <john-ietf@jck.com>
To: SM <sm@resistor.net>, jehakala@mappi.helsinki.fi
Message-ID: <CCE2B61EFCBECEAE1EB3CA3E@JCK-EEE10>
In-Reply-To: <6.2.5.6.2.20140505145214.0e626308@resistor.net>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> <6.2.5.6.2.20140505145214.0e626308@resistor.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: ::1
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/VADSaoJodUoWs4UfxUYAyhlV2hY
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 06 May 2014 11:10:07 -0000

--On Monday, 05 May, 2014 15:24 -0700 SM <sm@resistor.net> wrote:

> There seems to be different groups interested in URNs.  The
> national library group, for example, consider persistence as a
> matter of decades or more.

More like centuries or more.   See below, but I don't think that
is particularly important to category-forming, i.e., not a
useful starting point for a discussion.

>  I don't know whether the other
> groups (excluding people who usually participate in the IETF)
> share the same view.  I agree that the similarity of the
> syntax is deceptive.

I think it is obvious that different groups have different
perceived requirements.  For better or worse and despite a sense
that more education and listening would be helpful, I think the
"my perspective is right and you are wrong" tone of many of the
recent discussions are not leading us toward progress.  

Perhaps a more useful way to look at this is to try to
understand the needs of real communities [1] and then figure out
what we need to have in a URN standard to meet those needs.  My
working hypothesis is that, after trying to do with within the
constraints of 3986 and the compromises people are willing to
make is that it is not possible.  I hope we can do better than
   urn:nid:<stuff>
but maybe, if all we can do is to push NIS and tail syntax to
NID definitions and registrations, that is better than permanent
(sic) paralysis.

  best,
   john

[1] It has been 14 years since RFC 2141 was published.  There
are millions of URNs and many different NIDs out there.  I
suggest that is long enough for us to be able to tell the
difference between real communities with real user populations
and needs and philosophical speculation and that it is time to
start paying more attention to the former as less to the latter.
A lot more.


From nobody Tue May  6 11:25:44 2014
Return-Path: <sm@resistor.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 BEC1B1A0234 for <urn@ietfa.amsl.com>; Tue,  6 May 2014 11:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 RAGDJJEt1CYt for <urn@ietfa.amsl.com>; Tue,  6 May 2014 11:25:43 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B91A01C4 for <urn@ietf.org>; Tue,  6 May 2014 11:25:42 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s46IPQ3J006524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2014 11:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399400736; bh=2VcsEIYZhgW4sytlPqVZF2vKzQ1KhTEc3Ve/yzWf/9k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FO8cNGXQ5XVztJmS1WsyjZce3DOI4XrQFfGT2bi0zQP9dloGNUHKPyNKTTgkR0Xj9 2pRpyhHOaSomiqS+2r+rK9QZOw5fJef0lDgRfR0ULLurfRyMIw0Y58hVXQfYx/zLDH GpL57LnwlkS5zO6C9bLP8giPLcxXx0EgjHtHccN4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1399400736; i=@resistor.net; bh=2VcsEIYZhgW4sytlPqVZF2vKzQ1KhTEc3Ve/yzWf/9k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Bxo9PKrLJNZHlUoT6c0u5gw6Dp4qnwDu2W0EFEASRcVttGBKQwRBe1JQVVvEeRYSu vMg7QQXAYKYzM2gaI4w16IKT3Xt0sG6NG6Ci8JHQoeSE72N2WRSGCOUombR/G8kEY9 oadNpq/f9L5UPMZZhcsSgJ8zc8pHlxJDHRUeWK9I=
Message-Id: <6.2.5.6.2.20140506104843.0bfed448@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 06 May 2014 11:23:41 -0700
To: John C Klensin <john-ietf@jck.com>, jehakala@mappi.helsinki.fi
From: SM <sm@resistor.net>
In-Reply-To: <CCE2B61EFCBECEAE1EB3CA3E@JCK-EEE10>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <20140502180642.Horde.k922N8-cIl2au4mAP9neJA2@webmail.helsinki.fi> <6.2.5.6.2.20140505145214.0e626308@resistor.net> <CCE2B61EFCBECEAE1EB3CA3E@JCK-EEE10>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/rpwnS78bhPK5ErtJfLvA0xp2j34
Cc: julian.reschke@gmx.de, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 06 May 2014 18:25:43 -0000

Hi John,
At 04:09 06-05-2014, John C Klensin wrote:
>I think it is obvious that different groups have different
>perceived requirements.  For better or worse and despite a sense
>that more education and listening would be helpful, I think the
>"my perspective is right and you are wrong" tone of many of the
>recent discussions are not leading us toward progress.

I agree that the recent discussions are not leading towards progress.

>Perhaps a more useful way to look at this is to try to
>understand the needs of real communities [1] and then figure out
>what we need to have in a URN standard to meet those needs.  My
>working hypothesis is that, after trying to do with within the
>constraints of 3986 and the compromises people are willing to
>make is that it is not possible.  I hope we can do better than
>    urn:nid:<stuff>
>but maybe, if all we can do is to push NIS and tail syntax to
>NID definitions and registrations, that is better than permanent
>(sic) paralysis.

Factual information would help in understanding the needs of the 
various communities.  I am not sure whether that would lead towards 
progress.  The probability of "we can do better" is very low.

Regards,
-sm 


From nobody Thu May  8 19:46:08 2014
Return-Path: <worley@ariadne.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 CBC991A0123 for <urn@ietfa.amsl.com>; Thu,  8 May 2014 19:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 GQ3fwPq2N-YU for <urn@ietfa.amsl.com>; Thu,  8 May 2014 19:46:05 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 435641A0107 for <urn@ietf.org>; Thu,  8 May 2014 19:46:05 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id zeXu1n0041ap0As5Eem0AJ; Fri, 09 May 2014 02:46:00 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id zelz1n00K1KKtkw3ielzgB; Fri, 09 May 2014 02:46:00 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s492jwbX001203; Thu, 8 May 2014 22:45:58 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s492jvSj001202; Thu, 8 May 2014 22:45:57 -0400
Date: Thu, 8 May 2014 22:45:57 -0400
Message-Id: <201405090245.s492jvSj001202@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: John C Klensin <john-ietf@jck.com>
In-reply-to: <71FCF3F23062A6AE7F8552C9@JcK-HP8200.jck.com> (john-ietf@jck.com)
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.com> <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> <201404252110.s3PLAPM1031471@hobgoblin.ariadne.com> <71FCF3F23062A6AE7F8552C9@JcK-HP8200.jck.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399603560; bh=hnbPrjHFRwl17a/30ilQBSaTml7OBHXjD4VENAD9krc=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=nhQYobEpy6QBo10sF3mBd42A7Gv+qD1cKsNzDM1g5iTTxA9KgkW3bDnmM1CMiWY9D Mq9Sbw0IhDjl7dwrOxYwXu1Zq5XzH2MyAbV8RmTF/vHFd/ZuwrBMr5iXRYegxGUwnj 7vK14LES12x55eQ14T6Vs+MDUQF2g0xJTrl9A4yiR1HPqL//LWmXtiIp4FwCzaQokQ 8Fcavz7K2l/QVlPDOWq8cZy7lP3xmccuYA+tBAuQZDY05cVdmNfqwMOUJNbwmUVTE+ YAuBmcq6KfMwYMlCpCk5iAasymLnu6Tl1t+S/MusPgsQcByzINzlkYlfXdhKY4Tvcd Osmc2T0yCSJgA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7LBT5y_eLcngicq1JOtkcYxCACQ
Cc: urn@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 09 May 2014 02:46:07 -0000

> From: John C Klensin <john-ietf@jck.com>

> Because the query model of 3986 is, at least IMO, pretty closely
> tied to the interpretation of queries in http-style URLs, it is hard
> to make those distinctions except, perhaps, by kludge.

This is one a I don't understand.  As far as I can tell, the
constraint on the semantics of the query-part in RFC 3986 is:

   3.4.  Query

   The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).

In regard to the urn-scheme, in which URNs do not have naming
authorities, this seems to establish essentially no limitations.  It
says "identify a resource", but a "resource" could be *anything*.
That is, the meaning of the query-part is entirely up to the NID
registration.  In particular, a particular query-part value can be
defined to mean "fetch the metadata", because the metadata of a
resource can itself be considered a "resource", which is designated by
a URN containing a specific query-part value.  Similar definitions can
be established regarding other "forks" of a resource, and modifiers of
how the query/resolution process is to be executed.

Given that no NID defined the use of query-part, we could write a
single standard for query-parts in the urn-scheme that would apply to
all NIDs.

> It can be accommodated using use "?" syntax of 3986, but only by the
> use of some reserved keywords or other instances of horrible kludges.
> One or two such kludges were proposed to the WG.  I think it is
> accurate to report that they got no traction.

I'm not able to visualize how one could denote the "it" in this
sentence (whose meaning I do not clearly understand) by character
strings in a way in which the syntax of 3986 proves to be excessively
restrictive.  The 3986 syntax is a string from this character set:

   ALPHA / DIGIT
   / "-" / "." / "_" / "~" / "/" / "?" / ":" / "@"
   "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
   and %-escapes

I can't visualize a syntax for identifiers that is significantly more
accommodating -- with the large exception of changing to Unicode as
the underlying character set.  Although Unicode can be represented by
%-escapes, so we can cover even Unicode by having the user interface
translate to/from %-escapes.

Perhaps you know of a proposed modifier syntax (e.g., a way of
specifying a "fork" or specifying modification of the query/resolution
dynamics) that illustrates features that are difficult to implement
within the current syntax of query-part.

Of course, none of this deals with the fact that 2141 does not admit
query-part on urn-scheme URNs.  But solution of any of these problems
will almost certainly require some extension of 2141.

Dale


From nobody Thu May 22 08:57:45 2014
Return-Path: <sm@resistor.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 654381A01E0 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 08:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 gUD3SAji1bJG for <urn@ietfa.amsl.com>; Thu, 22 May 2014 08:57:42 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA611A01C8 for <urn@ietf.org>; Thu, 22 May 2014 08:57:42 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4MFuswq003244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 08:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400774222; bh=mSyTQdeyynj3UdKoWbNn9sd9c5u3XqpU/QYFWNxQsq0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KxBCH0Gt34hqXe5YpubbWXi93n7rCbe4Q/NJ9egvJpTTR8NFCQqbtJTkv/C9yTE9l HhECXq/lYsHvJ3Rb2Lqa8WeEJWAKQt3EoW4exvcCqIgw/AeUugV/iBmQCx1rVkw8e4 ME6/RKKPUtRqt2x02ltOXIvgagQJzbXukQPeylvY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1400774222; i=@resistor.net; bh=mSyTQdeyynj3UdKoWbNn9sd9c5u3XqpU/QYFWNxQsq0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kXNRA93AWPWQdxxBF4A9PnaC2fSWgfN2msr6ZWKM5UswFn5/yJnoQ1Xn2ntvpolnw D/BgqSorcD3l/iwp+10roORQJqK/GPz6KgETwPV7ZmoTPt8w+TO3sSUxvu43wWxkfD QYX9qtseT6nDaa1vq4TL93JfIWHpOOhy6hAX4qqU=
Message-Id: <6.2.5.6.2.20140522084107.0c0700b8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 22 May 2014 08:50:12 -0700
To: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, Barry Leiba <barryleiba@computer.org>
From: SM <sm@resistor.net>
In-Reply-To: <4002.1400765721@sandelman.ca>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QHkwGx3QMpehwUM22uf783WKE6M
Cc: urn@ietf.org, Bob Hinden <bob.hinden@gmail.com>
Subject: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 15:57:43 -0000

Hi Michael,

[Cc to URNbis and Barry as he wrote RFC 6924]

At 06:35 22-05-2014, Michael Richardson wrote:
>I'm saying that we (the IETF) have totally failed to dogfood URNs.

Ok.

>It seems that there are tragedy-of-the-commons for much of the URN stuff,
>and it seems that this is more than a nobody-is-running-the urn:ietf: server,
>because there is, I think, client-side stuff that has to happen, and maybe
>there is a lack of client side code.

urn:ietf:rfc has been registered.  What needs to be done to fix the 
resolution of the namespace?

Regards,
-sm


From nobody Thu May 22 09:09:17 2014
Return-Path: <barryleiba@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 67ADA1A01DC for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 YL---sBTzWoS for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:09:13 -0700 (PDT)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F9F1A01D9 for <urn@ietf.org>; Thu, 22 May 2014 09:09:13 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id i17so5986275qcy.36 for <urn@ietf.org>; Thu, 22 May 2014 09:09:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1hH6Nocd38sp6BdTN1BAOY10+k0ob8fd5MRkzPSg9R4=; b=Vrh8f2MNAdustOFWZFjJWw+d+RQBJYlXCslxFEj0r+ZD1dRwibEZt2byI0dlJXuHJq a+ghvaTjSmwOTWzQEKMJhuxfpSopZPFxz2BufNH10qilXXAYpzbjVIgz1v19Fy85qdrx peSU+KZarEBVH6pEKTQTGl+dPF0VLe7lJq/ber7LMw/l0hsEHi1usq5YJLOH9bAYsX3v yxq/PyCqnL02YnR6J9kG9FsnWiEp5FmXY21sCLbWfyZpdCXV9qneu40H+OCidf9u1hT+ P56Cu8dISlJ6SavnIWW3IFbGVS7pymgZNphFz7wJbsxPM8VGVpJ8tFITjP4dIeea0cHz 4Sqw==
MIME-Version: 1.0
X-Received: by 10.140.26.179 with SMTP id 48mr66748097qgv.51.1400774951701; Thu, 22 May 2014 09:09:11 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.99.1 with HTTP; Thu, 22 May 2014 09:09:11 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20140522084107.0c0700b8@resistor.net>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net>
Date: Thu, 22 May 2014 12:09:11 -0400
X-Google-Sender-Auth: feKdUw_uqW2zy83Ofxe44Bvdrtk
Message-ID: <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: SM <sm@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Kx7CLF8IRuCnPT2z_aKPdrKTk5I
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, "urn@ietf.org" <urn@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 16:09:14 -0000

>> It seems that there are tragedy-of-the-commons for much of the URN stuff,
>> and it seems that this is more than a nobody-is-running-the urn:ietf:
>> server,
>> because there is, I think, client-side stuff that has to happen, and maybe
>> there is a lack of client side code.
>
> urn:ietf:rfc has been registered.  What needs to be done to fix the
> resolution of the namespace?

I don't understand:
URNs are names, not locators.  They aren't meant to be "resolvable" in
the sense that, say, an http URI is.

"urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely and
persistently identifies it.

The following are all locators that will find the document that URN names:

http://datatracker.ietf.org/doc/rfc6924/
http://tools.ietf.org/html/rfc6924
http://tools.ietf.org/rfc/rfc6924.txt
http://tools.ietf.org/pdf/rfc6924
http://www.rfc-editor.org/rfc/rfc6924.txt
http://www.rfc-editor.org/pdfrfc/rfc6924.txt.pdf

How you *find* documents, given their names, is well out of the scope
of naming them.

Barry


From nobody Thu May 22 09:10:36 2014
Return-Path: <julian.reschke@gmx.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 023661A01D9 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6KPsUU2eo7NS for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:10:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C661A0049 for <urn@ietf.org>; Thu, 22 May 2014 09:10:30 -0700 (PDT)
Received: from [192.168.2.117] ([93.217.94.21]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MHoC5-1WkUlD2G3Z-003dFm; Thu, 22 May 2014 18:10:02 +0200
Message-ID: <537E2152.50506@gmx.de>
Date: Thu, 22 May 2014 18:09:54 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: SM <sm@resistor.net>, Michael Richardson <mcr+ietf@sandelman.ca>,  Carsten Bormann <cabo@tzi.org>, Barry Leiba <barryleiba@computer.org>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net>
In-Reply-To: <6.2.5.6.2.20140522084107.0c0700b8@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:FTny8IQ4ZwlWKnQG2WKMpUFkkTNFAKJN06nLSSJGz8F+nRmO1Na bfZ7D/Du0z4z1GpMmU5Depp9E0o7oKHMwC+OoHJuJwfTCMq1y1OnpuzbcZ0SmfyRrT5oO/r 488WUDkeQLXuMimvfHg9NkN3wgPoVnd7FzFAgQ5KXyQbThqfaHKPIE/afmCNl5ggjCvfCQX fBIq7cRYAGx+Adgvirx8A==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0-IivOHmbIMUvdzZLwzLE6SuRYY
Cc: urn@ietf.org, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: [urn] urn:ietf:rfc
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, 22 May 2014 16:10:33 -0000

On 2014-05-22 17:50, SM wrote:
> Hi Michael,
>
> [Cc to URNbis and Barry as he wrote RFC 6924]
>
> At 06:35 22-05-2014, Michael Richardson wrote:
>> I'm saying that we (the IETF) have totally failed to dogfood URNs.
>
> Ok.
>
>> It seems that there are tragedy-of-the-commons for much of the URN stuff,
>> and it seems that this is more than a nobody-is-running-the urn:ietf:
>> server,
>> because there is, I think, client-side stuff that has to happen, and
>> maybe
>> there is a lack of client side code.
>
> urn:ietf:rfc has been registered.  What needs to be done to fix the
> resolution of the namespace?

What problem are we solving by having a resolver for these URNs?

Best regards, Julian


From nobody Thu May 22 09:42:44 2014
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 288E91A0219 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 FOO38a9EdGvr for <urn@ietfa.amsl.com>; Thu, 22 May 2014 09:42:41 -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 A028E1A01D9 for <urn@ietf.org>; Thu, 22 May 2014 09:42:41 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WnW3w-000EkJ-PZ; Thu, 22 May 2014 12:41:49 -0400
Date: Thu, 22 May 2014 12:42:18 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, SM <sm@resistor.net>
Message-ID: <F3650CE869694591A671E9BA@JCK-EEE10>
In-Reply-To: <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.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: ::1
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/z0z_9pv_IcKteQA29rRtu_RXnFs
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is	down)
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, 22 May 2014 16:42:43 -0000

--On Thursday, 22 May, 2014 12:09 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

>>> It seems that there are tragedy-of-the-commons for much of
>>> the URN stuff, and it seems that this is more than a
>>> nobody-is-running-the urn:ietf: server,
>>> because there is, I think, client-side stuff that has to
>>> happen, and maybe there is a lack of client side code.
>> 
>> urn:ietf:rfc has been registered.  What needs to be done to
>> fix the resolution of the namespace?
> 
> I don't understand:
> URNs are names, not locators.  They aren't meant to be
> "resolvable" in the sense that, say, an http URI is.
> 
> "urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely and
> persistently identifies it.
> 
> The following are all locators that will find the document
> that URN names:
> 
> http://datatracker.ietf.org/doc/rfc6924/
> http://tools.ietf.org/html/rfc6924
> http://tools.ietf.org/rfc/rfc6924.txt
> http://tools.ietf.org/pdf/rfc6924
> http://www.rfc-editor.org/rfc/rfc6924.txt
> http://www.rfc-editor.org/pdfrfc/rfc6924.txt.pdf
> 
> How you *find* documents, given their names, is well out of
> the scope of naming them.

Barry,

Fortunately or unfortunately, the interplay between assorted
URN, URI, and DDDS documents provides a solid basis for claiming
that URNs can be bound to resolution services as well as just
names.  So, without looking up the NID spec for urn:ietf:rfc, it
could either be "just a name" or be bound to a resolution
service that would, in turn, be able to provide a locator
associated with that name.  So, although it should have been
stated differently if one being very precise, SM's question is
reasonable.

That interplay and its non-obvious side effects are another
reason for separating URNs from the URI family, thereby
requiring that any words about resolution services be explicit
in 2141bis and/or the 3406bis discussion and template rather
than requiring a treasure hunt of a variety that caused you, SM,
and Julian to make slightly different inferences about what was
(or should be) going on.

The URIs are not URNs draft does not deal with that particular
issue explicitly in the current version and probably should.

    john



From nobody Thu May 22 10:33:14 2014
Return-Path: <cabo@tzi.org>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFAD1A0226 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 10:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 9iTgQ_THjvq7 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 10:11:12 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A6A1A0216 for <urn@ietf.org>; Thu, 22 May 2014 10:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4MHB2Kb004161; Thu, 22 May 2014 19:11:02 +0200 (CEST)
Received: from [192.168.217.145] (p54893706.dip0.t-ipconnect.de [84.137.55.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EFAC61729; Thu, 22 May 2014 19:11:00 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com>
Date: Thu, 22 May 2014 19:10:59 +0200
X-Mao-Original-Outgoing-Id: 422471459.26665-688be20f68dc1a050bffd0c46c744285
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9E19C80-7E38-4055-A7BD-5F7F45211F41@tzi.org>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/X9kdSfaVtWfEiQlgB1mbfW4I9eo
X-Mailman-Approved-At: Thu, 22 May 2014 10:33:04 -0700
Cc: "urn@ietf.org" <urn@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 17:11:13 -0000

On 22 May 2014, at 18:09, Barry Leiba <barryleiba@computer.org> wrote:

> "urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely and
> persistently identifies it.
>=20
> The following are all locators that will find the document that URN =
names:
> [=85]


Actually, for RFC production we are interested in metadata about this =
RFC, as we would find it in

	=
http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6924.xml

(Note that the transformation from the URN to this URL is non-trivial, =
and currently encoded in some ad-hoc code at various places.)

I think I=92d like to see something like

	http://metadata.ietf.org/urn:ietf:rfc:6924

at some future point in time.

Bonus points if something like this also works for

	=
http://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html401=
-19991224.xml

etc.

Gr=FC=DFe, Carsten


From nobody Thu May 22 10:33:15 2014
Return-Path: <mcr@sandelman.ca>
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 1C7A61A0248 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 10:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.942
X-Spam-Level: 
X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 FypkFgwB07Vg for <urn@ietfa.amsl.com>; Thu, 22 May 2014 10:27:05 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F61F1A0238 for <urn@ietf.org>; Thu, 22 May 2014 10:27:05 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D9CF320011; Thu, 22 May 2014 13:29:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 39F9D63B0B; Thu, 22 May 2014 13:26:58 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 23AEE63B0A; Thu, 22 May 2014 13:26:58 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org, SM <sm@resistor.net>, Barry Leiba <barryleiba@computer.org>, Carsten Bormann <cabo@tzi.org>, Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <F3650CE869694591A671E9BA@JCK-EEE10>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 22 May 2014 13:26:58 -0400
Message-ID: <21546.1400779618@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/48nh42fJp9f69eby_5-Ese5KJSQ
X-Mailman-Approved-At: Thu, 22 May 2014 10:33:03 -0700
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 17:27:08 -0000

--=-=-=


On Thursday, 22 May, 2014 12:09 -0400 Barry Leiba <barryleiba@computer.org> wrote:
barry> URNs are names, not locators.  They aren't meant to be
barry> "resolvable" in the sense that, say, an http URI is.

agreed, and this is why they are so useful a thing to put into
your .xml document;  I don't care where the data comes from,
I just want it, and if it can come from my local hard disk, even better...

barry> How you *find* documents, given their names, is well out of
barry> the scope of naming them.

John C Klensin <john-ietf@jck.com> wrote:
    > Fortunately or unfortunately, the interplay between assorted
    > URN, URI, and DDDS documents provides a solid basis for claiming
    > that URNs can be bound to resolution services as well as just
    > names.  So, without looking up the NID spec for urn:ietf:rfc, it
    > could either be "just a name" or be bound to a resolution
    > service that would, in turn, be able to provide a locator
    > associated with that name.  So, although it should have been
    > stated differently if one being very precise, SM's question is
    > reasonable.

I know that there are mechanisms... (reads... ) rfc3401, etc.
which would let one map urn:ietf to something which might be
widely mirrored.
Why aren't we using them?

I think it is because:
  1) no client code which xml2rfc could easly leverage.
  2) nobody is running the right urn.arpa. DNS system for it,
  and the system(s) it would point to.  Possibly because the software
  to serve that does not exist.  (I don't know. I suspect it's just
  DNS, but, I didn't read past abstracts...)

i.e. lack of running code.  Maybe there is code, but maybe it's not
     deployed.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU34zX4CLcPvd0N1lAQL3bQf+O3HU5vyqZCMf6j76S+yxAvI38x9QOTts
7YRWCZQUSsg0OARf6uSyiMJLyzSV7yYK62yTPzvQk4L+Q3S0AsrubnjGY56Qx5WR
TanNgrEnLifzN4FNJmmX1h0Yk1xFvs2bH+NkI8hJrLeKa452q9kE+KMUPDQWTSN0
YjVHc8S4Q04UKL/UmP7RRXnhtKcRe343KZ+Qzh6ekUr2ov85OmVRsj5XkkJJ/Xfp
/99afXnZoW04zrpyGRjpIYVQn+nINoRsVaQMu/EupFlGC0uZ8k8xS6RvekPdoMoi
lxsKzlFnRSbmb9MeVbJNHvpERZoaVEaXB4zUOfTkAg7DwCmI6nCjjw==
=5K8X
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu May 22 11:12:04 2014
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 08E0D1A0271 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 11:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 TV5_NMdjMMxO for <urn@ietfa.amsl.com>; Thu, 22 May 2014 11:12:00 -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 575CF1A0248 for <urn@ietf.org>; Thu, 22 May 2014 11:12:00 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WnXSS-000EuN-Ox; Thu, 22 May 2014 14:11:13 -0400
Date: Thu, 22 May 2014 14:11:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>, Barry Leiba <barryleiba@computer.org>
Message-ID: <4498C573F29B262695660341@JCK-EEE10>
In-Reply-To: <D9E19C80-7E38-4055-A7BD-5F7F45211F41@tzi.org>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <D9E19C80-7E38-4055-A7BD-5F7F45211F41@tzi.org>
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: ::1
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/CBqSjXRzv9Cnpx8kJLYMq58CVyw
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, urn@ietf.org, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is	down)
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, 22 May 2014 18:12:02 -0000

--On Thursday, 22 May, 2014 19:10 +0200 Carsten Bormann
<cabo@tzi.org> wrote:

> On 22 May 2014, at 18:09, Barry Leiba
> <barryleiba@computer.org> wrote:
>=20
>> "urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely =
and
>> persistently identifies it.
>>=20
>> The following are all locators that will find the document
>> that URN names: [=E2=80=A6]
>=20
>=20
> Actually, for RFC production we are interested in metadata
> about this RFC, as we would find it in
>=20
> 	http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
> .6924.xml
>...

Folks, for those who are actually interested in URN rather than
using this list to complain about a perceived IETF operational
problem, this actually illustrates a point that Juha (and, to
some extent, myself) have been trying to make.

   urn:ietf:rfc:6924

is, as Barry says, a name for RFC 6924, an object that, as far
as the URN specs are concerned, and that, in principle, may or
may not be retrievable over the Internet.    RFC 6925 may have
other names.  It may have a location.  And it may have
descriptive information such as a bibliography entry.  The
latter may, in turn, be available in multiple forms: RFC plain
text, ALS, bibtex, xml2rfc, etc.

Similarly a hypothetical=20
   urn:duck:johns-duck-33
may be a name with no other properties or at may be associated
with a location algorithm or locator (probably a different type
than an RFC), and assorted additional information that one might
want without wanting the duck itself: length, weight, age, color
scheme, whether it quacks when squeezed, whether it is a live
duck, a recently-alive duck, or a rubber ducky, etc.  I'm pretty
sure that it won't have bibliographic information, but one can
never know for sure (e.g., there is no International Standard
Duck Number, at least as far as I know).

Those properties -- what information is available about the
URN-named object and how that information is identified -- have
to be part of NID registration (perhaps by reference).  Unless
we aspire to a Universal Digital and Non-Digital Description
Language (if anyone does, enjoy yourself and please arrange for
a report to the IETF when you emerge victorious from the rat
hole), there is simply no other place to put it.

But, even for RFCs, Michael wants to get the document associated
with the urn:ietf:rfc:6924 name (or a locator for it) and
Carsten wants a bibliographic entry in a particular format (or a
locator for that).  That is at least five separate cases for a
relatively simple case:

  name-in-itself
  copy of RFC wanted
  locator for RFC wanted (one or several- another distinction)
  copy of xml2rfc-formatted bibliographic entry
  locator for that entry

That implies that you can't just say=20
   urn:ietf:rfc:6924

because, at least absent information in the NID registration,
that is just the name.  One decision we need to make is whether
it should _always_ be just the name because 2141 is less than
clear as illustrated by earlier messages in this thread.

But, if you want that other stuff, you have to be able to
specify which stuff you are looking for.  2141 syntax is simply
not adequate.  One could extend it with the query syntax of RFC
3986 but it is not clear whether the implicit semantics for URI
queries are really appropriate to a "this is the information
associated with that name which I need" specification,
especially if there are NIDs that also need things more similar
to a traditional query (such as something that should be passed,
intact, to a locator.  If both need to be specified, we either
end up violating or overconstraining 3986, or we develop
something complex and nested that will turn URNs (and us) into a
joke, or a take a URN path that is different from the Generic
URI one.  =20

That is precisely what the "URNs are not URIs" effort is about.

     john



From nobody Thu May 22 11:27:22 2014
Return-Path: <michael@refactored-networks.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 C6C5E1A02B6 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 11:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 zRMXFhVHdBqU for <urn@ietfa.amsl.com>; Thu, 22 May 2014 11:27:19 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03D1A02B8 for <urn@ietf.org>; Thu, 22 May 2014 11:27:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3DFE740944E; Thu, 22 May 2014 13:27:02 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPTpyUQLW5dH; Thu, 22 May 2014 13:27:02 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1EA80409498; Thu, 22 May 2014 13:27:02 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 09669409497; Thu, 22 May 2014 13:27:02 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4Sr0kTTEmO2j; Thu, 22 May 2014 13:27:01 -0500 (CDT)
Received: from [192.168.0.100] (50-199-114-66-static.hfc.comcastbusiness.net [50.199.114.66]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 701DD40944E; Thu, 22 May 2014 13:27:00 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Mealling <michael@refactored-networks.com>
In-Reply-To: <WM!e63853fb5e6b0e32f2c67ca27fc83cfde0f7e5f1ac2e807666ef1e30bc903bbb271aa6e4fffae952f94650c07729e8d3!@asav-1.01.com>
Date: Thu, 22 May 2014 14:26:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <84AC852A-E40D-45E4-86AC-ADC276CB77D6@refactored-networks.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <21546.1400779618@sandelman.ca> <WM!e63853fb5e6b0e32f2c67ca27fc83cfde0f7e5f1ac2e807666ef1e30bc903bbb271aa6e4fffae952f94650c07729e8d3!@asav-1.01.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/K2h0_ozx4KM7gM6OkOvKg72DN4U
Cc: Barry Leiba <barryleiba@computer.org>, Bob Hinden <bob.hinden@gmail.com>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 18:27:21 -0000

On May 22, 2014, at 1:26 PM, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:
>  2) nobody is running the right urn.arpa. DNS system for it,
>  and the system(s) it would point to.  Possibly because the software
>  to serve that does not exist.  (I don't know. I suspect it's just
>  DNS, but, I didn't read past abstracts...)

All modern DNS servers support the required records so someone just =
needs to specify what the records hold and put them into the zone. =
Several such records already exist...

-MM


Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling




From nobody Thu May 22 14:52:47 2014
Return-Path: <sm@resistor.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 0E5511A037F for <urn@ietfa.amsl.com>; Thu, 22 May 2014 14:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 QttRo9oF3kKy for <urn@ietfa.amsl.com>; Thu, 22 May 2014 14:52:44 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F29AF1A037E for <urn@ietf.org>; Thu, 22 May 2014 14:52:43 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4MLqJXN002323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 14:52:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400795550; bh=wIt4GcZvD5ojKIe0pVCk/eLncWrD/PQTWw9tMfEJNHM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eowVWEO7hT5NGAMYF77JCGiEFbJsTtG0pUioImEqV78e9YGVVUw9BrcG7Zir019rl qB6XIVe7qgK8uBa8rlpKg0cU+W0peOL34f5C0cu/fLffEGm9pmmTqs1UpWcVQ9lqho PufLNEUriQ+6u5riFE2il/4q7OEQA1JdenOd5MXo=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1400795550; i=@resistor.net; bh=wIt4GcZvD5ojKIe0pVCk/eLncWrD/PQTWw9tMfEJNHM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dCfgLATrLi1vlYX/NBbXb1PUTxRUSZHvDomHb+7KChR83wrND29TVtGNb7BH0RAdX C/0Zw+4SOw2DvgKOFGTb4RxZLws5aVdIFzJaVj6IQV3FHvYzZIb0h6iB5fGp+6qDRA GKLr2d4rOJtJfyKLlERNf+BPMJ0XyHj7JjzUbqJ4=
Message-Id: <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 22 May 2014 14:49:54 -0700
To: Barry Leiba <barryleiba@computer.org>, John C Klensin <john-ietf@jck.com>,  Julian Reschke <julian.reschke@gmx.de>
From: SM <sm@resistor.net>
In-Reply-To: <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.g mail.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Iwp-p-EesVSgLo7MT-SYrvFKth8
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 21:52:45 -0000

Hi Barry, John, Julian,
At 09:09 22-05-2014, Barry Leiba wrote:
>I don't understand:
>URNs are names, not locators.  They aren't meant to be "resolvable" in
>the sense that, say, an http URI is.

Agreed.

>"urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely and
>persistently identifies it.

The short answer is yes.

>The following are all locators that will find the document that URN names:
>
>http://datatracker.ietf.org/doc/rfc6924/
>http://tools.ietf.org/html/rfc6924
>http://tools.ietf.org/rfc/rfc6924.txt
>http://tools.ietf.org/pdf/rfc6924
>http://www.rfc-editor.org/rfc/rfc6924.txt
>http://www.rfc-editor.org/pdfrfc/rfc6924.txt.pdf
>
>How you *find* documents, given their names, is well out of the scope
>of naming them.

The discussion (on other IETF mailing lists) was about having a 
mechanism to resolve the name.

At 09:42 22-05-2014, John C Klensin wrote:
>Fortunately or unfortunately, the interplay between assorted
>URN, URI, and DDDS documents provides a solid basis for claiming
>that URNs can be bound to resolution services as well as just
>names.  So, without looking up the NID spec for urn:ietf:rfc, it
>could either be "just a name" or be bound to a resolution
>service that would, in turn, be able to provide a locator
>associated with that name.  So, although it should have been
>stated differently if one being very precise, SM's question is
>reasonable.

Apologies for the ambiguous question.

Yes, what I was thinking about is passing "urn:ietf:rfc:6924" to a 
resolution service which would provide a locator.  The locator can 
change in future.  That does not affect the name.

At 09:09 22-05-2014, Julian Reschke wrote:
>What problem are we solving by having a resolver for these URNs?

The problem is how do I use "urn:ietf:rfc:6924"?  For example, can I 
use "urn:ietf:rfc:6924" instead of http://www.rfc-editor.org/rfc/rfc6924.txt?

Regards,
-sm  


From nobody Thu May 22 15:01:03 2014
Return-Path: <barryleiba@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 9F8A71A039A for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 yVD2AGfPC7-i for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:01:00 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715C01A0397 for <urn@ietf.org>; Thu, 22 May 2014 15:01:00 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so6621064qcv.5 for <urn@ietf.org>; Thu, 22 May 2014 15:00:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ix5zD6tBE3qNCzf5dDRma+T0JQpC2HZn2kXKney3+vk=; b=eKSR6/tEhb53nHjc+5QkAAnTNMWirkKOzrstiTBUPq0P8OvRbCm+yw8NBMRTJGU3eO OWWC4XfymVWW/BsDSlxzr7s3XFtWYm9zXKA3IIWDYtLK3b2qTNRuVyy21W/0RNQt0T0O 1VGfBEiTwnfkm+Yns/5rbfwJzDKuXK6xaukwyjDQWDGFAExT1orDkZoQ7E3f2qorIYw2 Li3X0JWIyysUTFmihu1ER27pUhFWdCDgMxtDhsvsKpIXTjLENSIfUtNKlZFrJkp6vge7 +WkndrgbMUC+n/bV/5Gv5lD71a8MmJ4wVFTPrMYSom+uf/lr4zfiGnEOK+po6Dgu0ubR mOLA==
MIME-Version: 1.0
X-Received: by 10.140.26.179 with SMTP id 48mr661066qgv.51.1400796058624; Thu, 22 May 2014 15:00:58 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.99.1 with HTTP; Thu, 22 May 2014 15:00:58 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net>
Date: Thu, 22 May 2014 18:00:58 -0400
X-Google-Sender-Auth: 5shcYRNBjHenP_DFT4iI2s_bOEw
Message-ID: <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: SM <sm@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/XV7-zwPXZONQkF0Fa69npZBfgbo
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, "urn@ietf.org" <urn@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 22:01:01 -0000

> The problem is how do I use "urn:ietf:rfc:6924"?  For example, can I use
> "urn:ietf:rfc:6924" instead of http://www.rfc-editor.org/rfc/rfc6924.txt?

The answer depends upon what you want to use it for.  Mostly, the
thing that uses it has to know how to resolve it.

So, for instance, if xml2rfc were to accept the RFC (and ID, and BCP,
and STD) URNs, then it could turn them into proper references, which
is what xml2rfc needs them for.

Putting the URN into the search field of the datatracker would have a
different result, but one that's equally useful in that context.

Barry


From nobody Thu May 22 15:36:59 2014
Return-Path: <sm@resistor.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 B14451A0226 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 amfHaZei4gOg for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:36:55 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBDF1A01C6 for <urn@ietf.org>; Thu, 22 May 2014 15:36:55 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4MMaUJZ021412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 15:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400798199; bh=Fel9+/9ON8Ct5qHQcU/3rN0fWdmqCcawzmxSeU0jr/4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FvGqAzv6VZluGurMAtd8J4zMjSDZXagXepMsru4XHk3S9CQ6f95Z7OtPMRHHcr+zn xNcvVlY6VpjmKWZkJcsWR4QPR34d07Y2BRhLl2ZTeV5AKzyEqzrJdXBLsl/EsXP9+5 +eRDNynsZtLx55yZPMX1WyIbZ3AmVg7PMcLOLHa4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1400798199; i=@resistor.net; bh=Fel9+/9ON8Ct5qHQcU/3rN0fWdmqCcawzmxSeU0jr/4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Vol9nAGO+PmNyfjznbeQM1zSZXyJnmf/wCOfj38DhzIewJaAoJ0BdpXvbXE1KosnO g67ZxlC7bzVYdFNewi78kDTvVAaw4rGe0QA3V+V0X4QwOdoK/dN1PolCaUH0vs53lO +u3yATGRRUvWrXB77NDCZg7iBUC5/rdexQLKJdoU=
Message-Id: <6.2.5.6.2.20140522151036.0c032870@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 22 May 2014 15:36:07 -0700
To: Barry Leiba <barryleiba@computer.org>
From: SM <sm@resistor.net>
In-Reply-To: <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.g mail.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3ej7LR1ELxrWTygZ4Ahsr4ZkUyQ
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 22:36:57 -0000

Hi Barry,
At 15:00 22-05-2014, Barry Leiba wrote:
>The answer depends upon what you want to use it for.  Mostly, the
>thing that uses it has to know how to resolve it.
>
>So, for instance, if xml2rfc were to accept the RFC (and ID, and BCP,
>and STD) URNs, then it could turn them into proper references, which
>is what xml2rfc needs them for.
>
>Putting the URN into the search field of the datatracker would have a
>different result, but one that's equally useful in that context.

My understanding of the above is:

   (i)  I can use a name in various ways.

   (ii) The result is dependent on the resolution process.

One issue, unrelated to (i) and (ii), is that the name (urn:ietf:rfc 
...) does not identify one thing.  I can get a RFC as .txt or .pdf 
(different formats) or I can get metadata about the RFC.

Regards,
-sm 


From nobody Thu May 22 15:47:59 2014
Return-Path: <stpeter@stpeter.im>
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 4B6501A02A3 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 Fibhj6MF50hj for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:47:42 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D54841A0226 for <urn@ietf.org>; Thu, 22 May 2014 15:47:42 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4332B40CFC; Thu, 22 May 2014 16:47:34 -0600 (MDT)
Message-ID: <537E7E86.4040400@stpeter.im>
Date: Thu, 22 May 2014 16:47:34 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>, SM <sm@resistor.net>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com>
In-Reply-To: <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/v5cj_BsBD-Cwy08v7-L1xthSkyU
Cc: Julian Reschke <julian.reschke@gmx.de>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] urn:ietf:rfc
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, 22 May 2014 22:47:46 -0000

On 5/22/14, 4:00 PM, Barry Leiba wrote:
>> The problem is how do I use "urn:ietf:rfc:6924"?
>
> The answer depends upon what you want to use it for.

Just FYI, in the XMPP world, we have an example of one way to use it. In 
our specification of the ICE-UDP transport method in our Jingle 
technology for establishing media sessions, we use "urn:ietf:rfc:3264" 
as an identifier for offer/answer mode (i.e., not trickle-ICE), which is 
defined in RFC 3264...

http://xmpp.org/extensions/xep-0176.html#support-sdp

That is, we're referring to "the feature defined in RFC 3264", and we 
don't care about the physical location of the specification itself.

But I realize that's not what folks are trying to do in the thread that 
SM mentioned.

Peter


From nobody Thu May 22 15:58:56 2014
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 D25DD1A017D for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 s9xGHZznkvL3 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 15:58:53 -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 63A2B1A0226 for <urn@ietf.org>; Thu, 22 May 2014 15:58:53 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Wnbw0-000FQp-PL; Thu, 22 May 2014 18:58:01 -0400
Date: Thu, 22 May 2014 18:58:34 -0400
From: John C Klensin <john-ietf@jck.com>
To: SM <sm@resistor.net>, Barry Leiba <barryleiba@computer.org>
Message-ID: <24EDF4DFDAD9CD86E342D3C2@JCK-EEE10>
In-Reply-To: <6.2.5.6.2.20140522151036.0c032870@resistor.net>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <6.2.5.6.2.20140522151036.0c032870@resistor.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: ::1
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/P4C5Bi4RYzqWM1nBc0hgG7pPG34
Cc: Julian Reschke <julian.reschke@gmx.de>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 22 May 2014 22:58:55 -0000

--On Thursday, 22 May, 2014 15:36 -0700 SM <sm@resistor.net>
wrote:

> My understanding of the above is:
> 
>    (i)  I can use a name in various ways.
> 
>    (ii) The result is dependent on the resolution process.
> 
> One issue, unrelated to (i) and (ii), is that the name
> (urn:ietf:rfc ...) does not identify one thing.  I can get a
> RFC as .txt or .pdf (different formats) or I can get metadata
> about the RFC.

I try to use the term "metadata" in these discussions because
the term has been so much overused in different ways that it has
become a synonym for "hand waving".  But the above can
reasonably include

* a bibliographic reference to the RFC (potentially in different
forms)
* a question about the forms in which the bibliographic
reference can be obtained
* locators for at least the first of these and maybe the second.
   --plus--
* the RFC in various forms
* locators for those forms
* a question about what forms are available.

Note that some of these are requests for the object, others are
requests for information about how to find the object, and still
others are requests for specific information about the object
(possibly with additional indirection).

Any or all of them can be associated with the name and what is
very loosely called a resolution service -- loosely because some
of the above might ultimately call for different resolution
services, possibly redirected through the initial one.  In
particular, if one can figure out what "metadata" means in terms
of its differentiating properties, the resolution service for
the object and the resolution service for object metadata might
be different.  And _that_ is another reason why some of us are
concerned about the limitations of the Generic URI syntax.

For a specific URN type (NID) all of the above must be bound to
the NID registration/definition itself in some way unless we
want to go into the universal data dictionary business.

See my recent, longer, note for a slightly different take on
this.

     john




From nobody Thu May 22 16:40:42 2014
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 DA7DB1A0280 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 16:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level: 
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 fwkjj0Cr58_n for <urn@ietfa.amsl.com>; Thu, 22 May 2014 16:40:38 -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 C572D1A0295 for <urn@ietf.org>; Thu, 22 May 2014 16:40:35 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WncaL-000FVg-Ab; Thu, 22 May 2014 19:39:41 -0400
Date: Thu, 22 May 2014 19:40:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, Barry Leiba <barryleiba@computer.org>, SM <sm@resistor.net>
Message-ID: <3E8CB876A388DD8352A04912@JCK-EEE10>
In-Reply-To: <537E7E86.4040400@stpeter.im>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <537E7E86.4040400@stpeter.im>
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: ::1
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/gJQy3cL40CMK04Y5wRGbcI-rUd8
Cc: Julian Reschke <julian.reschke@gmx.de>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: [urn] URNs, permanence, resolution, and indirection/abstraction (was: Re:  urn:ietf:rfc)
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, 22 May 2014 23:40:40 -0000

(Changing subject line, which should have been done some time
ago-- this really isn't about RFC URNs except as a handy example)

--On Thursday, 22 May, 2014 16:47 -0600 Peter Saint-Andre
<stpeter@stpeter.im> wrote:

> On 5/22/14, 4:00 PM, Barry Leiba wrote:
>>> The problem is how do I use "urn:ietf:rfc:6924"?
>> 
>> The answer depends upon what you want to use it for.
> 
> Just FYI, in the XMPP world, we have an example of one way to
> use it. In our specification of the ICE-UDP transport method
> in our Jingle technology for establishing media sessions, we
> use "urn:ietf:rfc:3264" as an identifier for offer/answer mode
> (i.e., not trickle-ICE), which is defined in RFC 3264...
> 
> http://xmpp.org/extensions/xep-0176.html#support-sdp
> 
> That is, we're referring to "the feature defined in RFC 3264",
> and we don't care about the physical location of the
> specification itself.
> 
> But I realize that's not what folks are trying to do in the
> thread that SM mentioned.

Actually, Peter, this is very helpful because it illustrates
why, at least IMO, Barry and those folks aren't communicating.

There are three ways to get from a URN to one of more resolution
services (for those URNs that need or have such services and
whatever, generically, that means).  One is to bind the set of
things that can be produced by a resolution process to the
resolution mechanisms in using protocol definition itself.  That
is what you describe above.  If an XMPP application encounters
an urn:ietf:rfc URN, it uses that information as an indicator
and doesn't, in the traditional sense, resolve it at all.

A second is to bind to an actual resolution mechanism (or
task-specific set of them) in the NID definition or something it
points to, so that definition would say "if you want the RFC
text in PDF form, construct a URL as follows" and "if you want
an XML2RFC bibliographic reference for the RFC, construct a
URL..." and so on, for a long list.  That list might or might
not include a note about how XMPP uses the URN, e.g., "name only
as indicator".   For those old enough to remember, if we still
had "How to obtain RFCs" around and considered it normative, the
NID definition might incorporate it by reference for some of
that information.

Or, in the grand tradition of Computer Science and Internet
Engineering, one could introduce another layer of indirection.
One might want to do that for many reasons, but one would be
that elements of the resolution-location process might not be
stable.  RFCs are not a particularly good example because, if
rfc-editor.org and ietf.org aren't around and willing to keep
the links stable, maybe no one else cares.  Or not.  But suppose
we had a universal dodo identifier based on the International
Dodo Registry:

   urn:dodo:32

Now that raises all of the issues a few of us have been
discussing.   The URN itself provides information: Dodo 32 is
presumably a different dodo than Dodo 47.   But one can want to
locate or obtain Dodo 32, one can want information about it,
such as its weight or state of health (probably pretty
consistent for dodos), and so on and a way is needed to talk
about that different stuff.  More important, if the Dodo
Registry were, say, at Oxford University, one might want some
level of indirection in case Oxford decided to transfer the
registry elsewhere or to close its institutional doors (this is
one place where the difference between tens of years and tens of
centuries becomes important).  Our typical way to way to deal
with that would be to build the constructed URL template as
Method://international-dodo-registry.org/?dodo-number=32> but
suppose one's concerns about permanence _for the particular NID_
was such that you wouldn't want to trust in the continued
existence of the DNS or that of the ORG TLD?  That is the job
URN.ARPA was intended to serve, so that dodo.urn.arpa would
provide a pointer to where the template information was at any
given time and/or appropriate DDDS material.  That would work
well for concerns about ORG, but not for concerns about the ARPA
TLD or the DNS.  For the latter, one would want to abstract
URN.ARPA too, such that there was a single, URN-specific (not
NID-specific) definition of where to look for the information
that is now (optionally) stored at <nid>.urn.arpa.  If the DNS
imploded, that document could be updated with the new "how to
find the tree" information and appropriate chronology retained. 

This is obviously turtles all the way down and getting the right
stopping rules requires fairly serious thought.  But, if one
wants to think about "permanence", one has to do that work...
and then the definers of each NID decide how permanent it needs
to be in terms of levels of abstraction and indirection such at
those outlined above.
    
     john


From nobody Thu May 22 17:01:05 2014
Return-Path: <sm@resistor.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 C94971A02A3 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 17:01:02 -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] 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 eHHHvei48yN0 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 17:00:56 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D82AE1A02B5 for <urn@ietf.org>; Thu, 22 May 2014 17:00:56 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4N00kk6017356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 17:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400803252; bh=T9lG/kRMhPIua6DTJA3IovyUUuHLGayd4lxMF37+tRM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OQE1H8T/XBEu52xfDEa9Y/Y3jF1aSnaNnw3eNYfXuZ7IOZ8TX2xDZ7bCLYXAijBep 2eSi9cLoLGLzb4Myp3tfC/3a1ha48GN7OEl+7TEM+e0djiuPTcT41qsk5B8U/n+Pc4 2Fadm5SU1NPLnTmMtNU1ftEl5acNZI/3Up7Nme8Y=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1400803252; i=@resistor.net; bh=T9lG/kRMhPIua6DTJA3IovyUUuHLGayd4lxMF37+tRM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xgAQuEpTfHh1x23+sd9YsVLU/cIkYOdNkDZ9Cdnl5jvLrqiNSxuRFfQVsxc1OYGCp qw5cxvzws5F2QRZL99kEadydW5ra67HsY4DXPJa+ORIM1h2IjOLpliflRFlfyBQ8/K E0nY9LkoEuvI8Lf2qv/FjHGOBC/yS++hlmXn/ATA=
Message-Id: <6.2.5.6.2.20140522161338.0ca615d8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 22 May 2014 16:59:46 -0700
To: John C Klensin <john-ietf@jck.com>
From: SM <sm@resistor.net>
In-Reply-To: <24EDF4DFDAD9CD86E342D3C2@JCK-EEE10>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <6.2.5.6.2.20140522151036.0c032870@resistor.net> <24EDF4DFDAD9CD86E342D3C2@JCK-EEE10>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vhQqHNI5v7k_troyj6UGx32uoyo
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)
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, 23 May 2014 00:01:03 -0000

Hi John,
At 15:58 22-05-2014, John C Klensin wrote:
>Any or all of them can be associated with the name and what is
>very loosely called a resolution service -- loosely because some
>of the above might ultimately call for different resolution
>services, possibly redirected through the initial one.  In
>particular, if one can figure out what "metadata" means in terms
>of its differentiating properties, the resolution service for
>the object and the resolution service for object metadata might
>be different.  And _that_ is another reason why some of us are
>concerned about the limitations of the Generic URI syntax.

A resolution service is not needed in Peter's case.  I mentioned this 
as one of different uses of a name.

I am okay with the idea of different resolution services.  One point 
in your message is the initial resolution service.  Would that be 
identified by the entity managing the namespace?

>See my recent, longer, note for a slightly different take on
>this.

Ok.

Regards,
-sm 


From nobody Thu May 22 22:55:01 2014
Return-Path: <julian.reschke@gmx.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 218AF1A0385 for <urn@ietfa.amsl.com>; Thu, 22 May 2014 22:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mAoBjgkMoxfE for <urn@ietfa.amsl.com>; Thu, 22 May 2014 22:54:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DD91A0383 for <urn@ietf.org>; Thu, 22 May 2014 22:54:57 -0700 (PDT)
Received: from [192.168.2.117] ([93.217.121.75]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MO7ee-1WiEmL48ns-005cUh; Fri, 23 May 2014 07:54:02 +0200
Message-ID: <537EE271.1070606@gmx.de>
Date: Fri, 23 May 2014 07:53:53 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: SM <sm@resistor.net>, Barry Leiba <barryleiba@computer.org>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <6.2.5.6.2.20140522151036.0c032870@resistor.net>
In-Reply-To: <6.2.5.6.2.20140522151036.0c032870@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:z9sHcinXRv2gM4gxuGHhnOZHeCWIIGj5RtO5CsPcQ9kzbTT36sq aJx0PgBq9shlSTx2g3hnRFiXnU1bwDrCq3bdAWOc1vRfbhngeXG/crShPc1HbeF/NBLcCJT z4kTz0lE9ph+DT6aiYkSEYtzlwAlbuweYxNgOAs0sM9p4xKv0vU7HGRPiWxWUPHpM0lVSgp sjgLmrWXt3QIqrIj2uCIg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-f6se5ozOmID3yv58JVIX-3yxFI
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 23 May 2014 05:55:00 -0000

On 2014-05-23 00:36, SM wrote:
> Hi Barry,
> At 15:00 22-05-2014, Barry Leiba wrote:
>> The answer depends upon what you want to use it for.  Mostly, the
>> thing that uses it has to know how to resolve it.
>>
>> So, for instance, if xml2rfc were to accept the RFC (and ID, and BCP,
>> and STD) URNs, then it could turn them into proper references, which
>> is what xml2rfc needs them for.
>>
>> Putting the URN into the search field of the datatracker would have a
>> different result, but one that's equally useful in that context.
>
> My understanding of the above is:
>
>    (i)  I can use a name in various ways.

Yes.

>    (ii) The result is dependent on the resolution process.

Yes.

> One issue, unrelated to (i) and (ii), is that the name (urn:ietf:rfc
> ...) does not identify one thing.  I can get a RFC as .txt or .pdf
> (different formats) or I can get metadata about the RFC.

So assuming there *was* a resolution process for urn:ietf:rfc. How would 
it know whether you're looking for the document itself (and in which 
format), or about metadata, or a bib reference?

Concretely, how would having that resolution process solve the problem 
that started the discussion?

Best regards, Julian


From nobody Fri May 23 01:04:38 2014
Return-Path: <sm@resistor.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 144A11A03AD for <urn@ietfa.amsl.com>; Fri, 23 May 2014 01:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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 QJ74KnFLlvaN for <urn@ietfa.amsl.com>; Fri, 23 May 2014 01:04:37 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D381A03A7 for <urn@ietf.org>; Fri, 23 May 2014 01:04:37 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4N84DHW013230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 01:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400832263; bh=vgrGzel0X0aEoTk8Ka3mF0Mo5XzXumpavONV0PahzHo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ielqy2f5e1y5CQjmt3C6CXxfTj4kT+Q2UK2iTQhDTlou6N2iieto4gGUVYrMzaXzL /31n9C53LvFRe2pjFHlNwahJkdGXA/YePg17FQjD1JVSrP9t4eGDc7gvkwVadsWoHb ApmVl9aJYqWEW+aAVun69OkrN2q5AS7BGvehW6DA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1400832263; i=@resistor.net; bh=vgrGzel0X0aEoTk8Ka3mF0Mo5XzXumpavONV0PahzHo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0i396joSDhO9T0NuyJcNAcP8ZAQiadPf64zs47ydKfu9Aq6hLyszZwtZ8z5vLlERh WZZmYltGjXehJBtc8b7EeXuSbIrNvM6wD1ztEpYsRjreujqzdDaudu2TdbhW83eQGf d45cNdVXCc8iyMSlOJzorosnRBKkXskXecpMxgdc=
Message-Id: <6.2.5.6.2.20140522233618.0ea7ac50@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 23 May 2014 00:20:59 -0700
To: Julian Reschke <julian.reschke@gmx.de>, Barry Leiba <barryleiba@computer.org>
From: SM <sm@resistor.net>
In-Reply-To: <537EE271.1070606@gmx.de>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.com> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <6.2.5.6.2.20140522151036.0c032870@resistor.net> <537EE271.1070606@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Awj0Q7XkIDbQ2R1Li5SVMRLxWSw
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 23 May 2014 08:04:38 -0000

Hi Julian,
At 22:53 22-05-2014, Julian Reschke wrote:
>So assuming there *was* a resolution process for urn:ietf:rfc. How 
>would it know whether you're looking for the document itself (and in 
>which format), or about metadata, or a bib reference?

The resolution process would have to be able to provide the list of 
things for the name.  It won't know what I am looking for unless the 
name identified one thing only, e.g. the bib reference.

>Concretely, how would having that resolution process solve the 
>problem that started the discussion?

The problem was about using a URN to avoid location dependence.  What 
I would need is an index and the references or a resolution process 
which takes me to a reference.  The organization managing the 
namespace could provide me with information about the resolution 
process so that I can use urn:ietf:rfc.

Regards,
-sm 


From nobody Fri May 23 12:43:18 2014
Return-Path: <worley@ariadne.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 487E11A0297 for <urn@ietfa.amsl.com>; Fri, 23 May 2014 12:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFukMkRzTnhw for <urn@ietfa.amsl.com>; Fri, 23 May 2014 12:43:15 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 21A531A02AF for <urn@ietf.org>; Fri, 23 May 2014 12:43:15 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id 5XWA1o0040cZkys5CXjDEf; Fri, 23 May 2014 19:43:13 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta10.westchester.pa.mail.comcast.net with comcast id 5XjC1o00m1KKtkw3WXjDMx; Fri, 23 May 2014 19:43:13 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s4NJhCjc012273 for <urn@ietf.org>; Fri, 23 May 2014 15:43:12 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4NJhCCq012272; Fri, 23 May 2014 15:43:12 -0400
Date: Fri, 23 May 2014 15:43:12 -0400
Message-Id: <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: urn@ietf.org
In-reply-to: <F3650CE869694591A671E9BA@JCK-EEE10> (john-ietf@jck.com)
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400874193; bh=g5VhtmL1FQ/gqmGAeaHlY8bPtVszU4jiQ+G4iy/IA5o=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=JAbb2VAic4vcbCeNu8WADm6XvwRo7wK56ERjde7ofk8McDLZ7hqrvn34ITzA9ucdU 7CXJgmxan7LzCHgiYOC4Jk+KVBwy3+hydIJDndW9BpuCLiSJhfXP4SM1pw3Gv2W1Ac ehtNAP3o6AIMnYZriV0PaANSPvHSSSlUtfIYNBakYzCLvwCMBA4pBJpLbge/lYGhmh CR31WO6tRXW5Jz9okzmQTH5tp4gakfghxzUgv1xaYM1piLFZOrfJ26dbQOuO0xdPWW Qy1d7le1ZX0WVbulb33zDr8O+Ba90kBcGU2sYbChGS6omyke1uAUpl4cRj+f0M1EwQ AWX/epDHnmUHg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FPik0f0AI6W2FzDaLoeMK9Z_oOc
Subject: Re: [urn] urn:ietf:rfc
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, 23 May 2014 19:43:16 -0000

> From: John C Klensin <john-ietf@jck.com>

> Fortunately or unfortunately, the interplay between assorted
> URN, URI, and DDDS documents provides a solid basis for claiming
> that URNs can be bound to resolution services as well as just
> names.  So, without looking up the NID spec for urn:ietf:rfc, it
> could either be "just a name" or be bound to a resolution
> service that would, in turn, be able to provide a locator
> associated with that name.  So, although it should have been
> stated differently if one being very precise, SM's question is
> reasonable.
> 
> That interplay and its non-obvious side effects are another
> reason for separating URNs from the URI family, [...]


> From: Michael Richardson <mcr+ietf@sandelman.ca>

> I know that there are mechanisms... (reads... ) rfc3401, etc.
> which would let one map urn:ietf to something which might be
> widely mirrored.
> Why aren't we using them?
> 
> I think it is because:
>   1) no client code which xml2rfc could easly leverage.
>   2) nobody is running the right urn.arpa. DNS system for it,
>   and the system(s) it would point to.  Possibly because the software
>   to serve that does not exist.  (I don't know. I suspect it's just
>   DNS, but, I didn't read past abstracts...)
> 
> i.e. lack of running code.  Maybe there is code, but maybe it's not
>      deployed.

I think these two remarks can be extended:  As far as I can tell from
the DDDS documents, at a pont in the past it was expected (at least by
some substantial fraction of the community) that there would be an
overarching URN resolution system that would map all URN NIDs to
appropriate resolution services, and the resolution services would in
turn map the URNs into network resources (via URLs).

Clearly, this system hasn't been deployed, at least not for the
typical NID.  But its absence changes the philosophical basis of URNs:
They're still names, but it is no longer assumed that the things that
are named are network-accessible resources, which means that for many
purposes, URNs can no longer be used in locations where URLs are
needed.  Thus, the conceptual separation between URNs and URLs becomes
much larger than it was in earlier days.

One interesting question is *why* the DDDS hasn't been deployed.  It
may be impossible based on the information represented by URNs.  It
may be that there is no need to resolve most URNs.  Or it may be that
nobody has bothered implementing the software and setting up the
operational systems.  (Can't we put some graduate students on this?)

Dale


From nobody Sat May 24 14:41:15 2014
Return-Path: <john@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2571A0041 for <urn@ietfa.amsl.com>; Fri, 23 May 2014 13:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level: 
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 1cm4ePLZwHVH for <urn@ietfa.amsl.com>; Fri, 23 May 2014 13:16:58 -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 78FF91A0031 for <urn@ietf.org>; Fri, 23 May 2014 13:16:58 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1Wnvsz-000I5p-2F; Fri, 23 May 2014 16:16:13 -0400
Date: Fri, 23 May 2014 16:16:50 -0400
From: John C Klensin <john@jck.com>
To: "Dale R. Worley" <worley@ariadne.com>, urn@ietf.org
Message-ID: <41BF2367E6EBF9E081E9F860@[192.168.1.102]>
In-Reply-To: <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.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: ::1
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ZQCi4geBzhCrdP695xQiw40d5iU
X-Mailman-Approved-At: Sat, 24 May 2014 14:41:14 -0700
Subject: Re: [urn] urn:ietf:rfc
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, 23 May 2014 20:17:00 -0000

--On Friday, 23 May, 2014 15:43 -0400 "Dale R. Worley"
<worley@ariadne.com> wrote:

>> I think it is because:
>>   1) no client code which xml2rfc could easly leverage.
>>   2) nobody is running the right urn.arpa. DNS system for it,
>>   and the system(s) it would point to.  Possibly because the
>>   software to serve that does not exist.  (I don't know. I
>>   suspect it's just DNS, but, I didn't read past abstracts...)
>> 
>> i.e. lack of running code.  Maybe there is code, but maybe
>> it's not deployed.
> 
> I think these two remarks can be extended:  As far as I can
> tell from the DDDS documents, at a pont in the past it was
> expected (at least by some substantial fraction of the
> community) that there would be an overarching URN resolution
> system that would map all URN NIDs to appropriate resolution
> services, and the resolution services would in turn map the
> URNs into network resources (via URLs).
> 
> Clearly, this system hasn't been deployed, at least not for the
> typical NID.  But its absence changes the philosophical basis
> of URNs: They're still names, but it is no longer assumed that
> the things that are named are network-accessible resources,
> which means that for many purposes, URNs can no longer be used
> in locations where URLs are needed.  Thus, the conceptual
> separation between URNs and URLs becomes much larger than it
> was in earlier days.
> 
> One interesting question is *why* the DDDS hasn't been
> deployed.  It may be impossible based on the information
> represented by URNs.  It may be that there is no need to
> resolve most URNs.  Or it may be that nobody has bothered
> implementing the software and setting up the operational
> systems.  (Can't we put some graduate students on this?)

Dale,

I think this is an interesting analysis.  It stimulated an idea
I hadn't had before.

I'm pretty sure we always anticipated that some URNs would be
"pure names" --no resolution of any type anticipated, just,
maybe, comparisons.   But, even if that is right, it doesn't
change your argument very much.  Suppose we think of this whole
situation as at least partially a "levels of abstraction"
situation with

(1) locaters pointing more or less directly to network objects.
These basically involve no indirection.
(2) strings or identifiers that use a known, generic resolution
service to get to such locators.  One level of indirection.
(3) strings or identifiers that use an NID-specific resolution
mechanism (or more than one for different purposes) and that
need to specify that mechanism somewhere, perhaps through an
additional level of indirection, so there are typically one or
two levels of indirection.
(4) Pure names that aren't resolved, but might be compared
and/or used as flags or indicators.

The first group includes URLs.  Maybe everything in it is a URL.
DDDS is typical of the second and was certainly intended to be
the dominant, "standard", one.  The third is most of what my
recent note was talking about and includes such things as ISBN
and ISSN URNs.  The fourth group is pretty obvious, but we
should not forget it is out there -- and Peter's note reminds us
that that a single NID may be used, in different contexts, as
either a resolvable object (typically (3) but maybe (2)) and as
such "no resolution required or expected" names.

Especially given that breakdown, if anyone still believes that
DDDS == URN, they are pretty confused and, if participating in
this list, helping the rest of us achieve that state.   I
certainly don't read that equivalence into 2141.

Given that, I wonder whether, as a thought experiment, we should
investigate whether 
    DDDS:....
would be a useful and distinct alternative to 
    URN:nid:...

Thereby making clear that "DDDS" and "URN" are not synonyms and
separating case (2) from case (1) (the URLs) and case (3) and
(4) (the somewhat more abstracted names.   One could still have
a case (3) URN that used DDDS for some or all of its required
resolution or metadata retrieval functions, its registration
would just have to specify that.  By contrast, a name associated
with "DDDS:..." would presumably only require that the name be
registered, possibly along with a definition or explanation, but
that it was resolvable and how to do that would be
be completely obvious.

Does that help?
 best,
     john



From nobody Sat May 24 18:21:21 2014
Return-Path: <michael@refactored-networks.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 8F9A11A01A5 for <urn@ietfa.amsl.com>; Sat, 24 May 2014 18:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnDsqLrWJmaz for <urn@ietfa.amsl.com>; Sat, 24 May 2014 18:21:18 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C45181A00DD for <urn@ietf.org>; Sat, 24 May 2014 18:21:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6BC1B2953C9; Sat, 24 May 2014 20:21:16 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW83Vfny2OjG; Sat, 24 May 2014 20:21:16 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 49BC4296B34; Sat, 24 May 2014 20:21:16 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 33BC6295D84; Sat, 24 May 2014 20:21:16 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eTcX2WSiHwL8; Sat, 24 May 2014 20:21:16 -0500 (CDT)
Received: from [10.96.4.25] (unknown [216.53.137.131]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 574F52953C9; Sat, 24 May 2014 20:21:15 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Mealling <michael@refactored-networks.com>
In-Reply-To: <WM!388ddb5d9b06476d960741aafa89290ecebbd4bb2cec8bdf859c0a0fd9935209c777f3758120ad8d52c9f96424ee4def!@asav-1.01.com>
Date: Sat, 24 May 2014 21:21:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7384D3B-8F0C-4511-B0A8-8B59A2A51C8F@refactored-networks.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <WM!388ddb5d9b06476d960741aafa89290ecebbd4bb2cec8bdf859c0a0fd9935209c777f3758120ad8d52c9f96424ee4def!@asav-1.01.com>
To: John C Klensin <john@jck.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/r3ZFpwHU471oKxCQyRHZ6u30oog
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 25 May 2014 01:21:20 -0000

On May 23, 2014, at 4:16 PM, John C Klensin <john@jck.com> wrote:
> --On Friday, 23 May, 2014 15:43 -0400 "Dale R. Worley"
>>=20
>> One interesting question is *why* the DDDS hasn't been
>> deployed.  It may be impossible based on the information
>> represented by URNs.  It may be that there is no need to
>> resolve most URNs.  Or it may be that nobody has bothered
>> implementing the software and setting up the operational
>> systems.  (Can't we put some graduate students on this?)

The main reason at the time was that browsers had that code locked up. =
This was the time of Internet Explorer's dominance and everyone pretty =
much gave up on implementing anything in the browser to facilitate DDDS. =
We (I?) essentially failed Michael Porter's Five Forces test: each case =
where we planned on using DDDS there was an existing player that owned a =
piece of the namespace that prevented deployment: the telcos defeated =
ENUM and the browser vendors prevented any sane extensions to the =
browsers.=20

With the advent of a Javascript enabled browser world it would be fairly =
easy to implement as a JQuery plugin.=20

> I'm pretty sure we always anticipated that some URNs would be
> "pure names" --no resolution of any type anticipated, just,
> maybe, comparisons.   But, even if that is right, it doesn't
> change your argument very much.  Suppose we think of this whole
> situation as at least partially a "levels of abstraction"
> situation with
>=20

I always assumed that. Take the UUID namespace as an example. I think =
creating a UUID resolution service would be a fairly insane undertaking.

> (1) locaters pointing more or less directly to network objects.
> These basically involve no indirection.
> (2) strings or identifiers that use a known, generic resolution
> service to get to such locators.  One level of indirection.
> (3) strings or identifiers that use an NID-specific resolution
> mechanism (or more than one for different purposes) and that
> need to specify that mechanism somewhere, perhaps through an
> additional level of indirection, so there are typically one or
> two levels of indirection.
> (4) Pure names that aren't resolved, but might be compared
> and/or used as flags or indicators.
>=20
> The first group includes URLs.  Maybe everything in it is a URL.
> DDDS is typical of the second and was certainly intended to be
> the dominant, "standard", one.  The third is most of what my
> recent note was talking about and includes such things as ISBN
> and ISSN URNs.  The fourth group is pretty obvious, but we
> should not forget it is out there -- and Peter's note reminds us
> that that a single NID may be used, in different contexts, as
> either a resolvable object (typically (3) but maybe (2)) and as
> such "no resolution required or expected" names.
>=20
> Especially given that breakdown, if anyone still believes that
> DDDS =3D=3D URN, they are pretty confused and, if participating in
> this list, helping the rest of us achieve that state.   I
> certainly don't read that equivalence into 2141.

Correct. DDDS is a way of using DNS to discover syntax rules by encoding =
them into DNS. It has/had far more applicability in the ENUM world for =
decomposing telephone numbers.


-MM

Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling


From nobody Sun May 25 03:11:28 2014
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C171A0263 for <urn@ietfa.amsl.com>; Sun, 25 May 2014 03:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level: 
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 cWw2HsgROiE0 for <urn@ietfa.amsl.com>; Sun, 25 May 2014 03:11:24 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3961A025B for <urn@ietf.org>; Sun, 25 May 2014 03:11:22 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 93AF932E55E; Sun, 25 May 2014 19:11:19 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2ce6_883c_5049dbf0_c2a2_4c6a_b372_5a109ea4aa45; Sun, 25 May 2014 19:11:19 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9BF2EBF509; Sun, 25 May 2014 19:11:18 +0900 (JST)
Message-ID: <5381C1B9.9090300@it.aoyama.ac.jp>
Date: Sun, 25 May 2014 19:11:05 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Michael Mealling <michael@refactored-networks.com>,  John C Klensin <john@jck.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE86969459 1A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <WM!388ddb5d9b06476d960741aafa89290ecebbd4bb2cec8bdf859c0a0fd9935209c777f3758120ad8d52c9f96424ee4def!@asav-1.01.com> <B7384D3B-8F0C-4511-B0A8-8B59A2A51C8F@refactored-networks.com>
In-Reply-To: <B7384D3B-8F0C-4511-B0A8-8B59A2A51C8F@refactored-networks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/yyoWz7Q0LoystKgSzZ_Fkb709Ls
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 25 May 2014 10:11:26 -0000

On 2014/05/25 10:21, Michael Mealling wrote:

> The main reason at the time was that browsers had that code locked up. This was the time of Internet Explorer's dominance and everyone pretty much gave up on implementing anything in the browser to facilitate DDDS. We (I?) essentially failed Michael Porter's Five Forces test: each case where we planned on using DDDS there was an existing player that owned a piece of the namespace that prevented deployment: the telcos defeated ENUM and the browser vendors prevented any sane extensions to the browsers.
>
> With the advent of a Javascript enabled browser world it would be fairly easy to implement as a JQuery plugin.

With all these many Javascript hackers around, why hasn't anybody done 
this yet?

>> I'm pretty sure we always anticipated that some URNs would be
>> "pure names" --no resolution of any type anticipated, just,
>> maybe, comparisons.   But, even if that is right, it doesn't
>> change your argument very much.  Suppose we think of this whole
>> situation as at least partially a "levels of abstraction"
>> situation with
>>
>
> I always assumed that. Take the UUID namespace as an example. I think creating a UUID resolution service would be a fairly insane undertaking.

Well, in some sense there already is one. It's a combination of Google 
(or some other search engine) and probably some human intervention. But 
that's probably as good as it ever gets.
[And that's just another way to say that I agree with you that a good 
fully automatic UUID resolution service would be an insane undertaking.]

Regards,   Martin.


From nobody Tue May 27 12:16:23 2014
Return-Path: <worley@ariadne.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 C51C71A0664 for <urn@ietfa.amsl.com>; Tue, 27 May 2014 12:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 b5QYRwsygbSb for <urn@ietfa.amsl.com>; Tue, 27 May 2014 12:16:11 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2A1A0722 for <urn@ietf.org>; Tue, 27 May 2014 12:15:38 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id 74u01o0060ldTLk557FbYo; Tue, 27 May 2014 19:15:35 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta04.westchester.pa.mail.comcast.net with comcast id 77Fa1o0081KKtkw017FafG; Tue, 27 May 2014 19:15:35 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s4RJFXUD031149; Tue, 27 May 2014 15:15:33 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4RJFVfr031146; Tue, 27 May 2014 15:15:31 -0400
Date: Tue, 27 May 2014 15:15:31 -0400
Message-Id: <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: John C Klensin <john@jck.com>
In-reply-to: <41BF2367E6EBF9E081E9F860@[192.168.1.102]> (john@jck.com)
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401218135; bh=iszG0Ook5+RjARW8kRiRhXf5xa0uGW6+Vj0mxrc6ZNE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=tKR+5Fk85zZoedU/G10TIlqbEgNDH6a4ZTzBE14VbSXhQRSJN75ZLK2JEKpKLf+zt uFuDRT22txLKhrNQ3jfY9YyKdyAVPQhgaYLBn8DCIbMa8YRHLUvuPSA58pXZYqIHqy GUu1Zx2wMNF3gzon/e/AFOAYbHVtExsW1d9zJQZk5qtxLKfh1lyfnr72pEyw9V5ADB OC1PIoBl+5fC194uZqJUGXh+Y0WkIKdvUgXD5ZIWqFb2Yj1wvj0rWfxrPyKiGm9ZtV nFivHkuG1gayUSiFfKczTqGBjLBl9NCfMHW+69TgwkTM/9aRx3tFemIWMRkbAV9WLt n47Pw0q9qHRxQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/BJtCQvNzexbNFff7hXoLGr5eTX4
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 27 May 2014 19:16:13 -0000

> From: John C Klensin <john@jck.com>

> (1) locaters pointing more or less directly to network objects.
> These basically involve no indirection.
> (2) strings or identifiers that use a known, generic resolution
> service to get to such locators.  One level of indirection.
> (3) strings or identifiers that use an NID-specific resolution
> mechanism (or more than one for different purposes) and that
> need to specify that mechanism somewhere, perhaps through an
> additional level of indirection, so there are typically one or
> two levels of indirection.
> (4) Pure names that aren't resolved, but might be compared
> and/or used as flags or indicators.
> 
> The first group includes URLs.  Maybe everything in it is a URL.
> DDDS is typical of the second and was certainly intended to be
> the dominant, "standard", one.  The third is most of what my
> recent note was talking about and includes such things as ISBN
> and ISSN URNs.  The fourth group is pretty obvious, but we
> should not forget it is out there -- and Peter's note reminds us
> that that a single NID may be used, in different contexts, as
> either a resolvable object (typically (3) but maybe (2)) and as
> such "no resolution required or expected" names.

I think I agree with you, though I'd describe the spectrum in
different terms.  For instance, fetching a web page based on a URL
involves a tremendous amount of indirection (including not only DNS
but the routing table of every router along the path).  But in
practice, the required indirections are well-specified, and
conceptually we consider the *meaning* of the URL to be the *result*
of the resolution process (and/or the specified resolution actions
themselves).

A similar example is SIP URIs, which aren't called URLs, but have much
the same properties:  There is a rigidly specified resolution process,
and the meaning of the URI is still closely identified with the result
of the resolution process.  There is some difference, though, because
there are "address of record" URIs (like telco directory listings)
that are expected to be attached to individuals, organizations, and
the like, whose sociological meaning will change less quickly than the
identity of the SIP servers to which the URI routes.

But once we get to ISBN and ISSN, the meaning is much detached from
resolution.  In particular, there are assumed to be many different
ways of resolving the identifier (for various purposes), and no one of
them is expected to yield "the" meaning.

The extreme of this end of the spectrum are identifiers like the
urn:ietf:params URNs -- there is no particular network-accessible
resource involved, and no resolution process (in the ordinary sense)
at all.

An odd example is the Alert-Info URNs for SIP
(draft-ietf-salud-alert-info-urns), which tell phones how to announce
an incoming call (priority, internal/external source, etc.).  In that
case, there is a resolution algorithm, but it functions entirely
inside a phone, instructing how the phone should choose from among the
ringing signals that it is capable of generating which one to choose
(e.g., which information it should prioritize when it can't announce
all of the specified information).  So though the URN is tightly
identified with the resolution process, the resolution process does
not determine a network-accessible resource.

Dale


From nobody Tue May 27 12:59:35 2014
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 083B41A0768 for <urn@ietfa.amsl.com>; Tue, 27 May 2014 12:59:34 -0700 (PDT)
X-Quarantine-ID: <QhaGjvUk0C7p>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...Xdn28yaA@mail.gmail.com>\n  \n <CAK3OfOj7Zse[...]
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 QhaGjvUk0C7p for <urn@ietfa.amsl.com>; Tue, 27 May 2014 12:59:31 -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 124601A076C for <urn@ietf.org>; Tue, 27 May 2014 12:59:30 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WpNW3-0000Hy-H1; Tue, 27 May 2014 15:58:31 -0400
Date: Tue, 27 May 2014 15:59:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Dale R. Worley" <worley@ariadne.com>
Message-ID: <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com>
In-Reply-To: <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HWR6WUnvyKkfvx5BALGMlofLbT0
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 27 May 2014 19:59:34 -0000

--On Tuesday, May 27, 2014 15:15 -0400 "Dale R. Worley"
<worley@ariadne.com> wrote:

>> From: John C Klensin <john@jck.com>
> 
>> (1) locaters pointing more or less directly to network
>> objects. These basically involve no indirection.
>> (2) strings or identifiers that use a known, generic
>> resolution service to get to such locators.  One level of
>> indirection. (3) strings or identifiers that use an
>> NID-specific resolution mechanism (or more than one for
>> different purposes) and that need to specify that mechanism
>> somewhere, perhaps through an additional level of
>> indirection, so there are typically one or two levels of
>> indirection.
>> (4) Pure names that aren't resolved, but might be compared
>> and/or used as flags or indicators.
>> 
>> The first group includes URLs.  Maybe everything in it is a
>> URL. DDDS is typical of the second and was certainly intended
>> to be the dominant, "standard", one.  The third is most of
>> what my recent note was talking about and includes such
>> things as ISBN and ISSN URNs.  The fourth group is pretty
>> obvious, but we should not forget it is out there -- and
>> Peter's note reminds us that that a single NID may be used,
>> in different contexts, as either a resolvable object
>> (typically (3) but maybe (2)) and as such "no resolution
>> required or expected" names.
> 
> I think I agree with you, though I'd describe the spectrum in
> different terms.  For instance, fetching a web page based on a
> URL involves a tremendous amount of indirection (including not
> only DNS but the routing table of every router along the
> path).  But in practice, the required indirections are
> well-specified, and conceptually we consider the *meaning* of
> the URL to be the *result* of the resolution process (and/or
> the specified resolution actions themselves).

Right, although, at the same time, that "meaning" can change.
If http://flowers.example.com/ led today to a web page whose
first line was "the flowers that bloom in the spring", trying it
again next week might produce one (at the same well-specified
location/indirections) whose first line began "'Twas brillig,
and the slithy toves".   More on that below, but the distinction
is, I believe, very much where the "persistent identifier"
discussion begins.

> A similar example is SIP URIs, which aren't called URLs, but
> have much the same properties:  There is a rigidly specified
> resolution process, and the meaning of the URI is still
> closely identified with the result of the resolution process.
> There is some difference, though, because there are "address
> of record" URIs (like telco directory listings) that are
> expected to be attached to individuals, organizations, and the
> like, whose sociological meaning will change less quickly than
> the identity of the SIP servers to which the URI routes.

Right.  But, in parallel to the above, telco directory listings
are only temporarily bound to "individuals, organizations, and
the like".  The binding is a lot less temporary than it was in
the days before number portability and it certainly takes more
to change one than it does for the "owner" of
"flowers.example.com"  to change that hypothetical web page, but
"persistence" if the identifier binding to that final object is
still somewhat dubious.
 
> But once we get to ISBN and ISSN, the meaning is much detached
> from resolution.  In particular, there are assumed to be many
> different ways of resolving the identifier (for various
> purposes), and no one of them is expected to yield "the"
> meaning.

And here is where I get confused about where you are going
because, e.g., an ISBN, once assigned, very much identifies an
object.  If the object changes, the ISBN changes.  There are
well-defined rules requiring those changes and rules that are at
least fairly well-defined globally about what "change" means.
Once assigned to an object, the ISBN itself not only never
changes but is never reassigned to something else.   And, for
ISBNs, "never" means "never" -- not "after a while" or even
"after a decent period of time has passed after the former
subscriber stopped using it.

> The extreme of this end of the spectrum are identifiers like
> the urn:ietf:params URNs -- there is no particular
> network-accessible resource involved, and no resolution
> process (in the ordinary sense) at all.

Yes, we agree about that.

> An odd example is the Alert-Info URNs for SIP
> (draft-ietf-salud-alert-info-urns), which tell phones how to
> announce an incoming call (priority, internal/external source,
> etc.).  In that case, there is a resolution algorithm, but it
> functions entirely inside a phone, instructing how the phone
> should choose from among the ringing signals that it is
> capable of generating which one to choose (e.g., which
> information it should prioritize when it can't announce all of
> the specified information).  So though the URN is tightly
> identified with the resolution process, the resolution process
> does not determine a network-accessible resource.

Right.

But examples like that may also illustrate a different version
of the library/ museum/ etc. requirement.   With the
understanding that there are always tradeoffs and that I don't
pretend to understand that ones that underlay that spec --
particularly why one would want to bother with a URN rather than
an extensible list of keywords and, for some of them, allowable
values -- I note that, if one wanted to make that information
globally available (which might have privacy implications --
again, there are tradeoffs), one might go with an ordinary SIP
URI and some type of "alert" qualification.  Whatever that
qualification might be, it certainly is not a "query" or
"fragment" for the SIP URI or the pseudo-telco object it
represents.   Probably --I've skimmed the spec only quickly--
the nature of the transaction handshake and the proxy issues
mentioned would prevent a "unified URL" approach, but I trust
you see the point.

    john

p.s. you can expect me (or, now that it has come up, someone
else), to question the use of a URN structure on IETF Last Call.
As a co-author, you might want to preempt such questions by
explaining the choice in the draft.


From nobody Tue May 27 18:35:06 2014
Return-Path: <stpeter@stpeter.im>
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 C6FDA1A02D8 for <urn@ietfa.amsl.com>; Tue, 27 May 2014 18:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 ZI88PSZmaLAi for <urn@ietfa.amsl.com>; Tue, 27 May 2014 18:35:01 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 392D71A00B0 for <urn@ietf.org>; Tue, 27 May 2014 18:35:01 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9EE9F40332; Tue, 27 May 2014 19:34:51 -0600 (MDT)
Message-ID: <53853D3B.1070204@stpeter.im>
Date: Tue, 27 May 2014 19:34:51 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Barry Leiba <barryleiba@computer.org>,  SM <sm@resistor.net>
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <6.2.5.6.2.20140522093232.0c5fcfe0@resistor.net> <CALaySJLe9x1jB9D_Y_FJFYpiYX71uasPe7ePv6fLcJAi5Jy7pw@mail.gmail.com> <537E7E86.4040400@stpeter.im> <3E8CB876A388DD8352A04912@JCK-EEE10>
In-Reply-To: <3E8CB876A388DD8352A04912@JCK-EEE10>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SuxlH_peZrUApwmKmlhqLTT-cpY
Cc: Julian Reschke <julian.reschke@gmx.de>, Michael Richardson <mcr+ietf@sandelman.ca>, Carsten Bormann <cabo@tzi.org>, urn@ietf.org
Subject: Re: [urn] URNs, permanence, resolution, and indirection/abstraction
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, 28 May 2014 01:35:04 -0000

On 5/22/14, 5:40 PM, John C Klensin wrote:
> (Changing subject line, which should have been done some time
> ago-- this really isn't about RFC URNs except as a handy example)
>
> --On Thursday, 22 May, 2014 16:47 -0600 Peter Saint-Andre
> <stpeter@stpeter.im> wrote:
>
>> On 5/22/14, 4:00 PM, Barry Leiba wrote:
>>>> The problem is how do I use "urn:ietf:rfc:6924"?
>>>
>>> The answer depends upon what you want to use it for.
>>
>> Just FYI, in the XMPP world, we have an example of one way to
>> use it. In our specification of the ICE-UDP transport method
>> in our Jingle technology for establishing media sessions, we
>> use "urn:ietf:rfc:3264" as an identifier for offer/answer mode
>> (i.e., not trickle-ICE), which is defined in RFC 3264...
>>
>> http://xmpp.org/extensions/xep-0176.html#support-sdp
>>
>> That is, we're referring to "the feature defined in RFC 3264",
>> and we don't care about the physical location of the
>> specification itself.
>>
>> But I realize that's not what folks are trying to do in the
>> thread that SM mentioned.
>
> Actually, Peter, this is very helpful because it illustrates
> why, at least IMO, Barry and those folks aren't communicating.
>
> There are three ways to get from a URN to one of more resolution
> services (for those URNs that need or have such services and
> whatever, generically, that means).  One is to bind the set of
> things that can be produced by a resolution process to the
> resolution mechanisms in using protocol definition itself.  That
> is what you describe above.  If an XMPP application encounters
> an urn:ietf:rfc URN, it uses that information as an indicator
> and doesn't, in the traditional sense, resolve it at all.

Absolutely correct - for our use in the Jingle XMPP extensions, it's 
just an indicator of support for the offer/answer model.

> A second is to bind to an actual resolution mechanism (or
> task-specific set of them) in the NID definition or something it
> points to, so that definition would say "if you want the RFC
> text in PDF form, construct a URL as follows" and "if you want
> an XML2RFC bibliographic reference for the RFC, construct a
> URL..." and so on, for a long list.  That list might or might
> not include a note about how XMPP uses the URN, e.g., "name only
> as indicator".   For those old enough to remember, if we still
> had "How to obtain RFCs" around and considered it normative, the
> NID definition might incorporate it by reference for some of
> that information.
>
> Or, in the grand tradition of Computer Science and Internet
> Engineering, one could introduce another layer of indirection.
> One might want to do that for many reasons, but one would be
> that elements of the resolution-location process might not be
> stable.  RFCs are not a particularly good example because, if
> rfc-editor.org and ietf.org aren't around and willing to keep
> the links stable, maybe no one else cares.  Or not.  But suppose
> we had a universal dodo identifier based on the International
> Dodo Registry:
>
>     urn:dodo:32
>
> Now that raises all of the issues a few of us have been
> discussing.   The URN itself provides information: Dodo 32 is
> presumably a different dodo than Dodo 47.   But one can want to
> locate or obtain Dodo 32, one can want information about it,
> such as its weight or state of health (probably pretty
> consistent for dodos), and so on and a way is needed to talk
> about that different stuff.  More important, if the Dodo
> Registry were, say, at Oxford University, one might want some
> level of indirection in case Oxford decided to transfer the
> registry elsewhere or to close its institutional doors (this is
> one place where the difference between tens of years and tens of
> centuries becomes important).  Our typical way to way to deal
> with that would be to build the constructed URL template as
> Method://international-dodo-registry.org/?dodo-number=32> but
> suppose one's concerns about permanence _for the particular NID_
> was such that you wouldn't want to trust in the continued
> existence of the DNS or that of the ORG TLD?  That is the job
> URN.ARPA was intended to serve, so that dodo.urn.arpa would
> provide a pointer to where the template information was at any
> given time and/or appropriate DDDS material.  That would work
> well for concerns about ORG, but not for concerns about the ARPA
> TLD or the DNS.  For the latter, one would want to abstract
> URN.ARPA too, such that there was a single, URN-specific (not
> NID-specific) definition of where to look for the information
> that is now (optionally) stored at <nid>.urn.arpa.  If the DNS
> imploded, that document could be updated with the new "how to
> find the tree" information and appropriate chronology retained.
>
> This is obviously turtles all the way down and getting the right
> stopping rules requires fairly serious thought.  But, if one
> wants to think about "permanence", one has to do that work...

I admit that I'm happy to merely help define the URN syntax, not the 
resolution rules.

> and then the definers of each NID decide how permanent it needs
> to be in terms of levels of abstraction and indirection such at
> those outlined above.

Yes, that does seem to be a helpful exercise for those who are defining 
NIDs. Do we perhaps need some text along these lines in 3406bis?

Peter


From nobody Wed May 28 11:29:06 2014
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 D9B831A04B1 for <urn@ietfa.amsl.com>; Wed, 28 May 2014 11:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 4gLE6WT4rzIU for <urn@ietfa.amsl.com>; Wed, 28 May 2014 11:29:02 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921B51A01D8 for <urn@ietf.org>; Wed, 28 May 2014 11:29:02 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rp16so11522819pbb.6 for <urn@ietf.org>; Wed, 28 May 2014 11:28:59 -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:date:message-id:subject:from:to :content-type; bh=l2pXhfwq4syzSN/4wijYncR9pXqh0hLBuX41bF/urqw=; b=dvwPdT0mzO/xiexLfRE5XjLaQ8lVFL7+7wNjJxze/ZnAJenVRBb2y5/OORJ4FupCV8 KDxbnsnHi73CB8mDOb+fm0GGaasMzVoPMBcEb2AnnMWJTZIJJcwAwS720xj5FXOMxjmY 6bk1Pxun0iK8zrNuHtg3VE537gOCBp/HfjvRsb0cPA5Bi5+gQfduXZk/qLOaocGzcq70 m7MKoPHvpodmtL+9tAGRyYRITMN/G/f9VUBcihUZ5J0HMfksftbSha8uGSA715eB9rVu 9O9xwML6sBFqc+9DE1KFgWi6N8Re+Z5P51oYr2nWrUF7BVFhWcSMmp6eBcoYyfpcueXM PTmg==
X-Gm-Message-State: ALoCoQlUMSSka64j9PZ/IT2UdTNe5h6xct08yss73F3O8FADUGVw0KMyHQ5Ia4OE71nFCTh9RoRy
MIME-Version: 1.0
X-Received: by 10.68.240.34 with SMTP id vx2mr1752259pbc.1.1401301738985; Wed, 28 May 2014 11:28:58 -0700 (PDT)
Received: by 10.66.5.231 with HTTP; Wed, 28 May 2014 11:28:58 -0700 (PDT)
X-Originating-IP: [2001:500:4:15:c4e0:445c:1f05:b81f]
Date: Wed, 28 May 2014 14:28:58 -0400
Message-ID: <CAAQiQRcS0yf_y2O6vOLL+gH_Yg1xwVWA=6-y5hdCf=VdjHmP5w@mail.gmail.com>
From: Andrew Newton <andy@hxr.us>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "urn@ietf.org" <urn@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FlrMzIWrgCINuvrzavjhyoOVKtg
Subject: [urn] URNBIS session requested for IETF 90 in Toronto
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, 28 May 2014 18:29:04 -0000

All,

A URNBIS session request has been submitted for IETF 90 in Toronto. We
have requested this session to discuss the URNs Are Not URIs topic
(draft-ietf-urnbis-urns-are-not-uris). As this can be perceived as a
substantial change to URI/URN architecture, face-to-face discussion
would be beneficial for gaining consensus and facilitating an
important and broad discussion. This will be a great opportunity for
participants who have not otherwise been following the discussion to
now get involved.

Andy Newton,
URNBIS co-chair


From nobody Wed May 28 11:45:21 2014
Return-Path: <worley@ariadne.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 2B12A1A0645 for <urn@ietfa.amsl.com>; Wed, 28 May 2014 11:45:15 -0700 (PDT)
X-Quarantine-ID: <lQ80c-AsXWsp>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...Xdn28yaA@mail.gmail.com>\n  \n <CAK3OfOj7Zse[...]
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 lQ80c-AsXWsp for <urn@ietfa.amsl.com>; Wed, 28 May 2014 11:45:13 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2791A063F for <urn@ietf.org>; Wed, 28 May 2014 11:45:13 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta07.westchester.pa.mail.comcast.net with comcast id 7Vuh1o0060bG4ec57Wl9xN; Wed, 28 May 2014 18:45:09 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta03.westchester.pa.mail.comcast.net with comcast id 7Wl81o00q1KKtkw3PWl9bq; Wed, 28 May 2014 18:45:09 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s4SIj7Cn027053; Wed, 28 May 2014 14:45:07 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4SIj6Nc027052; Wed, 28 May 2014 14:45:06 -0400
Date: Wed, 28 May 2014 14:45:06 -0400
Message-Id: <201405281845.s4SIj6Nc027052@hobgoblin.ariadne.com>
From: worley@alum.mit.edu (Dale R. Worley)
Sender: worley@alum.mit.edu (Dale R. Worley)
To: John C Klensin <john-ietf@jck.com>
In-reply-to: <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com> (john-ietf@jck.com)
References: <CAK3OfOjTQotMnbvzoDxFHMGGYVRJg1Dsv2nO46rrdMmJRYTKsg@mail.gmail.com> <3BB4846B-08AB-4356-8396-9E2E3245B5E5@tzi.org> <CAK3OfOivj7-FMES7jo1ACd3TtDrq4ZGbSz3nYjVc=QXdn28yaA@mail.gmail.com> <CAK3OfOj7ZsezbV2NZzCLUCebvnrWDRghJRTKJExh-XVXcaGRzA@mail.gmail.c om> <2461.1400713811@sandelman.ca> <C05877CD-93F2-41E2-95DF-936E38974C08@gmail.com> <4002.1400765721@sandelman.ca> <6.2.5.6.2.20140522084107.0c0700b8@resistor.net> <CALaySJJHMxbU_xw6tAOQsbj3n=3g9h+-FbeCkVgsKng356TLFg@mail.gmail.com> <F3650CE869694591A671E9BA@JCK-EEE10> <201405231943.s4NJhCCq012272@hobgoblin.ariadne.com> <41BF2367E6EBF9E081E9F860@[192.168.1.102]> <201405271915.s4RJFVfr031146@hobgoblin.ariadne.com> <51FF45E6486D56CE2F633D90@JcK-HP8200.jck.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401302709; bh=b1+YXApRDl7ssZnRAffJXNpEpnOK+eUvXm6lHdcaEfE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=T9jI6pWoLmpfUmoWqRBt3A/x/LLwE7z+8t9K16CmJdE/MLfTc7xwRxoL1e9tCpCUV s17QB1AZKzw25S5FPTp9I7WcKCIQQU+FFZ2clN2EJqdQIFNUJ/xhDCDPgCHzTdtYEp EaXuIkt2ytmyOtr+a6/smDmtSd+PGJcO480O8wiG/A/yW3VR7mhxvXg3EWCb11aIBj QLhvZcoHJilf77Lsx5Y9FhDcpMtF9/zimc/U8oyrFAA1cLmQOu8iBK/lnaeSjeth1y iz1PJr6YROEHk4XitT3lobNWntQGX3WiEEYPJ6q+GQSoHeHHUsz/LLWm+R1I/vPeOR PelRjG7MOG9fw==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/NUr4iq9OZdnoBI8RLBcYQAyfOaI
Cc: urn@ietf.org
Subject: Re: [urn] urn:ietf:rfc
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, 28 May 2014 18:45:15 -0000

> From: John C Klensin <john-ietf@jck.com>

> > But once we get to ISBN and ISSN, the meaning is much detached
> > from resolution.  In particular, there are assumed to be many
> > different ways of resolving the identifier (for various
> > purposes), and no one of them is expected to yield "the"
> > meaning.
> 
> And here is where I get confused about where you are going
> because, e.g., an ISBN, once assigned, very much identifies an
> object.

Aye, but let's look at it in a couple of different ways.

One way to look at it is from the network engineering point of view.
An ISBN identifies "a book", but that isn't a network-accessible
resource, and so it's pretty much irrelevant.  If you're trying to get
any information via the internet about the book, what you're really
getting is various network-accessible resources that are only
sociologically connected to "the book".  Many of these are considered
"metadata" (cataloging information, current price on the used book
market, etc.) but some might be seen as semantically overlapping "the
book", such as a recording of the book's text or page images from the
book.

Our concept that the ISBN identifies "a book" diverges from the
reality that anything you can do with the ISBN on the internet is at
best a small subset of the information connected to "the book".  In
this regard, an ISBN URI is much more abstracted than an HTTP URI.

To add a layer of complexity, the "book" object that an ISBN
identifies is an abstraction.  I mean, there is a *book* on my desk at
this moment, but the ISBN printed on that book doesn't really identify
that object -- the ISBN identifies the entire set of existing and
potential books that are "from the same edition" (or whatever the
proper technical term is).  And this concept of an object is even
farther from the network engineering, because it isn't even a
physically describable thing.  (Of course, the library/publisher
people understand this, but it's an example that are hierarchies of
concepts that we often blithely lump together as "objects", and then
expect them to behave in generally similar ways.)

Dale


From nobody Thu May 29 07:19:36 2014
Return-Path: <barryleiba.mailing.lists@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 8249C1A6F04; Thu, 29 May 2014 07:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 87esOEV6BTSv; Thu, 29 May 2014 07:19:29 -0700 (PDT)
Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F262C1A0993; Thu, 29 May 2014 07:19:28 -0700 (PDT)
Received: by mail-ve0-f175.google.com with SMTP id jw12so447108veb.6 for <multiple recipients>; Thu, 29 May 2014 07:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:cc:content-type;  bh=7ywK+oQr96at73BWdBiIi+vYaGrHciSXaquIbIMnT2g=; b=BgaFYTQLrAE6XMPdwYn3S76OMFVXqS4wNxjFzIXVli2cwksPl2gS6khScO8s2BrJUl yqdUPV5FFG2mWzoV3PMQBtEgQtX7TeAJBjIbfr1rViBfFY+7UbHfnkSBNqicYYgQ3ChX grIp2xPgO9vhsLH5YzRybB1RZHI0T4SyAi9G0o7SCYn7Em5bTjAv6SNsn9aOCkfTA5Jc 5En1Vg3lx1VyxFl62g3VJ8fMQLPckI01h+dj6LLkfTQtN+3NP9QFjEF48yrbGqWBm45y 5rN+oemfP5UUbpBPbFp/z0eDpZ8dl93RT4JhWGeqSDbK1MQ4Pl9aIzS+w4uwZFjcvOAQ XXmQ==
MIME-Version: 1.0
X-Received: by 10.58.219.166 with SMTP id pp6mr6865340vec.1.1401373164515; Thu, 29 May 2014 07:19:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.33.199 with HTTP; Thu, 29 May 2014 07:19:24 -0700 (PDT)
Date: Thu, 29 May 2014 10:19:24 -0400
X-Google-Sender-Auth: y4NYw-WPc3YDBWV_KtNfwYuLNzM
Message-ID: <CAC4RtVBbGebw1Kp5_E9OxGYCnercYHNaF_=DKdNdXnY1RqO7Gw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DsrsTbZvYRM9RYCSR2kCCFus84U
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: [urn] Important URI-related topic: draft-ietf-urnbis-urns-are-not-uris
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2014 14:19:30 -0000

Andy Newton said...
> A URNBIS session request has been submitted for IETF 90 in Toronto. We
> have requested this session to discuss the URNs Are Not URIs topic
> (draft-ietf-urnbis-urns-are-not-uris). As this can be perceived as a
> substantial change to URI/URN architecture, face-to-face discussion
> would be beneficial for gaining consensus and facilitating an
> important and broad discussion. This will be a great opportunity for
> participants who have not otherwise been following the discussion to
> now get involved.

In preparation for this meeting, and whether or not you intend to
attend it: please, if you have any interest in the topic at all,
review and comment on the draft.  Please do that now, not later: we'd
like the discussion in Toronto to be the resolution, not the start of
the conversation.

Please comment on the urnbis working group mailing list
<urn@ietf.org>.  You can subscribe here:
https://www.ietf.org/mailman/listinfo/urn

Please don't cross-post; let's keep the discussion on <urn@ietf.org>.

Thanks,
Barry


From nobody Thu May 29 11:00:14 2014
Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F471A016D for <urn@ietfa.amsl.com>; Thu, 29 May 2014 11:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Kn7riWOrnKQZ for <urn@ietfa.amsl.com>; Thu, 29 May 2014 11:00:09 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1C1A0164 for <urn@ietf.org>; Thu, 29 May 2014 11:00:08 -0700 (PDT)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s4THxteu004035;  Thu, 29 May 2014 18:59:55 +0100 (BST)
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4THxshW021918; Thu, 29 May 2014 18:59:54 +0100
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4THxtSc001504; Thu, 29 May 2014 18:59:55 +0100
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s4THxstc001500; Thu, 29 May 2014 18:59:54 +0100
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Thu, 29 May 2014 18:59:54 +0100
In-Reply-To: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> (John C. Klensin's message of "Mon\, 14 Apr 2014 09\:11\:18 -0400")
Message-ID: <f5b38fsh3dx.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/gy6a7uZDxip7BopNjvDzmbpGoyM
Cc: urn@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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, 29 May 2014 18:00:13 -0000

I have a long-standing interest in Web Architecture, having served on
the W3C TAG for 9 years, and have a sort of informal liaison role even
though I left the TAG a few months ago.  I've been following the
thread you started here with interest, and have spent some time
reading the backtrail, and your draft [1].

I find some things that I recognise, and some that I sympathise with,
but a lot that I just don't understand.  This is, I hope, the first of
a number of posts I hope to make asking for help to be sure I
understand both your requirements and your explanations for how having
URNs governed _inter alia_ by 3986 frustrates those requirements.
-------
3986 says some things which seem very much in sympathy with URNBIS:

  1.2.2.  Separating Identification from Interaction [2]

   . . .

   A common misunderstanding of URIs is that they are only used to
   refer to accessible resources.  The URI itself only provides
   identification; access to the resource is neither guaranteed nor
   implied by the presence of a URI.  Instead, any operation
   associated with a URI reference is defined by the protocol element,
   data format attribute, or natural language text in which it
   appears.

   Given a URI, a system may attempt to perform a variety of
   operations on the resource, as might be characterized by words such
   as "access", "update", "replace", or "find attributes".  Such
   operations are defined by the protocols that make use of URIs, not
   by this specification.

  . . .

   Although many URI schemes are named after protocols, this does not
   imply that use of these URIs will result in access to the resource
   via the named protocol.  URIs are often used simply for the sake of
   identification.  Even when a URI is used to retrieve a
   representation of a resource, that access might be through
   gateways, proxies, caches, and name resolution services that are
   independent of the protocol associated with the scheme name.

 3.5 Fragment

   . . .

   As with any URI, use of a fragment identifier component does not
   imply that a retrieval action will take place.  A URI with a
   fragment identifier may be used to refer to the secondary resource
   without any implication that the primary resource is accessible or
   will ever be accessed.

Nonetheless fragment( and query) seem to be at the heart of the
perceived problems of URIs expressed in URNBIS [1]:

  8.  The role URI fragment and query could or should have in
       identification is unclear and the statements in RFC 3986 are
       definitely problematic from the points of view of existing
       identifier systems and management of naming.

   Does fragment identify a location or a certain section of a resource?
   In the evolving set of URN Internet standards, fragment will not be a
   part of the Namespace Specific String.  Then fragment only indicates
   a place / segment within the identified resource, but does not
   identify it.  If fragment had a role in identification, fragments
   would extend the scope of existing standard identifiers to component
   parts of resources.  For instance, anyone could use URN based on ISBN
   + fragment to identify chapters of electronic books.

There is certainly a fundamental tension with pretty fundamental IETF
principles (beyond just what we find in 3986) implied here, if I
understand it correctly.  Media types play a central role in the IETF
architectural vision: given a character string and a media type, I
know how to find out what I can do with the characters.  It doesn't
matter how I got them and their type: from my local disk, via HTTP, in
an email, or by carrier pigeon.  And it doesn't matter what name or
names may have been involved in helping me get access to them.  One of
the things I can do is use whatever fragment identifier syntax and
semantics is provided by the definition of the media type in question
to . . . identify 'fragments'.  And, crucially, those 'fragments'
_need not_ be any locations or sections of the character string or its
interpretation per the media type:

   The identified secondary resource may be some portion or subset of
   the primary resource, some view on representations of the primary
   resource, or _some other resource defined or described by those
   representations_. [emphasis added] [3]

To make this absolute concrete, given a text/html representation and a
fragment identifier "foo", the secondary resource in question is
e.g. a paragraph in the document resource represented by that html, in
particular the paragraph corresponding to the markup including "<a
name='foo'>" in the representation.  Or, given a text/turtle
representation and a fragment "tbl", the secondary resource in
question is e.g. the resource _described_ by the RDF node
corresponding to a line consisting of "<#tbl>" in the representation.
All of that follows straightforwardly from 3986 and the two respective
media type registrations.

3986 is clear that those secondary resources are _identified_ by those
fragment identifiers.  You appear to be proposing that per URNBIS and
2141bis e.g. urn:example:w3cstaff#tbl would _identify_ the same
resource as urn:example:w3cstaff (although it might be defined to
'indicate' something different. . .).

It seems pretty clear to me that this is a divisive and confusing
thing to do.  Let's take the e-book example (I'm using a DOI, because
I happen to remember where to find the resolver for them, but the
point would be the same for any URN->http:URI resolver today):  The
following _both_ identify the main body of an editorial in the journal
_Nature_ of 28 May 2014:

  doi:10.1038/509534a#article
  http://dx.doi.org/10.1038/509534a#article

Am I right that your proposal would change this (assuming a URN
instead of a DOI)?  I.e., that those two things would no longer
identify the same secondary resource, despite both, minus the
'#article', being usable to retrieve the same text/html representation
of the same resource?

Have I misread your document?  If not, could you expand what I guess
must lie behind your desire to move in this apparently divisive
direction, namely

  "If fragment had a role in identification, fragments would extend
   the scope of existing standard identifiers to component parts of
   resources.  For instance, anyone could use URN based on ISBN
   + fragment to identify chapters of electronic books."

I _think_ this is intended to describe a _bad_ outcome from the
perspective of CiMo [4], one which is however understood to be
required by some combination of 3986 and 2141 as they stand, and thus
to amount to an argument why 3986+2141 won't meet your requirements.

Since it looks to me like a _good_ outcome, I'd be very grateful if
you could help me understand why it's bad from the CiMo perspective.

Thanks,

ht

[1] http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00
[2] http://tools.ietf.org/html/rfc3986#section-1.2.2
[3] http://tools.ietf.org/html/rfc3986#section-3.5
[4] http://www.ietf.org/mail-archive/web/urn/current/msg02249.html
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]


From nobody Fri May 30 09:07:03 2014
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 1A2451A09BC for <urn@ietfa.amsl.com>; Fri, 30 May 2014 09:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 z3zuscJwNO45 for <urn@ietfa.amsl.com>; Fri, 30 May 2014 09:07: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 DEBF71A0946 for <urn@ietf.org>; Fri, 30 May 2014 09:06:59 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WqPJS-00076u-Oh; Fri, 30 May 2014 12:05:46 -0400
Date: Fri, 30 May 2014 12:06:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <3F3B55235A6DFEF4BFBD07FF@JcK-HP8200.jck.com>
In-Reply-To: <CAC4RtVBbGebw1Kp5_E9OxGYCnercYHNaF_=DKdNdXnY1RqO7Gw@mail.gmail.com>
References: <CAC4RtVBbGebw1Kp5_E9OxGYCnercYHNaF_=DKdNdXnY1RqO7Gw@mail.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.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/71FMTX8Jf7Z3MQKfJ8KltN3eKKQ
Cc: Barry Leiba <barryleiba@computer.org>
Subject: Re: [urn] Important URI-related topic:	draft-ietf-urnbis-urns-are-not-uris
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 16:07:02 -0000

--On Thursday, May 29, 2014 10:19 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

> Andy Newton said...
>> A URNBIS session request has been submitted for IETF 90 in
>> Toronto. We have requested this session to discuss the URNs
>> Are Not URIs topic (draft-ietf-urnbis-urns-are-not-uris). As
>> this can be perceived as a substantial change to URI/URN
>> architecture, face-to-face discussion would be beneficial for
>> gaining consensus and facilitating an important and broad
>> discussion. This will be a great opportunity for participants
>> who have not otherwise been following the discussion to now
>> get involved.
> 
> In preparation for this meeting, and whether or not you intend
> to attend it: please, if you have any interest in the topic at
> all, review and comment on the draft.  Please do that now, not
> later: we'd like the discussion in Toronto to be the
> resolution, not the start of the conversation.

Barry (and Andrew),

Thanks.  I really hope we can get this process moving forward.

I had a couple of interesting, but necessarily incomplete, f2f
discussions this week.  I am going to need to think more about
the issues at their core before commenting further, but it is
increasingly clear to me that, when we say "URN" or make any of
the distinctions about, e.g., naming and location that have gone
on here, we trigger very different and almost independent
discussions.  

The first one is fundamentally more interesting to many of us.
It involves the very nature of naming and identification,
edge-case distinctions about the difference between objects and
their names, even questions about what we mean when we talk
about objects and how (or if) those topics change in the
"information age" (or, if one prefers, with an expansive
definition of the web).  One variation of an old joke about a
fairly early forward-looking information storage and retrieval
system [1] is that, with a traditional library catalog, looking
up "cat" would get pointers to books and articles about cats
while, with systems to come, one would need to be specific about
whether information about cats was wanted or one wanted a sample
cat or two and, if the latter, whether their state of health was
relevant.    All of this leads to very fundamental questions
about naming, knowing, abstraction, and epistemology generally.


The topic is of significant interest and importance to anyone
who believes that the introduction of the web (or Internet more
generally) represents or will cause basic changes in how humans
organize knowledge or think or who is trying to predict the
future in those areas.  From that point of view, philosophical
discussions of some of the topics for the last circa 2500 years
have abruptly become irrelevant -- perhaps the ultimate paradigm
shift.  Or, if one has sufficient convictions or understanding
along those lines, the topic may have become completely trivial
and no longer worth addressing.


The other topic and discussion is completely pragmatic.  The
IETF is supposed to be in the standards business.  There are
communities out there have have (at least in their beliefs and
often based on decades or centuries of experience) real
requirements for real functionality.  One might work through the
first discussion and believe that they and their thinking will
rapidly (or soon) become obsolete, but that doesn't make the
perceived need less real today even if dealing with that need
is, in the long term, nothing more than a short-term patch until
a greater understanding spreads.     As a standards body that
lacks either judicial or divine authority, our choices when
faced with such needs are between responding to them in a way
that promotes interoperability and abandoning the requirement to
others to work out their own solutions.

In the URN space, I still believe that the IETF can do a better
and more realistic job of getting the relevant communities
together and working out solutions that are tolerable for
everyone using the Internet (not just the web).  When I stop
believing that, I'll start pushing to close the WG and leave the
work to other groups or bodies.  We may have an educational role
too -- "doesn't, e.g., the semantic web contain a better answer"
is a legitimate question.   But, from that perspective, the
stated needs of legitimate contemporary communities are much
more relevant than the conclusions of those whose concern is
with the longer-term and more philosophical questions above,
questions that, for URNs, start with whether those needs are
"correct" or not.

best,
     john


[1] See, e.g., http://files.eric.ed.gov/fulltext/ED056732.pdf or
http://dl.acm.org/citation.cfm?id=1476862&dl=ACM&coll=DL&CFID=347915301&CFTOKEN=26330164



From nobody Fri May 30 09:13:55 2014
Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46001A6F53 for <urn@ietfa.amsl.com>; Fri, 30 May 2014 09:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level: 
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 LJjBAzriVyVz for <urn@ietfa.amsl.com>; Fri, 30 May 2014 09:13:50 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 76BE71A6F47 for <urn@ietf.org>; Fri, 30 May 2014 09:13:50 -0700 (PDT)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s4UGDjd7025521;  Fri, 30 May 2014 17:13:45 +0100 (BST)
Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4UGDhEg030842; Fri, 30 May 2014 17:13:43 +0100
Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s4UGDinh028118; Fri, 30 May 2014 17:13:44 +0100
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s4UGDhXp028114; Fri, 30 May 2014 17:13:43 +0100
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: John C Klensin <john-ietf@jck.com>
References: <CAC4RtVBbGebw1Kp5_E9OxGYCnercYHNaF_=DKdNdXnY1RqO7Gw@mail.gmail.com> <3F3B55235A6DFEF4BFBD07FF@JcK-HP8200.jck.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Fri, 30 May 2014 17:13:43 +0100
In-Reply-To: <3F3B55235A6DFEF4BFBD07FF@JcK-HP8200.jck.com> (John C. Klensin's message of "Fri\, 30 May 2014 12\:06\:46 -0400")
Message-ID: <f5blhtjb5xk.fsf@troutbeck.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fb002qr5kn5KNXP79dYKV12POBw
Cc: urn@ietf.org, Barry Leiba <barryleiba@computer.org>
Subject: Re: [urn] Important URI-related topic:	draft-ietf-urnbis-urns-are-not-uris
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 16:13:53 -0000

John C Klensin writes:

> Barry (and Andrew),
>
> Thanks.  I really hope we can get this process moving forward.
>
> I had a couple of interesting, but necessarily incomplete, f2f
> discussions this week.  I am going to need to think more about
> the issues at their core before commenting further, but it is
> increasingly clear to me that, when we say "URN" or make any of
> the distinctions about, e.g., naming and location that have gone
> on here, we trigger very different and almost independent
> discussions.  

> . . .

> There are communities out there have have (at least in their beliefs
> and often based on decades or centuries of experience) real
> requirements for real functionality.

I have a great deal of respect for the Information Science community,
particularly the practitioners.  I'd welcome a summary from you of
what you take their requirements to be (or a pointer to one of your
earlier messages where you have already provided one).

Thanks,

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


From nobody Sat May 31 11:01:41 2014
Return-Path: <johnl@iecc.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 49B111A004D for <urn@ietfa.amsl.com>; Sat, 31 May 2014 11:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.563
X-Spam-Level: *
X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 1wh3XMngxy8N for <urn@ietfa.amsl.com>; Sat, 31 May 2014 11:01:38 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9991B1A0051 for <urn@ietf.org>; Sat, 31 May 2014 11:01:38 -0700 (PDT)
Received: (qmail 21114 invoked from network); 31 May 2014 18:01:29 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 31 May 2014 18:01:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=611c.538a18f9.k1405; i=johnl@user.iecc.com; bh=wVSnOeiqFVS8LBSOPOO3+dgmWcrcFBacBNIxC1UCNz4=; b=P0cMiV39T+dm3gQi8cddoX4BXWZh8mvg8kYEdEifUFZ1fUUP/0fPHbQmgpB674yfBT5CYfkPumtIlTZ1qGCCVDDX3YX5CPM4cnMzX8QBkV9zzgm5ia9/OrTdzyrLO+7crZ7a7iOoN9D9bDrDAsVtCAb2boyQ9aOZwo4ENmzVJiUJu2bDY4XNqhfg9FEDXzsaaFIZwqsj+SIH2UmH7jXx80W/sqqkcfTcOVL4Q6OW3t326/qVp3ClJ/lf4qaF4Tf4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=611c.538a18f9.k1405; olt=johnl@user.iecc.com; bh=wVSnOeiqFVS8LBSOPOO3+dgmWcrcFBacBNIxC1UCNz4=; b=OjFE8YqFpDijehlFMszdoscuekA0t9vho77pzNxvLa2hYymJlmWj145dqjMn8vDwmiuUm+QJvrUoibcWvxb/WQsYo3u7Lggqc1akXg4o2zwPToASH09563OXErWU/pDf50z6L7SayslzC7/elXVIuYvJPVAPQCUbQXOkxTb317K/TFE9GGGegxmc9vPKlwcaVqBPHsK5H5dJiJfn1hopOJYdA0AcRaqZ7m2rgII4Ian/upxiQAUd+f2CL70Yd79m
Date: 31 May 2014 18:01:07 -0000
Message-ID: <20140531180107.24859.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: urn@ietf.org
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/CcvZjDkamaPXfYOcgHtbamEuQrw
Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 18:01:40 -0000

> Let's take the e-book example (I'm using a DOI, because
> I happen to remember where to find the resolver for them, but the
> point would be the same for any URN->http:URI resolver today):  The
> following _both_ identify the main body of an editorial in the journal
> _Nature_ of 28 May 2014:

>  doi:10.1038/509534a#article
>  http://dx.doi.org/10.1038/509534a#article

Actually, they don't.  The DOI maps to a bunch of bibliographic info
which you get if you fetch that URL and ask for JSON or bibtex.  (See
JSON below.)

As a hack, albeit the one that people use 99% of the time, if the
publisher provides a URL, the DOI web server responds with a redirect
to the publisher's URL if you ask for html, thereby in practice
turning DOIs which are supposed to be names into locators.  In your
example, the #article is a fragment in the redirected page at
www.nature.com, nothing to do with the DOI.

The original plan, which seems to have been implemented approximately
nowhere, is that institutions would run their own DOI resolvers that
can provide local copies when available, which matters for the large
amount of DOI material that is behind paywalls.

There is a documented lookup scheme for DOIs (RFCs 3650-3652) which is
also implemented approximately nowhere, so a few years ago the DOI
people threw in the towel and told people to use the URL syntax.  I
expect this is the same issue as with DDDS, URLs are good enough for
many purposes and are a whole lot easier to implement.

R's,
John

-----------------------------------------------------------
{
    "subtitle": [

    ],
    "subject": [
        "General"
    ],
    "issued": {
        "date-parts": [
            [
                2014,
                5,
                28
            ]
        ]
    },
    "score": 1.0,
    "prefix": "http://id.crossref.org/prefix/10.1038",
    "container-title": "Nature",
    "reference-count": 0,
    "page": "534-534",
    "deposited": {
        "date-parts": [
            [
                2014,
                5,
                28
            ]
        ],
        "timestamp": 1401235200000
    },
    "issue": "7502",
    "title": "Welcome, Scientific Data!",
    "type": "journal-article",
    "DOI": "10.1038/509534a",
    "ISSN": [
        "0028-0836",
        "1476-4687"
    ],
    "URL": "http://dx.doi.org/10.1038/509534a",
    "source": "CrossRef",
    "publisher": "Nature Publishing Group",
    "indexed": {
        "date-parts": [
            [
                2014,
                5,
                31
            ]
        ],
        "timestamp": 1401519310045
    },
    "volume": "509"
}