From L.Svensson@dnb.de Mon May 2 01:14:44 2011 Return-Path: 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 C8A86E070D for ; Mon, 2 May 2011 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op-Yd4QD5k1n for ; Mon, 2 May 2011 01:14:43 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 4CBDAE0707 for ; Mon, 2 May 2011 01:14:41 -0700 (PDT) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id 75C99D5C31; Mon, 2 May 2011 10:14:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 May 2011 10:14:35 +0200 Message-ID: <6DA97EFF2763174B8BDC409CA19729840D74F3DB@dbf-ex.AD.DDB.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [urn] Are there minutes from the WG meeting in Prague? Thread-Index: AcwGdvyyuLctbI1VSVOTzl0V00pfnwBpII9w References: <6DA97EFF2763174B8BDC409CA19729840D74F313@dbf-ex.AD.DDB.DE><6DA97EFF2763174B8BDC409CA19729840D74F341@dbf-ex.AD.DDB.DE> From: "Svensson, Lars" To: "Andrew Newton" Cc: urn@ietf.org Subject: Re: [urn] Are there minutes from the WG meeting in Prague? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 08:14:44 -0000 Andy, thanks for your offer but there's no action needed! The host seems to be = up again because now the link works. All the best, Lars **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. **** **** Please note my new internet- and email-address. **** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de > -----Urspr=FCngliche Nachricht----- > Von: Andrew Newton [mailto:andy@hxr.us] > Gesendet: Freitag, 29. April 2011 16:09 > An: Svensson, Lars > Cc: Ted Hardie; urn@ietf.org > Betreff: Re: [urn] Are there minutes from the WG meeting in Prague? >=20 > Lars, >=20 > I have successfully pulled the mp3 down to my own server. I can > provide you a link if you are still having issues pulling the mp3 from > the IETF site. >=20 > -andy >=20 > On Thu, Apr 28, 2011 at 5:43 AM, Svensson, Lars > wrote: > > Andy, > > > > thanks for the link [1]. The host seems to be down, however, since > none of the links from the meeting website [2] work. > > > > [1] http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch6-thurs- > pm.mp3 > > [2] http://www.ietf.org/meeting/80/remote-participation.html#audio > > > > /Lars > > > > =A0**** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. = **** > > =A0**** Please note my new internet- and email-address. **** > > > > -- > > Dr. Lars G. Svensson > > Deutsche Nationalbibliothek / Informationstechnik > > http://www.dnb.de/ > > l.svensson@dnb.de > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Andrew Newton [mailto:andy@hxr.us] > >> Gesendet: Mittwoch, 27. April 2011 21:29 > >> An: Ted Hardie > >> Cc: Svensson, Lars; urn@ietf.org > >> Betreff: Re: [urn] Are there minutes from the WG meeting in Prague? > >> > >> Thanks for the nudge, Ted. This had slipped my mind. > >> > >> Also, people should be aware that there is an audio recording of = the > >> session which can be found here: > >> http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch6-thurs-pm.mp3 > >> > >> -andy > >> > >> On Wed, Apr 27, 2011 at 2:36 PM, Ted Hardie > wrote: > >> > I sent the raw notes to Andy some time ago; they're not quite in > the > >> format > >> > the IETF would expect (too much detail), but attached is what I > took > >> down. > >> > =A0Others who have corrections, please speak up. > >> > regards, > >> > Ted Hardie > >> > > >> > On Wed, Apr 27, 2011 at 11:31 AM, Svensson, Lars > > >> wrote: > >> >> > >> >> All, > >> >> > >> >> for those of us who couldn't make it to the WG meeting in = Prague: > >> Are > >> >> there minutes available? I'm particularly interested in the > outcome > >> of > >> >> the discussion about fragment identifiers. > >> >> > >> >> Thanks and all the best, > >> >> > >> >> Lars > >> >> > >> >> =A0**** Bitte beachten Sie die neue Internet- und = E-Mail-Adresse. > **** > >> >> =A0**** Please note my new internet- and email-address. **** > >> >> > >> >> -- > >> >> Dr. Lars G. Svensson > >> >> Deutsche Nationalbibliothek / Informationstechnik > >> >> http://www.dnb.de/ > >> >> l.svensson@dnb.de > >> >> > >> >> > >> >> _______________________________________________ > >> >> urn mailing list > >> >> urn@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/urn > >> > > >> > > >> > _______________________________________________ > >> > urn mailing list > >> > urn@ietf.org > >> > https://www.ietf.org/mailman/listinfo/urn > >> > > >> > > > From Freek.Dijkstra@sara.nl Thu May 5 04:21:02 2011 Return-Path: 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 24502E073A for ; Thu, 5 May 2011 04:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGdcfLiNHlUJ for ; Thu, 5 May 2011 04:21:01 -0700 (PDT) Received: from smtp.xel.nl (smtp.xel.nl [82.94.246.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFD8E0725 for ; Thu, 5 May 2011 04:21:00 -0700 (PDT) Received: from localhost (smtp.xel.nl [127.0.0.1]) by smtp.xel.nl (Postfix) with ESMTP id 7D880DB9AB for ; Thu, 5 May 2011 13:20:58 +0200 (CEST) X-Virus-Scanned: mailscan @ Xel Media SMTP Received: from smtp.xel.nl ([127.0.0.1]) by localhost (smtp.xel.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hMkY9B-6TcT7 for ; Thu, 5 May 2011 13:20:52 +0200 (CEST) Received: from lampje.macfreek.nl (lampje.macfreek.nl [145.99.1.74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.xel.nl (Postfix) with ESMTPSA id A3538DB966 for ; Thu, 5 May 2011 13:20:52 +0200 (CEST) Message-ID: <4DC28812.60703@sara.nl> Date: Thu, 05 May 2011 13:20:50 +0200 From: Freek Dijkstra User-Agent: Postbox 2.1.4 (Macintosh/20110308) MIME-Version: 1.0 To: urn@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:21:02 -0000 Hi, Does anyone in this group have experience with allow Unicode code points in URNs, in particular what code points to allow? I am writing a URN spec, and was wondering to allow percentage-escaped characters or not. Currently, there is no need by the community, but I feel that allowing ASCII-only is a bit too restrictive these days. The basic requirements of my URN namespace are: - percentage-escaped characters must be valid UTF-8 encoded code points - lexical equivalence: two URNs are equivalent if and only if the two URNs are byte-by-byte equivalent after case folding. (Thus no decoding should be necessary to compare URNs) Any more complex rules will not be accepted by the community. Now my current draft says that everything confirming to the above should be accepted as a valid URN. At the same time, the draft has more strict rules in what may be assigned. That allows some room for future assignments of identifiers with non-latin characters. For now, I like to limit the code points in assigned URNs. My question, what would you do? 1- not allow percentage-escaped characters in the first place 2- only allow code points defined by RFC 5892 3- only allow NFKC-normalised unicode strings 4- only allow NFKD-normalised unicode strings 5- Only allow NFKC strings with RFC 5892 code points 6- Only allow NFKD strings with RFC 5892 code points Pro 1: simple, but not very "international" :) Pro 2: No problems with case normalization (RFC 5892 does not allow uppercase characters, and forbids a whole slew of control characters; it is in use for international domain names, and seems to replace the older stringprep stuff.) Con 2: Disallows upper case. It seems to allow both precomposed and decomposed character combination (so ü, u-umlaut, can be both "u%cc%88" = code points 0075+0308 or "%c3%bc" = code point 00FC) Pro 3: Nearly all input systems use NFC (The Mac file system is the only thing that uses NFD as far as I know), so no problems with copy & paste. Con 4: Rarely used, might give problems with copy & paste. Con 3,4: Allows a slew of control characters. It seems useful to disallow may of the control characters, so 5 & 6 seems best: 5: No problems with copy & paste, allows lowercase accented characters and non-latin characters (but no uppercase accented characters) 6: Might have copy & past problems, allow accented lower AND uppercase characters, and non-latin characters. NKFD gives decomposed diacriticals. E.g. U-umlaut is decomposed in U + combining diaeresis -- and because the U is not percentage-escaped, it is even lexical equivalent to lower case u-umlaut. Awesome. 3 and 4 may give problems with the control characters later. 2 is ambiguous. So what is the best choice? - 1 (ASCII only), - 5 (no upper case, but no copy & paste problems) or - 6 (upper case allowed, but may have copy & paste problems)? Regards, Freek (PS: sorry for any possible delay in replying on-list; my experience with urn-nid is that it takes a couple of days before my posts are approved) From ted.ietf@gmail.com Thu May 5 10:11:41 2011 Return-Path: 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 D5F58E06C9 for ; Thu, 5 May 2011 10:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.059 X-Spam-Level: X-Spam-Status: No, score=-3.059 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id komrDq3aJRc6 for ; Thu, 5 May 2011 10:11:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82776E06B3 for ; Thu, 5 May 2011 10:11:40 -0700 (PDT) Received: by pwi5 with SMTP id 5so1398204pwi.31 for ; Thu, 05 May 2011 10:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VNaVd72ANlKMOcLEMpQVubTbB2aH5pn8F4Sh4heNGw4=; b=SrQHj2SEvuCF1s5Gx2JZ/Q0KTKD9I3h2+bCww4LB9taw6V+y7widwbvKOwmvRvOEdn KRqUSTCMQO0bCem574BgbffVTOx5Ofu7Tnrq6MeE+cqSLLBdrpkIvdyhsMqX6grd7KSW ob+XZGG42gUzYe+lBF3bBxKkoPJISrrgd+jYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n/kn2t1Hf+w26JgTuFkDxiiBYSPBeAttUN+iq9qQUoQMUovO14FFW318AcxnbKRnRy i7XHDZJrvn/cn/hsHVJ3YcXg5FsfjUQGZ+NpGL8kvjfZhJBHxXxye/v7tUraz8uoeALy 0uvHMQtRiXR/NL0wgnnvfnhx6vtQuA1gPjoxg= MIME-Version: 1.0 Received: by 10.68.39.39 with SMTP id m7mr3530716pbk.39.1304615500119; Thu, 05 May 2011 10:11:40 -0700 (PDT) Received: by 10.68.47.102 with HTTP; Thu, 5 May 2011 10:11:40 -0700 (PDT) In-Reply-To: <4DC28812.60703@sara.nl> References: <4DC28812.60703@sara.nl> Date: Thu, 5 May 2011 10:11:40 -0700 Message-ID: From: Ted Hardie To: Freek Dijkstra Content-Type: multipart/alternative; boundary=bcaec520ea1b73ffc004a28a77bb Cc: urn@ietf.org Subject: Re: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:11:42 -0000 --bcaec520ea1b73ffc004a28a77bb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2011 at 4:20 AM, Freek Dijkstra wrot= e: > Hi, > > Does anyone in this group have experience with allow Unicode code points > in URNs, in particular what code points to allow? > > I am writing a URN spec, and was wondering to allow percentage-escaped > characters or not. Currently, there is no need by the community, but I > feel that allowing ASCII-only is a bit too restrictive these days. > > The basic requirements of my URN namespace are: > - percentage-escaped characters must be valid UTF-8 encoded code points > - lexical equivalence: two URNs are equivalent if and only if the two > URNs are byte-by-byte equivalent after case folding. > (Thus no decoding should be necessary to compare URNs) > > So far, this seem to me to follow RFC 2141 pretty well. The only thing tha= t it seems to me that you need to say is that all %-escaped characters will be in UTF-8 encoded, as per RFC 3986. > Any more complex rules will not be accepted by the community. > > Now my current draft says that everything confirming to the above should > be accepted as a valid URN. At the same time, the draft has more strict > rules in what may be assigned. That allows some room for future > assignments of identifiers with non-latin characters. > > For now, I like to limit the code points in assigned URNs. > My question, what would you do? > > 1- not allow percentage-escaped characters in the first place > I don't get the use case for this, but you can limit the characters in the NSS at registration time, and I suspect you could simply say "No character *requiring* %-escaping will be present in this NSS". Then you would add a normalization step that said any %-escaped characters should be restored an= d case-folded before comparison. 2- only allow code points defined by RFC 5892 > I would reference http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml, along with the characteristic. E.g. only characters marked "PVALID" in tha= t table may occur. > 3- only allow NFKC-normalised unicode strings > 4- only allow NFKD-normalised unicode strings > 5- Only allow NFKC strings with RFC 5892 code points > 6- Only allow NFKD strings with RFC 5892 code points > > I don't think referencing strings is the right way to do it; I think you have to do it using code points. That would mean you'd either have to reference a table with the valid code points or present a way to derive them. I suppose that you could use ABNF that permitted PVALID characters but note in the text that only NFKC-normalized strings would be created, pointing to http://unicode.org/reports/tr15/. But writing ABNF that handles something like the composition exclusion table or the non-Starter rule seems like it is going to be hard to do. regards, Ted Pro 1: simple, but not very "international" :) > Pro 2: No problems with case normalization (RFC 5892 does not allow > uppercase characters, and forbids a whole slew of control characters; it > is in use for international domain names, and seems to replace the older > stringprep stuff.) > Con 2: Disallows upper case. It seems to allow both precomposed and > decomposed character combination (so =FC, u-umlaut, can be both "u%cc%88" > =3D code points 0075+0308 or "%c3%bc" =3D code point 00FC) > Pro 3: Nearly all input systems use NFC (The Mac file system is the only > thing that uses NFD as far as I know), so no problems with copy & paste. > Con 4: Rarely used, might give problems with copy & paste. > Con 3,4: Allows a slew of control characters. > > It seems useful to disallow may of the control characters, so 5 & 6 > seems best: > > 5: No problems with copy & paste, allows lowercase accented characters > and non-latin characters (but no uppercase accented characters) > 6: Might have copy & past problems, allow accented lower AND uppercase > characters, and non-latin characters. > > NKFD gives decomposed diacriticals. E.g. U-umlaut is decomposed in U + > combining diaeresis -- and because the U is not percentage-escaped, it > is even lexical equivalent to lower case u-umlaut. Awesome. > > 3 and 4 may give problems with the control characters later. 2 is > ambiguous. So what is the best choice? > - 1 (ASCII only), > - 5 (no upper case, but no copy & paste problems) or > - 6 (upper case allowed, but may have copy & paste problems)? > > Regards, > Freek > > (PS: sorry for any possible delay in replying on-list; my experience > with urn-nid is that it takes a couple of days before my posts are > approved) > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > --bcaec520ea1b73ffc004a28a77bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2011 at 4:20 AM, Freek Dijkstra <Freek.Dijkstra@sara.nl> w= rote:
Hi,

Does anyone in this group have experience with allow Unicode code points in URNs, in particular what code points to allow?

I am writing a URN spec, and was wondering to allow percentage-escaped
characters or not. Currently, there is no need by the community, but I
feel that allowing ASCII-only is a bit too restrictive these days.

The basic requirements of my URN namespace are:
- percentage-escaped characters must be valid UTF-8 encoded code points
- lexical equivalence: two URNs are equivalent if and only if the two
=A0URNs are byte-by-byte equivalent after case folding.
=A0(Thus no decoding should be necessary to compare URNs)


So far, this seem to me to follow RFC = 2141 pretty well. =A0The only thing that it seems to me
that you = need to say is that all %-escaped characters will be in UTF-8 encoded, as p= er RFC 3986.



=A0
Any more complex rules will not be accepted by the community.

Now my current draft says that everything confirming to the above should be accepted as a valid URN. At the same time, the draft has more strict
rules in what may be assigned. That allows some room for future
assignments of identifiers with non-latin characters.

For now, I like to limit the code points in assigned URNs.
My question, what would you do?

=A01- not allow percentage-escaped characters in the first place
=A0
I don't get the use case for this, but you can= limit the characters in the NSS at registration time, and I suspect you co= uld simply say "No character *requiring* %-escaping will be present in= this NSS". =A0Then you would add a normalization step that said any %= -escaped characters should be restored and case-folded before comparison.

=A02- only allow code points defined by RFC 5892

along with th= e characteristic. =A0E.g. only characters marked "PVALID" in that= table may occur.
=A0
=A03- only allow NFKC-normali= sed unicode strings
=A04- only allow NFKD-normalised unicode strings
=A05- Only allow NFKC strings with RFC 5892 code points
=A06- Only allow NFKD strings with RFC 5892 code points


I don't think referencing strings = is the right way to do it; I think you have to do it using code points. =A0=
That would mean you'd either have to reference a table with = the valid code points or present a way to derive them. =A0I suppose that yo= u could use ABNF that permitted PVALID characters but note in the text that= only NFKC-normalized strings would be created, pointing to=A0http://unicode.org/reports/tr15/. But w= riting ABNF that handles something like the composition exclusion table or = the non-Starter rule seems like it is going to be hard to do.

regards,

Ted

Pro 1: simple, but not very "international" :)
Pro 2: No problems with case normalization (RFC 5892 does not allow
uppercase characters, and forbids a whole slew of control characters; it is in use for international domain names, and seems to replace the older stringprep stuff.)
Con 2: Disallows upper case. It seems to allow both precomposed and
decomposed character combination (so =FC, u-umlaut, can be both "u%cc%= 88"
=3D code points 0075+0308 =A0or "%c3%bc" =3D code point 00FC)
Pro 3: Nearly all input systems use NFC (The Mac file system is the only thing that uses NFD as far as I know), so no problems with copy & paste= .
Con 4: Rarely used, might give problems with copy & paste.
Con 3,4: Allows a slew of control characters.

