Subject: [urn] Formal request for URN for ITU

From: Scott Mansfield <[email-masked]>
Date: Mon, 2 Jul 2018 14:03:15 +0000

This is a request from International Telecommunication Union (ITU) for a namespace.

Please review and provide comments/revisions to ensure clarity and focus of the request.  The format of the request is in ID format capturing the information requested from Appendix A of RFC 8141.

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Jul 2018 11:44:39 -0700

Hi Scott,

Thanks for providing this.  Two questions to confirm my understanding of
how the namespace will be maintained.  First, it's my understanding that in
the ITU system that a single document may have more than one recommendation
string defined.  See:  https://www.itu.int/rec/R-REC-BO.1774/en for an
example, of a pointer to identical documents within that system.  It would
be useful for the ITU to communicate whether, as namespace manager, it will
mint multiple identifiers for identical documents (as I understand it, this
is permitted, but it is useful for others to understand when or if it will
be done).  Second, the document lists a registrant in ITU-TSB and the
origin of the request is apparently in the needs of Study Group 15.  Has
the registrant considered whether a namespace specific to ITU-TSB might
serve its needs as well, or confirmed that the other ITU Sectors have
confirmed this registration?

Note that I do not believe that answering either of these is required by
the process; I put them forward solely to understand better how this will
be used.  Thanks for any insight.

regards,

Ted

On Mon, Jul 2, 2018 at 7:03 AM, Scott Mansfield <
[email-masked]> wrote:

> Please review and provide comments/revisions to ensure clarity and focus
> of the request.  The format of the request is in ID format capturing the
> information requested from Appendix A of RFC 8141.
>
>
>
> Regards,
>
> -scott.
>
>
>
> Scott Mansfield
>
> Ericsson Inc.
>
> +1 724 931 9316
>
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>
>

---

From: Scott Mansfield <[email-masked]>
Date: Mon, 2 Jul 2018 19:21:03 +0000

For your first question about “a single document may have more than one recommendation string defined’…
<scott>
If the namespace was used for their document repository, the ITU would create a unique identifier for each document.  So that if the documents were identical (except for file name) then there would be multiple identifiers.
</scott>

For your second question about “ITU-TSB”.
<scott>
Registering organization:
      Name: International Telecommunication Union (ITU)

The address provided is the address of the group that is maintaining the ITU namespace.  So I would argue that ITU-TSB is not the registrant, but ITU is.  In the purpose section it talks about “Namespace needed for identifier defined by ITU”.  Also in section 2.6 it states that “ITU will manage…”.  Yes the example I give is for the ITU-T, but that is because the T Sector will be the first to use the ITU namespace.

The ITU General Secretariat has been contacted and has agreed with this proposal.  TSB will manage and coordinate with the ITU General Secretariat and also the other ITU sectors.
</scott>

If I’m not being clear, or have misunderstood something, please let me know.

Regards,
-scott.

From: Ted Hardie <[email-masked]>
Sent: Monday, July 02, 2018 2:45 PM
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

Hi Scott,

Thanks for providing this.  Two questions to confirm my understanding of how the namespace will be maintained.  First, it's my understanding that in the ITU system that a single document may have more than one recommendation string defined.  See:  https://www.itu.int/rec/R-REC-BO.1774/en for an example, of a pointer to identical documents within that system.  It would be useful for the ITU to communicate whether, as namespace manager, it will mint multiple identifiers for identical documents (as I understand it, this is permitted, but it is useful for others to understand when or if it will be done).  Second, the document lists a registrant in ITU-TSB and the origin of the request is apparently in the needs of Study Group 15.  Has the registrant considered whether a namespace specific to ITU-TSB might serve its needs as well, or confirmed that the other ITU Sectors have confirmed this registration?

Note that I do not believe that answering either of these is required by the process; I put them forward solely to understand better how this will be used.  Thanks for any insight.

regards,

Ted

On Mon, Jul 2, 2018 at 7:03 AM, Scott Mansfield <[email-masked]<mailto:[email-masked]>> wrote:
This is a request from International Telecommunication Union (ITU) for a namespace.

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Jul 2018 13:11:43 -0700

Hi Scott,

Thanks for the quick responses, I appreciate it.

regards,

Ted

On Mon, Jul 2, 2018 at 12:21 PM, Scott Mansfield <
[email-masked]> wrote:

