gmane.ietf.urn

Fwd: Last Call: (A Uniform Resource Name (URN) Namespace for Examples) to Best Current Practice

Julian Reschke — 2013-03-13T16:50:22

(FYI)

-------- Original Message --------
Subject: Last Call: <draft-saintandre-urn-example-04.txt> (A Uniform 
Resource Name (URN) Namespace for Examples) to Best Current Practice
Date: Tue, 12 Mar 2013 09:49:06 -0700
From: The IESG <iesg-secretary< at >ietf.org>
Reply-To: ietf< at >ietf.org
To: IETF-Announce <ietf-announce< at >ietf.org>

The IESG has received a request from an individual submitter to consider
the following document:
- 'A Uniform Resource Name (URN) Namespace for Examples'
   <draft-saintandre-urn-example-04.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf< at >ietf.org mailing lists by 2013-04-09. Exceptionally, comments may be
sent to iesg< at >ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

    This document defines a Uniform Resource Name (URN) namespace
    identifier enabling generation of URNs that are appr

draft-saintandre-urn-example-03

Julian Reschke — 2013-03-08T11:45:30

Hi,

I was looking for discussion about draft-saintandre-urn-example-03 
(which is in status "publication requested"), but almost everything I 
could find on the mailing list were unrelated discussions (about what 
type of resources URNs should be used for).

If anybody is disagreeing to the introduction of the "example" 
namespace, please speak up.

Best regards, Julian

draft-montemurro-gsma-imei-urn-13 defining a URN namespace for the GSMA and sub namespace for the IMEI

Andrew Allen — 2013-03-08T11:44:38

The following revised draft was submitted a few weeks ago.

http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-13.txt


the abstract is as follows:

   This specification defines a Uniform Resource Name namespace for the
   GSMA (GSM Association)and a sub-namespace for the IMEI (International
   Mobile station Equipment Identity), and associated parameter for the
   IMEISV (International Mobile station Equipment Identity and Software
   Version number).  The IMEI is 15 decimal digits long and the IMEISV
   is 16 decimal digits long and both are encoded using Binary Encoded
   Decimal (BCD).  The IMEI and IMEISV were introduced as part of the
   specification for Global System for Mobile communications(GSM) and
   are also now incorporated by the 3rd Generation Partnership Project
   (3GPP) as part of the 3GPP specification for GSM, the Universal
   Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term
   Evolution).  The IMEI and IMEISV are used to uniquely identify Mobile
   Equipment within t

Re: URN fragments

Svensson, Lars — 2013-02-27T08:37:46

Juha, Julian, all,

On February 27, 2013, 08:03, Juha wrote 

I think this depends on your urn namespace. In my opinion, we need to differ between queries that "operate on the urn itself" (in lack of a better description) and queries aimed at passing information to resolution services. As to the question if the query is part of the urn or not, my reading of rfc 3986 §3.4 is that it _is_ part of the urn
[[
The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.]]
If the query component ends at the end of the URI, it must be part of it.

Regarding the difference between queries in the context of the urn itself and in the context of resolution services, I made up a case to illustrate my point (thereby deliberately moving away from urn:nbn and urn:isbn).

In order to ensure that we can always identify integers in a location-independent way, we have registered the urn namespace 'int'. The NSS is defined as eight hexadec

Re: URN fragments

Juha Hakala — 2013-02-27T07:03:20

Hello,

On 26.2.2013 21:53, Julian Reschke wrote:

You have to be careful with the word "identify" in the URN context.

 From the URN point of view, the resource identified does not change 
when a query is added, if queries are used to facilitate the services 
specified in RFC 2483. All these services are related to one and only 
one identified resource.  A user can request for instance the resource 
itself, metadata about it, its current URL or URLs, and so forth. In 
practice, HTTP URIs (locations) the URN resolves to and the things that 
are being retrieved change, but the resource identified by the (location 
independent) URN does not.

I suppose it will not be possible to prevent URN implementers from 
constructing systems in which query is used to enable identification of 
multiple resources using the "absolute" URN as the starting point. But 
if the URN syntax says that the query is not part of the namespace 
specific string, then such an URN implementation is violating the syntax 
specification. And

Re: URN fragments

Julian Reschke — 2013-02-26T19:53:20

I was actually talking about the query part; sorry for the confusion.

It's up to the URN or NIS syntax to describe what the query part means, 
and how it applies to different namespaces. But in *general*, adding a 
query part to a URI changes the resource being identified.

Best regards, Julian

Re: URN fragments

2013-02-26T19:26:21

Hello,

Quoting Peter Saint-Andre <stpeter< at >stpeter.im>:



It is a different string, thus a different URI, as dictated by RFC 3986.

But it is the same URN, since fragment is not part of the Namespace  
specific string, as specified by the Alfred Hoenes' version of the URN  
syntax, or any other syntax specification which approves the current  
idea that fragment is not part of the NSS. And we know already that  
incorporating the fragment into NSS would cause a lot of avoidable  
trouble (for instance, many namespaces could not use fragment at all).

Of course this whole point is entirely theoretical. If IETF cannot  
live with the idea that URN and URN + fragment still identify the same  
thing and are in that sense the same URN, we can extend the syntax so  
that after NSS one can add fragment and / or query into the URN string  
itself. Then, but only then, URN and URN + fragment are different.  
Different in which way exactly should of course be discussed, and  
whatever we do with the chapter dealing w

Re: URN fragments

Peter Saint-Andre — 2013-02-26T17:10:24

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/26/13 9:01 AM, Julian Reschke wrote:

Correct. As Martin suggested, one might refer to the
organizationally-assigned or algorithmically-determined URN as an
"absolute URN", but that doesn't change the fact that absolute+query
or absolute+fragment is still a different URN.

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRLOx/AAoJEOoGpJErxa2p9aMQAKoZUm0Uq0Sa0xQ23TsmKqhL
i7C4PKkYJ8dpjKWJ65SVFTKn1jCr+td2oR+qNMny7MqGm58GTcmmkYmTPlCx39I8
UhpAXw3jL9HXScLpdUCGtV3IPPuiMVT+FLHfqVdXm/sbew/ICe9KwDVmCYKEve0y
fMzlW3PdQPPjncBjTFdHsPpmAVS/gn7NZ4sX7hD8q2bMn3Cym+bSjRRK8L4k/it8
h+xGPOXi6waOE4EfZJcL2Sme+4u5uN98aSE6lBxa1J1J9L8ZzNU7z1hhdrv+iztH
1yT1QaS2jEj5uN7V8dhI6LkRf3yy883j8WKyBs4BvLYQG++C+hboQgyAuh/O7+O5
LmHQtsLPQWjsNoawa2lceAs+MNcLVH3+PPkT6jJ3rxPDITYay/d/0Byr6SAPYs6Y
mfiWg5w+1A69KSEu+n9nJnpPyqoUZBjJ8YfiiwIr1F/Ft1NjFD2+v

Re: URN fragments

Julian Reschke — 2013-02-26T16:01:12

Well, it's a different string, thus a different URN.

 > ...

Best regards, Julian

Re: query component in URNs

Keith Moore — 2013-02-25T14:40:57

Uh, no.   The entire space of URI queries is specific to the target system.

In general, any resource (not just those named by URNs) is potentially 
able to have different services requested from it. That the URI syntax 
doesn't support a way to ask for each service is perhaps unfortunate, 
but for better or worse, that's the way it was designed.   Making the 
URI syntax work differently for URNs than the way it works for other 
resource names is not a good idea.

Keith

Re: query component in URNs

Juha Hakala — 2013-02-25T09:18:57

Hello,

On 24.2.2013 5:58, Keith Moore wrote:

Query semantics for URN will be richer than for other URIs due to extra 
functionality supported by resolution services. Queries specific to the 
URN will be processed by the appropriate URN resolution service, which 
will not pass them on as such. Instead they will be mapped to the form 
supported by the appropriate target system.

For instance, if the requested service is I2C (URI to URC), the 
resolution service would map the URN into a search statement encoded as 
HTTP URI. The exact syntax of the search will depend on search / 
retrieval protocol used.

Let us assume that a user wants metadata related to a book he's 
interested in. The client he's using would assemble a URN in the format 
URN:ISBN:<ISBN-number> plus a query indicating that the user wants 
resource description in Dublin Core format. Choosing the OPAC of the 
Library of Congress OPAC as the target, the URN resolver would map the 
URN sent by the client system into a HTTP URI like this:

http:

Re: query component in URNs

Keith Moore — 2013-02-24T03:58:11

Why should query semantics for URNs be different than for other URIs?
i.e. Why isn't a query on a URN semantically equivalent to the same 
query on the underlying resource?

Similarly, why isn't a fragment on a URN semantically equivalent to the 
same fragment of the underlying resource?
(granted, fragments are problematic for any kind of resource that can 
map to different formats with different ways of specifying fragments, 
but that's no worse for URNs than for any other kind of URI for which 
content-negotiation comes into play)

I don't think it makes sense to overload URN query and fragment 
semantics to mean different things than they mean for other URIs.

Keith

Re: URN fragments

Juha Hakala — 2013-02-22T06:57:10

Hi,

On 22.2.2013 5:36, Peter Saint-Andre wrote:

Despite the addition of fragment and query the URN itself remains the 
same, even though the HTTP URI changes.

"Added to the URN" means that neither query nor fragment are part of the 
URN, or more specifically, its namespace specific string. When something 
is identified, more or less formally, the NSS is and must always be 
sufficient for that, and RFC 2141 does not provide any functionality 
beyond that. Full alignment with RFC 3986 would in this interpretation 
mean that once a resource has been identified with a URN, anybody can 
add a fragment to the URN in order to pinpoint a location within the 
resource (for the browsers to act upon), or a query to demand a service 
from the URN resolver.

Syntactically and semantically this interpretation should match the one 
in RFC 3986. Note that fragments do not identify anything since they are 
not part of the NSS. IMHO, since we must use RFC 3986 as the starting 
point it is not even appropriate to say that i

Re: URN fragments

Martin J. Dürst — 2013-02-22T04:10:47


This is different for the query part and for the fragment part. The 
fragment part is independent of the scheme. The query part is not.

