Re: [urn] Formal request for URN for ITU

John C Klensin <john-ietf@jck.com> Thu, 05 July 2018 17:35 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E939F130F0F for <urn@ietfa.amsl.com>; Thu, 5 Jul 2018 10:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiYC1VCGy6pq for <urn@ietfa.amsl.com>; Thu, 5 Jul 2018 10:35:39 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9321D130E66 for <urn@ietf.org>; Thu, 5 Jul 2018 10:35:39 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fb8AL-000PN9-Oa; Thu, 05 Jul 2018 13:35:37 -0400
Date: Thu, 05 Jul 2018 13:35:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: Scott Mansfield <scott.mansfield@ericsson.com>
cc: urn@ietf.org
Message-ID: <E552A135F191B2BCF6E724AF@PSB>
In-Reply-To: <CY1PR15MB023507708A716A8BEEE8DEEB8B400@CY1PR15MB0235.namprd15.prod.outlook.com>
References: <HE1PR07MB30973FDE0B164C8DD774BE58FA410@HE1PR07MB3097.eurprd07.prod.outlook.com> (juha.hakala@helsinki.fi) <871sci6elu.fsf@hobgoblin.ariadne.com> <CY1PR15MB023507708A716A8BEEE8DEEB8B400@CY1PR15MB0235.namprd15.prod.outlook.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/xjJNbEPtElhFJDVLocQmI3bKJ6A>
Subject: Re: [urn] Formal request for URN for ITU
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 17:35:43 -0000

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
<scott.mansfield@ericsson.com> 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 <worley@ariadne.com> 
> Sent: Wednesday, July 04, 2018 2:27 PM
> To: Hakala, Juha E <juha.hakala@helsinki.fi>
> Cc: Scott Mansfield <scott.mansfield@ericsson.com>;
> urn@ietf.org Subject: Re: [urn] Formal request for URN for ITU
> 
> "Hakala, Juha E" <juha.hakala@helsinki.fi> 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
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn