Subject: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 16 Mar 2015 12:25:28 +0000

All,

Having been away from URN matters for a while, I finally got around to reading draft-ietf-urnbis-rfc2141bis-urn-10. A good piece of work, thank you, Peter and John!

I have a few questions/comments:

1) §3 URN syntax: I have some issues with the use of p-component vs. percent-encoding of "/". If I create a (sub-)namespace for DOI (urn:example:doi) and want to create an identifier for the DOI "10.1007/10929179_65", I could choose between (1) "urn:example:doi:10.1007/10929179_65" and (2) "urn:example:doi:10.1007%2F10929179_65". In the syntax defined by 2141bis, the first one uses NSS + p-component, the second one puts the complete DOI in the NSS. This is potentially confusing for consumers, since §5 says that 
[[
[urn-aware] applications might support display of URNs in a more human-friendly
 form and might use a character set that includes characters that are
 not permitted in URN syntax as defined in this specification (e.g.,
 when displaying URNs to humans, such applications might replace
 percent-encoded strings with characters from an extended character
 repertoire [...]).
]]

That means that if I choose option (2) (putting the complete DOI into the NSS using percent-encoding), a conforming urn-aware application MUST show "urn:example:doi:10.1007%2F10929179_65" and MAY show "urn:example:doi:10.1007/10929179_65". This is likely to be _very_ confusing to some users not aware of the difference between the two.

I suggest that the p-component is incorporated into the NSS; this is more intuitive.

2) CREF9:
I agree with Ted that " ...individual URI contexts;" is better, since the urn namespace description cannot anticipate all places where URIs can be used in the future.

3) CREF10:
I feel that there is a piece missing in the following text:
[[
[...] must treat the URI as opaque unless the scheme and its
 requirements are recognized. The URN resolver can either be an
 external resolver that the URI resolver knows of [...].
]]

My suggestion:
[[
[...] must treat the URI as opaque unless the scheme and its
 requirements are recognized. If the URI resolver extracts a URI
scheme of "urn", it can choose to resolve the urn by itself (the URI
resolver being also the URN resolver) or to pass the urn to
an external resolver that the URI resolver knows of [...].
]]

The current text then goes on with
[[
Note that this
 requirement MAY impose constraints on the contexts in which URNs are
 appropriately used; see the previous section.
]]

Is it correct that MAY is capitalised making it RFC 2119 language?

4) CREF12
This does open a new can of worms. Do we need to add some text that organisations operating resolution services need to ensure that the (meta-)data they resolve to is accurate? On the other hand, we could also emphasise that urn assignment is about identification and that any retrievable metadata is only there to help identify that I've found the right entity... 

5) NID syntax
The list items 4. and 5. give the examples "aa-" and "xn--" where "aa" or "xn" can be any two characters. Is there a reason that 5. uses "xn" and not "aa"?
The text at the end of the section ("All two -letter strings [...] beyond the scope of this document") could/should be moved to list item 4 since it deals with the two-letter strings.

6) CREF14
We should keep completely out of trademark procedures. Namespace registrants must ensure that they do not infringe on trademarks (a requirement for the registration template?).
Regarding ISO 3166-1 alpha-3 codes it unfortunately is too late to prohibit three-letter NIDs and since the of those codes is not closed (or is it?), we can only say that it is not allowed to register a NID that is equivalent to such a code.

7) §7.1 Syntax
List item 7 says that "rules [for determining equivalence] ought to always have the effect of eliminating false negatives [...]". Is that good enough or is there anything opposing us saying that "[those] rules MUST always have the effect of eliminating false negatives and MUST NOT produce any false positives [...]"?
Also I cannot find a reason for the mention of double- vs. single-quotes; can anyone give an example where such a rule would be helpful?

Best regards,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur und Bestanderhaltung
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49-69-1525-1752
Telefax: +49-69-1525-1799
mailto:[email-masked] 
http://www.dnb.de

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 16 Mar 2015 20:36:21 -0600

Lars, thank you for taking the time to review the document and to 
provide feedback. Please find my comments inline.

On 3/16/15 6:25 AM, Svensson, Lars wrote:
> All,
>
> Having been away from URN matters for a while, I finally got around
> to reading draft-ietf-urnbis-rfc2141bis-urn-10. A good piece of work,
> thank you, Peter and John!
>
> 1) §3 URN syntax: I have some issues with the use of p-component vs.
> percent-encoding of "/".

Although I don't claim to fully understand the DOI numbering system 
(with regard to URNs, Section 2.6.3 of the DOI Handbook is especially 
confusing to me because it implies that in a URN the slash could be 
replaced by a colon), let's take your example at face value.

> If I create a (sub-)namespace for DOI
> (urn:example:doi) and want to create an identifier for the DOI
> "10.1007/10929179_65", I could choose between (1)
> "urn:example:doi:10.1007/10929179_65" and (2)
> "urn:example:doi:10.1007%2F10929179_65".

I'm curious to hear your reasoning about why we would use a p-component 
to represent the identifier (DOI suffix). I don't think it's wrong, but 
I think it would helpful to explain your reasoning on the list.

Further: are there alternative representations? For example, might it 
make sense to represent the complete DOI (prefix and suffix) as a 
p-component? Such as:

urn:example:doi/10.1007/10929179_65

> In the syntax defined by
> 2141bis, the first one uses NSS + p-component, the second one puts
> the complete DOI in the NSS.

As far as I understand things, putting the complete DOI in the 
p-component makes the most sense (option 3).

> This is potentially confusing for
> consumers, since §5 says that [[ [urn-aware] applications might
> support display of URNs in a more human-friendly form and might use a
> character set that includes characters that are not permitted in URN
> syntax as defined in this specification (e.g., when displaying URNs
> to humans, such applications might replace percent-encoded strings
> with characters from an extended character repertoire [...]). ]]

I agree that using option 1 or option 2 is potentially confusing.

> That means that if I choose option (2) (putting the complete DOI into
> the NSS using percent-encoding), a conforming urn-aware application
> MUST show "urn:example:doi:10.1007%2F10929179_65" and MAY show
> "urn:example:doi:10.1007/10929179_65". This is likely to be _very_
> confusing to some users not aware of the difference between the two.
>

Either that or don't split an identifier (e.g., a DOI name) across the 
NSS/p-component boundary.

> 2) CREF9: I agree with Ted that " ...individual URI contexts;" is
> better, since the urn namespace description cannot anticipate all
> places where URIs can be used in the future.

Agreed.

> 3) CREF10: I feel that there is a piece missing in the following
> text: [[ [...] must treat the URI as opaque unless the scheme and
> its requirements are recognized. The URN resolver can either be an
> external resolver that the URI resolver knows of [...]. ]]

You didn't quote the complete text:

    In part because of the separation of semantics from syntax
    [I-D.ietf-urnbis-semantics-clarif], generic URI processors must pay
    special attention to the parsing and analysis rules of RFC 3986 and,
    in particular, must treat the URI as opaque unless the scheme and its
    requirements are recognized.  The URN resolver can either be an
    external resolver that the URI resolver knows of, or it can be
    functionality built into the URI resolver.

> My suggestion: [[ [...] must treat the URI as opaque unless the
> scheme and its requirements are recognized. If the URI resolver
> extracts a URI scheme of "urn", it can choose to resolve the urn by
> itself (the URI resolver being also the URN resolver) or to pass the
> urn to an external resolver that the URI resolver knows of [...]. ]]

Thanks for the proposal. I'll look more closely at the URI resolver 
issue tomorrow.

> The current text then goes on with [[ Note that this requirement MAY
> impose constraints on the contexts in which URNs are appropriately
> used; see the previous section. ]]
>

I'd prefer "might".

> 4) CREF12 This does open a new can of worms. Do we need to add some
> text that organisations operating resolution services need to ensure
> that the (meta-)data they resolve to is accurate? On the other hand,
> we could also emphasise that urn assignment is about identification
> and that any retrievable metadata is only there to help identify that
> I've found the right entity...

See my separate note on the topic:

http://www.ietf.org/mail-archive/web/urn/current/msg02802.html

Here is possible text:

    3.  Commitment to not reassigning existing names and to allowing old
        names to continue to be valid (e.g., if the assignee of a name is
        no longer a member or customer of the assigning organization, if
        various information about the assignee or named entity happen to
        change, or even if the assignee or the named entity itself is no
        longer in existence; in all these cases, the name is still
        valid).  With regard to URN resolution [RFC2276], this does not
        mean that there needs to be resolution of such names, only that
        the names will not resolve to false or stale information.