> If the namespace was used for their document repository, the ITU would
> create a unique identifier for each document.  So that if the documents
> were identical (except for file name) then there would be multiple
> identifiers.
>
> </scott>
>
>
>
> The address provided is the address of the group that is maintaining the
> ITU namespace.  So I would argue that ITU-TSB is not the registrant, but
> ITU is.  In the purpose section it talks about “Namespace needed for
> identifier defined by ITU”.  Also in section 2.6 it states that “ITU will
> manage…”.  Yes the example I give is for the ITU-T, but that is because the
> T Sector will be the first to use the ITU namespace.
>
>
>
> The ITU General Secretariat has been contacted and has agreed with this
> proposal.  TSB will manage and coordinate with the ITU General Secretariat
> and also the other ITU sectors.
>
> </scott>
>
>
>
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Monday, July 02, 2018 2:45 PM
> *To:* Scott Mansfield <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [urn] Formal request for URN for ITU
>
>
>
> Hi Scott,
>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 02 Jul 2018 23:08:47 -0400

Scott Mansfield <[email-masked]> writes:
> Please review and provide comments/revisions to ensure clarity and
> focus of the request.  The format of the request is in ID format
> capturing the information requested from Appendix A of RFC 8141.

The registration looks generally good to me.  Some questions are:

   Abstract

   This document describes the Namespace Identifier (NID) 'itu' for
   Uniform Resource Names (URNs) used to identify resources published by
   the ITU (International Telecommunication Union).

The word "published" is used in the Abstract but nowhere else.  All of
the example URNs seem to name either publications or abstract resources
described in publications.  But some thought should be given to whether
"published" is more restrictive that you want to commit to, and if you
want to keep the word, it would probably be better to incorporate it
into section 2.5 ("Purpose").

Section 2.5 describes the purpose of this namespace entirely in terms of
Yang module names.  But it seems likely to me that other purposes will
be found for ITU URNs, and it would be wise to allow the ITU to define
URNs for other types of resources.

This document is referenced four times:

   [4]        ITU, "ITU URN Management", 2017, <http://www.itu.int/en/
              ITU-T/Documents/ITU-URN-Management.pdf>.

This document is an Informative Reference, so the namespace registration
supersedes it, but it would be wise to edit "ITU URN Management" and the
registration to be compatible.  In particular:

(1) The registration states:

       The ITU process is found in the ITU URN Management [4] document.

Although [4] describes the syntax and semantics of URNs, it doesn't seem
to describe any organizational processes.

(2) The document contains two syntax specifications that omit colons
between components that seem to be intended:

    urn:itu:t:rec:{ITU-T-RecommendationNumber}{ITU-T-RecommendationSpecificString}

    {ITU-T-RecommendationType}{ITU-T-RecommendationTypeIdentifier}

Dale

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 3 Jul 2018 14:51:25 +0000

Please see inline (marked with <scott></scott>)

Thanks,
-scott.

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Monday, July 02, 2018 11:09 PM
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

   Abstract

The word "published" is used in the Abstract but nowhere else.  All of the example URNs seem to name either publications or abstract resources described in publications.  But some thought should be given to whether "published" is more restrictive that you want to commit to, and if you want to keep the word, it would probably be better to incorporate it into section 2.5 ("Purpose").

<scott>
I'm not sure I understand how 'published' is overly restrictive.  I want what the itu puts under the itu NID to be limited to resources published by the itu (not by other groups).
</scott>

Section 2.5 describes the purpose of this namespace entirely in terms of Yang module names.  But it seems likely to me that other purposes will be found for ITU URNs, and it would be wise to allow the ITU to define URNs for other types of resources.

<scott>
Section 2.5 says "including those used in YANG modules", that indicates that identifiers can be used for other things.  YANG is the example here because that will be the first use of this namespace.
</scott>

This document is an Informative Reference, so the namespace registration supersedes it, but it would be wise to edit "ITU URN Management" and the registration to be compatible.  In particular:

Although [4] describes the syntax and semantics of URNs, it doesn't seem to describe any organizational processes.

(2) The document contains two syntax specifications that omit colons between components that seem to be intended:

<scott>
This is good feedback.  I will get the ITU to fix the syntax errors and also add a paragraph about how the ITU General Secretariat has given the ITU-T TSB the role of coordinating with the rest of ITU to manage the assignments.
</scott>

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 03 Jul 2018 22:26:09 -0400

Scott Mansfield <[email-masked]> writes:
> The word "published" is used in the Abstract but nowhere else.  [...]
>
> <scott>
> I'm not sure I understand how 'published' is overly restrictive.  I
> want what the itu puts under the itu NID to be limited to resources
> published by the itu (not by other groups).
> </scott>

As written, the ITU can only assign URNs to things that it *publishes*.
Whereas many other organizations want to be able to assign URNs to
some things that they do not publish.

> Section 2.5 describes the purpose of this namespace entirely in terms
> of Yang module names.  [...]
>
> <scott>
> Section 2.5 says "including those used in YANG modules", that
> indicates that identifiers can be used for other things.  YANG is the
> example here because that will be the first use of this namespace.
> </scott>

Sorry, I read that section hastily and overlooked that the first
sentence permits URNs to be assigned to other things than Yang modules.
Nonetheless, I find the emphasis on Yang modules to be surprising.

Dale

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 4 Jul 2018 10:28:30 +0000

Hello Scott,

the only question I have is a generic one:

According to  2.5, the namespace is needed for identifiers defined by ITU.

ITU is closely involved with the Handle system:

http://www.itu.int/osg/csd/emerging_trends/handle_system/index.html

Does "identifiers defined by ITU" cover also Handles and if so, what is their relation to URNs? In other words, are there ITU sectors which use Handles as SectorResourceSpecificStrings? If there are, it might be better to assign URN namespace to Handles as well. As far as I know, ITU is the one organization which can make such a request, having adopted CNRI's Handle responsibilities.

You may have heard that International DOI Foundation is considering whether to send a request for URN namespace for DOIs. Although the political decision is still pending, Handle resolver has already been modified in such a way that each DOI can be expressed as actionable URN just by adding urn:doi: in front of the DOI prefix (note that such NID has not been registered the DOI system or some other identifier yet). I assume it would not be too difficult to make Handles actionable URNs as well, in e.g. urn:handle: namespace.

All the best,

Juha Hakala

From: urn <[email-masked]> On Behalf Of Scott Mansfield
Sent: maanantai 2. heinäkuuta 2018 17.03
To: [email-masked]
Subject: [urn] Formal request for URN for ITU

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 04 Jul 2018 14:27:25 -0400

"Hakala, Juha E" <[email-masked]> writes:
> Does "identifiers defined by ITU" cover also Handles and if so, what
> is their relation to URNs? In other words, are there ITU sectors which
> use Handles as SectorResourceSpecificStrings? If there are, it might
> be better to assign URN namespace to Handles as well. As far as I
> know, ITU is the one organization which can make such a request,
> having adopted CNRI's Handle responsibilities.

Wikipedia claims:

    Handles can be used natively. or expressed as Uniform Resource
    Identifiers (URIs) through a namespace within the info URI scheme;
    for example, 20.1000/100 may be written as the URI,
    info:hdl/20.1000/100. Some Handle System namespaces, such as Digital
    Object Identifiers, are "info:" URI namespaces in their own right;
    for example, info:doi/10.1000/182 is another way of writing the
    handle for the current revision of the DOI Handbook as a URI.

> [...] each DOI can be expressed as actionable
> URN just by adding urn:doi: in front of the DOI prefix (note that such
> NID has not been registered the DOI system or some other identifier
> yet). I assume it would not be too difficult to make Handles
> actionable URNs as well, in e.g. urn:handle: namespace.

That's interesting, in that DOIs have a defined format like
"doi:10.1000/182", which is official per the International DOI
Foundation but "doi" is NOT a registered URI scheme.

So these are equivalent, to the degree that they are defined:

    info:hdl/10.1000/182
    info:doi/10.1000/182
    doi:10.1000/182
    urn:doi:10.1000/182

Dale

---

From: "John Levine" <[email-masked]>
Date: 4 Jul 2018 15:01:12 -0500

In article <[email-masked]> you write:
>    Identifiers ...

Wikipedia claims a lot of things.

>Foundation but "doi" is NOT a registered URI scheme.

The DOI crowd wrote a Netscape plugin to handle doi: URIs which was
abandoned a decade ago.  Now they say that the preferred syntax for
DOIs is a real URI using their gateway, e.g.

https://dx.doi.org/10.1000/182

I have noticed that dx.doi.org will also resove ITU 11.* handles but that's not documented
anywhere so I presume it's an informal hack.

>So these are equivalent, to the degree that they are defined:

The info registry closed down in 2010 and although they have old
definitions for info:hdl and info:doi, I'm not aware of any
implementations.

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 5 Jul 2018 05:52:05 +0000

Hello,

some comments inline. 

-----Original Message-----
From: urn <[email-masked]> On Behalf Of John Levine
Sent: keskiviikko 4. heinäkuuta 2018 23.01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

