From L.Svensson@dnb.de  Tue Sep  6 11:05:56 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3921F8B6B for <urn@ietfa.amsl.com>; Tue,  6 Sep 2011 11:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Level: 
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLzoc0qcMBXD for <urn@ietfa.amsl.com>; Tue,  6 Sep 2011 11:05:56 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 9136421F8B66 for <urn@ietf.org>; Tue,  6 Sep 2011 11:05:55 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 2DFB5D7264 for <urn@ietf.org>; Tue,  6 Sep 2011 20:07:41 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 6 Sep 2011 20:07:40 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E0EBF4C@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [urn] Finding the end of the URN string
Thread-Index: AcxobB2IbdqLAWhqRduXz2p1Wy3EwwETvPiw
References: <20110901085749.18843tlsjpp5168t.jehakala@webmail.helsinki.fi>
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: <urn@ietf.org>
Subject: Re: [urn] Finding the end of the URN string
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 18:05:57 -0000

Juha, all,

I'm not quite sure I understand exactly where the problem is, but I have
a feeling that it is based in a confusion between the urn and the
identifier embedded in the urn string (the NSS).

> RFC2141 has this to say about parsing URN strings embedded in plain
> text:
>=20
> "In textual context, a URN ends when an octet/character from the
> excluded character set (<excluded>) is encountered.  The character
> from the excluded character set is NOT part of the URN."
>=20
> Although URNs will usually be incorporated in Dublin Core and other
> kind of metadata records where the encoding makes the data machine
> understandable, it may be useful or even necessary to discuss the
> issue of URN parsing in plain text in more detail in RFC 2141bis. And
> unlike back in 1997 we know a lot how URNs are used in textual
context.
>=20
> The problem with the current statement is that there is no guarantee
> that the first character after the URN string is from the excluded
> character set. For instance, International Standard Name Identifier
>=20
> urn:isni:1111222233334444
>=20
> could be followed by the telephone number of the person / organization
> to whom the ISNI belongs to. This information would not be part of the
> ISNI, but RFC 2141 would fail in making this clear.

Would I in that case add the telephone number directly to the urn:isni,
making it urn:isni:1234567890123456-49-69-123456789 (assuming that my
phone number is +49-69-123456789, which it isn't)? Can you elaborate
more on this?

> In order to be able to parse URNs in plain text in reliable manner,
> applications must be aware of the syntax of the identifier system. For
> instance, there are 16 digits in ISNI, which makes it easy to find the
> end of the NSS.
>=20
> ISBNs assigned since 2007 consist of 13 digits, like this:
>=20
> urn:isbn:978-0-07-166346-5
>=20
> (As an aside, Principles of Digital Audio, 6th ed., to which this ISBN
> belongs to, contains a chapter which explains the structure of ISBN. I
> was a little bit surprised.)
>=20
> Applications parsing urn:isbn's based on the new ISBN standard must
> know that the NSS should consist of 13 digits. Therefore, if somebody
> builds URNs like these:
>=20
> urn:isbn:<isbn-string>.<foo> (where "." is a local fragment separator)
>=20
> or
>=20
> urn:isbn:<isbn-string>#<foo>
>=20
> or
>=20
> urn:isbn:<isbn-string>?<foo>

But RFC 2141 is not about where the NSS ends, it's about where the URN
itself ends: "In textual context, a _URN_ ends" (emphasis mine). And in
urn:isbn:<isbn-string>#<foo> the _URN_ ends after <foo>, just as
urn:isbn:<isbn-string>#<bar> ends after <bar>.
=20
> the ISBN parsing algorithms should either ignore everything that comes
> after the 13th digit, or conclude that the NSS string in this
> particular URN is incorrect. A sophisticated algorithm should always
> do the former when the thing added to the URN is <query>. To my
> knowledge, no such algorithms exist yet.

If I want to find the NSS in a generic URN, shouldn't I be able to do
that by decomposing the URN using the ABNF?

> There are namespaces such as urn:nbn where no generic rules for the
> NSS parsing exist. It may be that such parsing rules can be developed
> sub-sections of these namespaces (for instance: to the NBNs generated
> in the National Library of Finland). In these cases, a last resort
> parsing rule can be used, which is that the first character which is
> not allowed in that particular namespace indicates the end of the URN.
> And if the namespace does not have any rules that go beyond the URN
> syntax specification as regards the allowed characters, RFC 2141 can
> be used as the basis for parsing the URN.
>=20
> To sum up, the short text section quoted above could be edited to this
> form in the next version of RFC2141bis in order to reflect the reality
> more closely:
>=20
> URNs will often be embedded in metadata records or in structured text.
> There the encoding will make it clear where the NSS ends, and
> therefore this method of incorporating URNs is recommended. A special
> case of this is the use of URNs as HTTP URIs to make them resolvable
> in the present Internet.
>=20
> When URNs are incorporated in plain text, reliable parsing of
> namespace specific strings is possible only if the identifier system
> has a well formed syntax (which specifies e.g. the length of the
> string) and the parser is familiar with it. For instance, ISBN numbers
> are either 10 or 13 digits long depending on the version of the ISBN
> standard, and the parser must be able to recognize which type of ISBN
> is being processed, and behave accordingly.

Again, shouldn't this be done by using the ABNF?

> If NSS contains a <query>, parsing algorithms MUST ignore it. If NSS
> contains a <fragment> or a local add-on,

Would that local add-on be part of the URN? Does that have to be
specified in the syntax?

> parsing algorithms SHOULD
> behave in different ways depending on the namespace. In the ISBN
> namespace the algorithms SHALL ignore anything that comes after the
> ISBN itself, and MAY label the ISBN as erroneous. Some other
> namespaces (and possibly even future versions of ISBN) may allow the
> user of <fragment> or local add-ons for identification of fragments of
> resources, in which case the parsing algorithms will know how to deal
> with them.

I would not have anything specific to a particular namespace in a
document concerned with a generic syntax (in this case for URNs).

> If the identifier does not have a specified syntax, but its character
> set is more limited than that allowed by the URN syntax, a URN has
> certainly ended when an octet/character from the character set
> excluded in that namespace is encountered. This method is not
> reliable; NSS may have ended earlier if the characters following the
> NSS and not excluded.

Again, in my understanding it's not just about finding the NSS, it's
currently about finding the end of the URN in text.=20

> If the namespace does not have any limitations concerning the
> character set, a URN has certainly ended when an octet/character from
> the excluded character set (<excluded>) is encountered.This method is
> not reliable: NSS may have ended earlier.
>=20
> Please note that the character from the excluded character set is NOT
> part of the URN.

As I don't know enough about those things, can someone with more
knowledge of URI parsing algorithms help us out?

Thanks and all the best,

Lars

From juha.hakala@helsinki.fi  Wed Sep  7 03:53:47 2011
Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879EB21F8B76 for <urn@ietfa.amsl.com>; Wed,  7 Sep 2011 03:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level: 
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=2.050,  BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyQx-wY5azaZ for <urn@ietfa.amsl.com>; Wed,  7 Sep 2011 03:53:46 -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 249AE21F8B72 for <urn@ietf.org>; Wed,  7 Sep 2011 03:53:45 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p87AtSFX021811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2011 13:55:29 +0300
Message-ID: <4E674DA0.7040400@helsinki.fi>
Date: Wed, 07 Sep 2011 13:55:28 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "Svensson, Lars" <L.Svensson@dnb.de>
References: <20110901085749.18843tlsjpp5168t.jehakala@webmail.helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E0EBF4C@dbf-ex.AD.DDB.DE>
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840E0EBF4C@dbf-ex.AD.DDB.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [urn] Finding the end of the URN string
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 07 Sep 2011 10:53:47 -0000

Hello Lars; all,

The discussion started from the problem that RFC 2141 specifies only 
this method for finding the end of the NSS:

> An URN ends when an octet/character from the excluded character set
>    (<excluded>) is encountered. 

This method fails when the first character after the NSS is not an 
excluded one. Therefore, when the identifier standards specify the 
syntax of the identifier, including its length, parsers should use this 
information for more reliable parsing results. Syntax may even allow the 
applications to check if the NSS string is correct (several identifiers 
contain a check digit).

RFC2141bis must still include the current method for a) backward 
compatibility, and b) in order to accommodate namespaces where the 
length of the identifier string is not specified.

Svensson, Lars wrote:
> Juha, all,
> 
> I'm not quite sure I understand exactly where the problem is, but I have
> a feeling that it is based in a confusion between the urn and the
> identifier embedded in the urn string (the NSS). 

>> The problem with the current statement is that there is no guarantee
>> that the first character after the URN string is from the excluded
>> character set. For instance, International Standard Name Identifier
>>
>> urn:isni:1111222233334444
>>
>> could be followed by the telephone number of the person / organization
>> to whom the ISNI belongs to. This information would not be part of the
>> ISNI, but RFC 2141 would fail in making this clear.
> 
> Would I in that case add the telephone number directly to the urn:isni,
> making it urn:isni:1234567890123456-49-69-123456789 (assuming that my
> phone number is +49-69-123456789, which it isn't)? Can you elaborate
> more on this?

In the (admittedly unlikely) situation shown above, parsing according to 
RFC2141 would go wrong; the end of the NSS would be the space following 
the last digit (9). In contrast, a parser using the ISNI syntax would 
know that ISNI has just 16 digits and thus the last digit of the NSS 
becomes the 6 before the first hyphen.

There is also a related issue that (ISO) identifier standards often 
specify how to express the identifier in human readable form. This 
involves adding non-semantic characters such as spaces and hyphens. For 
instance, 9780071663465 becomes ISBN 978-0-07-166346-5 and 
1111222233334444 ISNI 1111 2222 3333 4444. The ISO standards provide no 
guidelines as regards how to express these identifiers as URIs / URNs. 
This may be just a blessing, because it is easy to provide the general 
guidelines in RFC2141bis and namespace specific details in namespace 
registrations.

So, 2141bis should say something to the effect that

A. if the NSS itself contains  excluded characters, they must be percent 
encoded. An example of this are the square brackets in ISCI.

B. if the identifier in human readable form contains non-semantic 
characters which are acceptable, these may be used in NSS, but lexical 
equivalence must be specified. For instance,urn:isbn:9780071663465 is 
the same as urn:isbn:978-0-07-166346-5. Any non-semantic characters must 
be ignored when e.g. the length of the NSS is calculated.

C. if the identifier in human readable form contains non-semantic 
characters which are excluded, they should not be used in NSS, because 
in percent encoded form they no longer improve readability. For 
instance, string like 1111%202222%203333%204444 would not help anybody.

>> Applications parsing urn:isbn's based on the new ISBN standard must
>> know that the NSS should consist of 13 digits. Therefore, if somebody
>> builds URNs like these:
>>
>> urn:isbn:<isbn-string>.<foo> (where "." is a local fragment separator)
>>
>> or
>>
>> urn:isbn:<isbn-string>#<foo>
>>
>> or
>>
>> urn:isbn:<isbn-string>?<foo>
> 
> But RFC 2141 is not about where the NSS ends, it's about where the URN
> itself ends: "In textual context, a _URN_ ends" (emphasis mine). And in
> urn:isbn:<isbn-string>#<foo> the _URN_ ends after <foo>, just as
> urn:isbn:<isbn-string>#<bar> ends after <bar>.

No, according to the rules of the ISBN namespace as specified in RFC 
3187, you will not be allowed to use fragment, and if you do, then the 
parsing algorithm shall / should ignore it. RFC 2141bis already says 
that namespace registrations must specify if fragments are allowed, and 
in the ISBN namespace they will not be.

Please note that for instance this URN

urn:nbn:<isbn-string>#<foo>

is well formed and does end only after <foo>, and the parsing rules, if 
any, must take that into account.
>  
>> the ISBN parsing algorithms should either ignore everything that comes
>> after the 13th digit, or conclude that the NSS string in this
>> particular URN is incorrect. A sophisticated algorithm should always
>> do the former when the thing added to the URN is <query>. To my
>> knowledge, no such algorithms exist yet.
> 
> If I want to find the NSS in a generic URN, shouldn't I be able to do
> that by decomposing the URN using the ABNF?

That is the idea underlying the current RFC2141. But in the plain text 
context we cannot be sure that the NSS will always be followed by an 
excluded character such as space, although that will often be the case.

A lot of attention has been put to being able to find URNs from text 
(the "urn:" in the beginning of the string is only there for this 
purpose). But we have not really worked out properly how to find the end 
of the NSS.

>> When URNs are incorporated in plain text, reliable parsing of
>> namespace specific strings is possible only if the identifier system
>> has a well formed syntax (which specifies e.g. the length of the
>> string) and the parser is familiar with it. For instance, ISBN numbers
>> are either 10 or 13 digits long depending on the version of the ISBN
>> standard, and the parser must be able to recognize which type of ISBN
>> is being processed, and behave accordingly.
> 
> Again, shouldn't this be done by using the ABNF?

See above.
> 
>> If NSS contains a <query>, parsing algorithms MUST ignore it. If NSS
>> contains a <fragment> or a local add-on,
> 
> Would that local add-on be part of the URN? Does that have to be
> specified in the syntax?

Local add-ons used for identification of e.g. logical fragments will be 
part of NSS and URN. As "local" implies, namespace registration cannot 
be aware of them. URN resolution process must know what to do with them, 
though. That is, a URN with local add-on must resolve to URI (URL).
> 
>> parsing algorithms SHOULD
>> behave in different ways depending on the namespace. In the ISBN
>> namespace the algorithms SHALL ignore anything that comes after the
>> ISBN itself, and MAY label the ISBN as erroneous. Some other
>> namespaces (and possibly even future versions of ISBN) may allow the
>> user of <fragment> or local add-ons for identification of fragments of
>> resources, in which case the parsing algorithms will know how to deal
>> with them.
> 
> I would not have anything specific to a particular namespace in a
> document concerned with a generic syntax (in this case for URNs).

RFC2141bis can (and I think should) use e.g. ISCI, ISBN and ISNI as 
examples in order to clarify how to implement the generic guidelines 
specified in the RFC.
> 
>> If the identifier does not have a specified syntax, but its character
>> set is more limited than that allowed by the URN syntax, a URN has
>> certainly ended when an octet/character from the character set
>> excluded in that namespace is encountered. This method is not
>> reliable; NSS may have ended earlier if the characters following the
>> NSS and not excluded.
> 
> Again, in my understanding it's not just about finding the NSS, it's
> currently about finding the end of the URN in text. 
> 
>> If the namespace does not have any limitations concerning the
>> character set, a URN has certainly ended when an octet/character from
>> the excluded character set (<excluded>) is encountered.This method is
>> not reliable: NSS may have ended earlier.
>>
>> Please note that the character from the excluded character set is NOT
>> part of the URN.
> 
> As I don't know enough about those things, can someone with more
> knowledge of URI parsing algorithms help us out?

Parsing URNs is one step further from parsing URIs, especially if URN 
parsers should have namespace specific syntactical knowledge.

Since we are only working on the principles the algorithms are not there 
yet. But since e.g. ISO identifiers have simple syntax, it is not 
exactly rocket science to develop these applications. And to be honest, 
we have done quite well for 10 years without having any kind of 
sophistication in place as regards URN parsing. That does not mean that 
such functionality will not be of use in the future.

Best regards,

Juha
> 
> Thanks and all the best,
> 
> Lars
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From L.Svensson@dnb.de  Fri Sep  9 05:52:30 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D9221F8B13 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 05:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Level: 
X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ7jNYi-r7aT for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 05:52:29 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 71E6721F8ACA for <urn@ietf.org>; Fri,  9 Sep 2011 05:52:28 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 0FACFD710B; Fri,  9 Sep 2011 14:54:17 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Sep 2011 14:54:16 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E4CA339@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [urn] URNs and URI <fragment>
Thread-Index: Acxhgj8NNX59B6ibRkCsrARenwsPvgNadatA
References: <4E3A37FE.7060609@helsinki.fi><vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de> <4E53857A.4000209@helsinki.fi>
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Juha Hakala" <juha.hakala@helsinki.fi>, "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 12:52:30 -0000

All,

I'm arriving late to this party, so I don't really know where to chime
in, but I opt for adding my comments to the thread in reverse order of
posting.

Juha wrote:

> I think some level of initial confusion is natural when we have two
> communities (IETF and people who work with bibliographic identifiers)
> with differing ideas and terminology as regards what a fragment is and
> how they can and should be identified.
>=20
> But such initial diversity should not prevent us from finding a
> solution
> which will be acceptable for both communities and beneficial for the
> URN
> users.

Yes!

[...]

> However, there are URN namespaces in which the possibility of using
> RFC3986-based URI fragments exists, on the basis of the identifier
> syntax & assignment policy. And such functionality may be useful,
which
> is why Alfred Hoenes and myself decided to propose fragment usage in
> RFC2141bis and namespace registrations (when applicable).

+1, I see no reason to rule it out completely at the top level, if we
see possibilities for fragment identifiers further down in the chain.

> One namespace which can be "fragmented" is NBN (National bibliography
> number) specified in RFC 3188. Given the diversity of NBN systems used
> by different national libraries, there is no way to nail down a
non-RFC
> 3986 -based generic means for specifying fragments in the NBN
namespace
> (such as saying that "." is the delimiter between the two parts of the
> identifier). In such case, using URI fragment may come handy. For
> instance, one URN implementation project has analyzed the
possibilities
> for using URI fragments to identify elements of research data within a
> database.

If we decide to accept fragment identifiers in NBNs, the specification
MUST mandate that you can only use fragment identifiers if you also can
ensure that the media type of the returned representation
("manifestation" in FRBR-speak) will never change OR if you can ensure
that the use of the fragment identifier will be forward-compatible will
_all_ future representations. If we don't mandate this, it means that
future curators of digital objects will be responsible for mapping
fragment identifiers from older document versions to the new versions in
case you at some point in the future decide to migrate PDF 4.2 to PDF
648.16, where the meaning of the fragment might have changed. We mustn't
forget that one of the central use cases for urn:nbn in libraries is as
identifiers for digital long term preservation and that the decisions we
make to-day will be relevant for future generations.

> If a URN contains a fragment in the RFC 3986 sense of the word, then
> resolving or dereferencing that identifier should provide (among other
> things) direct access to the fragment. This functionality should be
> similar to how URLs with fragments work, except for permanence.

If I have a URN with a fragment, e. g. urn:nbn:aq:987-65432-1#chapter98,
and make this URN "actionable" by prefixing it with a resolver-URI --
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98 -- is the
fragment identifier then a part of the URN or of the http-URI? (And:
does it really matter?)

> Preserving access to a particular file (such as a document in PDF
> format) for long term (centuries) is of course very hard or
impossible;
> objects will usually be migrated. But most bibliographical identifiers
> are tied to particular manifestations. When a book in PDF format is
> migrated to, say, OOXML, the new manifestation will get another
> identifier / URN. The new manifestation may no longer have the same
> internal structure and therefore it is possible that the URI fragments
> cannot be used in the same manner.

See above: this really means that we potentially create a lot of work
for future digital curators.

> There is a more general problem of how to provide persistent links to
> resources when any digital manifestation of a resource is doomed to
> become non-accessible eventually. Library community has not developed
a
> general answer to this, but one possibility is to encourage creation
of
> URN links primarily to the description of the work.

"Work" in what sense? I assume you don't refer to FRBR Work here, but
that you mean "description of the [FRBR] expression".

> In this case,
> dereferencing would provide a metadata record (with links to the
> existing manifestations of the work), or perhaps all or at least some
> manifestations of the resource at one go. What I do not know is how
URI
> generic syntax is applicable to this or to the flexibility provided
> with
> URN resolution services in general in its current form.
>=20
> IMHO those namespaces which do not identify objects in the
> manifestation
> level cannot use URI syntax -based physical fragments.

Then that must be clearly specified in those namespaces.

[...]

All the best,

Lars

From L.Svensson@dnb.de  Fri Sep  9 06:11:26 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED45F21F867E for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level: 
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esrTSN9kCToz for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:11:25 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id C58BC21F863E for <urn@ietf.org>; Fri,  9 Sep 2011 06:11:24 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 0677CD6760; Fri,  9 Sep 2011 15:13:14 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Sep 2011 15:13:13 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [urn] URNs and URI <fragment>
Thread-Index: Acxgx95kZE88gJI0SbCCdae8ntqPvQOJ/yng
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <4E524CCC.4010800@helsinki.fi>
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Juha Hakala" <juha.hakala@helsinki.fi>, "Leslie Daigle" <leslie@thinkingcat.com>
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 13:11:26 -0000

Juha, all,

Juha wrote:
>=20
> Leslie Daigle wrote:
>=20
> > The URN WG meeting I was at during IETF80 seemed reasonably clear
> that
> > the options were:
> >
> > 1/ Define how fragments make sense for *ALL* URNs (i.e., not just
the
> > namespaces of which one is aware) and update the URN specifications
> > accordingly.
> >
> > -- OR --
> >
> > 2/ Include, in the NSS syntax for a given URN namespace, a means of
> > identifying what that Namespace means by 'fragment'.
> >
> >
> > I haven't seen any discussion on this list to accomplish "1/".  (I
> also
> > don't believe it's possible, but that's just a personal technical
> opinion).
>=20
> I am pretty certain that 1/ cannot be achieved, not least because this
> has not been the approach chosen by the WG. No generic specification
> can
> be exhaustive, given the diversity of the identifier systems /
> namespaces / media types. Also, we cannot take into account in the
> abstract level the logical fragments of publications, as namespaces
> tend
> to see and deal with them differently.
>=20
> However, generic principles (for instance, the requirement that the
> identifier must only apply to a single manifestation of a resource,
and
> the identified media type in that manifestation must support
fragments)
> can be given in RFC 2141bis. RFC2141bis should also stipulate that
> namespaces can have their internal fragment specifications which will
> be
> understood by resolvers that deal with that particular namespace.

I personally don't think it's possible to mandate that a URN MUST only
apply to a single manifestation of a resource, particularly since this
might impact all or at least some of the currently 44 registered urn
namespaces [1]

[...]
> >    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  So,
an
> > updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be
> achievable....?
>=20
> Sorry, it is not. Please observe that RFC 3187 makes it pretty clear
> that in the ISBN namespace namespace specific string must be an ISBN
> and
> nothing else. So in URN:ISBN:<foo> =3D URN:ISBN:<ISBN-string>. ISBN =
with
> a
> fragment identifier or anything else added to it is not an ISBN
anymore
> and does not belong to the ISBN namespace. For this kind of identifier
> construct, another namespace such as NBN can be used, if local NBN
> assignment policy approves this.

If I understand the discussion correctly, the question is if in
urn:isbn:1-234-56789-X#foo the #foo is part of the ISBN or not. If it's
part of the ISBN, the urn would be invalid since ISBNs cannot have
fragments. IMO a fragment (in the sense of RFC 3986) refers to the URI
as a whole and not to the NSS of a URN. I guess that there are people on
this list who can shed some light on this.
>=20
> So URN:NBN:<foo><fragment> is certainly achievable, and there may be /
> will be other namespaces out there where <foo><fragment> is also
> acceptable.
>=20
> Concerning the NBN namespace, given the broad scope of allowed / used
> syntaxes, URI fragment is the only way in which fragments can be
> generally expressed in the identifier syntax. New namespaces may
> specify
> their own fragment architectures for those cases when RFC3986 & 2046
> requirements are not fulfilled, but retrospectively such changes may
be
> impossible or at least complicated to implement. Such namespace
> specific
> arrangements should be referred to in RFC2141bis in the abstract, but
> they can only be specified in the namespace level.

Considering that RFC 3986 still mandates that the semantics of fragments
are specific to media types, I don't think it's possible to make
regulations on their meaning on the scheme-level except for very special
cases. 2141bis can say that fragments are generally allowed in URNs and
leave it to individual schemes to make their own arrangements, where my
guess is that most schemes will not be able to allow them, except where
the specification mandates that once you've created a URN with a
fragment, the resolution service MUST continue to return resources with
a media type compatible with that fragment.

[...]

Lars

[1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml

From L.Svensson@dnb.de  Fri Sep  9 06:21:13 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48C21F8498 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Level: 
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqtr36dveLS6 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:21:12 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 54D1021F8490 for <urn@ietf.org>; Fri,  9 Sep 2011 06:21:12 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id D6959D7044; Fri,  9 Sep 2011 15:23:06 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Sep 2011 15:23:06 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E4CA33E@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [urn] URNs and URI <fragment>
Thread-Index: AcxSlSE4QDgrhp5SQz2dgEtThflIVAcXXy5A
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de><4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi>
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Juha Hakala" <juha.hakala@helsinki.fi>, "Mykyta Yevstifeyev" <evnikita2@gmail.com>
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 13:21:13 -0000

All,

just one short comment on ISTC:

Juha wrote:

> > With respect to NBNs.  The situation is the same.  The matter of
> > fragment ID is the type, the format of the resource, not its actual
> > contents.  The same publication with the unique NBN number may exist
> in
> > electronic form in different formats.  Just the same as above.
>=20
> NBN does not refer to the work, but to a single manifestation of the
> work (in one file format). Manifestations in different file formats
> will
> get a different URN:NBNs. The reason for this is that file format
> changes may have an impact on the look and feel of the resource, and
> once something changes, for librarians it is no longer the same thing.
> We've had similar practices for printed stuff: hard back and paper =
back
> versions of a book have different ISBNs.

This is not always the case, but is not something libraries can solve.

> There is an interesting problem that all digital manifestations will =
be
> short-lived. When URN:ISBNs and URN:NBNs are not moved over to more
> modern versions of the document (which will receive other URNs) then
> somehow we must guarantee that the users will be made aware that there
> are later versions available as well.
>=20
> Other URN namespaces may be more flexible than the ones we are dealing
> now. We could have for instance urn:mykyta where the rule is that the
> file format does not matter. I don't know how much we can /should do =
in
> RFCs to co-ordinate those namespaces that deal with digital
> manifestations. Works are of course a different matter altogether,
> since
> they are immaterial and as such persistent.
>=20
> Independently of any physical manifestations libraries will also
> describe and identify works, but then we do not use ISBN but ISTC
> (International standard text code) for textual resources. And
> registering a namespace for that identifier (which has just recently
> went into production) remains to be done.

ISTC identifies texts, not works. E. g. the English translation of a =
German text doesn't get the same ISTC as the German original, and a new =
translation of the same text would get another ISTC as well, at least =
according to the ISTC user manual [1, =A77.1]
>=20
> > So, my position is that defining the fragment ID for use with ISBN
> and
> > NBN URNs makes very little sense; they may only be useful in URNs
> which
> > have very limited scope and resolve to the resource of the type =
which
> is
> > predefined.

I tend to agree with Mykyta here.
=20
> My take on this is that if we have e.g. a book in a file format that
> allows specification of fragments, then it is possible that these
> fragments can be accessed directly using HTTP URIs, and improving
> persistence of these access points to with URNs may make sense.
>=20
> In case of multimedia documents (with a multitude of file formats),
> URN:NBNs must be assigned at the file format level if the intention is
> to use fragments in one or more of these formats.

Is it at all possible to mandate this in the specification? (And what do =
we do if someone doesn't comply?)

All the best,

Lars

From L.Svensson@dnb.de  Fri Sep  9 06:22:42 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3520021F8997 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7NZQ60jNpxD for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:22:41 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 11E5821F8591 for <urn@ietf.org>; Fri,  9 Sep 2011 06:22:40 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 5897CD7052; Fri,  9 Sep 2011 15:24:32 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Sep 2011 15:24:31 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E4CA33F@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [urn] URNs and URI <fragment>
Thread-Index: AcxSlSE4QDgrhp5SQz2dgEtThflIVAcXXy5AAABFY2A=
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de><4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> 
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Juha Hakala" <juha.hakala@helsinki.fi>, "Mykyta Yevstifeyev" <evnikita2@gmail.com>
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 13:22:42 -0000

Sorry for omitting the link:

[1] =
http://www.istc-international.org/html/multimedia/pdfs/ISTC_User_Manual_2=
010v1.2.pdf=20

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

--=20
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de


> -----Urspr=FCngliche Nachricht-----
> Von: Svensson, Lars
> Gesendet: Freitag, 9. September 2011 15:23
> An: 'Juha Hakala'; Mykyta Yevstifeyev
> Cc: urn@ietf.org; Stella Griffiths
> Betreff: AW: Re: [urn] URNs and URI <fragment>
>=20
> All,
>=20
> just one short comment on ISTC:
>=20
> Juha wrote:
>=20
> > > With respect to NBNs.  The situation is the same.  The matter of
> > > fragment ID is the type, the format of the resource, not its =
actual
> > > contents.  The same publication with the unique NBN number may
> exist
> > in
> > > electronic form in different formats.  Just the same as above.
> >
> > NBN does not refer to the work, but to a single manifestation of the
> > work (in one file format). Manifestations in different file formats
> > will
> > get a different URN:NBNs. The reason for this is that file format
> > changes may have an impact on the look and feel of the resource, and
> > once something changes, for librarians it is no longer the same
> thing.
> > We've had similar practices for printed stuff: hard back and paper
> back
> > versions of a book have different ISBNs.
>=20
> This is not always the case, but is not something libraries can solve.
>=20
> > There is an interesting problem that all digital manifestations will
> be
> > short-lived. When URN:ISBNs and URN:NBNs are not moved over to more
> > modern versions of the document (which will receive other URNs) then
> > somehow we must guarantee that the users will be made aware that
> there
> > are later versions available as well.
> >
> > Other URN namespaces may be more flexible than the ones we are
> dealing
> > now. We could have for instance urn:mykyta where the rule is that =
the
> > file format does not matter. I don't know how much we can /should do
> in
> > RFCs to co-ordinate those namespaces that deal with digital
> > manifestations. Works are of course a different matter altogether,
> > since
> > they are immaterial and as such persistent.
> >
> > Independently of any physical manifestations libraries will also
> > describe and identify works, but then we do not use ISBN but ISTC
> > (International standard text code) for textual resources. And
> > registering a namespace for that identifier (which has just recently
> > went into production) remains to be done.
>=20
> ISTC identifies texts, not works. E. g. the English translation of a
> German text doesn't get the same ISTC as the German original, and a =
new
> translation of the same text would get another ISTC as well, at least
> according to the ISTC user manual [1, =A77.1]
> >
> > > So, my position is that defining the fragment ID for use with ISBN
> > and
> > > NBN URNs makes very little sense; they may only be useful in URNs
> > which
> > > have very limited scope and resolve to the resource of the type
> which
> > is
> > > predefined.
>=20
> I tend to agree with Mykyta here.
>=20
> > My take on this is that if we have e.g. a book in a file format that
> > allows specification of fragments, then it is possible that these
> > fragments can be accessed directly using HTTP URIs, and improving
> > persistence of these access points to with URNs may make sense.
> >
> > In case of multimedia documents (with a multitude of file formats),
> > URN:NBNs must be assigned at the file format level if the intention
> is
> > to use fragments in one or more of these formats.
>=20
> Is it at all possible to mandate this in the specification? (And what
> do we do if someone doesn't comply?)
>=20
> All the best,
>=20
> Lars

From julian.reschke@gmx.de  Fri Sep  9 06:29:33 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EEF21F86E0 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.585
X-Spam-Level: 
X-Spam-Status: No, score=-104.585 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ud3fpkTFL-K for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:29:33 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C1F5921F8680 for <urn@ietf.org>; Fri,  9 Sep 2011 06:29:32 -0700 (PDT)
Received: (qmail invoked by alias); 09 Sep 2011 13:31:26 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp003) with SMTP; 09 Sep 2011 15:31:26 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18I4zRTZekIVzS/+RHmX97bhvh1fmZP/39+HQY7Rk mDpALq5x2nFSJ9
Message-ID: <4E6A152A.5050704@gmx.de>
Date: Fri, 09 Sep 2011 15:31:22 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Svensson, Lars" <L.Svensson@dnb.de>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <4E524CCC.4010800@helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE>
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 13:29:33 -0000

On 2011-09-09 15:13, Svensson, Lars wrote:
> ...
> If I understand the discussion correctly, the question is if in
> urn:isbn:1-234-56789-X#foo the #foo is part of the ISBN or not. If it's
> part of the ISBN, the urn would be invalid since ISBNs cannot have
> fragments. IMO a fragment (in the sense of RFC 3986) refers to the URI
> as a whole and not to the NSS of a URN. I guess that there are people on
> this list who can shed some light on this.
> ...

It's not part of the ISBN -- I would have thought that's clear from the 
URI spec.

Best regards, Julian

From julian.reschke@gmx.de  Fri Sep  9 06:32:05 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A5E21F87D6 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.558
X-Spam-Level: 
X-Spam-Status: No, score=-104.558 tagged_above=-999 required=5 tests=[AWL=-1.958, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBr5Q4-GtdJV for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 06:32:05 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A6F8E21F8888 for <urn@ietf.org>; Fri,  9 Sep 2011 06:32:04 -0700 (PDT)
Received: (qmail invoked by alias); 09 Sep 2011 13:33:58 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 09 Sep 2011 15:33:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+wERcv3fSwoVjxVuDBPvh5v3WNOMdLV6GZs7dkuq aDEqt+hlHBKX5C
Message-ID: <4E6A15C1.5070702@gmx.de>
Date: Fri, 09 Sep 2011 15:33:53 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Svensson, Lars" <L.Svensson@dnb.de>
References: <4E3A37FE.7060609@helsinki.fi><vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de> <4E53857A.4000209@helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E4CA339@dbf-ex.AD.DDB.DE>
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840E4CA339@dbf-ex.AD.DDB.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, Bjoern Hoehrmann <derhoermi@gmx.net>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 13:32:05 -0000

On 2011-09-09 14:54, Svensson, Lars wrote:
> ...
> If I have a URN with a fragment, e. g. urn:nbn:aq:987-65432-1#chapter98,
> and make this URN "actionable" by prefixing it with a resolver-URI --
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98 -- is the
> fragment identifier then a part of the URN or of the http-URI? (And:
> does it really matter?)
> ...

The syntax is then defined by HTTP (RFC 2616) and URI (RFC 3986); so the 
identified resource is

   http://resolver.example.com/urn:nbn:aq:987-65432-1

any you apply the fragid "chapter98" to whatever is retrieved from that 
resource.

Best regards, Julian

From L.Svensson@dnb.de  Fri Sep  9 07:27:59 2011
Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27AA21F8B38 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 07:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.709
X-Spam-Level: 
X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.540,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we+jy1eVoLWD for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 07:27:58 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 43DC621F8ADC for <urn@ietf.org>; Fri,  9 Sep 2011 07:27:51 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 82256D6583; Fri,  9 Sep 2011 16:29:42 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 9 Sep 2011 16:29:41 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840E4CA34D@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [urn] URNs and URI <fragment>
Thread-Index: Acxu9MbXppe+1DxWR/KTvRSETjAhAgAB+1og
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <4E524CCC.4010800@helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE> <4E6A152A.5050704@gmx.de>
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 14:27:59 -0000

Julian wrote:

> On 2011-09-09 15:13, Svensson, Lars wrote:
> > ...
> > If I understand the discussion correctly, the question is if in
> > urn:isbn:1-234-56789-X#foo the #foo is part of the ISBN or not. If
> it's
> > part of the ISBN, the urn would be invalid since ISBNs cannot have
> > fragments. IMO a fragment (in the sense of RFC 3986) refers to the
> URI
> > as a whole and not to the NSS of a URN. I guess that there are
people
> on
> > this list who can shed some light on this.
> > ...
>=20
> It's not part of the ISBN -- I would have thought that's clear from
the
> URI spec.

Yes, that is what I thought, but I'm glad someone more knowledgeable
could confirm that. Thanks!

All the best,

Lars

From jar@creativecommons.org  Fri Sep  9 08:18:25 2011
Return-Path: <jar@creativecommons.org>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E9621F8AE6 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 08:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBbc2OFoMxay for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 08:18:25 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 553DE21F86AA for <urn@ietf.org>; Fri,  9 Sep 2011 08:18:25 -0700 (PDT)
Received: by qyk32 with SMTP id 32so493304qyk.10 for <urn@ietf.org>; Fri, 09 Sep 2011 08:20:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.44.1 with SMTP id y1mr1556385qce.294.1315581620238; Fri, 09 Sep 2011 08:20:20 -0700 (PDT)
Received: by 10.229.43.231 with HTTP; Fri, 9 Sep 2011 08:20:20 -0700 (PDT)
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840E4CA34D@dbf-ex.AD.DDB.DE>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <4E524CCC.4010800@helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE> <4E6A152A.5050704@gmx.de> <6DA97EFF2763174B8BDC409CA19729840E4CA34D@dbf-ex.AD.DDB.DE>
Date: Fri, 9 Sep 2011 11:20:20 -0400
Message-ID: <CACHXnaqjOaxmOTj_Lh5v59otY6aPhz34dA4Qun_cHt0qoa_Jxw@mail.gmail.com>
From: Jonathan Rees <jar@creativecommons.org>
To: urn@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 15:18:26 -0000

You could have it both ways by specifying a required # fragment id
semantics in the namespace registration, and say that any retrieved
representation has to respect that semantics.  That is, if the
namespace reg says #chapter1 refers to chapter 1, then any retrieved
representation in which #chapter1 meant something different would just
be incorrect, the same as if a representation for the wrong document
were retrieved.

I'm not sure I like this solution, but it does seem to both respect
3986 and allow namespace designers to say how they think fragids
should be used.

Just a thought.

Best
Jonathan

From stpeter@stpeter.im  Fri Sep  9 10:07:24 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E4A21F866A for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi1zDjrWxHW4 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:07:24 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30021F8663 for <urn@ietf.org>; Fri,  9 Sep 2011 10:07:23 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A13F041958; Fri,  9 Sep 2011 11:12:21 -0600 (MDT)
Message-ID: <4E6A483F.6010001@stpeter.im>
Date: Fri, 09 Sep 2011 11:09:19 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: rsalz@datapower.com, paulle@microsoft.com
Subject: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 17:07:24 -0000

I like UUIDs, for the reasons described in RFC 4122:

   One of the main reasons for using UUIDs is that no centralized
   authority is required to administer them.... As a result, generation
   on demand can be completely automated, and used for a variety of
   purposes.

However, RFC 4122 is a case of "one of these things is not like the
other". Every other formal namespace involves active management of the
URN assignment process, in accordance with RFC 3406. By contrast, URNs
in the urn:uuid: namespace are assigned without any management:

   The UUID generation algorithm described here supports very
   high allocation rates of up to 10 million per second per machine if
   necessary, so that they could even be used as transaction IDs....
   The unique ability to generate a new UUID without a registration
   process allows for UUIDs to be one of the URNs with the lowest
   minting cost.

Therefore it seems to me that, handy as UUIDs are, they don't deserve to
be URNs. Indeed, the existence of the urn:uuid: namespace causes
confusion because we periodically hear about people who want to register
formal namespaces for things like SHA hashes. I propose that it would be
proper and beneficial to publish an RFC that defines UUIDs without the
URN namespace (perhaps with a URI scheme instead) and that therefore
obsoletes RFC 4122 and declares it to be historic.

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From ted.ietf@gmail.com  Fri Sep  9 10:25:56 2011
Return-Path: <ted.ietf@gmail.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AD21F86C7 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA6GVOj2APnh for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:25:55 -0700 (PDT)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 752F821F86C1 for <urn@ietf.org>; Fri,  9 Sep 2011 10:25:55 -0700 (PDT)
Received: by gwb17 with SMTP id 17so2003557gwb.15 for <urn@ietf.org>; Fri, 09 Sep 2011 10:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I2BSX32gfw6HzPcbhYF9+nQKAvC26rdrUR+I/n/1QkQ=; b=TrA11LzTmmA1h1cKb/BsSpYnrS2s31SiU1Zdi9TPnsiNB1ZCp0+euSS4XtYvmEfwvm wmu534yvrcuLC5JuCLlThKzBwMacCkj6nFaWQr8uH+gvnbzRFJQtMsU04j+UhQ0TPtZm yopbay7sGrSGpn7he2FuEuDc6OBkKaBAjq8CY=
MIME-Version: 1.0
Received: by 10.236.179.103 with SMTP id g67mr13578961yhm.49.1315589268877; Fri, 09 Sep 2011 10:27:48 -0700 (PDT)
Received: by 10.236.110.174 with HTTP; Fri, 9 Sep 2011 10:27:48 -0700 (PDT)
In-Reply-To: <4E6A483F.6010001@stpeter.im>
References: <4E6A483F.6010001@stpeter.im>
Date: Fri, 9 Sep 2011 10:27:48 -0700
Message-ID: <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/alternative; boundary=20cf303ddbea0ab26404ac857f64
Cc: rsalz@datapower.com, paulle@microsoft.com, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 17:25:56 -0000

--20cf303ddbea0ab26404ac857f64
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <stpeter@stpeter.im>wrote:

> I like UUIDs, for the reasons described in RFC 4122:
>
>   One of the main reasons for using UUIDs is that no centralized
>   authority is required to administer them.... As a result, generation
>   on demand can be completely automated, and used for a variety of
>   purposes.
>
> However, RFC 4122 is a case of "one of these things is not like the
> other". Every other formal namespace involves active management of the
> URN assignment process, in accordance with RFC 3406. By contrast, URNs
> in the urn:uuid: namespace are assigned without any management:
>
>
So, I think you're mixing mechanism and desire effect.  The desired effect
is that URNs be unique across space and time.  The formal management
mechanisms are there to guarantee this property and to bind the resulting
identifier to a resource.  RFC 4122 says:

Identifier uniqueness considerations:
      This document specifies three algorithms to generate UUIDs: the
      first leverages the unique values of 802 MAC addresses to
      guarantee uniqueness, the second uses pseudo-random number
      generators, and the third uses cryptographic hashing and
      application-provided text strings.  As a result, the UUIDs
      generated according to the mechanisms here will be unique from all
      other UUIDs that have been or will be assigned.

If any of the algorithms mentioned can be shown not to guarantee uniqueness,
then I believe it should be removed by publication of a successor document.
If we are convinced that *no* algorithmic method can be used that generates
uniqueness, then perhaps a shift to a URI scheme (for which no such
guarantees are available) is appropriate.  But I'm not hearing that in your
argument.  Is there a credible risk that UUID URNs are not unique?

regards,

Ted






>   The UUID generation algorithm described here supports very
>   high allocation rates of up to 10 million per second per machine if
>   necessary, so that they could even be used as transaction IDs....
>   The unique ability to generate a new UUID without a registration
>   process allows for UUIDs to be one of the URNs with the lowest
>   minting cost.
>
> Therefore it seems to me that, handy as UUIDs are, they don't deserve to
> be URNs. Indeed, the existence of the urn:uuid: namespace causes
> confusion because we periodically hear about people who want to register
> formal namespaces for things like SHA hashes. I propose that it would be
> proper and beneficial to publish an RFC that defines UUIDs without the
> URN namespace (perhaps with a URI scheme instead) and that therefore
> obsoletes RFC 4122 and declares it to be historic.
>
> Thoughts?
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>

--20cf303ddbea0ab26404ac857f64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <span dir=3D"ltr">&l=
t;<a href=3D"mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>&gt;</span> w=
rote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I like UUIDs, for the reasons described in RFC 4122:<br>
<br>
 =A0 One of the main reasons for using UUIDs is that no centralized<br>
 =A0 authority is required to administer them.... As a result, generation<b=
r>
 =A0 on demand can be completely automated, and used for a variety of<br>
 =A0 purposes.<br>
<br>
However, RFC 4122 is a case of &quot;one of these things is not like the<br=
>
other&quot;. Every other formal namespace involves active management of the=
<br>
URN assignment process, in accordance with RFC 3406. By contrast, URNs<br>
in the urn:uuid: namespace are assigned without any management:<br>
<br>
 </blockquote><div><br>So, I think you&#39;re mixing mechanism and desire e=
ffect.=A0 The desired effect is that URNs be unique across space and time.=
=A0 The formal management mechanisms are there to guarantee this property a=
nd to bind the resulting identifier to a resource.=A0 RFC 4122 says:<br>
<br><pre>Identifier uniqueness considerations:
      This document specifies three algorithms to generate UUIDs: the
      first leverages the unique values of 802 MAC addresses to
      guarantee uniqueness, the second uses pseudo-random number
      generators, and the third uses cryptographic hashing and
      application-provided text strings.  As a result, the UUIDs
      generated according to the mechanisms here will be unique from all
      other UUIDs that have been or will be assigned.</pre>If any of the al=
gorithms mentioned can be shown not to guarantee uniqueness, then I believe=
 it should be removed by publication of a successor document.=A0 If we are =
convinced that *no* algorithmic method can be used that generates uniquenes=
s, then perhaps a shift to a URI scheme (for which no such guarantees are a=
vailable) is appropriate.=A0 But I&#39;m not hearing that in your argument.=
=A0 Is there a credible risk that UUID URNs are not unique?<br>
<br>regards,<br><br>Ted<br><br><br><br><br>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;">=A0 The UUID generation algorithm descri=
bed here supports very<br>

 =A0 high allocation rates of up to 10 million per second per machine if<br=
>
 =A0 necessary, so that they could even be used as transaction IDs....<br>
 =A0 The unique ability to generate a new UUID without a registration<br>
 =A0 process allows for UUIDs to be one of the URNs with the lowest<br>
 =A0 minting cost.<br>
<br>
Therefore it seems to me that, handy as UUIDs are, they don&#39;t deserve t=
o<br>
be URNs. Indeed, the existence of the urn:uuid: namespace causes<br>
confusion because we periodically hear about people who want to register<br=
>
formal namespaces for things like SHA hashes. I propose that it would be<br=
>
proper and beneficial to publish an RFC that defines UUIDs without the<br>
URN namespace (perhaps with a URI scheme instead) and that therefore<br>
obsoletes RFC 4122 and declares it to be historic.<br>
<br>
Thoughts?<br>
<br>
Peter<br>
<br>
--<br>
Peter Saint-Andre<br>
<a href=3D"https://stpeter.im/" target=3D"_blank">https://stpeter.im/</a><b=
r>
<br>
<br>
_______________________________________________<br>
urn mailing list<br>
<a href=3D"mailto:urn@ietf.org">urn@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/urn" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/urn</a><br>
</blockquote></div><br>

--20cf303ddbea0ab26404ac857f64--

From stpeter@stpeter.im  Fri Sep  9 10:51:48 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191C21F849D for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level: 
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7PZgCRTzG3S for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:51:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA72221F8562 for <urn@ietf.org>; Fri,  9 Sep 2011 10:51:45 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6ACFD4195A; Fri,  9 Sep 2011 11:56:43 -0600 (MDT)
Message-ID: <4E6A52A3.1020405@stpeter.im>
Date: Fri, 09 Sep 2011 11:53:39 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
In-Reply-To: <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: rsalz@datapower.com, paulle@microsoft.com, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 17:51:49 -0000

On 9/9/11 11:27 AM, Ted Hardie wrote:
> 
> On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
> 
>     I like UUIDs, for the reasons described in RFC 4122:
> 
>       One of the main reasons for using UUIDs is that no centralized
>       authority is required to administer them.... As a result, generation
>       on demand can be completely automated, and used for a variety of
>       purposes.
> 
>     However, RFC 4122 is a case of "one of these things is not like the
>     other". Every other formal namespace involves active management of the
>     URN assignment process, in accordance with RFC 3406. By contrast, URNs
>     in the urn:uuid: namespace are assigned without any management:
> 
> 
> So, I think you're mixing mechanism and desire effect.  The desired
> effect is that URNs be unique across space and time.  The formal
> management mechanisms are there to guarantee this property and to bind
> the resulting identifier to a resource.  RFC 4122 says:
> 
> Identifier uniqueness considerations:
>       This document specifies three algorithms to generate UUIDs: the
>       first leverages the unique values of 802 MAC addresses to
>       guarantee uniqueness, the second uses pseudo-random number
>       generators, and the third uses cryptographic hashing and
>       application-provided text strings.  As a result, the UUIDs
>       generated according to the mechanisms here will be unique from all
>       other UUIDs that have been or will be assigned.
> 
> If any of the algorithms mentioned can be shown not to guarantee
> uniqueness, then I believe it should be removed by publication of a
> successor document.  If we are convinced that *no* algorithmic method
> can be used that generates uniqueness, then perhaps a shift to a URI
> scheme (for which no such guarantees are available) is appropriate.  But
> I'm not hearing that in your argument.  Is there a credible risk that
> UUID URNs are not unique?

Interesting. So the UUID algorithm itself effectively provides a managed
process for URN assignment. Correct?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From ted.ietf@gmail.com  Fri Sep  9 11:29:18 2011
Return-Path: <ted.ietf@gmail.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5AE21F8726 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 11:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asibkoJe-enj for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 11:29:18 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1297A21F8610 for <urn@ietf.org>; Fri,  9 Sep 2011 11:29:17 -0700 (PDT)
Received: by qyk35 with SMTP id 35so1558122qyk.10 for <urn@ietf.org>; Fri, 09 Sep 2011 11:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvvqcsQMwdDCl6mwCiRwR9iTXP1onZxq3gx21OqzBow=; b=EyE8Il3XsLgzWqNmGHBvEEAEvAQDFzEP0KvDffHh+JrtrMAue5vo2Af2Oq+c4Mtl8W Iupg1aKwiI1ut3d+YP3ux7X97ZqPL8sOT/8fRsOMQkBLncMYjAEndor/oQbC/0BJjWzH QxeE8c7NVQ2yG3Kok1jVduZZIZurJYJMlhkns=
MIME-Version: 1.0
Received: by 10.229.10.198 with SMTP id q6mr500171qcq.66.1315593067295; Fri, 09 Sep 2011 11:31:07 -0700 (PDT)
Received: by 10.229.156.212 with HTTP; Fri, 9 Sep 2011 11:31:07 -0700 (PDT)
In-Reply-To: <4E6A52A3.1020405@stpeter.im>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com> <4E6A52A3.1020405@stpeter.im>
Date: Fri, 9 Sep 2011 11:31:07 -0700
Message-ID: <CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/alternative; boundary=0016364ed99e71f4b004ac86612b
Cc: rsalz@datapower.com, paulle@microsoft.com, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 18:29:18 -0000

--0016364ed99e71f4b004ac86612b
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre <stpeter@stpeter.im>wrote:


> Interesting. So the UUID algorithm itself effectively provides a managed
> process for URN assignment. Correct?
>
>
Yes, that's the theory.   Each of the algorithms is intended to provide a
process which guarantees uniqueness.  For the statistical algorithms, the
presumption has been that, run correctly, there is a vanishingly small
chance of collision; it's true that it is non-zero, but the chance of
collision due to human error in a managed system is probably higher.

regards,

Ted



> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>

--0016364ed99e71f4b004ac86612b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>&gt;</span> wrote=
:<br><div class=3D"gmail_quote"><div>=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
<div class=3D"h5">Interesting. So the UUID algorithm itself effectively pro=
vides a managed<br></div>
process for URN assignment. Correct?<br>
<div><div></div><div class=3D"h5"><br></div></div></blockquote><div><br>Yes=
, that&#39;s the theory.=A0=A0 Each of the algorithms is intended to provid=
e a process which guarantees uniqueness.=A0 For the statistical algorithms,=
 the presumption has been that, run correctly, there is a vanishingly small=
 chance of collision; it&#39;s true that it is non-zero, but the chance of =
collision due to human error in a managed system is probably higher.<br>
<br>regards,<br><br>Ted<br><br>=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;"><div><div class=3D"h5">
Peter<br>
<br>
--<br>
Peter Saint-Andre<br>
<a href=3D"https://stpeter.im/" target=3D"_blank">https://stpeter.im/</a><b=
r>
<br>
<br>
</div></div></blockquote></div><br>

--0016364ed99e71f4b004ac86612b--

From stpeter@stpeter.im  Fri Sep  9 11:35:16 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EA321F877F for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 11:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsYgNlpzgOQ2 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 11:35:15 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A57BC21F86EC for <urn@ietf.org>; Fri,  9 Sep 2011 11:35:10 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9AF9A41963; Fri,  9 Sep 2011 12:40:08 -0600 (MDT)
Message-ID: <4E6A5CD1.3070104@stpeter.im>
Date: Fri, 09 Sep 2011 12:37:05 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com> <4E6A52A3.1020405@stpeter.im> <CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com>
In-Reply-To: <CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: rsalz@datapower.com, paulle@microsoft.com, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 18:35:16 -0000

On 9/9/11 12:31 PM, Ted Hardie wrote:
> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stpeter@stpeter.im>> wrote:
>  
> 
>     Interesting. So the UUID algorithm itself effectively provides a managed
>     process for URN assignment. Correct?
> 
> 
> Yes, that's the theory.   Each of the algorithms is intended to provide
> a process which guarantees uniqueness.  For the statistical algorithms,
> the presumption has been that, run correctly, there is a vanishingly
> small chance of collision; it's true that it is non-zero, but the chance
> of collision due to human error in a managed system is probably higher.

Thanks. I'd never thought of it that way, but it makes sense. I hereby
retract the suggestion to obsolete RFC 4122. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From duerst@it.aoyama.ac.jp  Fri Sep  9 18:54:40 2011
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3E21F86A4 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 18:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.748
X-Spam-Level: 
X-Spam-Status: No, score=-99.748 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzfyCVJeB35J for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 18:54:40 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E721F86A1 for <urn@ietf.org>; Fri,  9 Sep 2011 18:54:39 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8A1uR2Q031508 for <urn@ietf.org>; Sat, 10 Sep 2011 10:56:27 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7988_10a2_184eb5d0_db50_11e0_aeee_001d096c5782; Sat, 10 Sep 2011 10:56:27 +0900
Received: from [IPv6:::1] ([133.2.210.1]:46998) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S154C2A5> for <urn@ietf.org> from <duerst@it.aoyama.ac.jp>; Sat, 10 Sep 2011 10:56:29 +0900
Message-ID: <4E6AC3BF.2080606@it.aoyama.ac.jp>
Date: Sat, 10 Sep 2011 10:56:15 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4E6A483F.6010001@stpeter.im>	<CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>	<4E6A52A3.1020405@stpeter.im>	<CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com> <4E6A5CD1.3070104@stpeter.im>
In-Reply-To: <4E6A5CD1.3070104@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rsalz@datapower.com, "urn@ietf.org" <urn@ietf.org>, paulle@microsoft.com
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 10 Sep 2011 01:54:40 -0000

On 2011/09/10 3:37, Peter Saint-Andre wrote:
> On 9/9/11 12:31 PM, Ted Hardie wrote:
>> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre<stpeter@stpeter.im
>> <mailto:stpeter@stpeter.im>>  wrote:
>>
>>
>>      Interesting. So the UUID algorithm itself effectively provides a managed
>>      process for URN assignment. Correct?
>>
>>
>> Yes, that's the theory.   Each of the algorithms is intended to provide
>> a process which guarantees uniqueness.  For the statistical algorithms,
>> the presumption has been that, run correctly, there is a vanishingly
>> small chance of collision; it's true that it is non-zero, but the chance
>> of collision due to human error in a managed system is probably higher.
>
> Thanks. I'd never thought of it that way, but it makes sense. I hereby
> retract the suggestion to obsolete RFC 4122. :)

Apart from the arguments already given, it'd be a very bad idea to just 
obsolete RFC 4122. Making preexisting urn:uuid: identifiers obsolete 
would be the worst in terms of persistency.

Regards,   Martin.

From K.Kocer@dnb.de  Mon Sep 12 00:25:38 2011
Return-Path: <K.Kocer@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC221F8634 for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.049
X-Spam-Level: 
X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IZ82tSu2gfG for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:25:37 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 1247D21F85FF for <urn@ietf.org>; Mon, 12 Sep 2011 00:25:36 -0700 (PDT)
Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 4451BD5B70 for <urn@ietf.org>; Mon, 12 Sep 2011 09:27:34 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 12 Sep 2011 09:27:34 +0200
Message-ID: <6DA97EFF2763174B8BDC409CA19729840A8E83C7@dbf-ex.AD.DDB.DE>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: URNs and URI <fragment> --> better URN <query> discussion?
Thread-Index: AcxxHXBPWdKG8TcHTIG0LiA3FsxLmg==
From: "Kocer, Kadir Karaca" <K.Kocer@dnb.de>
To: <urn@ietf.org>
Cc: =?iso-8859-1?Q?Kett=2C_J=FCrgen?= <J.Kett@dnb.de>, "Altenhoener, Reinhard" <R.Altenhoener@dnb.de>
Subject: [urn] URNs and URI <fragment> --> better URN <query> discussion?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 12 Sep 2011 07:25:38 -0000

Dear list members,

the Fragment Identifiers discussion is very interesting indeed.

German National Library, one of the largest members of user communities =
of both urn:isbn, urn:nbn, ... supports all efforts towards <fragments>.
May be the experience with about 20 million objects, 6 million URNs and =
an active project implementing a new generation of URN-System can bring =
some practical facts in this mostly theoretical discussion.

First of all personally I find extending the "Fragment Identifiers in =
NBN" discussion on ISBN namespace contra productive.
This *personal opinion* of mine has to do with existing bad ISBN =
practice in Germany. Therefore other countries with "ideal" =
ISBN-Administrations may have other opinions.

In Germany each ISBN costs money. Unfortunately to save this (small =
amount of) money it is a common practice that some publishers "recycle" =
existing ISBNs of sold-out publications and assign them a second/third =
time to a new publication.

A simple example: if we resolve the following ISBN
https://www.abebooks.co.uk/servlet/SearchResults?isbn=3D9783430185691
we see that more than one completely different publications (different =
topics, different authors, ... even different publishing orts) are filed =
under this "Uniform Resource Name".

A non-unique identifier is for most of use-cases completely useless, so =
I think we do not need a further discussion about if ISBN is a =
"persistent" identifier (for me in a long term preservation point of =
view NOT, because uniqueness *not* guaranteed) or if fragments can be =
defined for this identifier type.

I know it sounds hard and I have a certain, subjective point of view, =
but as project manager of the new URN system implementation I have to =
keep project milestones and deadlines in mind. That means if the scope =
of this discussion extends with the consequence of a delayed RFC, our =
new system must be implemented as a non-RFC-Conform system.
Such a development is really annoying for us and I'm sure no one in this =
list will find it positive.

The second fact that must be taken into account is, the fact that Julian =
Reschke already explained:

> The syntax is then defined by HTTP (RFC 2616)
> and URI (RFC 3986); so the identified resource is
>
> http://resolver.example.com/urn:nbn:aq:987-65432-1
>
> any you apply the fragid "chapter98" to whatever is
> retrieved from that resource

At the moment there is no built-in direct support for URNs in Internet =
Explorer/Firefox/..., so that *every* URN needs some kind of resolving =
mechanism.
Most widely implemented solution is a HTTP-Based-Resolver.

Unfortunately my Test-Implementation shows that neither Internet =
Explorer nor Firefox sends # Fragments to the HTTP server/servlet =
container. That means if we consider the Julian's example:
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
the resolver do *not* receive the information that the user requests =
only chapter98 and not any other chapter so it can not react in =
appropriate way.

This simple fact has huge effect on URN-Fragments discussion: even the =
perfect URN fragment solution we agree here will not have any practical =
effect in daily life, till a future Internet Explorer (version 14/15?) =
supports URNs natively and all older obsolete IE versions are updated.

As a consequence of those two points I tried to explain above, I suggest =
to start a new discussion:
queries in URN(:NBN).
Instead of
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
standardizing
http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=3D98
so the resolver can get the information, that only a small part of the =
resource and not the whole is required.

This solution seems to be the only solution that can in real existing =
desktop systems function and easily be implemented*.

What is your opinion?
Karaca Ko=E7er


(*) besides a REST based approach like
http://resolver.example.com/urn:nbn:aq:987-65432-1/chapter/98

--
Kadir Karaca Ko=E7er
Deutsche Nationalbibliothek
Informationstechnik
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49-69-1525-1735
Telefax: +49-69-1525-1799=20
http://www.dnb.de/=20


From julian.reschke@gmx.de  Mon Sep 12 00:39:43 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702421F8634 for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.243
X-Spam-Level: 
X-Spam-Status: No, score=-104.243 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1DaAIqCjwPd for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:39:43 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9A17721F84FA for <urn@ietf.org>; Mon, 12 Sep 2011 00:39:42 -0700 (PDT)
Received: (qmail invoked by alias); 12 Sep 2011 07:41:43 -0000
Received: from p508FAAE9.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.170.233] by mail.gmx.net (mp035) with SMTP; 12 Sep 2011 09:41:43 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/cubwTQnDc4aMPypTug5sB9n+INYx768P24Ab4Ce lVtvTGqbnreAhz
Message-ID: <4E6DB7B4.8020407@gmx.de>
Date: Mon, 12 Sep 2011 09:41:40 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Kocer, Kadir Karaca" <K.Kocer@dnb.de>
References: <6DA97EFF2763174B8BDC409CA19729840A8E83C7@dbf-ex.AD.DDB.DE>
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840A8E83C7@dbf-ex.AD.DDB.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: =?ISO-8859-1?Q?=22Kett=2C_J=FCrgen=22?= <J.Kett@dnb.de>, urn@ietf.org, "Altenhoener, Reinhard" <R.Altenhoener@dnb.de>
Subject: Re: [urn] URNs and URI <fragment> --> better URN <query> discussion?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 12 Sep 2011 07:39:43 -0000

On 2011-09-12 09:27, Kocer, Kadir Karaca wrote:
> ...
> ...
> At the moment there is no built-in direct support for URNs in Internet Explorer/Firefox/..., so that *every* URN needs some kind of resolving mechanism.
> Most widely implemented solution is a HTTP-Based-Resolver.
>
> Unfortunately my Test-Implementation shows that neither Internet Explorer nor Firefox sends # Fragments to the HTTP server/servlet container. That means if we consider the Julian's example:
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> the resolver do *not* receive the information that the user requests only chapter98 and not any other chapter so it can not react in appropriate way.
> ...

That's by design; not a bug.

> This simple fact has huge effect on URN-Fragments discussion: even the perfect URN fragment solution we agree here will not have any practical effect in daily life, till a future Internet Explorer (version 14/15?) supports URNs natively and all older obsolete IE versions are updated.

If your ultimate goal is to have URNs that are resolvable then why do 
you start with URNs in the first place?

> As a consequence of those two points I tried to explain above, I suggest to start a new discussion:
> queries in URN(:NBN).
> Instead of
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> standardizing
> http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=98
> so the resolver can get the information, that only a small part of the resource and not the whole is required.

If the goal is to make an HTTP-based resolver aware of the chapter 
number, then yes.

It seems to me that this just indicates that using the fragment 
identifier for use in the URN was a bad choice in the first place :-)

> This solution seems to be the only solution that can in real existing desktop systems function and easily be implemented*.
>
> What is your opinion?
> Karaca Koçer
>
>
> (*) besides a REST based approach like
> http://resolver.example.com/urn:nbn:aq:987-65432-1/chapter/98

Query parameter vs path segment is just a different notation and really 
has little to do with being Restful.

Best regards, Julian

From juha.hakala@helsinki.fi  Mon Sep 12 06:39:55 2011
Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2A21F8B5E for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 06:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.542
X-Spam-Level: 
X-Spam-Status: No, score=-4.542 tagged_above=-999 required=5 tests=[AWL=2.057,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvqkvnjSj-0Z for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 06:39: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 0334421F8B53 for <urn@ietf.org>; Mon, 12 Sep 2011 06:39:54 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p8CDfotC009981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2011 16:41:50 +0300
Message-ID: <4E6E0C1D.6030307@helsinki.fi>
Date: Mon, 12 Sep 2011 16:41:49 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <4E524CCC.4010800@helsinki.fi> <6DA97EFF2763174B8BDC409CA19729840E4CA33C@dbf-ex.AD.DDB.DE> <4E6A152A.5050704@gmx.de>
In-Reply-To: <4E6A152A.5050704@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 12 Sep 2011 13:39:56 -0000

Hello,

Julian Reschke wrote:
> On 2011-09-09 15:13, Svensson, Lars wrote:
>> ...
>> If I understand the discussion correctly, the question is if in
>> urn:isbn:1-234-56789-X#foo the #foo is part of the ISBN or not. If it's
>> part of the ISBN, the urn would be invalid since ISBNs cannot have
>> fragments. IMO a fragment (in the sense of RFC 3986) refers to the URI
>> as a whole and not to the NSS of a URN. I guess that there are people on
>> this list who can shed some light on this.
>> ...
> 
> It's not part of the ISBN -- I would have thought that's clear from the 
> URI spec.

I agree; #foo is not part of the ISBN, and that is clear both from the 
URI spec and the ISBN standard.

The current draft of RFC2141bis states that <fragment> is part of the 
NSS, the reason being that an identifier without a <fragment> identifies 
the entire resource, and an identifier with a <fragment> only the 
relevant part of the resource. For the same reason we have not 
considered <query> to be a part of the NSS.

We need to have a shared understanding of the impact of <fragment> usage 
to the resolution process. We will of course be dependent on HTTP 
functionality, and should not assume that the system design will be 
changed. Otherwise it would be a bad idea to use <fragment> at all.

I have assumed that a URN such as

http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98

would, like Julian says, first retrieve the entire resource, and then 
fragment identifier is applied on it. This is how HTTP works, and the 
Web users are used to this kind of behaviour. If we expect something 
else, then we should develop another solution to achieve it.

In contrast, when domain specific fragment identifiers are used (such as 
urn:nbn:aq:987-65432-1.chapter98) the will be the relevant fragment 
(e.g. the chapter 98) only, unless the domain specific fragment is 
mapped into <fragment> in the resolution process.

As regards this proposal by Kadir:

> As a consequence of those two points I tried to explain above, I suggest to start a new discussion:
> queries in URN(:NBN).
> Instead of
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> standardizing
> http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=98
> so the resolver can get the information, that only a small part of the resource and not the whole is required.

one idea behind the RFC2141bis revision has been to use <query> to 
deliver service parameters. While URN syntax will not say much about the 
services themselves, in the revision of RFC2483 I could already consider 
ways in which to expand resource retrieval service in such a manner that 
only predefined sections of a resource are retrieved. For instance, if a 
resource is a journal issue and the user wants just single article 
(certain pages), this could be specified in a <query> containing a 
retrieval request. Satisfying the request would not be done by an HTTP 
resolver, but a digital asset management application to which the 
resolver passes the request.

Whether this kind of usage of <query> would force us to reconsider the 
view that <query> is never a part of the NSS I haven't really thought 
about yet.

Best regards,

Juha
> 
> Best regards, Julian
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From stpeter@stpeter.im  Mon Sep 12 11:07:21 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E8A21F8B92 for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 11:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.39
X-Spam-Level: 
X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzz6ZeU9X0c4 for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 11:07:21 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E8CA821F8B90 for <urn@ietf.org>; Mon, 12 Sep 2011 11:07:20 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 99BF2419CB; Mon, 12 Sep 2011 12:12:35 -0600 (MDT)
Message-ID: <4E6E4AD3.8090002@stpeter.im>
Date: Mon, 12 Sep 2011 12:09:23 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
References: <4E6A483F.6010001@stpeter.im>	<CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>	<4E6A52A3.1020405@stpeter.im>	<CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com> <4E6A5CD1.3070104@stpeter.im> <4E6AC3BF.2080606@it.aoyama.ac.jp>
In-Reply-To: <4E6AC3BF.2080606@it.aoyama.ac.jp>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: rsalz@datapower.com, "urn@ietf.org" <urn@ietf.org>, paulle@microsoft.com
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 12 Sep 2011 18:07:21 -0000

On 9/9/11 7:56 PM, "Martin J. Dürst" wrote:
> On 2011/09/10 3:37, Peter Saint-Andre wrote:
>> On 9/9/11 12:31 PM, Ted Hardie wrote:
>>> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre<stpeter@stpeter.im
>>> <mailto:stpeter@stpeter.im>>  wrote:
>>>
>>>
>>>      Interesting. So the UUID algorithm itself effectively provides a
>>> managed
>>>      process for URN assignment. Correct?
>>>
>>>
>>> Yes, that's the theory.   Each of the algorithms is intended to provide
>>> a process which guarantees uniqueness.  For the statistical algorithms,
>>> the presumption has been that, run correctly, there is a vanishingly
>>> small chance of collision; it's true that it is non-zero, but the chance
>>> of collision due to human error in a managed system is probably higher.
>>
>> Thanks. I'd never thought of it that way, but it makes sense. I hereby
>> retract the suggestion to obsolete RFC 4122. :)
> 
> Apart from the arguments already given, it'd be a very bad idea to just
> obsolete RFC 4122. Making preexisting urn:uuid: identifiers obsolete
> would be the worst in terms of persistency.

Obsoleting RFC 4122 would not obsolete existing URNs in that namespace.

But I don't plan to try obsoleting RFC 4122 anyway, so I see no point in
discussing it further.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From juha.hakala@helsinki.fi  Tue Sep 13 01:05:24 2011
Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E673021F8B85 for <urn@ietfa.amsl.com>; Tue, 13 Sep 2011 01:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=1.200,  BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEKpIS0VOPc1 for <urn@ietfa.amsl.com>; Tue, 13 Sep 2011 01:05:24 -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 B6BEC21F8A7B for <urn@ietf.org>; Tue, 13 Sep 2011 01:05:22 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p8D7sh2R031022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 10:54:44 +0300
Message-ID: <4E6F0C43.6050803@helsinki.fi>
Date: Tue, 13 Sep 2011 10:54:43 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4E6A483F.6010001@stpeter.im>	<CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>	<4E6A52A3.1020405@stpeter.im>	<CA+9kkMC9cyYkpq60fR5B25eMbXDFCX_JLnwc0M_mefSaROK=hw@mail.gmail.com>	<4E6A5CD1.3070104@stpeter.im> <4E6AC3BF.2080606@it.aoyama.ac.jp> <4E6E4AD3.8090002@stpeter.im>
In-Reply-To: <4E6E4AD3.8090002@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rsalz@datapower.com, "urn@ietf.org" <urn@ietf.org>, paulle@microsoft.com
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 13 Sep 2011 08:05:25 -0000

Hello,

Based on this discussion, it seems to me that we should add into 
RFC3406bis a chapter which discusses obsoleting URN namespaces. We may 
also need to refine the paragraphs which discuss management of (formal) 
namespaces.

I see no problem in obsoleting experimental namespaces. Since there is 
no IANA registration, such decisions can be made by organizations which 
utilize these namespaces (which are not supposed to be persistent).

In contrast, informal namespaces should be treated in the same manner as 
the formal ones.

IANA may / should consider allowing deprecation of an informal or formal 
namespace if a) it has never been used (and this can be proven); b) it 
is consistently and extensively abused (and this can be proven); or c) 
if the registrant sends a request asking for deprecation. The cases of 
the last kind can happen e.g. when a namespace registration is replaced 
by a new one, and the new identifier standard requires another namespace.

There will also be cases when the registrant / user of a namespace 
disappears and the resolution services the organization has maintained 
collapse as a result. Such cases will be very problematic to deal with; 
even finding out what is going on can be difficult. Ideally somebody 
else will pick up the torch, but if this does not happen, it may be 
necessary to obsolete the namespace.

Deprecation of a namespace means only that no new URNs in that namespace 
should be assigned. Existing URNs will still be valid and they should 
remain managed and actionable as well.

As regards the UUID namespace, each URN:UUID is unique, so there is some 
justification to say that assignment of URN:UUIDs is a managed process. 
   There are other URN namespaces where the level of control is much 
higher, such as ISBN. There is nothing wrong with this; most PIDs allow 
a lot of diversity. For instance, assignment of Handles or ARKs may be 
either tightly controlled or relaxed, depending on who is using them. An 
important difference between Handles and DOI is that the latter is more 
strictly controlled.

People managing e.g. the Handle system and ARK system have no way of 
checking who is using these persistent identifiers and how they are 
using them. URNs are different; namespace registration is a control 
mechanism, and I am glad we have such a mechanism in place. Up to now, 
central management of the URN system has been relaxed; namespace such as 
URN:UUID where almost anything can be identified by almost anybody is 
not exactly a strictly managed one. IANA can tighten the control if they 
deem it necessary, or we can make more requirements in RFC3406bis. I 
don't see much need for this; we should just admit the fact that there 
will be all kinds of URN namespaces. And some of them, alas, will not be 
persistent. But at least for the time being for instance this

http://verkottaja.tieke.fi/urn:uuid:0113C86C-F6F9-FF39-3917-7AD0D560A92B/

HTTP URI is working fine.

Best regards,

Juha

Peter Saint-Andre wrote:
> On 9/9/11 7:56 PM, "Martin J. Dürst" wrote:
>> On 2011/09/10 3:37, Peter Saint-Andre wrote:
>>> On 9/9/11 12:31 PM, Ted Hardie wrote:
>>>> On Fri, Sep 9, 2011 at 10:53 AM, Peter Saint-Andre<stpeter@stpeter.im
>>>> <mailto:stpeter@stpeter.im>>  wrote:
>>>>
>>>>
>>>>      Interesting. So the UUID algorithm itself effectively provides a
>>>> managed
>>>>      process for URN assignment. Correct?
>>>>
>>>>
>>>> Yes, that's the theory.   Each of the algorithms is intended to provide
>>>> a process which guarantees uniqueness.  For the statistical algorithms,
>>>> the presumption has been that, run correctly, there is a vanishingly
>>>> small chance of collision; it's true that it is non-zero, but the chance
>>>> of collision due to human error in a managed system is probably higher.
>>> Thanks. I'd never thought of it that way, but it makes sense. I hereby
>>> retract the suggestion to obsolete RFC 4122. :)
>> Apart from the arguments already given, it'd be a very bad idea to just
>> obsolete RFC 4122. Making preexisting urn:uuid: identifiers obsolete
>> would be the worst in terms of persistency.
> 
> Obsoleting RFC 4122 would not obsolete existing URNs in that namespace.
> 
> But I don't plan to try obsoleting RFC 4122 anyway, so I see no point in
> discussing it further.
> 
> Peter
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From mdolan@newtbt.com  Fri Sep  9 10:26:22 2011
Return-Path: <mdolan@newtbt.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADDE21F8560 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP3lboYN+xto for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:26:22 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E21C021F855F for <urn@ietf.org>; Fri,  9 Sep 2011 10:26:21 -0700 (PDT)
Received: from MikeVAIO2 (108-64-213-237.lightspeed.sndgca.sbcglobal.net [108.64.213.237]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LZzGf-1RRoIc18Iv-00lKpT; Fri, 09 Sep 2011 13:28:16 -0400
From: "Michael A Dolan" <mdolan@newtbt.com>
To: <urn@ietf.org>
References: <4E6A483F.6010001@stpeter.im>
In-Reply-To: <4E6A483F.6010001@stpeter.im>
Date: Fri, 9 Sep 2011 10:28:12 -0700
Message-ID: <016001cc6f15$dbb6ac00$93240400$@newtbt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKYzu2t9n/EjMeht0TlVRiimwvySJOsjI7g
Content-Language: en-us
X-Provags-ID: V02:K0:3L59RgS46kK+OfP7lR3O4v3ciVbEYHuO/TMiS6AMOQL C4VUejeOrFiC6Q5tsKZOxDkV4OFYYz+1rqWQ6ybzG9ef7lQuO2 zYcpkFuNHB7NKXTnU827WFA49SrgzrFxYn5SuKun2a8bv938SY wnIxfBHG8keu1kUYuWX4c2jw1vchOWaMks02Tac6LKLvURzCXJ YhLB4ZHMVBtaJZngHqUJzHB3aWP398D3hDJBz8Zgy95d5ys60Z NUHQAyct5EFoZwuNn7Pb9+BozvfsXzEryXzK+Z+bmLKXhkYyLI WpPEC/Qbu8Zpkf/Dhp2N3osd6YkpQNwgIL8I0S16j4JRzTKPPB nquzCT0d07ZkFyKmt1HA=
X-Mailman-Approved-At: Tue, 13 Sep 2011 10:34:12 -0700
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 17:28:12 -0000

RFC4122 is in pretty widespread use.  So, any new RFC would still need to be
backwards compatible.

-----Original Message-----
From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Peter
Saint-Andre
Sent: Friday, September 09, 2011 10:09 AM
To: urn@ietf.org
Cc: rsalz@datapower.com; paulle@microsoft.com
Subject: [urn] the UUID namespace

I like UUIDs, for the reasons described in RFC 4122:

   One of the main reasons for using UUIDs is that no centralized
   authority is required to administer them.... As a result, generation
   on demand can be completely automated, and used for a variety of
   purposes.

However, RFC 4122 is a case of "one of these things is not like the other".
Every other formal namespace involves active management of the URN
assignment process, in accordance with RFC 3406. By contrast, URNs in the
urn:uuid: namespace are assigned without any management:

   The UUID generation algorithm described here supports very
   high allocation rates of up to 10 million per second per machine if
   necessary, so that they could even be used as transaction IDs....
   The unique ability to generate a new UUID without a registration
   process allows for UUIDs to be one of the URNs with the lowest
   minting cost.

Therefore it seems to me that, handy as UUIDs are, they don't deserve to be
URNs. Indeed, the existence of the urn:uuid: namespace causes confusion
because we periodically hear about people who want to register formal
namespaces for things like SHA hashes. I propose that it would be proper and
beneficial to publish an RFC that defines UUIDs without the URN namespace
(perhaps with a URI scheme instead) and that therefore obsoletes RFC 4122
and declares it to be historic.

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


From mdolan@newtbt.com  Fri Sep  9 10:31:56 2011
Return-Path: <mdolan@newtbt.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD221F86D0 for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpBtXLmU5dEy for <urn@ietfa.amsl.com>; Fri,  9 Sep 2011 10:31:54 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id F0E1421F85C0 for <urn@ietf.org>; Fri,  9 Sep 2011 10:31:53 -0700 (PDT)
Received: from MikeVAIO2 (108-64-213-237.lightspeed.sndgca.sbcglobal.net [108.64.213.237]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0ML6mf-1R2LwP3PiD-0008xv; Fri, 09 Sep 2011 13:33:46 -0400
From: "Michael A Dolan" <mdolan@newtbt.com>
To: <urn@ietf.org>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
In-Reply-To: <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com>
Date: Fri, 9 Sep 2011 10:33:42 -0700
Message-ID: <017701cc6f16$a00c5c30$e0251490$@newtbt.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01CC6EDB.F3B0DF90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKYzu2t9n/EjMeht0TlVRiimwvySAFMCDTqk6IueuA=
Content-Language: en-us
X-Provags-ID: V02:K0:B/0kuyTzvKcaAT44XYV3jFFGD7uAATzXBb7TjiEVUty yMfDpT7cBbWakxOiw/3h6oAB9O5HrrpEjymFplfGElF1AtFVFe PBM4aUFEfkdSq1Sh9axM5kPQ5vwMAv1u312foRHak05rLffwzU KYPx6UHAPSAGyol7EzCSHTNIBpE+H/X4aGWlGZJ+46HqJB+Htg qrBG5YI49ZNu5SRPZckdTjCPUrSSOZOwYFqk/jdqPlWgjrKLce 66hBuW+8ER5yO2XZQVEkikEI/XUWtsIHjzfFTvuumeMeNPx4Lh 4gpRhOlcY1Nu6f/bqRETi4UmT/VxPBVfogb8j1GT4ATfIYAOOP YMS1Y6o2TKmunaEkQp+U=
X-Mailman-Approved-At: Tue, 13 Sep 2011 10:34:12 -0700
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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 Sep 2011 17:31:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0178_01CC6EDB.F3B0DF90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I should add that UUID's are used widely to number media assets and are thus
a namespace and are thus appropriate for a URN encoding.

 

There are different forms for constructing UUIDs.  Some are guaranteed to be
unique as they are based on the IEEE MAC address namespace. Some are
"statistically unique".

 

                Mike

 

From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Ted
Hardie
Sent: Friday, September 09, 2011 10:28 AM
To: Peter Saint-Andre
Cc: rsalz@datapower.com; paulle@microsoft.com; urn@ietf.org
Subject: Re: [urn] the UUID namespace

 


On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <stpeter@stpeter.im>
wrote:

I like UUIDs, for the reasons described in RFC 4122:

  One of the main reasons for using UUIDs is that no centralized
  authority is required to administer them.... As a result, generation
  on demand can be completely automated, and used for a variety of
  purposes.

However, RFC 4122 is a case of "one of these things is not like the
other". Every other formal namespace involves active management of the
URN assignment process, in accordance with RFC 3406. By contrast, URNs
in the urn:uuid: namespace are assigned without any management:


So, I think you're mixing mechanism and desire effect.  The desired effect
is that URNs be unique across space and time.  The formal management
mechanisms are there to guarantee this property and to bind the resulting
identifier to a resource.  RFC 4122 says:

Identifier uniqueness considerations:
      This document specifies three algorithms to generate UUIDs: the
      first leverages the unique values of 802 MAC addresses to
      guarantee uniqueness, the second uses pseudo-random number
      generators, and the third uses cryptographic hashing and
      application-provided text strings.  As a result, the UUIDs
      generated according to the mechanisms here will be unique from all
      other UUIDs that have been or will be assigned.

If any of the algorithms mentioned can be shown not to guarantee uniqueness,
then I believe it should be removed by publication of a successor document.
If we are convinced that *no* algorithmic method can be used that generates
uniqueness, then perhaps a shift to a URI scheme (for which no such
guarantees are available) is appropriate.  But I'm not hearing that in your
argument.  Is there a credible risk that UUID URNs are not unique?

regards,

Ted




 

  The UUID generation algorithm described here supports very
  high allocation rates of up to 10 million per second per machine if
  necessary, so that they could even be used as transaction IDs....
  The unique ability to generate a new UUID without a registration
  process allows for UUIDs to be one of the URNs with the lowest
  minting cost.

Therefore it seems to me that, handy as UUIDs are, they don't deserve to
be URNs. Indeed, the existence of the urn:uuid: namespace causes
confusion because we periodically hear about people who want to register
formal namespaces for things like SHA hashes. I propose that it would be
proper and beneficial to publish an RFC that defines UUIDs without the
URN namespace (perhaps with a URI scheme instead) and that therefore
obsoletes RFC 4122 and declares it to be historic.

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn

 


------=_NextPart_000_0178_01CC6EDB.F3B0DF90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I should add that UUID&#8217;s are used widely to number media assets =
and are thus a namespace and are thus appropriate for a URN =
encoding.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>There are different forms for constructing UUIDs.&nbsp; Some are =
guaranteed to be unique as they are based on the IEEE MAC address =
namespace. Some are &#8220;statistically =
unique&#8221;.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; Mike<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] <b>On Behalf Of =
</b>Ted Hardie<br><b>Sent:</b> Friday, September 09, 2011 10:28 =
AM<br><b>To:</b> Peter Saint-Andre<br><b>Cc:</b> rsalz@datapower.com; =
paulle@microsoft.com; urn@ietf.org<br><b>Subject:</b> Re: [urn] the UUID =
namespace<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><br>On Fri, =
Sep 9, 2011 at 10:09 AM, Peter Saint-Andre &lt;<a =
href=3D"mailto:stpeter@stpeter.im">stpeter@stpeter.im</a>&gt; =
wrote:<o:p></o:p></p><div><blockquote =
style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in =
6.0pt;margin-left:4.8pt;margin-right:0in'><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'>I like UUIDs, for the reasons described =
in RFC 4122:<br><br>&nbsp; One of the main reasons for using UUIDs is =
that no centralized<br>&nbsp; authority is required to administer =
them.... As a result, generation<br>&nbsp; on demand can be completely =
automated, and used for a variety of<br>&nbsp; purposes.<br><br>However, =
RFC 4122 is a case of &quot;one of these things is not like =
the<br>other&quot;. Every other formal namespace involves active =
management of the<br>URN assignment process, in accordance with RFC =
3406. By contrast, URNs<br>in the urn:uuid: namespace are assigned =
without any management:<o:p></o:p></p></blockquote><div><p =
class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>So, I think you're =
mixing mechanism and desire effect.&nbsp; The desired effect is that =
URNs be unique across space and time.&nbsp; The formal management =
mechanisms are there to guarantee this property and to bind the =
resulting identifier to a resource.&nbsp; RFC 4122 =
says:<o:p></o:p></p><pre>Identifier uniqueness =
considerations:<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
document specifies three algorithms to generate UUIDs: =
the<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; first leverages =
the unique values of 802 MAC addresses =
to<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; guarantee =
uniqueness, the second uses pseudo-random =
number<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generators, =
and the third uses cryptographic hashing =
and<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
application-provided text strings.&nbsp; As a result, the =
UUIDs<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generated =
according to the mechanisms here will be unique from =
all<o:p></o:p></pre><pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other UUIDs that =
have been or will be assigned.<o:p></o:p></pre><p class=3DMsoNormal>If =
any of the algorithms mentioned can be shown not to guarantee =
uniqueness, then I believe it should be removed by publication of a =
successor document.&nbsp; If we are convinced that *no* algorithmic =
method can be used that generates uniqueness, then perhaps a shift to a =
URI scheme (for which no such guarantees are available) is =
appropriate.&nbsp; But I'm not hearing that in your argument.&nbsp; Is =
there a credible risk that UUID URNs are not =
unique?<br><br>regards,<br><br>Ted<br><br><br><br><br>&nbsp;<o:p></o:p></=
p></div><blockquote style=3D'border:none;border-left:solid #CCCCCC =
1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p =
class=3DMsoNormal>&nbsp; The UUID generation algorithm described here =
supports very<br>&nbsp; high allocation rates of up to 10 million per =
second per machine if<br>&nbsp; necessary, so that they could even be =
used as transaction IDs....<br>&nbsp; The unique ability to generate a =
new UUID without a registration<br>&nbsp; process allows for UUIDs to be =
one of the URNs with the lowest<br>&nbsp; minting cost.<br><br>Therefore =
it seems to me that, handy as UUIDs are, they don't deserve to<br>be =
URNs. Indeed, the existence of the urn:uuid: namespace =
causes<br>confusion because we periodically hear about people who want =
to register<br>formal namespaces for things like SHA hashes. I propose =
that it would be<br>proper and beneficial to publish an RFC that defines =
UUIDs without the<br>URN namespace (perhaps with a URI scheme instead) =
and that therefore<br>obsoletes RFC 4122 and declares it to be =
historic.<br><br>Thoughts?<br><br>Peter<br><br>--<br>Peter =
Saint-Andre<br><a href=3D"https://stpeter.im/" =
target=3D"_blank">https://stpeter.im/</a><br><br><br>____________________=
___________________________<br>urn mailing list<br><a =
href=3D"mailto:urn@ietf.org">urn@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/urn" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/urn</a><o:p></o:p=
></p></blockquote></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_0178_01CC6EDB.F3B0DF90--


From masinter@adobe.com  Fri Sep 16 04:07:19 2011
Return-Path: <masinter@adobe.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A294C21F884C for <urn@ietfa.amsl.com>; Fri, 16 Sep 2011 04:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dc9TwEukT1y for <urn@ietfa.amsl.com>; Fri, 16 Sep 2011 04:07:18 -0700 (PDT)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0FD21F8AF8 for <urn@ietf.org>; Fri, 16 Sep 2011 04:07:17 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTnMuXrLmBC2W5/Wj54FKTuWc3Cdqx+1e@postini.com; Fri, 16 Sep 2011 04:09:33 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8GB7nC7022746 for <urn@ietf.org>; Fri, 16 Sep 2011 04:07:50 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p8GB932d011740 for <urn@ietf.org>; Fri, 16 Sep 2011 04:09:15 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 16 Sep 2011 04:09:02 -0700
From: Larry Masinter <masinter@adobe.com>
To: "urn@ietf.org" <urn@ietf.org>
Date: Fri, 16 Sep 2011 04:08:38 -0700
Thread-Topic: [urn] the UUID namespace
Thread-Index: AQKYzu2t9n/EjMeht0TlVRiimwvySAFMCDTqk6IueuCACoqukA==
Message-ID: <C68CB012D9182D408CED7B884F441D4D05D45EB135@nambxv01a.corp.adobe.com>
References: <4E6A483F.6010001@stpeter.im> <CA+9kkMANG22L0qfWJPqqS1jZBGpX-udVFkMGJSDsT_C_c6RV3Q@mail.gmail.com> <017701cc6f16$a00c5c30$e0251490$@newtbt.com>
In-Reply-To: <017701cc6f16$a00c5c30$e0251490$@newtbt.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [urn] the UUID namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 16 Sep 2011 11:07:19 -0000

RFC 4122 says "Since UUIDs are unique and persistent ."  but in what way ar=
e UUIDs "persistent"?=20

UUIDs might be persistently unique. UUIDs are not persistently resolvable, =
or even persistently confirmable, i.e., if someone claims to resolve a UUID=
 to a resource, is can that resolution be confirmed in any way?=20

Personally, what I don't like about urn:uuid is that the "naming authority"=
  (i.e., "uuid") doesn't in fact name an organization or authority or syste=
m for managing and persistently providing the discovery of urn -> resource =
mapping, or even merely confirming that a purported URN -> resource mapping=
 might be correct.=20

I see no point in obsoleting urn:uuid, since it is widely used in deployed =
software (as is uuid: without a urn: prefix, alas), but I'd like to encoura=
ge those proposing future URN namespaces to avoid systems without an active=
 authority or method.  Of course, uniqueness of the URN strings is necessar=
y for providing reliable discovery or validation.

Larry


From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Micha=
el A Dolan
Sent: Friday, September 09, 2011 6:34 PM
To: urn@ietf.org
Subject: Re: [urn] the UUID namespace

I should add that UUID's are used widely to number media assets and are thu=
s a namespace and are thus appropriate for a URN encoding.

There are different forms for constructing UUIDs.=A0 Some are guaranteed to=
 be unique as they are based on the IEEE MAC address namespace. Some are "s=
tatistically unique".

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mike

From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Ted H=
ardie
Sent: Friday, September 09, 2011 10:28 AM
To: Peter Saint-Andre
Cc: rsalz@datapower.com; paulle@microsoft.com; urn@ietf.org
Subject: Re: [urn] the UUID namespace


On Fri, Sep 9, 2011 at 10:09 AM, Peter Saint-Andre <stpeter@stpeter.im> wro=
te:
I like UUIDs, for the reasons described in RFC 4122:

=A0 One of the main reasons for using UUIDs is that no centralized
=A0 authority is required to administer them.... As a result, generation
=A0 on demand can be completely automated, and used for a variety of
=A0 purposes.

However, RFC 4122 is a case of "one of these things is not like the
other". Every other formal namespace involves active management of the
URN assignment process, in accordance with RFC 3406. By contrast, URNs
in the urn:uuid: namespace are assigned without any management:

So, I think you're mixing mechanism and desire effect.=A0 The desired effec=
t is that URNs be unique across space and time.=A0 The formal management me=
chanisms are there to guarantee this property and to bind the resulting ide=
ntifier to a resource.=A0 RFC 4122 says:
Identifier uniqueness considerations:
=A0=A0=A0=A0=A0 This document specifies three algorithms to generate UUIDs:=
 the
=A0=A0=A0=A0=A0 first leverages the unique values of 802 MAC addresses to
=A0=A0=A0=A0=A0 guarantee uniqueness, the second uses pseudo-random number
=A0=A0=A0=A0=A0 generators, and the third uses cryptographic hashing and
=A0=A0=A0=A0=A0 application-provided text strings.=A0 As a result, the UUID=
s
=A0=A0=A0=A0=A0 generated according to the mechanisms here will be unique f=
rom all
=A0=A0=A0=A0=A0 other UUIDs that have been or will be assigned.
If any of the algorithms mentioned can be shown not to guarantee uniqueness=
, then I believe it should be removed by publication of a successor documen=
t.=A0 If we are convinced that *no* algorithmic method can be used that gen=
erates uniqueness, then perhaps a shift to a URI scheme (for which no such =
guarantees are available) is appropriate.=A0 But I'm not hearing that in yo=
ur argument.=A0 Is there a credible risk that UUID URNs are not unique?

regards,

Ted




=A0
=A0 The UUID generation algorithm described here supports very
=A0 high allocation rates of up to 10 million per second per machine if
=A0 necessary, so that they could even be used as transaction IDs....
=A0 The unique ability to generate a new UUID without a registration
=A0 process allows for UUIDs to be one of the URNs with the lowest
=A0 minting cost.

Therefore it seems to me that, handy as UUIDs are, they don't deserve to
be URNs. Indeed, the existence of the urn:uuid: namespace causes
confusion because we periodically hear about people who want to register
formal namespaces for things like SHA hashes. I propose that it would be
proper and beneficial to publish an RFC that defines UUIDs without the
URN namespace (perhaps with a URI scheme instead) and that therefore
obsoletes RFC 4122 and declares it to be historic.

Thoughts?

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn