Re: New URN scheme proposal: urn:service

Martin Duerst <duerst@it.aoyama.ac.jp> Tue, 31 January 2006 02:56 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3lh0-0003LT-3F; Mon, 30 Jan 2006 21:56:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3lgy-0003KV-Jh for urn-nid@megatron.ietf.org; Mon, 30 Jan 2006 21:56:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05151 for <urn-nid@apps.ietf.org>; Mon, 30 Jan 2006 21:54:40 -0500 (EST)
Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3lre-00013R-Jz for urn-nid@apps.ietf.org; Mon, 30 Jan 2006 22:07:32 -0500
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k0V2s1u25288; Tue, 31 Jan 2006 11:54:01 +0900 (JST)
Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7cfb_d551b4f2_9204_11da_86bc_0014221f2a2d; Tue, 31 Jan 2006 11:54:00 +0900
Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k0V2qdDr017630; Tue, 31 Jan 2006 11:53:09 +0900
Message-Id: <6.0.0.20.2.20060130184247.0571a5d0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Mon, 30 Jan 2006 18:46:47 +0900
To: Henning Schulzrinne <hgs@cs.columbia.edu>, Leslie Daigle <leslie@thinkingcat.com>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
In-Reply-To: <0945CC21-9095-48A2-9A8C-E87451A7F8BF@cs.columbia.edu>
References: <4380BF2D.8010307@cs.columbia.edu> <43C3F50B.8060103@thinkingcat.com> <43C7CF20.7050401@cs.columbia.edu> <43CD66BB.2040509@thinkingcat.com> <ff7ba12a0601171404v3f6c453cj1dfbf2f4d9f58a8f@mail.gmail.com> <43CD6D32.6010309@cs.columbia.edu> <43DAACBC.9000205@thinkingcat.com> <0945CC21-9095-48A2-9A8C-E87451A7F8BF@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: urn-nid@apps.ietf.org
Subject: Re: New URN scheme proposal: urn:service
X-BeenThere: urn-nid@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:urn-nid@apps.ietf.org>
List-Help: <mailto:urn-nid-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@apps.ietf.org?subject=subscribe>
Sender: urn-nid-bounces@apps.ietf.org
Errors-To: urn-nid-bounces@apps.ietf.org

At 04:31 06/01/29, Henning Schulzrinne wrote:

 >Is it acceptable in the days of I18N to limit this to RFC 1034 set
 >([A-Z0-9-])? That would be my preference as these are more akin to
 >protocol constants than user-visible identifiers.

I think that a better solution would be to syntactically allow
a wider range of characters (via UTF-8 and %-encoding), but to
clearly say that because of the nature of the identifier, you don't
expect that to be used too much.

There is always the chance that non-ASCII characters come in very
handy for education, local governement needs, and so on.

Regards,    Martin.