>Foundation but "doi" is NOT a registered URI scheme.

The DOI crowd wrote a Netscape plugin to handle doi: URIs which was abandoned a decade ago.  Now they say that the preferred syntax for DOIs is a real URI using their gateway, e.g.

Juha: both the DOI standard (ISO 26324) and the DOI Handbook say: 

When displayed on screen or in print, a DOI name shall be preceded by a lowercase "doi:" unless the context clearly indicates that a DOI name is implied. The "doi:" label is not part of the DOI name value.

EXAMPLE
The DOI name "10.1006/jmbi.1998.2354" is displayed and printed as "doi:10.1006/jmbi.1998.2354".
 
The problem with this display format is that it is not actionable (URI). Therefore e.g Crossref recommends URI as the display format, e.g. https://doi.org/10.1006/jmbi.1998.2354 (see https://www.crossref.org/display-guidelines/).  

The current recommendation is to use https://doi.org, but other options (http://doi.org, https://dx.doi.org and http://dx.doi.org) will continue to work. 

I have noticed that dx.doi.org will also resove ITU 11.* handles but that's not documented anywhere so I presume it's an informal hack.

Juha: I would rather call it "undocumented feature" :-). 

Since DOIs and Handles use the same resolver, you can add urn:doi: to every Handle, and it resolves OK. For instance: https://hdl.handle.net/urn:doi:10138/236932. Alas, adding urn:handle: to Handle URI does not work. Since currently the resolver just ignores the urn:doi: part of the URI, extending similar behaviour to urn:handle: is trivial (although the Handle service should be smart enough to apply urn:handle: just to Handles, and urn:doi: just to DOIs). 

>So these are equivalent, to the degree that they are defined:

The info registry closed down in 2010 and although they have old definitions for info:hdl and info:doi, I'm not aware of any implementations.

Juha: at http://info-uri.info/, creators of "info" URI scheme say that "the "info" registry will continue to be supported for the foreseeable future, although prudent adopters should consider migrating their resource identity requirements towards mainstream Web practices over the long term". So I would not recommend the first two options. 

DOI display is an important issue since "naked" DOI such as 10.100/182 is neither actionable nor (fully reliably) recognizable in plain text. There are a lot of other strings which begin with "10." and contain "/".  Crossref solution is technology dependent but may be expected to be actionable in the Web for a long time. 

Note that the URN display format is still experimental. It has some benefits: URN:DOIs can be easily located from plain text and they may eventually be actionable as such (without the resolver address). Moreover, when DOI is encoded as URN it is possible to use f-, r- and q-components although they (or the URI syntax equivalents of f- and q-components) have not been specified in the DOI standard. Although URI fragments and queries are already commonly used with DOIs, International DOI Foundation was unwilling to revise the ISO standard in 2017 (the standard was published in 2012, so this was the ISO routine 5-year review). But any DOI with URI fragment which is not compliant with the ISO standard can be converted into RFC 8141 -compliant URN with f-component.      

Juha

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 5 Jul 2018 15:08:32 +0000

This is an interesting idea.  However, I'm not sure what I need to do to the "URN Namespace for ITU" document to address your comment.

The use case driving the request for the namespace called 'itu" (which comes from the ITU General Secretariat) is to support ITU developed YANG.  If the ITU wants to support doi as an identifier in their tree, that is up to the ITU since they have to manage everything below 'itu'.  The URN equivalence language is generic, pointing back to section 3 of RFC 8141.  The request notes that the ITU-Sector information (and below) are provided as examples to express that the ITU has thought about how they will manage the hierarchy under the IANA assigned 'itu'.  The language in the request indicates that some ITU coordination has already occurred with the various sectors of the ITU.  What each sector will do will be up to that sector and coordinated with the ITU.  Looking at the DOI issue, I don't see any issues with the ITU using/identifying handles as part of their structure.

I want to ensure the ITU has flexibility in what they do under their IANA assigned namespaceID, while providing IANA with a view into how the ITU plans to use the hierarchy based on current planned usage.

Regards,
-scott.

From: Hakala, Juha E <[email-masked]>
Sent: Wednesday, July 04, 2018 6:29 AM
To: Scott Mansfield <[email-masked]>; [email-masked]
Subject: RE: Formal request for URN for ITU

Hello Scott,

All the best,

Juha Hakala

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 5 Jul 2018 16:26:35 +0000

This is what the doi factsheet says...

"DOI is not registered as a URN namespace, despite fulfilling all the functional requirements, since URN registration appears to offer no advantage to the DOI System."

