Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 25 November 2009 11:09 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398DE28C0E4 for <uri-review@core3.amsl.com>; Wed, 25 Nov 2009 03:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level:
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xICN1KtVnYAq for <uri-review@core3.amsl.com>; Wed, 25 Nov 2009 03:09:20 -0800 (PST)
Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 96D4E3A6872 for <uri-review@ietf.org>; Wed, 25 Nov 2009 03:09:20 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id nAPB94aH016381 for <uri-review@ietf.org>; Wed, 25 Nov 2009 20:09:04 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4ebb_f156dcbe_d9b2_11de_aa18_001d096c566a; Wed, 25 Nov 2009 20:09:04 +0900
Received: from [IPv6:::1] ([133.2.210.1]:53370) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S127BC43> for <uri-review@ietf.org> from <duerst@it.aoyama.ac.jp>; Wed, 25 Nov 2009 20:05:27 +0900
Message-ID: <4B0D103F.1070509@it.aoyama.ac.jp>
Date: Wed, 25 Nov 2009 20:08:47 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: Lisa Dusseault <lisa.dusseault@gmail.com>
References: <4ADDF6ED.3080803@btinternet.com> <ca722a9e0911181137w4d105b93i700c0a4e80d12fdc@mail.gmail.com>
In-Reply-To: <ca722a9e0911181137w4d105b93i700c0a4e80d12fdc@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Martin Duerst <duerst@w3.org>, uri-review@ietf.org, gk@ninebynine.org, larmouth@btinternet.com, Larry Masinter <masinter@adobe.com>
Subject: Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2009 11:09:22 -0000

Hello Lisa,

I have looked at that draft.

On 2009/11/19 4:37, Lisa Dusseault wrote:
> Hi Larry, Martin, Graham,
>
> Graham, I haven't seen your response to John Larmouth's request for review
> on the 'uri-review' list.  Did I miss it?
>
> Larry&  Martin, since this particularly involves IRI syntax, I would
> appreciate a review from one of you, particularly with an eye to the
> comparison function.  The current description for comparison seems to
> include a DNS lookup which might be problematic in many use cases.

I agree that this locks out many use cases. My guess is that this is 
necessary because there is a proliferation of representations, first 
there are numeric and alpha(numeric) ways to identify arcs, and second, 
if I understand correctly, it may be possible to give more than one 
alpha(numeric) arc, e.g. for different scripts/languages which are like 
translations. At that point, there's virtually no other way than to use 
lookup for comparison.

I think there should be a clearer explanation abouth this and some real 
examples, including (with appropriate circumscription) some non-ASCII 
ones, both in the draft and e.g. at places such as 
http://www.oid-info.com/faq.htm#iri.

If my understanding is correct, then this is not exactly the way that 
IRIs are intended to be used, but it's not something we need to forbid 
if the proponents are aware of the consequences.

> The
> encoding is also "normally" UTF-8, but I believe that requires a bit more
> explanation for when an agent gets a OID IRI in one encoding, and needs to
> compare it to an IRI in another encoding.

In my eyes, the following:

 >>>>
                                                                A URI is
    restricted to the ASCII character set, but [RFC3987], Section 3.1
    specifies the conversion of the characters allowed in an IRI into the
    characters allowed in a URI, enabling both an IRI and a URI to carry
    the same semantics for the identification.  This mapping is an
    integral part of the "oid" URI/IRI scheme.  This enables names based
    on the Unicode labels in the International OID tree to be used
    wherever an IRI or a URI is required.
 >>>>

is sufficient, but this may be because I'm too familiar with all this 
encoding stuff.

> It's also not clear to me in what cases a oid IRI might use numbers in
> arcids, and where it might use strings with unicode characters.  I probably
> don't understand OIDs well enough, but the description so far makes me think
> that these are substitutable

I agree that this needs to be explained better.

> -- again providing problems for a comparison function.

If the proponents understand the implications, both of having both 
URI/IRI and URN, and of having various forms that need network activity 
for comparison, then in my view, it's their business to decide whether 
they are okay with that or not. There are limits to how far we can force 
people to design good URI/IRI schemes, after that, it is "natural 
selection".


> Next, if these are intended to be more human-friendly than the numerical
> representations, how are bidi characters to be displayed?

The display of bidi characters should follow whatever RFC 3987 (and it's 
successor) say. There is absolutely no point in having special rules for 
displaying bidi "oid:" IRIs.

In addition, I agree with Graham that the use of slashes in this scheme 
should be carefully checked against RFC 3986, and potentially be fixed. 
In my understanding, slashes are only appropriate if relative URIs/IRIs 
are potentially used, and in that case, the whole thing has to start 
with '//' (which wouldn't be a problem because indeed the first part of 
an OID is an authority). But I may as well have some details wrong here, 
the best person to answer this is Roy.

Regards,    Martin.


> John, Is there any requirement to compare OID URNs (urn:oid:*) to OID IRIs?
> If not, this should be mentioned as being not desired.
>
> If these questions have already been answered in the discussion on
> uri-review,  I must have missed that.  I believe Alfred raised very similar
> questions in Dec 2008 and I did not see answers in the spec or on the list.
>
> Thanks,
> Lisa
>
> ---------- Forwarded message ----------
> From: John Larmouth<j.larmouth@btinternet.com>
> Date: Tue, Oct 20, 2009 at 9:44 AM
> Subject: [Fwd: Registration of 'oid:' as a URI/IRI scheme]
> To: lisa.dusseault@gmail.com, alexey.melnikov@isode.com
>
>
> Lisa and Alexey,
>
> The following request for IANA registration has been made following earlier
> discussions in uri-review.
>
> It was originally intended to request "permanent", but Ira said that this
> was not normal and that we should request "provisional". Alred HÎnes
> responded saying that as it is based on an existing ITU-T Rec. X.660 |
> ISO/IEC 9834-1,
> an immediate request for "permanent" might be better.
>
> The current request to IANA is for "provisional", but presumably this could
> be upgraded if you were to recommend that?
>
> Whether "provisional" or "permanent", it would be helpful if you could give
> the proposed IANA registration your support for rapid progression.
>
> Thank you.
>
> John L
>
>
> -------- Original Message --------
> Subject: Registration of 'oid:' as a URI/IRI scheme
> Date: Tue, 20 Oct 2009 18:08:18 +0100
> From: John Larmouth<j.larmouth@btinternet.com>
> Reply-To: j.larmouth@btinternet.com
> To: iana@iana.org
>
> I refer to the Internet Draft draft-larmouth-oid-iri-03.
>
> I would like IANA to register 'oid:' as a "permanent" URI scheme,  with the
> registration template given in the 'IANA considerations' section
> of the Internet Draft draft-larmouth-oid-iri-03.
>
> This request is on behalf of the ASN.1 group, which is collaborative work
> between ITU-T SG 17 Q.12 (I am the Rapporteur) and ISO/IEC JTC 1/SC 6 WG 9
> (I am
> the Convenor).
>
> I understand that a "provisional" registration would be approptiate until
> the
> I-D reaches a certain stage of processing, but the target is "permanent" (so
> an
> early progression to "permanent" would be good), as the scheme is based on
> existing ITU-T Recommendations and ISO Standards that are stable.
>
> There has been review of earlier drafts by uri-review, with no adverse
> comments
> that have not been addressed, but I understand that you will appoint your
> own
> expert for a further review.
>
> I will contact the Area Director shortly to alert her to this request.
>
> Thank you.
>
> John L
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp