Re: [urn] Formal request for URN for ITU

["Hakala, Juha E" <[e-mail]>]

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 <[e-mail]> On Behalf Of John C Klensin
Sent: torstai 5. heinäkuuta 2018 20.36
To: Scott Mansfield <[e-mail]>
Cc: [e-mail]
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 <[e-mail]> wrote:

> 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 <[e-mail]>
> Sent: Wednesday, July 04, 2018 2:27 PM
> To: Hakala, Juha E <[e-mail]>
> Cc: Scott Mansfield <[e-mail]>; [e-mail] 
> Subject: Re: [urn] Formal request for URN for ITU
> 
> "Hakala, Juha E" <[e-mail]> writes:
>> ITU is closely involved with the Handle system:
>> 
>> http://www.itu.int/osg/csd/emerging_trends/handle_system/inde
>> x.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.
> 
> 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
> 
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn




_______________________________________________
urn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/urn