So any examples they provide of the form urn:doi are not officially sanctioned, and could cause a conflict if anyone actually convinced IANA to register doi as a namespace.  What the ITU or DOI do with their parses/resolution services is not something that is being considered by the ITU's request for an 'itu' namespace. However, if/when 'itu' becomes a namespace, then urn:itu:doi would become something that could be used, but based on what I'm reading in the DOI literature, there seems little reason for the ITU to pursue that.  What the ITU does need is a valid Namespace that can be used for their YANG documents (since a namespace is needed for module identification).

Regards,
-scott.

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Wednesday, July 04, 2018 2:27 PM
To: Hakala, Juha E <[email-masked]>
Cc: Scott Mansfield <[email-masked]>; [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

Wikipedia claims:

> [...] each DOI can be expressed as actionable URN just by adding 
> urn:doi: in front of the DOI prefix (note that such NID has not been 
> registered the DOI system or some other identifier yet). I assume it 
> would not be too difficult to make Handles actionable URNs as well, in 
> e.g. urn:handle: namespace.

That's interesting, in that DOIs have a defined format like "doi:10.1000/182", which is official per the International DOI Foundation but "doi" is NOT a registered URI scheme.

    info:hdl/10.1000/182
    info:doi/10.1000/182
    doi:10.1000/182
    urn:doi:10.1000/182

Dale

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jul 2018 13:35:31 -0400

A suggestion, partially in support of getting this done rather
than dragging it out further.

Let's take the request at face value: The ITU wants an NID and
namespace for ITU uses, which the General Secretariat will take
responsibility for but T-Sector will managed.  At least in the
near term, the only things that namespace is likely to be used
for are YANG-related.  In the longer term, I hope the ITU will
be alert enough to the possibilities of disruption and confusion
to be careful about what other sub-namespaces might be used an
to consult with this list and others before doing that.

For the particular case of DOI, whether I can see any value in
having urn:doi:10/.... or not, it as clear that, as of now, the
DOI folks don't think so.  It is even more clear to me that
having urn:doi:10/... and urn:itu:doi:10/... and/or
urn:itu:handle:10/... or some other variation would be far worse
than picking on of them.  

Scott, I don't think it is part of the registration or anything
this group needs to discuss, but it would be good to be sure the
ITU understands that expanding the namespace (or creating
different sub-namespaces) in other (non-YANG) directions might
raise interesting issues that, if handled badly, could disrupt
that Internet and/or discredit the ITU, and that some
consultation would be in everyone's best interests.  I hope the
best way to accomplish that does not require me (as an
individual) to drop Houlin ZHOU a note but, if it is necessary,
I believe he would read such a note from me.

If you wanted to guarantee that, you'd put language into the
registration tying its initial use to YANG and requiring
re-review for any updates or changes, but I recommend against
that, if only because some hothead around the ITU would
undoubtedly consider such a provision insulting.

For the present, let's not tie this up trying to sort out
hypothetical possibilities in which there is no present
practical interest.

best,
   john

--On Thursday, July 5, 2018 16:26 +0000 Scott Mansfield
<[email-masked]> wrote:

> "DOI is not registered as a URN namespace, despite fulfilling
> all the functional requirements, since URN registration
> appears to offer no advantage to the DOI System."
> 
> So any examples they provide of the form urn:doi are not
> officially sanctioned, and could cause a conflict if anyone
> actually convinced IANA to register doi as a namespace.  What
> the ITU or DOI do with their parses/resolution services is not
> something that is being considered by the ITU's request for an
> 'itu' namespace. However, if/when 'itu' becomes a namespace,
> then urn:itu:doi would become something that could be used,
> but based on what I'm reading in the DOI literature, there
> seems little reason for the ITU to pursue that.  What the ITU
> does need is a valid Namespace that can be used for their YANG
> documents (since a namespace is needed for module
> identification).
> 
> Regards,
> -scott.
> 
> Cc: Scott Mansfield <[email-masked]>;
> [email-masked] Subject: Re: [urn] Formal request for URN for ITU
> 
>> Does "identifiers defined by ITU" cover also Handles and if
>> so, what  is their relation to URNs? In other words, are
>> there ITU sectors which  use Handles as
>> SectorResourceSpecificStrings? If there are, it might  be
>> better to assign URN namespace to Handles as well. As far as
>> I  know, ITU is the one organization which can make such a
>> request,  having adopted CNRI's Handle responsibilities.
> 
> Wikipedia claims:
> 
>     Handles can be used natively. or expressed as Uniform
> Resource     Identifiers (URIs) through a namespace within the
> info URI scheme;     for example, 20.1000/100 may be written
> as the URI,     info:hdl/20.1000/100. Some Handle System
> namespaces, such as Digital     Object Identifiers, are
> "info:" URI namespaces in their own right;     for example,
> info:doi/10.1000/182 is another way of writing the     handle
> for the current revision of the DOI Handbook as a URI.
> 
>> [...] each DOI can be expressed as actionable URN just by
>> adding  urn:doi: in front of the DOI prefix (note that such
>> NID has not been  registered the DOI system or some other
>> identifier yet). I assume it  would not be too difficult to
>> make Handles actionable URNs as well, in  e.g. urn:handle:
>> namespace.
>

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 5 Jul 2018 17:44:50 +0000

Thanks John,

Exactly right on your points below.  I don't want to get into hypotheticals and I was trying to point out what is driving the ITU's request.  I like your point about providing some text that will ensure the ITU considers the impact of expanding the use of the namespace outside of the current known use-cases.

This is something I will have the ITU capture in an update to their internal document that the request points to.  There are a couple of updates already needed to that document.

This will raise awareness in the ITU, and provide a pointer for others to see that the ITU will consider impacts when the use of the namespace grows.

Regards,
-scott.

-----Original Message-----
From: John C Klensin <[email-masked]> 
Sent: Thursday, July 05, 2018 1:36 PM
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

A suggestion, partially in support of getting this done rather than dragging it out further.

Let's take the request at face value: The ITU wants an NID and namespace for ITU uses, which the General Secretariat will take responsibility for but T-Sector will managed.  At least in the near term, the only things that namespace is likely to be used for are YANG-related.  In the longer term, I hope the ITU will be alert enough to the possibilities of disruption and confusion to be careful about what other sub-namespaces might be used an to consult with this list and others before doing that.

For the particular case of DOI, whether I can see any value in having urn:doi:10/.... or not, it as clear that, as of now, the DOI folks don't think so.  It is even more clear to me that having urn:doi:10/... and urn:itu:doi:10/... and/or urn:itu:handle:10/... or some other variation would be far worse than picking on of them.  

Scott, I don't think it is part of the registration or anything this group needs to discuss, but it would be good to be sure the ITU understands that expanding the namespace (or creating different sub-namespaces) in other (non-YANG) directions might raise interesting issues that, if handled badly, could disrupt that Internet and/or discredit the ITU, and that some consultation would be in everyone's best interests.  I hope the best way to accomplish that does not require me (as an
individual) to drop Houlin ZHOU a note but, if it is necessary, I believe he would read such a note from me.

If you wanted to guarantee that, you'd put language into the registration tying its initial use to YANG and requiring re-review for any updates or changes, but I recommend against that, if only because some hothead around the ITU would undoubtedly consider such a provision insulting.

For the present, let's not tie this up trying to sort out hypothetical possibilities in which there is no present practical interest.

best,
   john

--On Thursday, July 5, 2018 16:26 +0000 Scott Mansfield <[email-masked]> wrote:

> "DOI is not registered as a URN namespace, despite fulfilling all the 
> functional requirements, since URN registration appears to offer no 
> advantage to the DOI System."
> 
> So any examples they provide of the form urn:doi are not officially 
> sanctioned, and could cause a conflict if anyone actually convinced 
> IANA to register doi as a namespace.  What the ITU or DOI do with 
> their parses/resolution services is not something that is being 
> considered by the ITU's request for an 'itu' namespace. However, 
> if/when 'itu' becomes a namespace, then urn:itu:doi would become 
> something that could be used, but based on what I'm reading in the DOI 
> literature, there seems little reason for the ITU to pursue that.  
> What the ITU does need is a valid Namespace that can be used for their 
> YANG documents (since a namespace is needed for module 
> identification).
> 
> Regards,
> -scott.
> 
>> is their relation to URNs? In other words, are there ITU sectors 
>> which  use Handles as SectorResourceSpecificStrings? If there are, it 
>> might  be better to assign URN namespace to Handles as well. As far 
>> as I  know, ITU is the one organization which can make such a 
>> would not be too difficult to make Handles actionable URNs as well, 
>> in  e.g. urn:handle:
>> namespace.
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jul 2018 13:52:15 -0400

--On Thursday, July 5, 2018 17:44 +0000 Scott Mansfield
<[email-masked]> wrote:

> Thanks John,
> 
> Exactly right on your points below.  I don't want to get into
> hypotheticals and I was trying to point out what is driving
> the ITU's request.  I like your point about providing some
> text that will ensure the ITU considers the impact of
> expanding the use of the namespace outside of the current
> known use-cases.
> 
> This is something I will have the ITU capture in an update to
> their internal document that the request points to.  There are
> a couple of updates already needed to that document.

And _that_ is, IMO, exactly where it should be... part of their
internal norms for how the namespace is managed rather than
promises they make to IANA or the IETF.   Even if there were no
other reasons, if someone in the ITU structure (either volunteer
or staff) comes along in a few years and starts thinking about
new sub-namespaces, we can be rather confident that document
will be consulted while I would be fairly pessimistic about
consultation of the IANA site (at least before a pointer to it
was found in that document).

> This will raise awareness in the ITU, and provide a pointer
> for others to see that the ITU will consider impacts when the
> use of the namespace grows.

Exactly.
Thanks
    john

---

From: "John R Levine" <[email-masked]>
Date: 5 Jul 2018 12:53:25 -0500

> Since DOIs and Handles use the same resolver, you can add urn:doi: to 
> every Handle, and it resolves OK. For instance: 
> https://hdl.handle.net/urn:doi:10138/236932. Alas, adding urn:handle: to 
> Handle URI does not work. Since currently the resolver just ignores the 
> urn:doi: part of the URI, extending similar behaviour to urn:handle: is 
> trivial (although the Handle service should be smart enough to apply 
> urn:handle: just to Handles, and urn:doi: just to DOIs).

Well, for some version of work.  The doi.org proxy is actually quite 
sophisticated and returns different results depending on want content type 
the client asks for.  The default is a redirect to the object's own URI, 
but it can also return bibliographic info in a variety of formats, 
something that document formatters depend on.  Does handle.net do that? 
Since it's not connected to the DOI database it's hard to see how it could 
unless it's just a double proxy to doi.org.

> DOI display is an important issue since "naked" DOI such as 10.100/182 is neither actionable nor (fully reliably) recognizable in plain text. There are a lot of other strings which begin with "10."…

I have no objection to making it easier to recognize DOIs (having written 
the code that creates and maintains the DOIs for RFCs) but be careful of 
assuming that all ways to write or dereference DOIs are the same.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 5 Jul 2018 19:09:03 +0000

I understand your point about the word publish, but the ITU request is modeled after previous SDO requests (MEF, IEEE, and ONF) that use the same language.  For the purposes that are known at this time, the language provides the scope needed.  If the scope changes, an updated request would be made.

Thanks,
-scott.

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Tuesday, July 03, 2018 10:26 PM
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

As written, the ITU can only assign URNs to things that it *publishes*.
Whereas many other organizations want to be able to assign URNs to some things that they do not publish.

> example here because that will be the first use of this namespace.

Sorry, I read that section hastily and overlooked that the first sentence permits URNs to be assigned to other things than Yang modules.
Nonetheless, I find the emphasis on Yang modules to be surprising.

Dale

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 6 Jul 2018 06:32:58 +0000

Hello, 

I am definitely in favour of getting the "itu" registration approved quickly. In order to facilitate that, chapter 2.5 Purpose could be truncated into: 

"Namespace needed for identifiers defined by ITU, including those used  in YANG data modeling language modules specified in RFC 6020 [2] and RFC 7950 [3]. "

The current chapter 2.5 provides IMO too much detail about YANG, especially because the syntax has been designed in such a way that ITU can use this namespace for wide variety of identifiers / things. Therefore I also do not think that it is necessary to tell in the registration request that ITU may register other namespaces in the future (and just like any other organization, ITU has that privilege anyway). 

Chapter 2.10 Resolution which says that "no resolution mechanism is intended or anticipated" may be based on identifiers used in the YANG context and lacks the more generic approach apparent in chapter 2.6 (Syntax). Since ITU may provide actionable identifiers in the future for some other resources such as standard documents, you could make the wording of 2.10 a bit more relaxed (e.g. No resolution mechanism is currently intended or anticipated).  

Regarding namespaces for DOI and Handle, the reason why I brought this issue up is that the International DOI Foundation (IDF) has been discussing the possibility of sending a URN namespace registration request. A few months ago I was asked to participate in the process of writing a draft namespace registration request for DOI, and a document explaining to IDF the benefits of registering a URN namespace for DOI. Whether this namespace registration will be sent to the IETF review team (us) depends on politics; in IDF there may still be DOI registration agencies which do not see the need for a URN namespace for DOI. But there is also at least one DOI registration agency which is using URNs and has registered a URN namespace of its own: EIDR, Entertainment identifier registry (https://eidr.org/). And these internal discussions within IDF about URN namespace registration are the reason why Handle service already supports URN:DOIs. 

I assume that if/when DOI gets a URN namespace, some Handle users may consider the possibility of doing the same for Handle. In the DOI community IDF is the decision maker, but Handle community is more diverse and it is not obvious who should make the decision. I think ITU may be asked to do this on behalf of the DONA Foundation. Be that as it may, Handle will need its own namespace; urn:itu:handle would not be a practical solution and any considerations about possible Handle namespace registration in the future on behalf of ITU do not need to slow down the approval of the urn:itu registration request now. 

 Best, 

Juha

-----Original Message-----
From: urn <[email-masked]> On Behalf Of John C Klensin
Sent: torstai 5. heinäkuuta 2018 20.36
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

best,
   john

---

From: Scott Mansfield <[email-masked]>
Date: Fri, 6 Jul 2018 19:23:39 +0000

I don't mind simplifying, but the detail was added because of comments I received from this very list on the ONF request I made last month.  I don't want to take out the information, to have someone else ask me to add it back in.

YANG is what the namespace will be used for first.  The YANG examples are in the ITU's document, so if there is consensus among the URN list to make this request to IANA simple --- I'm all for that.  It is easy to delete material.

The edits to 2.10 are ok with me.

I agree with your analysis of the doi/handle situation.

Regards,
-scott.

-----Original Message-----
From: Hakala, Juha E <[email-masked]> 
Sent: Friday, July 06, 2018 2:33 AM
To: John C Klensin <[email-masked]>; Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: RE: [urn] Formal request for URN for ITU

Hello, 

 Best, 

Juha

-----Original Message-----
From: urn <[email-masked]> On Behalf Of John C Klensin
Sent: torstai 5. heinäkuuta 2018 20.36
To: Scott Mansfield <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

best,
   john

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 06 Jul 2018 22:36:07 -0400

> definitions for info:hdl and info:doi, I'm not aware of any

Strictly speaking, it appears that the registry still exists, it's just
not accepting new entries.

Dale

---

From: "John R Levine" <[email-masked]>
Date: 6 Jul 2018 22:39:23 -0400

> not accepting new entries.

You're right, but I don't get the impression that there are any production 
browsers that implement any of it so it hardly matters.

Regards,

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 06 Jul 2018 22:41:20 -0400

> to consult with this list and others before doing that.

I think I'm echoing John here when I say that in this conversation we've
touched on a lot of complicated tangential issues, but none of them are
relevant to approving this request.

There have been a bunch of concrete "issues" raised, but as far as I can
tell, all of them are of the form "Have you considered that alternative
XYZ might be better?"  And it appears that the people behind the
registration either have already considered those questions or are
currently resolving them.

So it seems to me that all we're waiting for is for Scott to provide the
final version of the registration request (and aligning that ITU
internal document).

Am I mistaken?

Dale

---

From: Scott Mansfield <[email-masked]>
Date: Mon, 9 Jul 2018 21:56:43 +0000

Thanks Dale,

I have the same interpretation.  I will update the internal ITU document, get it published on the ITU site and then send a formal request based on the information provided previously.

Thanks to everyone on the URN list for providing valuable comments and helping me through this process.

Regards,
-scott.

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Friday, July 06, 2018 10:41 PM
To: John C Klensin <[email-masked]>
Cc: Scott Mansfield <[email-masked]>; [email-masked]
Subject: Re: [urn] Formal request for URN for ITU

John C Klensin <[email-masked]> writes:
> responsibility for but T-Sector will managed.  At least in the near 
> term, the only things that namespace is likely to be used for are 
> YANG-related.  In the longer term, I hope the ITU will be alert enough 
> to the possibilities of disruption and confusion to be careful about 
> what other sub-namespaces might be used an to consult with this list 
> and others before doing that.

I think I'm echoing John here when I say that in this conversation we've touched on a lot of complicated tangential issues, but none of them are relevant to approving this request.

There have been a bunch of concrete "issues" raised, but as far as I can tell, all of them are of the form "Have you considered that alternative XYZ might be better?"  And it appears that the people behind the registration either have already considered those questions or are currently resolving them.

So it seems to me that all we're waiting for is for Scott to provide the final version of the registration request (and aligning that ITU internal document).

Am I mistaken?

Dale

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 9 Jul 2018 16:02:17 -0600

+1. Thanks, Scott!

Peter