You will see that in Appendix A of RFC 3986 
(http://tools.ietf.org/html/rfc3986#appendix-A). There, URI is defined 
as including an (optional) fragment part, but absolute-URI is defined 
excluding the fragment part. Same in RFC 3987 for IRIs. So in terms of 
terminology, it might be possible to call an URN without a fragment part 
an absolute URN (in places where such a distinction is necessary).

For fragments, the conclusion that Juha explains above is how it was 
intended for all URIs from the start, and how RFC 3986 is written. It 
may have taken some time for the URN community to arrive at this point, 
but it's a very good conclusion, because it's what works best with the 
rest of the infrastructure.

Regards,   Martin.

Re: URN fragments

Peter Saint-Andre — 2013-02-22T03:36:54

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/21/13 4:36 AM, Juha Hakala wrote:

Hi Juha, this model sounds similar to what you described for the query
component: the fragment can be "added to the URN". I'm not sure what
that means. When you add a query component or a fragment identifier to
the URN, is that now a different URN (which wasn't assigned by the
minting organization or in accordance with the minting algorithm)? Or
is "a URN with some additional data appended" and therefore not really
a URN anymore? Or is actually a URI (such as an HTTP URI) whose path
is the URN itself as just a string of characters embedded in the
broader URI?

Still confused,

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJufWAAoJEOoGpJErxa2pijYP/1Fq0JUQmr4r3oZg7rumqYB8
Y37kB4Um6e1/D/AYyMuebICyWU3dIIO5RckEr5Di+n15xMk3zREsIbbdvFWeKlIh
/hX1LFPLEbqqlvG85GqSC9T2RA0uJE1mt

Re: Transition of 2141bis and 3406bis

Peter Saint-Andre — 2013-02-22T02:51:48

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/21/13 12:05 AM, Juha Hakala wrote:
Does the Finnish ISO TC 46 shadow committee plan to proceed along the

Juha, I am confused. First you say that "There are several reasons why
query components cannot be part of the URN." Then you say that service
parameters will be passed to URN resolution services using query
components. Do you propose that service parameters will be passed by
appending them to the URN but not as part of the URN itself? Do you
have examples of what that would look like? My impression from your
earlier messages was that the parameters would be passed in the query
component of a URI, such as:

http://resolver.example.com/urn:isbn:some-number?param=value

But in that case the query component is not part of the URN, it is
part of the URI. And if that's what you are proposing, then URNs still
don't have query components. If I'm missing something here, please do
tell.

Peter

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


-----BEGIN PGP SIGNATUR

Re: call for comments: an alternative 2141bis document

Ted Hardie — 2013-02-21T22:06:34

I think my main point is that we now see the registration process differently.
We want people to notify the community that they are using a particular
scheme, so that we can avoid collision; to maximize that, we're minimize
other sorts of review (including pushback like "this should be  a URN").
Anyone can make the same claims about a new URI scheme as are made
for a URN under that approach.

Ted

Re: Transition of 2141bis and 3406bis

Andrew Newton — 2013-02-21T15:34:22



I know we've had a lot of conversations about fragments, but I don't think
adding query components has been discussed much here. Are there any
specific objection to adding query to the URN syntax?

-andy
_______________________________________________
urn mailing list
urn< at >ietf.org
https://www.ietf.org/mailman/listinfo/urn

Re: URN fragments

2013-02-21T14:52:31

Hello,

As I said, our conclusion has been that fragment is not part of the  
URN (NSS). Therefore the fragment semantics comes from RFC 3986 and  
nowhere else. Note however that we should not talk about fragment  
identifiers; fragment is just something that is attached to the  
identifier as a guideline to the browser to take the user into a given  
location within the resource.

If it were not possible to use fragment with URN, we might have two  
URIs (one URN and one URL) both resolving to the same resource  
(location), but it would only be OK to use fragment with the URL,  
although the fragment string would be exactly the same in both cases.  
I doubt this was the intention of RFC 3986.

In practice, people will attach fragments to URNs (when they are  
expressed as HTTP URIs). For these Internet users, this will be like  
using fragments with URLs. It is important to support them by  
explaining the rules of the game for them in RFC 2141.

Juha

Quoting Jonathan A Rees <rees< at >mumble.net>:

Re: URN fragments

Jonathan A Rees — 2013-02-21T13:56:18

urn: registration is that fragment id semantics comes from RFC 3986 and
simply cannot be changed or overridden by any URI scheme registration.
Quoth 3986:

   Fragment identifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications.

Jonathan
_______________________________________________
urn mailing list
urn< at >ietf.org
https://www.ietf.org/mailman/listinfo/urn

URN fragments

Juha Hakala — 2013-02-21T11:36:28

Hello Peter; all,

Concerning this:
It took a while before the bibliographic community got a sufficient grasp of how fragment can best be used in the URN context. Initially we thought that fragment should be part of the URN namespace specific string, but we realized soon that that would complicate things a lot. Since many (most, probably) standard namespaces do not allow add-ons to identifier strings, this:

  Ex. 1http://urn.fi/URN:ISBN:978-952-10-7670-1

would have been possible, but not this (NOTE: this is only an example)

Ex. 2http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2

Moreover, adding a fragment to an existing URN would in this case have been an act of identifier assignment, which in some namespaces is a managed process, so too few people would have been allowed to use fragments with URNs.

Eventually Alfred Hoenes, myself and others concluded that the best solution is to separate identification & URN assignment from fragment assignment, that is, not to include fragment in the NSS. Which means