> 5) NID syntax The list items 4. and 5. give the examples "aa-" and
> "xn--" where "aa" or "xn" can be any two characters. Is there a
> reason that 5. uses "xn" and not "aa"? The text at the end of the
> section ("All two -letter strings [...] beyond the scope of this
> document") could/should be moved to list item 4 since it deals with
> the two-letter strings.

These cases are slightly distinct so I would prefer to mention them in 
separate items.

> 6) CREF14 We should keep completely out of trademark procedures.

Agreed.

> Namespace registrants must ensure that they do not infringe on
> trademarks (a requirement for the registration template?).

I'm not quite sure what you're suggesting here, since you just said that 
we should keep out of trademark issues and now you seem to be saying 
that perhaps the expert reviewers need to keep trademarks in mind.

> Regarding
> ISO 3166-1 alpha-3 codes it unfortunately is too late to prohibit
> three-letter NIDs and since the of those codes is not closed (or is
> it?), we can only say that it is not allowed to register a NID that
> is equivalent to such a code.

I think we could say something like this:

    6.  It MUST NOT start with a string that is the same as a three-
        letter country code in accordance with the ISO 3166-1 standard
        [ISO.3166-1.2006], or any similar code that could be considered
        deceptive or confusing.

> 7) §7.1 Syntax List item 7 says that "rules [for determining
> equivalence] ought to always have the effect of eliminating false
> negatives [...]". Is that good enough or is there anything opposing
> us saying that "[those] rules MUST always have the effect of
> eliminating false negatives and MUST NOT produce any false positives
> [...]"?

Although I don't think that a MUST from RFC 2119 makes much of a 
difference here, I'm not actively opposed to it.

> Also I cannot find a reason for the mention of double- vs.
> single-quotes; can anyone give an example where such a rule would be
> helpful?

Well, in HTML href='foo' and href="foo" are the same. However, I don't 
have an example from URNs.

Peter

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

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 17 Mar 2015 13:16:16 +0000

Dear Peter,

> I think it would helpful to explain your reasoning on the list.

I choose to use a p-component because I guess that most (non-technical) users will simply copy the DOI from the somewhere, put a (urn-based) prefix in front of it and think they are done. I. e. given "doi:10.1007/10929179_65" and their knowledge that there is a urn namespace "urn:example:doi" they will create "urn:example:doi:10.1007/10929179_65" by simple string concatenation. It will require a substantial amount of education to make people substitute the slash in the DOI for a colon.

> urn:example:doi/10.1007/10929179_65

Yes, for DOIs that would be a much better idea.

My point is, however, that when non-technical users create urns just adding a prefix to an existing identifier, we should make sure that things work as intuitively as possible. Since 2141bis allows the "/" in the syntax, a generic URN parser will accept " urn:example:doi:10.1007/10929179_65" (or any other URN created from an identifier with a "/" in it) as a valid URN. I realise that this might also be the case for other characters with special meaning, but I also think that the "/" character will be more confusing to implementers and users since it's more commonly used as a delimiter than e. g. "@".

Agreed.

> NSS/p-component boundary.

Right. Nonetheless I'd argue that it's more intuitive that the p-component is incorporated into the NSS. If we say that a URN consists of schema + NID + NSS + p-component (+ q-component + f-component), this (at least to me) indicates that the p-component is not a real part of the name, but something that is added to it. When determining URN equality, however, the p-component is considered. It would be more consistent to say two URNs are equivalent iff all parts of the name are octet-by-octet equal (modulo normalisation). URN components that are not part of the name (i. e. q-component and f-component) are not considered when determining equality.
 
> > Is it correct that MAY is capitalised making it RFC 2119 language?

Works for me.

>         the names will not resolve to false or stale information.

Yes, I've read the discussion. I shall think about it and come back to you.

> These cases are slightly distinct so I would prefer to mention them in

OK. But is there a reason that item 4 gives two-letter codes as "aa" and item 5 as "xn"?

> that perhaps the expert reviewers need to keep trademarks in mind.

Sorry, I see that my proposal was unclear. What I'm suggesting is that the registration template contains text that says that the registrants are responsible that their proposed NID does not infringe on trademarks (and that the experts or IETF or IANA assume no liability). The point is that the experts need _not_ keep trademarks in mind.

>         [ISO.3166-1.2006], or any similar code that could be considered

OK with me.

> difference here, I'm not actively opposed to it.

OK, the MUST in the first part is not really necessary, but what about the "MUST NOT produce any false positives"?

> have an example from URNs.

OK

Best,

Lars

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Mar 2015 10:45:58 -0600

On 3/17/15 7:16 AM, Svensson, Lars wrote:
>>> Having been away from URN matters for a while, I finally got
>>> around to reading draft-ietf-urnbis-rfc2141bis-urn-10. A good
>>> piece of work, thank you, Peter and John!
>>>
>>> 1) §3 URN syntax: I have some issues with the use of p-component
>>> vs. percent-encoding of "/".
>>
>> Although I don't claim to fully understand the DOI numbering
>> system (with regard to URNs, Section 2.6.3 of the DOI Handbook is
>> especially confusing to me because it implies that in a URN the
>> slash could be replaced by a colon), let's take your example at
>> face value.
>>
>>> If I create a (sub-)namespace for DOI (urn:example:doi) and want
>>> to create an identifier for the DOI "10.1007/10929179_65", I
>>> could choose between (1) "urn:example:doi:10.1007/10929179_65"
>>> and (2) "urn:example:doi:10.1007%2F10929179_65".
>>
>> I'm curious to hear your reasoning about why we would use a
>> p-component to represent the identifier (DOI suffix). I don't think
>> it's wrong, but I think it would helpful to explain your reasoning
>> on the list.
>
> I choose to use a p-component because I guess that most
> (non-technical) users will simply copy the DOI from the somewhere,
> put a (urn-based) prefix in front of it and think they are done.

But non-technical users aren't creating URNs.

> I.
> e. given "doi:10.1007/10929179_65" and their knowledge that there is
> a urn namespace "urn:example:doi"

But non-technical users don't know about URNs.

> they will create
> "urn:example:doi:10.1007/10929179_65" by simple string concatenation.
> It will require a substantial amount of education to make people
> substitute the slash in the DOI for a colon.

I'd assume that the International DOI Foundation would create these URNs.

(And remember this is just an example - we have no idea if the IDF has 
any plans to use URNs. But the same reasoning would apply to any 
similarly structured identifier system.)

>> Further: are there alternative representations? For example, might
>> it make sense to represent the complete DOI (prefix and suffix) as
>> a p-component? Such as:
>>

So, if the IDF registers a URN namespace, we'd encourage them to do the 
right thing regarding the p-component.

> My point is, however, that when non-technical users create urns just
> adding a prefix to an existing identifier,

I question many assumptions in that part of your sentence. :-)

> we should make sure that
> things work as intuitively as possible. Since 2141bis allows the "/"
> in the syntax, a generic URN parser will accept "
> urn:example:doi:10.1007/10929179_65" (or any other URN created from
> an identifier with a "/" in it) as a valid URN. I realise that this
> might also be the case for other characters with special meaning, but
> I also think that the "/" character will be more confusing to
> implementers and users since it's more commonly used as a delimiter
> than e. g. "@".

If we're going to reuse URI syntax, then "/" is what we have as a 
delimiter between the authority and the p-component. Are you suggesting 
that we diverge from URI syntax?

>>> In the syntax defined by 2141bis, the first one uses NSS +
>>> p-component, the second one puts the complete DOI in the NSS.
>>
>>> This is potentially confusing for consumers, since §5 says that
>>> [[ [urn-aware] applications might support display of URNs in a
>>> more human-friendly form and might use a character set that
>>> includes characters that are not permitted in URN syntax as
>>> defined in this specification (e.g., when displaying URNs to
>>> humans, such applications might replace percent-encoded strings
>>> That means that if I choose option (2) (putting the complete DOI
>>> into the NSS using percent-encoding), a conforming urn-aware
>>> application MUST show "urn:example:doi:10.1007%2F10929179_65" and
>>> MAY show "urn:example:doi:10.1007/10929179_65". This is likely to
>>> be _very_ confusing to some users not aware of the difference
>>> between the two.
>>>
>> Either that or don't split an identifier (e.g., a DOI name) across
>> the NSS/p-component boundary.
>
> Right. Nonetheless I'd argue that it's more intuitive that the
> p-component is incorporated into the NSS. If we say that a URN
> consists of schema + NID + NSS + p-component (+ q-component +
> f-component), this (at least to me) indicates that the p-component is
> not a real part of the name, but something that is added to it. When
> determining URN equality, however, the p-component is considered. It
> would be more consistent to say two URNs are equivalent iff all parts
> of the name are octet-by-octet equal (modulo normalisation). URN
> components that are not part of the name (i. e. q-component and
> f-component) are not considered when determining equality.

The use of the p-component is up to the URN namespace.

Again using the example of DOI numbers, the IDF has identifiers like 
"10.1007/10929179_65" and if they decided to define a URN namespace, 
they could place that existing identifier in the p-component.

Although we are not following URI *semantics*, the description of the 
path component from RFC 3896 is not irrelevant:

    The path component contains data, usually organized in hierarchical
    form, that ... serves to identify a resource within the scope of the
    URI's scheme and naming authority (if any).

As far as I understand it, a DOI number is hierarchical. It serves to 
identify a resource or entity or item of intellectual property. The 
naming authority for a urn:doi namespace would be the IDF. So if this 
namespace were defined, using a p-component for the DOI number would 
seem sensible. (Just because it wasn't done that way for ISBNs and ISSNs 
doesn't mean we couldn't do it for DOI numbers.)

Again, this is all hypothetical with regard to DOI numbers because we 
don't know the IDF's intentions, but the same reasoning might apply to 
similar identifier systems.

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Mar 2015 13:00:30 -0400

--On Wednesday, March 18, 2015 10:45 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>...
>> they will create
>> "urn:example:doi:10.1007/10929179_65" by simple string
>> concatenation. It will require a substantial amount of
>> education to make people substitute the slash in the DOI for
>> a colon.
> 
> (And remember this is just an example - we have no idea if the
> IDF has any plans to use URNs. But the same reasoning would
> apply to any similarly structured identifier system.)
>...

FWIW, my understanding is that the International DOI Foundation
has lost interest in URNs and is instead looking at a separate
URI scheme or use of HTTP ones, so that the example above would
appear rather more like

	doi:10.1007/10929179_65

or

	http://doi.example.org/10.1007/10929179_65

The examples may still be useful to clarify our thinking, but,
if this particular case is directly relevant to URNs, it would
be useful to have some pointers to documents, etc.

> Again, this is all hypothetical with regard to DOI numbers
> because we don't know the IDF's intentions, but the same
> reasoning might apply to similar identifier systems.

Exactly.

    john

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 25 Mar 2015 16:24:10 +0000

All,

Sorry for causing much confusion, I should make clear that what I intended to say here is _not specifically about DOIs_, but about the (proposed) p-component, the NSS and urn comparison (my use of DOI was only to illustrate my point and obviously was not helpful). Specifics below:

On Wednesday, March 18, 2015 5:46 PM, Peter wrote:

> To: Svensson, Lars; [email-masked]
> Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10
> 
[...]
> >> On 3/16/15 6:25 AM, Svensson, Lars wrote:
[...]
> But non-technical users aren't creating URNs.

I fear that in some cases they will. Organisations that want to promote the use of specific identifiers often market it as "just take (our identifier) and prefix it with (some prefix) and you will get a URI that you can use (in some application that is beneficial to the organisation promoting the identifier). DOI currently do this with http://dx.doi.org/ + DOI in order to get an actionable http-URI. We also promote urn:isbn by saying "take your isbn (including dashes) and put 'urn:isbn:' in front of it and it will give you a URI".

> But non-technical users don't know about URNs.

In libraries concerned with long-term preservation and access, we try to teach them.

> I'd assume that the International DOI Foundation would create these URNs.

And others might want to figure out what would be the URN for a given identifier (e. g. ISBN or ISSN).

> >> the NSS/p-component boundary.

[Skipping some discussion about DOIs and coming to the point about urn comparison and p-component]

> > f-component) are not considered when determining equality.

[Peter had answered to this but his answer is more about the syntactic aspect of the p-component and not about naming and urn comparison which is the point I'm failing to make...]

I try to reformulate what is my concern:

Right now we have urn=assigned-name + p-component (+q-component + f-component), where assigned-name = 'urn' + NID + NSS. To me this implies that p-, q- and f-components are not part of the name and thus (my reading) not really identifying anything (sort of second-class citizens). That seems OK for q- and f-components since they are ignored when we do urn comparison. But to me it seems counter-intuitive to have a part of the identifier that is not relevant for the _identification_ (not part of the assigned name) but nonetheless matters when it comes to _comparison_. 

Am I over-interpreting the use of "assigned-name" to mean that the rest of the urn is not part of the name and thus not part of the identifier?

Best,

Lars

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 26 Mar 2015 07:05:28 +0000

Hello,

Some comments below. 

________________________________________
Lähettäjä: urn <[email-masked]> käyttäjän  puolestaSvensson, Lars <[email-masked]>
Lähetetty: 25. maaliskuuta 2015 18:24
Vastaanottaja: [email-masked]
Aihe: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-10

All,

> >> slash could be replaced by a colon), let's take your example at

Slash may appear in two different roles in Handles and DOIs: as a separator between prefix and suffix, and as a character within the identifier string. These two cases should receive different treatment when DOIs are converted to URNs. That is why the DOI Handbook section 2.6.3 says that: 

"To enable the use of DOIs in workflows that have already standardized on URNs, the DOI proxy servers understand the substitution of a colon in place of the initial slash in a DOI name. DOI names may therefore be expressed as URNs in the doi.org domain by writing, for example, the DOI name 10.123/456 in the form http://doi.org/urn:doi:10.123:456. Note, however, that a DOI suffix is allowed to contain other slashes, and where these occur they must be percent-encoded rather than replaced with a colon: for example, the DOI name 10.123/456ABC/zyz would become http://doi.org/urn:doi:10.123:456ABC%2Fzyz, with the final slash character encoded as %2F. "

IMO it is best not to divert from this representation, which makes sense to me. However, the example is theoretical since the namespace DOI has not been registered for the time being and the DOI community does not seem to have much interest to do so. 

> But non-technical users aren't creating URNs.

Incorrect. In Finland graduating students often publish their master's thesis in the Web. If they do that, they are asked to create metadata for their work. The template which assists them in the process retrieves a URN:NBN which is used as the identifier for the thesis. 

So with the help of tools provided by the national library non-technical users are minting thousands of URNs annually. 

> But non-technical users don't know about URNs.

Students and researchers may not know what URN is, but the importance of persistent identifiers in general is gradually becoming more apparent due to increased usage of PIDs. Large percentage of research articles published in electronic format receive them, and the same applies for research data sets.  On the other hand, increasing link rot has an impact on what people think about so called cool URIs.    

About the usage and role of persistent identifiers in science, see for instance 

http://www.pidconsortium.eu/

> I'd assume that the International DOI Foundation would create these URNs.

As far as I know, IDF is not involved with this kind of practical work.  

> And others might want to figure out what would be the URN for a given identifier (e. g. ISBN or ISSN).

As an aside, it may not be trivial to restore an identifier in its pristine form from within DOI / Handle string. You cannot assume that the DOI suffix = URN NSS. For instance for ISBN the recommendation is to put the publisher part of the ISBN to the DOI suffix. So ISBN 951-0-18435-7 should be represented as DOI 10.9510/184357. 

> similarly structured identifier system.)

There are no plans to represent any other persistent identifiers as URNs (or vice versa). ISBN can be presented both as DOI and as URN, and that makes sense because the ISBN would then be resolved in two different resolution services (DOI resolver maintained by the publisher and URN resolver maintained by the national library, for instance). But there is no reason to stack persistent identifiers on top of one another so that the resulting combo-PID needs to be resolved twice (for instance, URN containing a DOI first in the national library's URN resolver in order to find the publisher's DOI resolver which would then retrieve the actual document). 
> > Yes, for DOIs that would be a much better idea.

The best idea is to stick to what the DOI Handbook says. 

All the best,

Juha

Best,

Lars
_______________________________________________
urn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 26 Mar 2015 21:17:07 -0600

On 3/26/15 1:05 AM, Hakala, Juha E wrote:
> Hello,
>
> Some comments below.
>
> ________________________________________ Lähettäjä: urn
> <[email-masked]> käyttäjän  puolestaSvensson, Lars
> <[email-masked]> Lähetetty: 25. maaliskuuta 2015 18:24
> Vastaanottaja: [email-masked] Aihe: Re: [urn] Comments on
> draft-ietf-urnbis-rfc2141bis-urn-10
>
> All,
>
> Sorry for causing much confusion, I should make clear that what I
> intended to say here is _not specifically about DOIs_, but about the
> (proposed) p-component, the NSS and urn comparison (my use of DOI was
> only to illustrate my point and obviously was not helpful). Specifics
> below:
>
>> To: Svensson, Lars; [email-masked] Subject: Re: [urn] Comments on
>> draft-ietf-urnbis-rfc2141bis-urn-10
>>
>>>> system (with regard to URNs, Section 2.6.3 of the DOI Handbook
>>>> is especially confusing to me because it implies that in a URN
>>>> the slash could be replaced by a colon), let's take your
>>>> example at face value.
>
> Slash may appear in two different roles in Handles and DOIs: as a
> separator between prefix and suffix, and as a character within the
> identifier string. These two cases should receive different treatment
> when DOIs are converted to URNs. That is why the DOI Handbook section
> 2.6.3 says that:
>
> "To enable the use of DOIs in workflows that have already
> standardized on URNs, the DOI proxy servers understand the
> substitution of a colon in place of the initial slash in a DOI name.
> DOI names may therefore be expressed as URNs in the doi.org domain by
> writing, for example, the DOI name 10.123/456 in the form
> http://doi.org/urn:doi:10.123:456. Note, however, that a DOI suffix
> is allowed to contain other slashes, and where these occur they must
> be percent-encoded rather than replaced with a colon: for example,
> the DOI name 10.123/456ABC/zyz would become
> http://doi.org/urn:doi:10.123:456ABC%2Fzyz, with the final slash
> character encoded as %2F."
>
> IMO it is best not to divert from this representation, which makes
> sense to me. However, the example is theoretical since the namespace
> DOI has not been registered for the time being and the DOI community
> does not seem to have much interest to do so.

I think it is best not to speculate about a URN namespace for DOI numbers.

However, consider the hypothetical example of a hierarchical naming 
system in which the identifiers take the form of a series of numbers 
separated by the "/" character, such as "1/406/47452/2".  If the naming 
authority for such identifiers were to use URNs, it seems natural to me 
if we place the existing identifiers in the p-component, resulting in 
URNs such as "urn:example/1/406/47452/2". Yes, the naming authority 
could differentiate among the "/" character as used in different places 
within the original identifier, but that seems a bit complicated.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 26 Mar 2015 21:27:26 -0600

On 3/25/15 10:24 AM, Svensson, Lars wrote:

> Right now we have urn=assigned-name + p-component (+q-component +
> f-component), where assigned-name = 'urn' + NID + NSS. To me this
> implies that p-, q- and f-components are not part of the name and
> thus (my reading) not really identifying anything (sort of
> second-class citizens). That seems OK for q- and f-components since
> they are ignored when we do urn comparison. But to me it seems
> counter-intuitive to have a part of the identifier that is not
> relevant for the _identification_ (not part of the assigned name) but
> nonetheless matters when it comes to _comparison_.
>
> Am I over-interpreting the use of "assigned-name" to mean that the
> rest of the urn is not part of the name and thus not part of the
> identifier?

I think that you might be over-interpreting, because the specification 
currently says that the p-component shall be taken into account for 
purposes of determining URN equivalence.

Thus "urn:example/1/2/3/" is not equivalent to "urn:example/4/5/6", 
whereas "urn:example:foo?123" is equivalent to "urn:example:foo?456" and 
"urn:example:foo#123" is equivalent to "urn:example:foo#456". So in 
practice the p-component matters in a way that the q-component and 
f-component do not.

However, perhaps the term "assigned-urn" is confusing so I will see if I 
can find a better term.

Peter

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

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 30 Mar 2015 16:43:19 +0000

Peter,

> However, perhaps the term "assigned-urn" is confusing so I will see if I

Yes I see. Even if I realise that it syntactically makes no difference, it seems more natural to me to say that urn equivalence is determined by comparing the assigned-name part of the urn. If it's not part of the name, it should not be relevant for equality. Thus my proposal would be

namestring = assigned-name [q-component] [f-component]
assigned-name = "urn:" NID ":" NSS [p-component]
etc.

Best,

Lars

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Mar 2015 15:22:51 -0400

--On Monday, March 30, 2015 16:43 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>> However, perhaps the term "assigned-urn" is confusing so I
>> will see if I can find a better term.
> 
> Yes I see. Even if I realise that it syntactically makes no
> difference, it seems more natural to me to say that urn
> equivalence is determined by comparing the assigned-name part
> of the urn. If it's not part of the name, it should not be
> relevant for equality. Thus my proposal would be
> 

This works for me.  Since Peter has passed the pen back to me
after doing most of the work on -11, I'll slip it into the draft
until someone objects very soon.  

    john