It seems useful to disallow may of the control characters, so 5 & 6
seems best:

5: No problems with copy & paste, allows lowercase accented characters<= br> and non-latin characters (but no uppercase accented characters)
6: Might have copy & past problems, allow accented lower AND uppercase<= br> characters, and non-latin characters.

NKFD gives decomposed diacriticals. E.g. U-umlaut is decomposed in U +
combining diaeresis -- and because the U is not percentage-escaped, it
is even lexical equivalent to lower case u-umlaut. Awesome.

3 and 4 may give problems with the control characters later. 2 is
ambiguous. So what is the best choice?
- 1 (ASCII only),
- 5 (no upper case, but no copy & paste problems) or
- 6 (upper case allowed, but may have copy & paste problems)?

Regards,
Freek

(PS: sorry for any possible delay in replying on-list; my experience
with urn-nid is that it takes a couple of days before my posts are approved= )
_______________________________________________
urn mailing list
urn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/urn

--bcaec520ea1b73ffc004a28a77bb-- From derhoermi@gmx.net Thu May 5 15:56:06 2011 Return-Path: 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 554F4E067C for ; Thu, 5 May 2011 15:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.283 X-Spam-Level: X-Spam-Status: No, score=-4.283 tagged_above=-999 required=5 tests=[AWL=-1.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK5++lX2Vm3n for ; Thu, 5 May 2011 15:56:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 95104E0663 for ; Thu, 5 May 2011 15:56:03 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2011 22:56:02 -0000 Received: from dslb-094-223-189-018.pools.arcor-ip.net (EHLO HIVE) [94.223.189.18] by mail.gmx.net (mp040) with SMTP; 06 May 2011 00:56:02 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+RLQAMSQiR9b510JFMItukSJfJqz38Gqr0pPTUgf T8xDOEUaSwKcBR From: Bjoern Hoehrmann To: Freek Dijkstra Date: Fri, 06 May 2011 00:56:07 +0200 Message-ID: References: <4DC28812.60703@sara.nl> In-Reply-To: <4DC28812.60703@sara.nl> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 22:56:06 -0000 * Freek Dijkstra wrote: >I am writing a URN spec, and was wondering to allow percentage-escaped >characters or not. Currently, there is no need by the community, but I >feel that allowing ASCII-only is a bit too restrictive these days. Note that per RFC 3986 for non-reserved characters the literal character is the same as its %hh-encoded equivalent, so allowing percent-encoding is not an option you have (there was a discussion in the IRI WG about it that I have not fully kept track of, but I would assume this to be true at least for characters in the ASCII range nonetheless). >For now, I like to limit the code points in assigned URNs. >My question, what would you do? > > 1- not allow percentage-escaped characters in the first place > 2- only allow code points defined by RFC 5892 > 3- only allow NFKC-normalised unicode strings > 4- only allow NFKD-normalised unicode strings > 5- Only allow NFKC strings with RFC 5892 code points > 6- Only allow NFKD strings with RFC 5892 code points I think you need very good reasons to specify more than "UTF-8" if you decide to use UTF-8 (you could also choose, say, Base64 encoded UTF-8, or whatever else may suit you). Personally, I think if it is important for, say, resolution or for establishing identity, which of these you use, then it's best to perform late normalization and ignore variance during exchange of identifiers. >It seems useful to disallow may of the control characters, so 5 & 6 >seems best: Generally speaking, where control characters like U+0000 or line feeds do not make sense as part of the protocol slash identifier slash what- ever, it does not really matter much whether you allow or disallow the use of them, what's more important is that the security implications are properly understood (for instance, if you get an identifier with, say, %00 in it, do you reject it outright). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From K.Kocer@dnb.de Fri May 6 07:10:58 2011 Return-Path: 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 411F4E0721 for ; Fri, 6 May 2011 07:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZlOFET-CdTN for ; Fri, 6 May 2011 07:10:57 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with SMTP id 5264AE06D4 for ; Fri, 6 May 2011 07:10:56 -0700 (PDT) Received: from dbf-ex.AD.DDB.DE (unknown [10.69.63.214]) by nordpol.ddb.de (Postfix) with ESMTP id CA2BED5B6D for ; Fri, 6 May 2011 16:10:50 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 May 2011 16:10:49 +0200 Message-ID: <6DA97EFF2763174B8BDC409CA19729840A8E8335@dbf-ex.AD.DDB.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [urn] International URNs Thread-Index: AcwLFojExRZxqx5TQlqqy59lpl58WwA4M6TA References: <4DC28812.60703@sara.nl> From: "Kocer, Kadir Karaca" To: Subject: Re: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:10:58 -0000 PkhpLA0KPg0KPkRvZXMgYW55b25lIGluIHRoaXMgZ3JvdXAgaGF2ZSBleHBlcmllbmNlIHdpdGgg YWxsb3cgVW5pY29kZSBjb2RlIHBvaW50cw0KPmluIFVSTnMsIGluIHBhcnRpY3VsYXIgd2hhdCBj b2RlIHBvaW50cyB0byBhbGxvdz8NCj4NCj5JIGFtIHdyaXRpbmcgYSBVUk4gc3BlYywgYW5kIHdh cyB3b25kZXJpbmcgdG8gYWxsb3cgcGVyY2VudGFnZS1lc2NhcGVkDQo+Y2hhcmFjdGVycyBvciBu b3QuIEN1cnJlbnRseSwgdGhlcmUgaXMgbm8gbmVlZCBieSB0aGUgY29tbXVuaXR5LCBidXQgSQ0K PmZlZWwgdGhhdCBhbGxvd2luZyBBU0NJSS1vbmx5IGlzIGEgYml0IHRvbyByZXN0cmljdGl2ZSB0 aGVzZSBkYXlzLg0KPg0KDQouLi4NCj4NCj5Qcm8gMTogc2ltcGxlLCBidXQgbm90IHZlcnkgImlu dGVybmF0aW9uYWwiIDopDQoNCkRlYXIgRnJlZWssDQoNCmZpcnN0IG9mIGFsbCBJIGRlZmluaXRl bHkgYXBwcmVjaWF0ZSB5b3VyICJQb2xpdGljYWwgQ29ycmVjdG5lc3MiIDstKQ0KDQpCdXQgd2hh dCB5b3UgYXJlIHRyeWluZyB0byBkbyB3aWxsIGVuZCB1cCB3aXRoIFVSTnMgdGhhdCBoYXZlIHBh cnRzIHdpdGggIm1lYW5pbmctZm9yLWh1bWFucyIgYW5kIHlvdSBzaG91bGQgc2VyaW91c2x5IGRp c2N1c3MgdGhpcyB3aXRoIHlvdXIgY29sbGVhZ3VlcyBpZiBpdCBpcyB0aGUgcmlnaHQgd2F5IGZv ciB5b3VyIHB1cnBvc2VzLg0KDQpNeSBwZXJzb25hbCBleHBlcmllbmNlIChvdmVyIDUgeWVhcnMg VVJOOk5CTiB3aXRoIDQuNjAwLjAwMCBVUk5zKSBpczoNCmlmIHlvdSBhbGxvdyBwZW9wbGUgdG8g YXNzaWduIFVSTnMgYXMgdGhleSBwcmVmZXIsIHRoZXkgYWx3YXlzIHRlbmQgdG8gImludmVudCIg c29tZSBzZW1hbnRpYyBydWxlcy4NCg0KQXQgdGhlIGVuZCB5b3UgaGF2ZSB5b3VyIGRhdGFiYXNl IGZ1bGwgb2YgSWRlbnRpZmllcnMgbGlrZToNCltpbnN0aXR1dGlvbi1uYW1lXS1bZGl2aXNpb24t bmFtZV0tW2NvbGxlY3Rpb24tbmFtZV0tW2RhdGVdLVtpdGVtLW51bWJlcl0NCg0KVGhpcyBnb2Vz IGZpbmUgbWFueSB5ZWFycy4NClRpbGwgdGhlIGRheSB0aGUgY29sbGVjdGlvbnMgYXJlIHJlbmFt ZWQgb3IgdHdvIGRpdmlzaW9ucyBmdXNpb24gdW5kZXIgYW5vdGhlciBuYW1lIG9yIHJlbmFtaW5n IG9mIHRoZSBpbnN0aXR1dGlvbiBvciAuLi4NCg0KRXhwZXJpZW5jZXMgbGlrZSB0aG9zZSBhcmUg dGhlIHJlYXNvbiB3aHkgbWFueSBjb2xsZWFndWVzIHdpdGggTG9uZyBUZXJtIEFyY2hpdmluZyBi YWNrZ3JvdW5kIHByb3BhZ2F0ZSBJZGVudGlmaWVycyB3aXRob3V0IHNlbWFudGljcyAtLW1lYW5p bmdsZXNzIHN0cmluZ3MganVzdCBmb3IgbWFjaGluZXMuDQoNCklNSE8gdGhhdCBpcyB0aGUgcHJv YmxlbSBhbmQgbm90IGlmIHRob3NlIG1lYW5pbmdmdWwtbmFtZXMgd3JpdHRlbiBpbiBLYW5qaSwg Q2hpbmVzZSwgQXJhYmljIG9yIEtyaWxsLg0KDQpTZXJpb3VzbHkgSSB3b3VsZCBhbGxvdyBPTkxZ IG51bWJlcnMgYW5kIDMtNCBzZXBhcmF0b3IgY2hhcnMgaWYgaSBjb3VsZCBkZWZpbmUgYSBuZXcg Z2VuZXJhdGlvbiBJRCBzeXN0ZW0uIFRoYXQgaXMgTk9UICJyZXN0cmljdGl2ZSIgYnV0IGZ1bmN0 aW9uYWwgYW5kIHByb2JsZW0gZnJlZS4NCg0KQmVzdCBSZWdhcmRzDQpLYXJhY2EgS2/Dp2VyIChZ ZXMsIG15IG5hbWUgaGFzIGFsc28gYSBOb24tQVNDSUkgY2hhcmFjdGVyISkNCg0KDQo= From Freek.Dijkstra@sara.nl Fri May 6 08:19:37 2011 Return-Path: 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 513EEE070E for ; Fri, 6 May 2011 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW707jA+1g5x for ; Fri, 6 May 2011 08:19:36 -0700 (PDT) Received: from smtp.xel.nl (smtp.xel.nl [82.94.246.111]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8DE06EA for ; Fri, 6 May 2011 08:19:34 -0700 (PDT) Received: from localhost (smtp.xel.nl [127.0.0.1]) by smtp.xel.nl (Postfix) with ESMTP id 0BC02DBA19; Fri, 6 May 2011 17:19:33 +0200 (CEST) X-Virus-Scanned: mailscan @ Xel Media SMTP Received: from smtp.xel.nl ([127.0.0.1]) by localhost (smtp.xel.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bOGDP3z2fGYg; Fri, 6 May 2011 17:19:26 +0200 (CEST) Received: from lampje.macfreek.nl (lampje.macfreek.nl [145.99.1.74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.xel.nl (Postfix) with ESMTPSA id B0E0DDB9FB; Fri, 6 May 2011 17:19:26 +0200 (CEST) Message-ID: <4DC4117E.6090208@sara.nl> Date: Fri, 06 May 2011 17:19:26 +0200 From: Freek Dijkstra User-Agent: Postbox 2.1.4 (Macintosh/20110308) MIME-Version: 1.0 To: "urn@ietf.org" References: <4DC28812.60703@sara.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------030402010101090402000809" Cc: Bjoern Hoehrmann Subject: Re: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:19:37 -0000 This is a multi-part message in MIME format. --------------030402010101090402000809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Bjoern, Thank you for you helpful email. >> I am writing a URN spec, and was wondering to allow percentage-escaped >> characters or not. Currently, there is no need by the community, but I >> feel that allowing ASCII-only is a bit too restrictive these days. > > Note that per RFC 3986 for non-reserved characters the literal character > is the same as its %hh-encoded equivalent, so allowing percent-encoding > is not an option you have (there was a discussion in the IRI WG about it > that I have not fully kept track of, but I would assume this to be true > at least for characters in the ASCII range nonetheless). Thanks, I missed that. Note that RFC 3986 section 2.3 recommends to not create URIs with %-encodings for unreserved characters, and at the same time suggests receivers should decode them. I just looked through the 40 RFCs and 1 I-D listed at http://www.iana.org/assignments/urn-namespaces/, but to my surprised none of the specifications takes this into consideration. Two specs (iso and nzl) explicitly mention that the percentage-encoded characters should be decoded to a code point. (Even though iso does not allow them in the syntax). None specifies if and what type of normalization should with the Unicode code points. For the record, here is my quick breakdown (see attachment): * 2 specs (above) explicitly describe the equivalence relation * 19 specs explicitly disallow percentage encoding, and one (publicid) limits it to 8 allowed code points. * 2 specs allow percentage encoding, and specify "case insensitive" for lexical equivalence * 5 specs allow percentage encoding, and specify "case sensitive" for lexical equivalence (which violates the equivalence rules of RFC 2141) * 5 specs delegate syntax and equivalence to subregistries or other documents * 6 specs do not specify syntax, and specify "case sensitive" for lexical equivalence * 2 specs do not specify syntax, and specify "case insensitive" for lexical equivalence >> For now, I like to limit the code points in assigned URNs. >> My question, what would you do? >> [...] > I think you need very good reasons to specify more than "UTF-8" if you > decide to use UTF-8 [...]. Personally, I think if it is important > for, say, resolution or for establishing identity, which of these you > use, then it's best to perform late normalization and ignore variance > during exchange of identifiers. What do you mean with "late normalization"? My preference would be not to normalize during exchange of identifiers at any time, but either forward/store/use a received URN as-is, or reject it outright because of bad syntax (just like any application should now reject a URI with a caret (^) character because that's not by RFC 3986.) Is that what you mean with "ignore variance during exchange of identifiers" -- do not normalise? > [...] what's more important is that the security implications > are properly understood (for instance, if you get an identifier with, > say, %00 in it, do you reject it outright). There is currently limited need for people to copy & paste identifiers in this namespace. That may be a security risk if copy & paste happens with the decoded form of the URN (instead of the percentage-decoded form) inadvertently changes the normalization (e.g. translation to NFC). This could potentially lead to malversed URIs (e.g. www.g00gle.com) I see four basic solution to this potential risk: 1. do not allow non-ASCII code points 2. only display/input encoded URNs 3. allow all code point and require the use of a validation service 4. only allow code points that are known not to cause this risk With "allow" in 4, I mean: - A created URN must contain only allowed code points - A received URN that is not a valid UTF-8 encoded string must be rejected. Other URNs should be accepted. - A received URN that contains illegal code points must not be displayed in decoded form (but only in encoded form). Is (4) a good strategy? Or do you recommend I change my draft to something else? Thanks for the feedback so far, Freek Dijkstra --------------030402010101090402000809 Content-Type: text/plain; name="percent-encoding.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="percent-encoding.txt" UGVyY2VudGFnZSBlbmNvZGluZzogYWxsb3dlZCBieSBzeW50YXggYW5kL29mIGVxdWl2YWxl bmNlIHJlbGF0aW9uIHNwZWNpZmllZD8KCklFVEYgICAgICAgICAgUkZDIDI2NDg6ICBub3Qg YWxsb3dlZApQSU4gICAgICAgICAgIFJGQyAzMDQzOiAgdW5rbm93biAocHJpdmF0ZSBzcGFj ZSksIGVxdWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIGluc2Vuc2l0aXZlKQpJU1NOICAg ICAgICAgIFJGQyAzMDQ0OiAgbm90IGFsbG93ZWQKT0lEICAgICAgICAgICBSRkMgMzA2MTog IG5vdCBhbGxvd2VkCk5FV1NNTCAgICAgICAgUkZDIDMwODU6ICBhbGxvd2VkLCBlcXVpdmFs ZW5jZSB1bnNwZWNpZmllZCAoY2FzZSBzZW5zaXRpdmUpCk9BU0lTICAgICAgICAgUkZDIDMx MjE6ICBub3QgYWxsb3dlZApYTUxPUkcgICAgICAgIFJGQyAzMTIwOiAgdW5zcGVjaWZpZWQs IGVxdWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIHNlbnNpdGl2ZSksIHByb2JhYmx5IG5v dCBhc3NpZ25lZApwdWJsaWNpZCAgICAgIFJGQyAzMTUxOiAgYWxsb3dzIDggJWVuY29kZWQg Y29kZSBwb2ludHMgKGNhc2Ugc2Vuc2l0aXZlKQpJU0JOICAgICAgICAgIFJGQyAzMTg3OiAg bm90IGFsbG93ZWQKTkJOICAgICAgICAgICBSRkMgMzE4ODogIHVuc3BlY2lmaWVkLCBydWxl cyBkZWxlZ2F0ZWQgdG8gc3VicmVnaXN0cmllcy4KV0VCM0QgICAgICAgICBSRkMgMzU0MTog IHVuc3BlY2lmaWVkLCBlcXVpdmFsZW5jZSB1bnNwZWNpZmllZCAoY2FzZSBzZW5zaXRpdmUp Ck1QRUcgICAgICAgICAgUkZDIDM2MTQ6ICBub3QgYWxsb3dlZAptYWNlICAgICAgICAgIFJG QyAzNjEzOiAgYWxsb3dlZCwgZXF1aXZhbGVuY2UgdW5zcGVjaWZpZWQgKGNhc2UgaW5zZW5z aXRpdmUpLCBwcm9iYWJseSBub3QgYXNzaWduZWQKZmlwYSAgICAgICAgICBSRkMgMzYxNjog IG5vdCBhbGxvd2VkCnN3aWZ0ICAgICAgICAgUkZDIDM2MTU6ICB1bmtub3duIChwcml2YXRl IHNwYWNlKSwgZXF1aXZhbGVuY2UgdW5zcGVjaWZpZWQgKGNhc2Ugc2Vuc2l0aXZlKQpsaWJl cnR5ICAgICAgIFJGQyAzNjIyOiAgYWxsb3dlZCwgZXF1aXZhbGVuY2UgdW5zcGVjaWZpZWQg KGNhc2Ugc2Vuc2l0aXZlKSwgcHJvYmFibHkgbm90IGFzc2lnbmVkCklQVEMgICAgICAgICAg UkZDIDM5Mzc6ICBhbGxvd2VkIGluIHNvbWUgcGFydHMsIGVxdWl2YWxlbmNlIHVuc3BlY2lm aWVkIChjYXNlIHNlbnNpdGl2ZSksIG5vdCBhc3NpZ25lZApVVUlEICAgICAgICAgIFJGQyA0 MTIyOiAgbm90IGFsbG93ZWQKVUNJICAgICAgICAgICBSRkMgNDE3OTogIGFsbG93ZWQgaW4g cHJlZml4LCBlcXVpdmFsZW5jZSB1bnNwZWNpZmllZCAoY2FzZSBpbnNlbnNpdGl2ZSksIG5v dCBhc3NpZ25lZApDTEVJICAgICAgICAgIFJGQyA0MTUyOiAgbm90IGFsbG93ZWQKdHZhICAg ICAgICAgICBSRkMgNDE5NTogIHVuc3BlY2lmaWVkLCBlcXVpdmFsZW5jZSB1bnNwZWNpZmll ZCAoY2FzZSBzZW5zaXRpdmUpLCBub3QgYXNzaWduZWQKZmRjICAgICAgICAgICBSRkMgNDE5 ODogIGFsbG93ZWQsIGVxdWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIHNlbnNpdGl2ZSkK SVNBTiAgICAgICAgICBSRkMgNDI0NjogIG5vdCBhbGxvd2VkCk5aTCAgICAgICAgICAgUkZD IDQzNTA6ICBhbGxvd2VkLCBlcXVpdmFsZW5jZSBzcGVjaWZpZWQuIFVuc3BlY2lmaWVkIHdo YXQgbm9ybWFsaXphdGlvbiB0byB1c2UgZm9yIFVURjggKGV4YW1wbGUgdXNlIHByZWNvbWJp bmVkIGRpYWNyaXRpY2FscykKb21hICAgICAgICAgICBSRkMgNDM1ODogIHVuc3BlY2lmaWVk LCBydWxlcyBkZWxlZ2F0ZWQgdG8gc3VicmVnaXN0cmllcywgcHJvYmFibHkgbm90IGFzc2ln bmVkCklWSVMgICAgICAgICAgUkZDIDQ2MTc6ICBub3QgYWxsb3dlZApTMTAwMEQgICAgICAg IFJGQyA0Njg4OiAgbm90IGFsbG93ZWQKbmZjICAgICAgICAgICBSRkMgNDcyOTogIHVuc3Bl Y2lmaWVkLCBydWxlcyBkZWxlZ2F0ZWQgdG8gc3VicmVnaXN0cmllcywgcHJvYmFibHkgbm90 IGFzc2lnbmVkCmlzbyAgICAgICAgICAgUkZDIDUxNDE6ICBub3cgYWxsb3dlZCwgZXF1aXZh bGVuY2Ugc3BlY2lmaWVkIChjYXNlIGluc2Vuc2l0aXZlKQpYTVBQICAgICAgICAgIFJGQyA0 ODU0OiAgbm90IGFsbG93ZWQKZ2VhbnQgICAgICAgICBSRkMgNDkyNjogIGFsbG93ZWQsIGVx dWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIHNlbnNpdGl2ZSkKc2VydmljZSAgICAgICBS RkMgNTAzMTogIG5vdCBhbGxvd2VkCnNtcHRlICAgICAgICAgUkZDIDUxMTk6ICBub3QgYWxs b3dlZAplcGMgICAgICAgICAgIFJGQyA1MTM0OiAgbm90IGFsbG93ZWQKZXBjZ2xvYmFsICAg ICBSRkMgNTEzNDogIG5vdCBhbGxvd2VkCmNnaSAgICAgICAgICAgUkZDIDUxMzg6ICB1bnNw ZWNpZmllZCwgcnVsZXMgZGVsZWdhdGVkIHRvIHN1YnJlZ2lzdHJpZXMsIHByb2JhYmx5IG5v dCBhc3NpZ25lZApvZ2MgICAgICAgICAgIFJGQyA1MTY1OiAgdW5zcGVjaWZpZWQsIHJ1bGVz IGRlbGVnYXRlZCB0byBzdWJyZWdpc3RyaWVzLCBwcm9iYWJseSBub3QgYXNzaWduZWQKZWJ1 ICAgICAgICAgICBSRkMgNTE3NDogIG5vdCBhbGxvd2VkCjNncHAgICAgICAgICAgUkZDIDUy Nzk6ICBub3QgYWxsb3dlZApkdmIgICAgICAgICAgIFJGQyA1MzI4OiAgdW5zcGVjaWZpZWQs IGVxdWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIGluc2Vuc2l0aXZlKSwgcHJvYmFibHkg bm90IGFzc2lnbmVkCm5lbmEgICAgICAgICAgUkZDIDYwNjE6ICB1bnNwZWNpZmllZCwgZXF1 aXZhbGVuY2UgdW5zcGVjaWZpZWQgKGNhc2Ugc2Vuc2l0aXZlKSwgcHJvYmFibHkgbm90IGFz c2lnbmVkCmNhYmxlbGFicyAgICAgZHJhZnQtY2FyZG9uYS1jYWJsZWxhYnMtdXJuOiAgdW5z cGVjaWZpZWQsIGVxdWl2YWxlbmNlIHVuc3BlY2lmaWVkIChjYXNlIHNlbnNpdGl2ZSksIHBy b2JhYmx5IG5vdCBhc3NpZ25lZAoK --------------030402010101090402000809-- From Freek.Dijkstra@sara.nl Fri May 6 11:47:44 2011 Return-Path: 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 A52D9E07D0 for ; Fri, 6 May 2011 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whKKB3WRcyyE for ; Fri, 6 May 2011 11:47:43 -0700 (PDT) Received: from smtp.xel.nl (smtp.xel.nl [82.94.246.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3F632E0768 for ; Fri, 6 May 2011 11:47:42 -0700 (PDT) Received: from localhost (smtp.xel.nl [127.0.0.1]) by smtp.xel.nl (Postfix) with ESMTP id A0F88DBA26; Fri, 6 May 2011 20:47:40 +0200 (CEST) X-Virus-Scanned: mailscan @ Xel Media SMTP Received: from smtp.xel.nl ([127.0.0.1]) by localhost (smtp.xel.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uB-58YdaFPsf; Fri, 6 May 2011 20:47:35 +0200 (CEST) Received: from lampje.macfreek.nl (lampje.macfreek.nl [145.99.1.74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.xel.nl (Postfix) with ESMTPSA id E782BDBA18; Fri, 6 May 2011 20:47:34 +0200 (CEST) Message-ID: <4DC44245.1020505@sara.nl> Date: Fri, 06 May 2011 20:47:33 +0200 From: Freek Dijkstra User-Agent: Postbox 2.1.4 (Macintosh/20110308) MIME-Version: 1.0 To: =?UTF-8?B?S2FkaXIgS2FyYWNhIEtvw6dlcg==?= , "urn@ietf.org" References: <4DC28812.60703@sara.nl> <6DA97EFF2763174B8BDC409CA19729840A8E8335@dbf-ex.AD.DDB.DE> In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840A8E8335@dbf-ex.AD.DDB.DE> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [urn] International URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 18:47:44 -0000 Kocer, Kadir Karaca wrote: > if you allow people to assign URNs as they prefer, they always tend to "invent" some semantic rules. > > At the end you have your database full of Identifiers like: > [institution-name]-[division-name]-[collection-name]-[date]-[item-number] > > This goes fine many years. > Till the day the collections are renamed or two divisions fusion > under another name or renaming of the institution or ... Thanks. The draft warned users of these risks. However, your note convinced me to disallow percentage encoded characters altogether. Thanks for the nudge. Freek From bengt.neiss@kb.se Mon May 16 06:25:15 2011 Return-Path: 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 D4BD9E06A0 for ; Mon, 16 May 2011 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFPqh-IkHapR for ; Mon, 16 May 2011 06:25:15 -0700 (PDT) Received: from Exchangefront01.kb.se (exchangefront01.kb.se [193.10.249.137]) by ietfa.amsl.com (Postfix) with ESMTP id 730AFE0669 for ; Mon, 16 May 2011 06:25:14 -0700 (PDT) Received: from Exchangefront01.kb.se ([172.16.25.25] RDNS failed) by Exchangefront01.kb.se with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 May 2011 15:25:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC13CC.AF3CAC3C" Date: Mon, 16 May 2011 15:25:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some short comments on RFC 2141bis Thread-Index: AcwTwQQ+03emd8vERca9Cq863cHqng== From: "Bengt Neiss" To: X-OriginalArrivalTime: 16 May 2011 13:25:12.0183 (UTC) FILETIME=[AF471870:01CC13CC] Subject: [urn] Some short comments on RFC 2141bis X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about possible revisions to the definition of Uniform Resource Names List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:25:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC13CC.AF3CAC3C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Just want to give some comments on a couple of issues. =20 =20 1. I think there should be a section describing the possibility to divide (or extend?) a namespace into sub-namespaces and what rules that applies to a sub-namespace. (ie. delegation to sub-naming authorities). =20 2. In section 2.1 there is a "note for discussion" on restricting NIDs even further. If restrictions still are considered for NIDs I think there should be no restrictions for a NID that consists of a numerical value of two or more numbers (eg. 118), or a numerical range (eg. 561111-2301). =20 3. Should there be a "max length" limit for a URN (or a recommendation?)? As identifiers, URNs might turn up in other systems and it might be good idea to give a recommendation on the "max length" of a URN even if there is no limit as such. =20 Regards, //Bengt =20 --------------------------------------------------------- Bengt Neiss Kungl. Biblioteket / National Library of Sweden Phone: +46 (0)10 709 35 41 =20 ------_=_NextPart_001_01CC13CC.AF3CAC3C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Just want to give some comments on a couple of = issues.

 

 

1.       = I think there should = be a section describing the possibility to divide (or extend?) a = namespace into sub-namespaces and what rules that applies to a = sub-namespace. (ie. delegation to sub-naming = authorities).

 

2.       =  In section 2.1 = there is a "note for discussion" on restricting NIDs even = further.
If restrictions still are considered for NIDs I think there = should be no restrictions for a NID that consists of a numerical value = of two or more numbers (eg. 118), or a numerical range (eg. = 561111-2301).

 

3.       = Should there be a = "max length" limit for a URN (or a recommendation?)?
As = identifiers, URNs might turn up in other systems and it might be good = idea to give a recommendation on the “max length” of a URN = even if there is no limit as such.

 

Regards,

//Bengt

 

---------------------------------------= ------------------

Bengt = Neiss

Kungl. Biblioteket / = National Library of Sweden

Phone: +46 = (0)10 709 35 41

 

------_=_NextPart_001_01CC13CC.AF3CAC3C--