From nobody Fri Jan 2 07:21:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52B1A1A79 for ; Wed, 31 Dec 2014 15:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.514 X-Spam-Level: X-Spam-Status: No, score=0.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, SPF_SOFTFAIL=0.665] autolearn=ham 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 YbeEHXwYXiEd for ; Wed, 31 Dec 2014 15:40:55 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3DA1A1A54 for ; Wed, 31 Dec 2014 15:40:54 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-12v.sys.comcast.net with comcast id aPgu1p0032N9P4d01PgunS; Wed, 31 Dec 2014 23:40:54 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-13v.sys.comcast.net with comcast id aPgt1p0011KKtkw01PgtFG; Wed, 31 Dec 2014 23:40:54 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBVNeWKG010576; Wed, 31 Dec 2014 18:40:34 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBV0EZjk010273; Tue, 30 Dec 2014 19:14:35 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-Reply-To: <1BCA16D96EC2C307E29BFABC@JcK-HP8200.jck.com> (john-ietf@jck.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Dec 2014 19:14:35 -0500 Message-ID: <87mw64smj8.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420069254; bh=3WY8W7t650hyhOWD4F6nI5dFN88E88UbnLhtabtYWX0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hSN+4Qc26/Cy1yFfkw/q3Wi8J8xiPH4MLOcWeHZDPpUTZm65ONaFhYFrJkRoxxgHu CPTLf2pzsDYTeLghrCUGu/h3tILzjW4/qVF6ZAtbEHuY75hUJzHWkOqwlea+Es4k9x NPNU76JHDgihwFVABU3R/6u1iTM24ZOM4mjy2EpUd6DFjPfOZG2vvxoGqs2EDNk5HD N3sclbhxUBV48IXG1ycn7ToiFq0CeJMOzLZG7dgn0tRKMGMp4HihbwGLtvS8R7CsRe zIH5lt90MwvS8O7j+yOMcbaMndEPkCLIr3BKnNkjitSfa33U9HnH8GtOW+3Yd4PfYJ SVk/InDRTFoEw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HBuOjrzB4m66veEQJTgIOqN8zTw X-Mailman-Approved-At: Fri, 02 Jan 2015 07:21:24 -0800 Cc: urn-nid@ietf.org, barryleiba@computer.org, urn@ietf.org Subject: Re: [urn] A few quick thoughts on "lex" (was" Re: continued use of urn-nid@ietf.org list) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 23:40:58 -0000 John C Klensin writes: > I draw two conclusions for the above. FIrst, there are a lot of > issues, some related to legal documents, some to URN (or URI) > niceties, and some to authority, that the document just does not > have sorted out yet. Second, the IETF may be appropriate as a > place to sort out the best syntax model for registering an > established name space as a URN-embedded namespace, but we > should not be in the business of recognizing or ratifying naming > authorities, especially in areas we know almost nothing about > (either technically or in terms of socio-political > relationships). [etc.] All of this is very well-said. Experience shows that the IETF is not a good forum to address issues traditionally handled by librarians. It seems to me that there are two ways to proceed with this document. One way is to provide proper references to a sufficiently universal association/authority of legal scholarship/librarianship/legislation that has examined and approved the underlying naming system, so that the IETF can be assured that the system as a whole has been examined and approved by people who are subject-matter experts. A second way is to consider this to be an experimental proposal. Then we can approve the publication of the current state of the proposal in order to inform the public, but leave the long-term development of the system to ITTIG or whoever. However, assuming that we proceed with the second method, there are some issues that must be resolved. 1) The syntax as presented in the draft produces URNs which are not accepted by the syntax of RFC 3986, even if we extend 3986 with the query and fragment syntax of 2396. (This is a critical technical requirement.) 2) The authorities that govern certain elements of the syntax are neither specified clearly or flagged as requiring further work. For example, the jurisdiction codes seem to be intended to be ISO 3166 Alpha-2 codes with assorted exceptions, but how the exceptions are defined is not made clear. Similarly, how the codes for non-nation-state entities are allocated is unclear. The proposal seems to allow for s to be reassigned, requiring wholesale reassignment of URNs. This is contrary to the principles of URN assignment. (The reassignment of codes is a critical technical requirement.) 3) The discussion of gives as examples "br:governo:decreto", "br;sao.paulo:governo:decreto", and "br;sao.paulo;campinas:governo: decreto". But none of these conform to the provided syntax -- ":" is not permitted in , and " " is not permitted in URIs. I believe that this is simply an oversight, and that the intended examples are "br", "br;sao.paulo", and "br;sao.paulo;campinas". But the fact that such an error has been made in the text suggests that the proposal has not been carefully edited. The proposal needs to be edited to be free of easily-visible errors as a demonstration that sufficient care has been taken in composing its text. (This is a matter of assuring the quality of the proposal document.) 4) The handling of characters outside of the 26-letter Latin alphabet seems to be philosophically contrary to internationalization. Indeed, the approach of requesting that all elements which are derived from natural language be turned into sequences of Latin letters is what I would expect a naive American to propose! In contrast, the URI system provides a method of encoding the full Unicode character set. (Albeit this encoding is visually ugly, it is uniquely mappable to and from a representation of the URI with the escapes represented by the glyphs they represent -- the latter representation is visually compatible with the original natural language.) Similarly, the DNS system (via Punycode) provides a method of encoding the full Unicode character set as components of DNS labels. And modern computer systems seem to commonly support the full Unicode character set. These considerations taken together suggest to me that an international legal reference system should express that the glyphs of all writing systems are equal. (This is a matter of supporting the IETF's principles of internationalism.) Dale From nobody Mon Jan 5 03:08:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E891A3BA0 for ; Mon, 5 Jan 2015 03:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VkOIpO6ss0Gz for ; Mon, 5 Jan 2015 03:08:17 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A900B1A1BE9 for ; Mon, 5 Jan 2015 03:08:16 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t05B8DHc015567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Jan 2015 13:08:14 +0200 Message-ID: <54AA709D.2050107@helsinki.fi> Date: Mon, 05 Jan 2015 13:08:13 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/emokbKVBac_nbjMEqzlBytY-isU Subject: Re: [urn] 2141bis questions - (10) Backward compatibility X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:08:25 -0000 Hello, On 25.12.2014 9:01, John C Klensin wrote: > The registration procedures for formal and informal namespaces > (Sections 8.1 and 8.2) both provide for revisions of the > registration by updating the template. Especially given some > discussions in the WG, I think we should impose an explicit > requirement for a description of differences from prior versions > and/or backward compatibility in updated registrations. > > Do others agree? + 1 Juha > > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jan 5 03:23:27 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12881A1B0A for ; Mon, 5 Jan 2015 03:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7IwaXZgjKoIi for ; Mon, 5 Jan 2015 03:23:22 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A2A1A1AD2 for ; Mon, 5 Jan 2015 03:23:22 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t05BNKtd031092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Jan 2015 13:23:20 +0200 Message-ID: <54AA7428.4080301@helsinki.fi> Date: Mon, 05 Jan 2015 13:23:20 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> In-Reply-To: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qYzHY1vwiYvMymxU7n3los0B9sc Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:23:24 -0000 Hello, On 25.12.2014 8:28, John C Klensin wrote: > The first part of Section 7, "Defining a URN Namespace", > outlines broad requirements. Under item (2), it seems > worthwhile to clarify that the status of *-components be > specified here (it is explained in more detail in Section 7.2, > as promised). > > Suggestion: > > Old: > 2. The syntax of URNs assigned within the namespace. > > New: > 2. The syntax of URNs assigned within the namespace, > including whether p-, q-, and/or f-components are > allowed. + 1. The downside of this is that people creating registration requests must find out what the implications of these components are for their identifier systems. But it should be easy both to supply this information, and to check if the information provided in the registration request is OK. Namespaces which do not intend to support resolution services should not allow q-component. Namespaces which deal with digital manifestations may be able to support f-component. The namespaces I am familiar with will at least for the time being not use the p component even if it were technically possible to do so. Juha > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jan 5 03:32:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7052F1A1AD2 for ; Mon, 5 Jan 2015 03:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1ABOurlD-FoN for ; Mon, 5 Jan 2015 03:31:59 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF931A0231 for ; Mon, 5 Jan 2015 03:31:59 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t05BVvbR002967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Jan 2015 13:31:57 +0200 Message-ID: <54AA762D.1030803@helsinki.fi> Date: Mon, 05 Jan 2015 13:31:57 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> In-Reply-To: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QZ9rLGWWrI3Ky0va4tyZX-zw4yc Subject: Re: [urn] 2141bis questions - (6) NID syntax for informal namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:32:01 -0000 Hello, I am in favour of John's Option 1, since IMO it makes our lives easier in the future, and does not create problems with the informal NIDs already approved. Juha On 25.12.2014 8:09, John C Klensin wrote: > Section 6.2 specifies the syntax of NIDs for Informal > Namespaces, but it lacks specificity in one area, which is > whether numbers with leading zeros are permitted and, if they > are, whether NIDs with leading zeros are considered equivalent > to those with the same numeric values with the leading zeros > removed. I suggest we pick one of two options and document it > more or less as described below. > > By the way, the syntax of an NID for an informal namespace is > not the syntax of the namespace. Equally important, the > syntax snippet isn't ABNF, ABNF is not referenced, and there is > no production for "". Those are editorial issues that > will have to be fixed in any event. > > Option 1: Leading zeros forbidden. Remove the present format > snippet and replace > > Old: > > Thus the syntax of an informal namespace is: > > "urn-" > > New: > The syntax for the NID of an informal namespace is: > > InformalNamespaceNID = "urn-" Digit19 [ *Digit09] > Digit19 = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / > "9" > Digit09 = "0" / Digit19 > > > Option 2: Leading zeros forbidden but equivalent to the NID if > they are > stripped. > > Add, after the sentence starting "The only restrictions..." (and > after fixing "syntax of an informal namespace" and ""), > something like: > > While IANA may choose to assign NIDs with leading zeros > following "urn-", a URN containing, for example, an NID of > "urn-007" would not be equivalent under the matching rules of > this specification and RFC 3986 to one containing and NID of > "urn-7" so IANA should use care to avoid creating confusion. > > > I think Option 1 is probably easier and simpler. A hypothetic > third option in which an NID with leading zeros in the number is > equivalent to one with them stripped leads, I think, to madness > despite its numerical obviousness. > > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jan 5 04:36:44 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3FD1A6F17 for ; Mon, 5 Jan 2015 04:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 X8A0Bmq2ym4A for ; Mon, 5 Jan 2015 04:36:39 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59F21A6F0D for ; Mon, 5 Jan 2015 04:36:37 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t05CaYc2021395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Jan 2015 14:36:35 +0200 Message-ID: <54AA8552.9050606@helsinki.fi> Date: Mon, 05 Jan 2015 14:36:34 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <5499B9E4.8010609@andyet.net> In-Reply-To: <5499B9E4.8010609@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GQ-FpyZTx_UeTsXq5MgtRt_jV0g Subject: Re: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 12:36:41 -0000 Hello, On 23.12.2014 20:52, Peter Saint-Andre - &yet wrote: > On 12/23/14, 10:54 AM, John C Klensin wrote: >> Section 6 ("URN Namespaces") of 2141bis talks about valid and >> invalid, formal and informal URNs. The combinations are a >> little confusing, especially since the current text makes a >> string that generally follows the URN syntax but that uses an >> unregistered NID invalid. I think some clarification is in >> order and want to make sure the WG agrees. Hence: >> >> Question 1: It is our intent to keep URN-like objects based on >> unregistered namespace invalid, right? > > I think so. URNs are a managed process. If someone starts creating > URNs under urn:klensin:* and no one ever registered "klensin" as a > NID, then they're out of bounds. + 1. There are at least two different cases here. Anyone who knows anything about usage of standard identifiers would see that urn:klensin:* URNs are (and probably will be) invalid. But it is more difficult to work out the status of URNs which look valid. For instance, even some librarians might think that urn:isrc:* are OK (ISRC = International Standard Recording Code, http://isrc.ifpi.org/en/), especially if those URNs are actionable (they might be). But without formal namespace registration urn:isrc:*'s are still as invalid as urn:klensin:* ones, even though it is not likely that NID "ISRC" will be assigned to some other identifier system than ISRC. > >> Question 2: The last paragraph of the Section 6 introduction >> (before Section 6.1 starts) disposes of "experimental" >> namespaces. I believe it should be made clear that continued >> use of such namespaces with URN-like syntax does not make them >> valid URNs (because they are unregistered). If anyone >> disagrees, please speak up not. > > Agreed. + 1. Juha > > > Peter > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jan 5 19:04:02 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8F1A038F for ; Mon, 5 Jan 2015 19:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FvxYiMA_O9aS for ; Mon, 5 Jan 2015 19:03:56 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id BFC971A066B for ; Mon, 5 Jan 2015 19:03:56 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 88FBF32E59C; Tue, 6 Jan 2015 12:03:11 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3744_42c3_b4387993_c550_4c30_9c31_60084280f0d6; Tue, 06 Jan 2015 12:03:10 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EBC7BBF4CC; Tue, 6 Jan 2015 12:03:10 +0900 (JST) Message-ID: <54AB506E.1060208@it.aoyama.ac.jp> Date: Tue, 06 Jan 2015 12:03:10 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> In-Reply-To: <54AA7428.4080301@helsinki.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YcO1pDWRWO1cXyUeWkIbBcEcZH4 Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:04:00 -0000 On 2015/01/05 20:23, Juha Hakala wrote: > Hello, > > On 25.12.2014 8:28, John C Klensin wrote: >> The first part of Section 7, "Defining a URN Namespace", >> outlines broad requirements. Under item (2), it seems >> worthwhile to clarify that the status of *-components be >> specified here (it is explained in more detail in Section 7.2, >> as promised). >> >> Suggestion: >> >> Old: >> 2. The syntax of URNs assigned within the namespace. >> >> New: >> 2. The syntax of URNs assigned within the namespace, >> including whether p-, q-, and/or f-components are >> allowed. > > + 1. > > The downside of this is that people creating registration requests must > find out what the implications of these components are for their > identifier systems. But it should be easy both to supply this > information, and to check if the information provided in the > registration request is OK. > > Namespaces which do not intend to support resolution services should not > allow q-component. Namespaces which deal with digital manifestations may > be able to support f-component. We should make sure we write so in the draft. Regards, Martin. > The namespaces I am familiar with will at least for the time being not > use the p component even if it were technically possible to do so. > > Juha >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > From nobody Mon Jan 5 22:17:26 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF951A90FD for ; Mon, 5 Jan 2015 22:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gsB6lyBkwPV3 for ; Mon, 5 Jan 2015 22:17:20 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 73D091A90F8 for ; Mon, 5 Jan 2015 22:17:19 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4309932E543; Tue, 6 Jan 2015 15:16:33 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3741_2c21_d727cafa_6d0c_4640_98f5_c16e27c33682; Tue, 06 Jan 2015 15:16:32 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9A1D8BF4CC; Tue, 6 Jan 2015 15:16:32 +0900 (JST) Message-ID: <54AB7DC0.1020909@it.aoyama.ac.jp> Date: Tue, 06 Jan 2015 15:16:32 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> In-Reply-To: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/u-SzGpLcGacjyb4Ve4cPYz9crqI Subject: Re: [urn] 2141bis questions - (6) NID syntax for informal namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:17:23 -0000 I agree, leading zeroes should be forbidden. Except for the ABNF itself, it's much simpler. Regards, Martin. On 2014/12/25 15:09, John C Klensin wrote: > Section 6.2 specifies the syntax of NIDs for Informal > Namespaces, but it lacks specificity in one area, which is > whether numbers with leading zeros are permitted and, if they > are, whether NIDs with leading zeros are considered equivalent > to those with the same numeric values with the leading zeros > removed. I suggest we pick one of two options and document it > more or less as described below. > > By the way, the syntax of an NID for an informal namespace is > not the syntax of the namespace. Equally important, the > syntax snippet isn't ABNF, ABNF is not referenced, and there is > no production for "". Those are editorial issues that > will have to be fixed in any event. > > Option 1: Leading zeros forbidden. Remove the present format > snippet and replace > > Old: > > Thus the syntax of an informal namespace is: > > "urn-" > > New: > The syntax for the NID of an informal namespace is: > > InformalNamespaceNID = "urn-" Digit19 [ *Digit09] > Digit19 = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / > "9" > Digit09 = "0" / Digit19 > I think Option 1 is probably easier and simpler. A hypothetic > third option in which an NID with leading zeros in the number is > equivalent to one with them stripped leads, I think, to madness > despite its numerical obviousness. > > john From nobody Tue Jan 6 01:33:24 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D62F1A911F for ; Tue, 6 Jan 2015 01:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.599 X-Spam-Level: * X-Spam-Status: No, score=1.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RdDnOrGrg9am for ; Tue, 6 Jan 2015 01:33:20 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 124531A9118 for ; Tue, 6 Jan 2015 01:33:19 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 89C0532E534; Tue, 6 Jan 2015 18:32:33 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3744_8d58_57b59aba_ae15_4b16_9250_e741e7c75e1b; Tue, 06 Jan 2015 18:32:33 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A4803BF537; Tue, 6 Jan 2015 18:32:32 +0900 (JST) Message-ID: <54ABABB1.1020000@it.aoyama.ac.jp> Date: Tue, 06 Jan 2015 18:32:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Newton , John C Klensin References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/TDk9Xhx6hm4vXix1Og6Bpjzb--g Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:33:22 -0000 On 2014/12/24 02:49, Andrew Newton wrote: > On Tue, Dec 23, 2014 at 12:13 PM, John C Klensin wrote: > >> "Note that "?" is not a special character after its >> first instance introduces a q-component (assuming one is >> allowed by the namespace). "?" appearing later in a >> q-component or in an f-component does not require >> %-escaping except as required on a per-namespace basis." >> >> Is that roughly correct? What we want? >> > > > > Using my possibly faulty recollection of 3986, I thought "?" was a general > delimiter That's correct, see http://tools.ietf.org/html/rfc3986#section-2.2. > and those needed to be escaped no matter what when not being used > as a delimiter. No. See http://tools.ietf.org/html/rfc3986#section-3.4 and http://tools.ietf.org/html/rfc3986#section-3.5. > From an implementation standpoint, certainly escaping "?" > everywhere is easier than only escaping it in certain portions of the UR*. It depends. Certainly, you don't want to escape the '?' that starts the q-component itself. Regards, Martin. P.S.: Checking the spec beats recollection (faulty or not) every time. From nobody Tue Jan 6 01:42:14 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748451A1EF1 for ; Tue, 6 Jan 2015 01:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ElRu1JialS-K for ; Tue, 6 Jan 2015 01:42:11 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 395431A1BC3 for ; Tue, 6 Jan 2015 01:42:11 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7709332E579; Tue, 6 Jan 2015 18:41:26 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3744_8e6d_4345dd5a_baee_40d0_9c72_40213955e5e7; Tue, 06 Jan 2015 18:41:26 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9D1D0BF537; Tue, 6 Jan 2015 18:41:25 +0900 (JST) Message-ID: <54ABADC6.6070604@it.aoyama.ac.jp> Date: Tue, 06 Jan 2015 18:41:26 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , John C Klensin , urn@ietf.org References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <5499B73C.3070506@andyet.net> In-Reply-To: <5499B73C.3070506@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/kpNT7t7kHNaOxM2hDCovPp3IAgg Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:42:12 -0000 On 2014/12/24 03:41, Peter Saint-Andre - &yet wrote: > On 12/23/14, 10:13 AM, John C Klensin wrote: >> In section 3.3.2 on q-component, it seems reasonable to add a >> bit of explanation, thereby providing some protection from >> people who might assume they know what 3986 says without >> checking it Probably a good idea. >> (especially given the ABNF issues with that >> document). [I think we had a policy of avoiding such remarks.] >> I propose something like: >> >> "Note that "?" is not a special character after its >> first instance introduces a q-component (assuming one is >> allowed by the namespace). "?" appearing later in a >> q-component or in an f-component does not require >> %-escaping except as required on a per-namespace basis." >> >> Is that roughly correct? What we want? > > As I read RFC 3986, what you propose is indeed roughly correct as an > informational note. I suggest shortening it to something like: Note that "?" can be used without %-encoding inside q-components and f-components. This removes the "except as required on a per-namespace basis", but I think it would be a really terribly bad idea to make escaping rules scheme dependent. >> There is also another issue with that paragraph. Given the >> "syntax only" principle, it is not clear that unquoted "?" [I guess by 'unquoted', you mean not %-encoded?] must >> be prohibited from appearing in the NSS and/or p-component > > I think it must be prohibited, given the ABNF definitions in RFC 3986 > that we borrow here. > > NSS = 1*(pchar) > p-component = "/" path-absolute > path-absolute = "/" [ segment-nz *( "/" segment ) ] > segment = *pchar > pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > > (no gen-delims allowed there) > >> (if >> we think that is distinct). > > I think the p-component is not part of the NSS. > > namestring = assigned-name > [ p-component ] > [ q-component ] > [ f-component ] > assigned-name = "urn" ":" NID ":" NSS > >> The argument for prohibiting it is >> potential confusion. The argument for allowing it is that it >> might be needed for externally-defined name spaces for which >> %-encoding would either be clutter or actually problematic. > > I would favor prohibiting it. Of course it must be prohibited, because the first non-%-encoded '?' starts the query part (q-component). You cannot have the cake and eat it too. Regards, Martin. From nobody Tue Jan 6 06:46:54 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742D1A8832 for ; Tue, 6 Jan 2015 06:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 FKiNfGUJdcW5 for ; Tue, 6 Jan 2015 06:46:51 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E4D1A8831 for ; Tue, 6 Jan 2015 06:46:50 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so30511421pdb.4 for ; Tue, 06 Jan 2015 06:46:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L6utmk5Q4M5pNhhSvJW5W19q4xLQ65hxxlA/E0fti2U=; b=Sp2ZQmCUH0xGvXXfp1FBqeeGjkhbqhIzUZ9ijHDTiJUefSPlsEyNXzhI+eOlczLPdO OFWCmSg+MI3etszd2575Oy4fjPSPP6OtQrltfAaRagFGDP1QB6fqnrtMb3f7FW6wxQpF RpBlAYO+SOSQoOD+Vwwt3m/3yyORLCpra7b6HLWFAEBU+ErTNPHVpCcZHLkimc/LymTz 2JdR6nsU1bZNAc5GPhmEf87KPXvv3esPLGqp8sstrNY2hjnGpa1vVOjjWFOqMB7DXVjx AoRD5/24OUUyqSZQxKQG75dl9e6surj7jUdbc1aqVGj9gU4fUEkEZAefIoI4xU+RP2RA Es4g== X-Gm-Message-State: ALoCoQlDR8u1RvOHVF1i4LhKEP88ajxIvHZo3fg0uvNgi4J3EhOVqvb39mIpOw94gU+q5LyKW940 MIME-Version: 1.0 X-Received: by 10.70.38.71 with SMTP id e7mr157534604pdk.130.1420555610466; Tue, 06 Jan 2015 06:46:50 -0800 (PST) Received: by 10.66.135.164 with HTTP; Tue, 6 Jan 2015 06:46:50 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <54ABABB1.1020000@it.aoyama.ac.jp> References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <54ABABB1.1020000@it.aoyama.ac.jp> Date: Tue, 6 Jan 2015 09:46:50 -0500 Message-ID: From: Andrew Newton To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=047d7bfe9d3a8bc567050bfce078 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FDuL5AEJXtbSmYEwRjwg2i0znHo Cc: "urn@ietf.org" Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:46:52 -0000 --047d7bfe9d3a8bc567050bfce078 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 6, 2015 at 4:32 AM, "Martin J. D=C3=BCrst" wrote: > On 2014/12/24 02:49, Andrew Newton wrote: > >> On Tue, Dec 23, 2014 at 12:13 PM, John C Klensin >> wrote: >> >> "Note that "?" is not a special character after its >>> first instance introduces a q-component (assuming one is >>> allowed by the namespace). "?" appearing later in a >>> q-component or in an f-component does not require >>> %-escaping except as required on a per-namespace basis." >>> >>> Is that roughly correct? What we want? >>> >>> >> >> >> Using my possibly faulty recollection of 3986, I thought "?" was a gener= al >> delimiter >> > > That's correct, see http://tools.ietf.org/html/rfc3986#section-2.2. > > and those needed to be escaped no matter what when not being used >> as a delimiter. >> > > No. See http://tools.ietf.org/html/rfc3986#section-3.4 and > http://tools.ietf.org/html/rfc3986#section-3.5 As I said, when not being used as a delimiter... which is what is going on in 3.4 and 3.5. Or am I missing some finer point you are trying to make? > From an implementation standpoint, certainly escaping "?" >> everywhere is easier than only escaping it in certain portions of the UR= *. >> > > It depends. Certainly, you don't want to escape the '?' that starts the > q-component itself. > Obviously! But that's not the issue given the text quoted above from the draft. -andy --047d7bfe9d3a8bc567050bfce078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 6, 2015 at 4:32 AM, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2014/12/24 02:49, Andrew Newton wrote:
On Tue, Dec 23, 2014 at 12:13 PM, John C Klensin <john-ietf@jck.com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Note that "?" is not a special c= haracter after its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0first instance introduces a q-component (= assuming one is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allowed by the namespace).=C2=A0 =C2=A0&q= uot;?" appearing later in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0q-component or in an f-component does not= require
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%-escaping except as required on a per-na= mespace basis."

Is that roughly correct?=C2=A0 What we want?


<chair hat=3D"off"/>

Using my possibly faulty recollection of 3986, I thought "?" was = a general
delimiter

 That's correct, see http://tools.ietf.org/html/rfc3986#section= -2.2.

and those needed to be escaped no matter what when not being used
as a delimiter.

 No. See http://tools.ietf.org/html/rfc3986#section-3.4 and http://tools.ietf.org/html/rfc3986#section-3.5

As I said, when not being used as a delimiter... which is = what is going on in 3.4 and 3.5. Or am I missing some finer point you are t= rying to make?
=C2=A0
>From an implementation standpoint, certainly escaping "?"
everywhere is easier than only escaping it in certain portions of the UR*.<= br>

It depends. Certainly, you don't want to escape the '?' that st= arts the q-component itself.

Obviously!= But that's not the issue given the text quoted above from the draft.

-andy
--047d7bfe9d3a8bc567050bfce078-- From nobody Thu Jan 8 19:50:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D531A1B60; Thu, 8 Jan 2015 19:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 e9Z5DM5Rk3-9; Thu, 8 Jan 2015 19:50:38 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CCE1A1A36; Thu, 8 Jan 2015 19:50:38 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at20so13162375iec.5; Thu, 08 Jan 2015 19:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6sLGI9jJjUej5tmI/jkvUZaJH7hLXi5uXYltWSjHGBc=; b=hWPHDEdEMU3xAjYq2JC6mx9U13yHgI+GqipAUAAMalpLnyjl+8DhU5Q5XL/xRPCcGM 0h31DcI7CjViDAXIdf3Fe/9qfkPSeQLUBY1HzgX/UkJWLd7TM7Dm+cP4qz4uwHlGnmji J0l7bqJMuJaFM6sH/pKFkjXn2gkWrDAOrPq4/nI3LJEFASk54Th4Go1gXxdGlrtwZCdM +oHeCw5QRdYipHjikFxJvEwaLkOovMeNsRcc+QJC59jd7Ms93C9Xx8KDRsB0tucpTS9t jzw7BZ7SaN4ADyReqwx7wjtQGCvwBbN2nUshKoSWpvr9yAxSGRuocXY928trGg5a1L/6 WgaA== MIME-Version: 1.0 X-Received: by 10.50.127.241 with SMTP id nj17mr403548igb.22.1420775434290; Thu, 08 Jan 2015 19:50:34 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.83 with HTTP; Thu, 8 Jan 2015 19:50:34 -0800 (PST) In-Reply-To: <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> Date: Fri, 9 Jan 2015 11:50:34 +0800 X-Google-Sender-Auth: hpAp2RfeRpa1H5U2clV19dHK82o Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: urn-nid@ietf.org, "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 03:50:41 -0000 Closing the loop on this: > Again, I'll defer to your decision about not combining the two > lists now, but note that, IMO, the continued separation is > weakening the work of this WG and increasing the risk of bad > results. Thanks. So here's the deal: 1. The IESG has just given approval for draft-higgs-hbbtv-urn, and as soon as he posts a new version I'm going to let it go out. That covers the in-process ones. 2. I will not start processing on any other URN namespace requests until this WG has finished the update. 3. I'll watch the time-frame on that, and reserve the right to reconsider at some point. Fair? Barry On Tue, Dec 30, 2014 at 10:28 PM, John C Klensin wrote: > > > --On Monday, December 29, 2014 15:37 -0500 Barry Leiba > wrote: > >>>> So I think we should put "urn@ietf.org" into the draft as the >>>> address for review/discussions of namespace proposals, with >>>> the understanding that this will attain force when the draft >>>> is published as an RFC. >>> >>> Actually, I think we should go a step further. I think we >>> should celebrate the new year and expected rapid progress in >>> the WG >> >> One can hope, and I do. >> >>> by blocking all pending and future URN namespace >>> registrations by referring them to the WG for formal review >>> until 2141bis is approved and becomes the new procedure. >> >> I strongly disagree with blocking pending ones. There is only >> one, and there's no reason to stop it now. If you see >> something wrong with it, say so specifically. If not, let it >> be approved, and we'll deal only with the future now. > > Some observations below, but I'm going to defer to you on this > because I just don't have time or energy to both have a long > discussion and to make progress on the URNBIS WG documents. > >> The urn-nid list is not a secret, and anyone here who thinks >> they need to scrutinize NID requests now more strongly than >> earlier... need only go there and do so. It would be sillier >> to have those requesting NIDs post to and follow this list, >> which goes far beyond what they know or care to know. > > I was actually thinking about the issue the other way around. > It has long been my experience that anyone who is active in the > IETF, knows where to find things or who to ask, and have lots of > time on their hands can find or follow just about anything that > amuses them. There have historically been exceptions, but they > are few and becoming fewer. However, one of several issues > with URNBIS is that people are coming into the discussions with > the perspective of one particular set of needs and advocating > for them on the implicit assumption that, if those needs are > accommodated, everything else will be taken care of [1]. > > The result is that we aren't getting a sufficient number of > perspectives and that increases the risks that we will get > something seriously wrong by omitting consideration of an > important case. So my thinking was to create a situation in > which someone proposing a new URN namespace and NID was more or > less forced, as a condition for getting that NID, to follow and > participate in the WG, primarily wrt two questions: > > (i) Would any of the changes being proposed either hurt > or help setting up their namespace, and any others > similar to it that they can think about, be defined in a > way that is clear, reasonable, and natural? > > (ii) Are there additional changes that should or should > not be made that would be significant from their > perspective? > > Now, one could figure out other ways to ask those questions than > having them emerge in a dialog with the WG, and try to assure > that we got answers, then forcing applicants onto the on the URN > mailing list and holding the applications until the WG signed > off. But, right now, it appears to me that we are not, and have > not been, getting those answers from the perspective of any > recent applicants other than Sean, and he hasn't been involved > for very long. > >>> I note that RFC 3406 not only requires IETF Consensus for new >>> URN namespaces but explicitly quotes the portion of RFC 2434 >>> pointing to referral to relevant WGs, so it has probably been >>> an error to approve new URN namespaces since this "bis" WG >>> came into being without formally asking the WG for it >>> consensus opinion. >> >> Hm. >> I don't see it that way. What I say above has always applied, >> and the existing documents shunted the work over to urn-nid >> for good reason. It's been quite a good thing, really, through >> most of the life of this working group, that it hasn't >> directly been on the hook for reviewing and approving NID >> requests. Participants here can be presumed to know well that >> urn-nid is where those go, and to know well how to go there >> too. > > See above. > >>... >>> but I believe that the IETF Last Call on >>> draft-higgs-hbbtv-urn should not be closed out and an IESG >>> vote taken until this WG has formally reviewed it for >>> conformance to our plans going forward >> >> Please, let's not do that. Let's just include that in the >> above "what's done is done" category, and let it finish. >> Unless you see specific harm, of course, which you absolutely >> should comment on. > > I actually commented, at some length, on the GSMA/IMEI > namespace(s) (now RFC 7254 and 7255). Those comments went > nowhere, including no useful responses from the authors or GSMA. > I considered making a fuss during the last round of IETF Last > Call (and, if necessary, on appeal) and concluded that > > (i) I'm reluctant to tell another standards body what > they need, even though I'd be a lot happier if there was > some sort of roadmap rather than "this request now and > maybe there will be others later"; > (ii) I don't see a particular example, in its own > namespace and with its own NID, as being especially > harmful -- especially since nothing says "you get to use > this as a precedent" -- even if there were serious > problems with it; > (iii) URNBIS wasn't nearly far enough along for us to > have a serious discussion about one GSMA namespace and > qualifiers of various sorts (?-components ?) that would > identify different uses of that namespace. I do note > that, AFAIK, the situation with GSMA is rather different > from that with ISO/TC 46. In the latter case, there are > separate registration authorities and oversight > arrangements for, e.g., ISSN and ISBN. If the > registrations arrived, de novo, under the procedures > outlined in 2141bis (and the former 3406bis), they would > almost certainly arrive from different applicants. > GSMA, again AFAIK, is a little more monolithic, so it > would be reasonable to press for "one organization, one > broad set of topics, one namespace" or at least for an > explanation of why that was not appropriate; > (iv) I just don't have time to both fight individual > URN namespace battles (unless they are obviously > critical-path), try to drag i18n work along, and pay > attention to anything else IETF-related. > > >>... >> I am mostly happy to hold the future requests up, and I think >> it's not unreasonable to do that, provided that we do put a >> time limit on it. > > Again, see the discussion of motivation above. > >> The possible exception is "lex", which has been held up very >> long already. It is, on the other hand, one that I find >> problematic for a number of reasons, and when the authors have >> responded to my last comments to them I'm inclined to ask you, >> John, to be its document shepherd... which may, in itself, >> throw it into the "delayed" pile (if you share my concerns, at >> least some of them, and/or have your own). > > In the interest of future discussion and to keep this note from > getting longer, I'll reply separately on that subject. > > Again, I'll defer to your decision about not combining the two > lists now, but note that, IMO, the continued separation is > weakening the work of this WG and increasing the risk of bad > results. > > best, > john > > > [1] There are more negative versions of that story, including > "as long as my needs are met, I don't care about anything else", > but such hypotheses are unnecessary to my point. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Jan 9 11:46:50 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4B1A0084; Fri, 9 Jan 2015 11:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nG2GiQG6p88m; Fri, 9 Jan 2015 11:46:45 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 995E41A006C; Fri, 9 Jan 2015 11:46:45 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y9fW7-000LLQ-Ju; Fri, 09 Jan 2015 14:46:43 -0500 Date: Fri, 09 Jan 2015 14:46:32 -0500 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <1D6DD11066A060EED966B640@JcK-HP8200.jck.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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn-nid@ietf.org, urn@ietf.org, Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 19:46:47 -0000 --On Friday, January 09, 2015 11:50 +0800 Barry Leiba wrote: > Closing the loop on this: > >> Again, I'll defer to your decision about not combining the two >> lists now, but note that, IMO, the continued separation is >> weakening the work of this WG and increasing the risk of bad >> results. > > Thanks. So here's the deal: > > 1. The IESG has just given approval for draft-higgs-hbbtv-urn, > and as soon as he posts a new version I'm going to let it go > out. That covers the in-process ones. > > 2. I will not start processing on any other URN namespace > requests until this WG has finished the update. > > 3. I'll watch the time-frame on that, and reserve the right to > reconsider at some point. > > Fair? Certainly reasonable. john From nobody Sat Jan 10 23:36:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE401A1B1A; Sat, 10 Jan 2015 23:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 wgjKDfNj2-o6; Sat, 10 Jan 2015 23:36:05 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BDB1A0087; Sat, 10 Jan 2015 23:36:05 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F9FC22E1F4; Sun, 11 Jan 2015 02:36:01 -0500 (EST) Message-ID: <54B2279C.2020203@seantek.com> Date: Sat, 10 Jan 2015 23:34:52 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "urn-nid@ietf.org" , "urn@ietf.org" References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Barry Leiba Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 07:36:07 -0000 I am catching up on e-mail and, other than my parenthetical note about a = couple of drafts, was unable to respond to this thread until now. On 12/29/2014 12:37 PM, Barry Leiba wrote: >>> So I think we should put "urn@ietf.org" into the draft as the >>> address for review/discussions of namespace proposals[...] >>> Actually, I think we should go a step further. I think we >>> should celebrate the new year and expected rapid progress in the >>> WG > One can hope, and I do. > >> by blocking all pending and future URN namespace >> registrations by referring them to the WG for formal review >> until 2141bis is approved and becomes the new procedure. and: > and that authors or proponents of > > [drafts] > > should be notified that their drafts [1] are going to be > referred to the WG for formal review when IETF Consensus > approval is formally requested. I completely disagree with, and would like to point out the=20 contradiction in terms, about: "I think we should celebrate...rapid=20 progress...*by blocking all pending and future [work]...*" With all due respect to the technical acumen of the URNBIS participants, = that WG has been around for a couple of years already and has failed to=20 produce thus far. There has been change of personnel, directional=20 problems, etc. Moreover, the group did not meet at IETF 91. Meanwhile there are a number of URN NID proposals that have languished=20 or have been blocked for seemingly obscure technical reasons, or because = people are evaluating the proposals based on shifting sands (i.e.,=20 URNBIS drafts) rather than objective, consensus-based criteria (RFC=20 2141, RFC 3406, etc.). People are debating about angels on the head of a pin, while=20 implementers, in good faith, are trying hard to build applications and=20 deliver them to market that make use of this technology area. If proposed NIDs don't match opinions in the URNBIS work, maybe that=20 should be a clue that (shifting) concepts around URNs is not delivering=20 the value that folks need to get out of this work. Practice should=20 inform the theory. And, in particular, drafts initiated up to now=20 (really, up until URNBIS finishes producing) should not be held up. Thus, the proposal "not [to] start not start processing on any other URN = namespace requests until [the URNBIS] WG has finished the update" is=20 both unfair to participants and technically unsound. (Under the current rules, new formal URN namespace registrations require = IETF Consensus. Therefore if any particular proposed NID conflicts with=20 the clear direction of the URNBIS work, a sufficiently small faction of=20 motivated URNBIS participants can block it anyway. That alone should get = proposed namespace authors and URNBIS participants to play nice, without = making one camp beholden to the other.) Thank you, Sean From nobody Sat Jan 10 23:58:49 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9701A1B1A for ; Sat, 10 Jan 2015 23:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 vLSGkAbSIM7R for ; Sat, 10 Jan 2015 23:58:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA8E1A0087 for ; Sat, 10 Jan 2015 23:58:45 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 748BD22E1F4 for ; Sun, 11 Jan 2015 02:58:44 -0500 (EST) Message-ID: <54B22CF0.8090002@seantek.com> Date: Sat, 10 Jan 2015 23:57:36 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 07:58:47 -0000 "For the record" I looked closely at draft-ietf-urnbis-rfc2141bis-urn-08, as well as the past few months' comments. Overall it looks okay. I would quibble with some word choices but with the comments already posted, it looks like it is on the right track. The only thing that concerns me is the term "basic Latin" in Section 3.2.: In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, namespaces SHOULD NOT allow characters outside the basic Latin repertoire unless the nature of the particular namespace makes such characters necessary. I believe that this is supposed to mean the "C0 Controls and Basic Latin" block in the Unicode Standard, which is exactly equivalent to US-ASCII (both in character set, and when encoded in UTF-8). See, e.g., and . I believe that this paragraph is blessing the entire range U+0000 - U+007F, not just the characters in the RFC 3986 repertoire. However, the term "basic Latin" is not defined in the draft-08 text, and could easily be misread to refer to: a) basic Latin (i.e, characters used to teach Latin in grade school, monasteries, seminaries, etc.); b) basic Latin characters (i.e., characters used in certain well-populated countries in Western Europe, therefore including U+00A0 - U+00FF, but possibly excluding the C0 and C1 ranges U+0000 - U+001F and U+0080 - U+009F); or c) only the range U+0020 - U+007E. At a minimum, this range needs to be clarified. At medium-scope, I do not see the point of that paragraph in Section 3.2. Basically it says "don't use non-US-ASCII, unless you have to". Okay...but...is this actionable? If you are encoding digits, using the unreserved set of characters is obvious. If you are encoding sub-namespaces (e.g., urn:ietf:rfc), the "sub-namespace name" will be fixed by the spec. I suggest excising the paragraph. At broad-scope, it appears that the UTF-8/Unicode assumption in urn: URIs is softened in this draft, compared to RFC 2141. Maybe I missed something awhile back, but why is that? I thought that all URNs are UTF-8/Unicode, and that made everything nice and consistent. Sean From nobody Sun Jan 11 05:50:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2071A3BA6; Sun, 11 Jan 2015 05:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 7a7yBb7fwgDY; Sun, 11 Jan 2015 05:50:45 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13491A3BA7; Sun, 11 Jan 2015 05:50:44 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so20603238lab.10; Sun, 11 Jan 2015 05:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dFDCQklvkmEjKfzPiaxWTagElDyJJ21ETErbF1Vnkuc=; b=Ra0da+EAVCkRf2ZU4YkNjdWqq/vkNr0hNgmOv0ZY0XDtJKiDWHKMGh6e4ku+beVplt H/eTG4jbYaAVMcn9Zd1dGCJZUK+3Z0iH5dfNAd5NY/BgxcsY+rBP9mxninwO8I8V3tN/ SON6YqJas9lNGnJ9VxFHBNy8Yj6pR8ZekT7IgfhYsnsxBin7q+5lNOoIpqZXNjWBNB5e Jhe/tqFZVtk5tW0kSDyjMAtzG6n84dtYfa1ISimPXqitYaxRcpmDKiLeZfskEeVQl8MD +x0cLKHs82XeThBNpvwa9Xq/KPd3gteoZ5RVlCQzmN+4LL80bOqQcSioeIe4B+dlT5Xb LDXw== MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr31592514lac.3.1420984242969; Sun, 11 Jan 2015 05:50:42 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Sun, 11 Jan 2015 05:50:42 -0800 (PST) In-Reply-To: <54B2279C.2020203@seantek.com> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <54B2279C.2020203@seantek.com> Date: Sun, 11 Jan 2015 21:50:42 +0800 X-Google-Sender-Auth: a3tBiDKPa15kpRuQt_VpX2wmidk Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "urn-nid@ietf.org" , "urn@ietf.org" Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 13:50:47 -0000 > I completely disagree with, and would like to point out the contradiction in > terms, about: "I think we should celebrate...rapid progress...*by blocking > all pending and future [work]...*" ... > Thus, the proposal "not [to] start not start processing on any other URN > namespace requests until [the URNBIS] WG has finished the update" is both > unfair to participants and technically unsound. Sean, I understand what you're saying, and I share some of your concern here, which is why, in my "closing the loop" message, I said that I'm watching the time and will re-evaluate if we remain stalled. But I also understand the concern about (1) registering more and more URN namespaces without taking into account the changes that are in the works and (2) registering more and more URN namespaces without getting input from the registrants about whether the changes that are in the works suit their needs. I'm therefore willing to delay those requests for a reasonable time in order to try to get that input and have the changes taken into account. Let's see how things go over the next couple of months, and then figure out where we are. Barry On Sun, Jan 11, 2015 at 3:34 PM, Sean Leonard wrote: > I am catching up on e-mail and, other than my parenthetical note about a > couple of drafts, was unable to respond to this thread until now. > > On 12/29/2014 12:37 PM, Barry Leiba wrote: >>>> >>>> So I think we should put "urn@ietf.org" into the draft as the >>>> address for review/discussions of namespace proposals[...] >>>> Actually, I think we should go a step further. I think we >>>> should celebrate the new year and expected rapid progress in the >>>> WG >> >> One can hope, and I do. >> >>> by blocking all pending and future URN namespace >>> registrations by referring them to the WG for formal review >>> until 2141bis is approved and becomes the new procedure. > > and: >> >> and that authors or proponents of >> >> [drafts] >> >> should be notified that their drafts [1] are going to be >> referred to the WG for formal review when IETF Consensus >> approval is formally requested. > > > I completely disagree with, and would like to point out the contradiction in > terms, about: "I think we should celebrate...rapid progress...*by blocking > all pending and future [work]...*" > > With all due respect to the technical acumen of the URNBIS participants, > that WG has been around for a couple of years already and has failed to > produce thus far. There has been change of personnel, directional problems, > etc. Moreover, the group did not meet at IETF 91. > > Meanwhile there are a number of URN NID proposals that have languished or > have been blocked for seemingly obscure technical reasons, or because people > are evaluating the proposals based on shifting sands (i.e., URNBIS drafts) > rather than objective, consensus-based criteria (RFC 2141, RFC 3406, etc.). > > People are debating about angels on the head of a pin, while implementers, > in good faith, are trying hard to build applications and deliver them to > market that make use of this technology area. > > If proposed NIDs don't match opinions in the URNBIS work, maybe that should > be a clue that (shifting) concepts around URNs is not delivering the value > that folks need to get out of this work. Practice should inform the theory. > And, in particular, drafts initiated up to now (really, up until URNBIS > finishes producing) should not be held up. > > Thus, the proposal "not [to] start not start processing on any other URN > namespace requests until [the URNBIS] WG has finished the update" is both > unfair to participants and technically unsound. > > (Under the current rules, new formal URN namespace registrations require > IETF Consensus. Therefore if any particular proposed NID conflicts with the > clear direction of the URNBIS work, a sufficiently small faction of > motivated URNBIS participants can block it anyway. That alone should get > proposed namespace authors and URNBIS participants to play nice, without > making one camp beholden to the other.) > > Thank you, > > Sean > From nobody Mon Jan 12 00:06:17 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE32A1A8A67; Mon, 12 Jan 2015 00:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 ujBNFVBdfYFB; Mon, 12 Jan 2015 00:06:07 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E753C1A8A66; Mon, 12 Jan 2015 00:06:06 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6932322E26A; Mon, 12 Jan 2015 03:06:05 -0500 (EST) Message-ID: <54B38029.9060804@seantek.com> Date: Mon, 12 Jan 2015 00:04:57 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <54B2279C.2020203@seantek.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn-nid@ietf.org" , "urn@ietf.org" Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 08:06:09 -0000 On 1/11/2015 5:50 AM, Barry Leiba wrote: >> I completely disagree with, and would like to point out the contradiction in >> terms, about: "I think we should celebrate...rapid progress...*by blocking >> all pending and future [work]...*" > ... >> Thus, the proposal "not [to] start not start processing on any other URN >> namespace requests until [the URNBIS] WG has finished the update" is both >> unfair to participants and technically unsound. > Sean, I understand what you're saying, and I share some of your > concern here, which is why, in my "closing the loop" message, I said > that I'm watching the time and will re-evaluate if we remain stalled. > But I also understand the concern about (1) registering more and more > URN namespaces without taking into account the changes that are in the > works and (2) registering more and more URN namespaces without getting > input from the registrants about whether the changes that are in the > works suit their needs. > > I'm therefore willing to delay those requests for a reasonable time in > order to try to get that input and have the changes taken into > account. Let's see how things go over the next couple of months, and > then figure out where we are. I can't speak for the other draft authors, but...I can live with a couple of months. Plenty of other I-Ds to write. Cheers, Sean From nobody Mon Jan 12 02:22:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835391A8AAB; Mon, 12 Jan 2015 02:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7wC47bn30Hvi; Mon, 12 Jan 2015 02:22:31 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1FA1A8AA3; Mon, 12 Jan 2015 02:22:30 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0CAMJHL013959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Jan 2015 12:22:19 +0200 Message-ID: <54B3A05B.1030809@helsinki.fi> Date: Mon, 12 Jan 2015 12:22:19 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , John C Klensin References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Helmi-Kanerva Tuori , urn-nid@ietf.org, "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 10:22:39 -0000 Hello, On 9.1.2015 5:50, Barry Leiba wrote: > > 1. The IESG has just given approval for draft-higgs-hbbtv-urn, and as > soon as he posts a new version I'm going to let it go out. That > covers the in-process ones. > > 2. I will not start processing on any other URN namespace requests > until this WG has finished the update. This should apply to the revision of existing namespaces - such as ISBN and NBN - as well. But once the URN syntax has been updated, I'll provide new versions of namespace registration requests for these identifiers. These identifiers will support f- and q-components. But specifying which resolution services will (initially) be supported would not be really useful, since any list would become outdated fairly soon. And resolvers may support only a subset of potential services (or some informal services which are not yet widely known). > > 3. I'll watch the time-frame on that, and reserve the right to > reconsider at some point. > > Fair? Depends on how long it will be necessary to wait. The National Library of Finland wishes to register a URN namespace for International Standard Collection Identifier (ISCI), but we can wait a few weeks / months. Best regards, Juha > > Barry > > On Tue, Dec 30, 2014 at 10:28 PM, John C Klensin wrote: >> >> --On Monday, December 29, 2014 15:37 -0500 Barry Leiba >> wrote: >> >>>>> So I think we should put "urn@ietf.org" into the draft as the >>>>> address for review/discussions of namespace proposals, with >>>>> the understanding that this will attain force when the draft >>>>> is published as an RFC. >>>> Actually, I think we should go a step further. I think we >>>> should celebrate the new year and expected rapid progress in >>>> the WG >>> One can hope, and I do. >>> >>>> by blocking all pending and future URN namespace >>>> registrations by referring them to the WG for formal review >>>> until 2141bis is approved and becomes the new procedure. >>> I strongly disagree with blocking pending ones. There is only >>> one, and there's no reason to stop it now. If you see >>> something wrong with it, say so specifically. If not, let it >>> be approved, and we'll deal only with the future now. >> Some observations below, but I'm going to defer to you on this >> because I just don't have time or energy to both have a long >> discussion and to make progress on the URNBIS WG documents. >> >>> The urn-nid list is not a secret, and anyone here who thinks >>> they need to scrutinize NID requests now more strongly than >>> earlier... need only go there and do so. It would be sillier >>> to have those requesting NIDs post to and follow this list, >>> which goes far beyond what they know or care to know. >> I was actually thinking about the issue the other way around. >> It has long been my experience that anyone who is active in the >> IETF, knows where to find things or who to ask, and have lots of >> time on their hands can find or follow just about anything that >> amuses them. There have historically been exceptions, but they >> are few and becoming fewer. However, one of several issues >> with URNBIS is that people are coming into the discussions with >> the perspective of one particular set of needs and advocating >> for them on the implicit assumption that, if those needs are >> accommodated, everything else will be taken care of [1]. >> >> The result is that we aren't getting a sufficient number of >> perspectives and that increases the risks that we will get >> something seriously wrong by omitting consideration of an >> important case. So my thinking was to create a situation in >> which someone proposing a new URN namespace and NID was more or >> less forced, as a condition for getting that NID, to follow and >> participate in the WG, primarily wrt two questions: >> >> (i) Would any of the changes being proposed either hurt >> or help setting up their namespace, and any others >> similar to it that they can think about, be defined in a >> way that is clear, reasonable, and natural? >> >> (ii) Are there additional changes that should or should >> not be made that would be significant from their >> perspective? >> >> Now, one could figure out other ways to ask those questions than >> having them emerge in a dialog with the WG, and try to assure >> that we got answers, then forcing applicants onto the on the URN >> mailing list and holding the applications until the WG signed >> off. But, right now, it appears to me that we are not, and have >> not been, getting those answers from the perspective of any >> recent applicants other than Sean, and he hasn't been involved >> for very long. >> >>>> I note that RFC 3406 not only requires IETF Consensus for new >>>> URN namespaces but explicitly quotes the portion of RFC 2434 >>>> pointing to referral to relevant WGs, so it has probably been >>>> an error to approve new URN namespaces since this "bis" WG >>>> came into being without formally asking the WG for it >>>> consensus opinion. >>> Hm. >>> I don't see it that way. What I say above has always applied, >>> and the existing documents shunted the work over to urn-nid >>> for good reason. It's been quite a good thing, really, through >>> most of the life of this working group, that it hasn't >>> directly been on the hook for reviewing and approving NID >>> requests. Participants here can be presumed to know well that >>> urn-nid is where those go, and to know well how to go there >>> too. >> See above. >> >>> ... >>>> but I believe that the IETF Last Call on >>>> draft-higgs-hbbtv-urn should not be closed out and an IESG >>>> vote taken until this WG has formally reviewed it for >>>> conformance to our plans going forward >>> Please, let's not do that. Let's just include that in the >>> above "what's done is done" category, and let it finish. >>> Unless you see specific harm, of course, which you absolutely >>> should comment on. >> I actually commented, at some length, on the GSMA/IMEI >> namespace(s) (now RFC 7254 and 7255). Those comments went >> nowhere, including no useful responses from the authors or GSMA. >> I considered making a fuss during the last round of IETF Last >> Call (and, if necessary, on appeal) and concluded that >> >> (i) I'm reluctant to tell another standards body what >> they need, even though I'd be a lot happier if there was >> some sort of roadmap rather than "this request now and >> maybe there will be others later"; >> (ii) I don't see a particular example, in its own >> namespace and with its own NID, as being especially >> harmful -- especially since nothing says "you get to use >> this as a precedent" -- even if there were serious >> problems with it; >> (iii) URNBIS wasn't nearly far enough along for us to >> have a serious discussion about one GSMA namespace and >> qualifiers of various sorts (?-components ?) that would >> identify different uses of that namespace. I do note >> that, AFAIK, the situation with GSMA is rather different >> from that with ISO/TC 46. In the latter case, there are >> separate registration authorities and oversight >> arrangements for, e.g., ISSN and ISBN. If the >> registrations arrived, de novo, under the procedures >> outlined in 2141bis (and the former 3406bis), they would >> almost certainly arrive from different applicants. >> GSMA, again AFAIK, is a little more monolithic, so it >> would be reasonable to press for "one organization, one >> broad set of topics, one namespace" or at least for an >> explanation of why that was not appropriate; >> (iv) I just don't have time to both fight individual >> URN namespace battles (unless they are obviously >> critical-path), try to drag i18n work along, and pay >> attention to anything else IETF-related. >> >> >>> ... >>> I am mostly happy to hold the future requests up, and I think >>> it's not unreasonable to do that, provided that we do put a >>> time limit on it. >> Again, see the discussion of motivation above. >> >>> The possible exception is "lex", which has been held up very >>> long already. It is, on the other hand, one that I find >>> problematic for a number of reasons, and when the authors have >>> responded to my last comments to them I'm inclined to ask you, >>> John, to be its document shepherd... which may, in itself, >>> throw it into the "delayed" pile (if you share my concerns, at >>> least some of them, and/or have your own). >> In the interest of future discussion and to keep this note from >> getting longer, I'll reply separately on that subject. >> >> Again, I'll defer to your decision about not combining the two >> lists now, but note that, IMO, the continued separation is >> weakening the work of this WG and increasing the risk of bad >> results. >> >> best, >> john >> >> >> [1] There are more negative versions of that story, including >> "as long as my needs are met, I don't care about anything else", >> but such hypotheses are unnecessary to my point. >> >> _______________________________________________ >> 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 -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jan 12 08:53:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9091ACD2F; Mon, 12 Jan 2015 08:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 HWCZe4plUKh0; Mon, 12 Jan 2015 08:53:07 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F831ACD2E; Mon, 12 Jan 2015 08:51:58 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so18640967lbi.3; Mon, 12 Jan 2015 08:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2Mac8HpuewsiQygnBRyPBNH4ezolXtLdx4xRRLqWJEU=; b=Eg69s/MkTkidp6+Z1JkXumidECLnVzBuVsg5c0wVtSPpC1UXacluhgk8sXXBU1sgKr tLorMnDOD8fkq6iphv3qYzjCPjtNXkUg/yddfjru2t6pjZc4genayy2vwHszpNKAb7UE 9sDrfzvpVjEB5HbMbLGyEExNvsOBPQx8Ctvc+eq3pGw0eEZl4q6oazGOWYZv2RWXMpjZ NokEbOqZ7OKtLyv7bp2Afr14Wm6FDrXBP5euY9Ao6/zIFirttn/8rMm2dg8pmpeYfeeX d0TXtjD1hHEOFWzWRhHfWWgHY8cneek5NRB8yvWOQnd9vP+8fc7pERJQ3ue+zUCBHGPy 9i+g== MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr37359486lbb.59.1421081516755; Mon, 12 Jan 2015 08:51:56 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 12 Jan 2015 08:51:56 -0800 (PST) In-Reply-To: <54B3A05B.1030809@helsinki.fi> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> <54B3A05B.1030809@helsinki.fi> Date: Mon, 12 Jan 2015 11:51:56 -0500 X-Google-Sender-Auth: kPIqG2lIEWXNgQpiAc4vx-YmQBI Message-ID: From: Barry Leiba To: Juha Hakala Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Peter Saint-Andre - &yet , Helmi-Kanerva Tuori , "urn-nid@ietf.org" , "urn@ietf.org" Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:53:08 -0000 > This should apply to the revision of existing namespaces - such as ISBN and > NBN - as well. But once the URN syntax has been updated, I'll provide new > versions of namespace registration requests for these identifiers. ... > Depends on how long it will be necessary to wait. The National Library of > Finland wishes to register a URN namespace for International Standard > Collection Identifier (ISCI), but we can wait a few weeks / months. Thanks, Juha: this is very helpful. Barry From nobody Mon Jan 12 17:32:45 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD91A883B for ; Mon, 12 Jan 2015 17:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 jgXkYuXJFdNz for ; Mon, 12 Jan 2015 17:32:41 -0800 (PST) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8DD1A883A for ; Mon, 12 Jan 2015 17:32:41 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id r10so339277pdi.9 for ; Mon, 12 Jan 2015 17:32:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=8C0rw5wL0yxoX0fy9rU4IDpBcMU7wWQXlWXJeEc7Xj0=; b=MCQJRK7ittC2nH8gA/EVngAAT/B1Zn6nhyy1ss2FqYK6fqYBeu4TZT9RDH6MInJjo/ c3nuRWlEhTd10FOGRiDRZ6UAmyqBh0eXE6uEf/H3FjsdfFFDD7snhqcmR1roGuDd3eAq Qbc8TXNI7IkmHg1LgXJHifEBXPfkj+LSfTzcgW+WTHknP1xouOZBRE0oHY3e1da1zcFG uBHP7/3tcbaYjEm/5hE0GSOLxyn7ljgwDqP4DyjY4UetRZ8s3uSR7ImCiXw7pwtRmySQ ZqkGQzMMVtfWRKhc+E7fAtGWWytGCewO6yB9kgLoRvcWMghA9jyFV8aCsCg5cZQAbtDL 6SjQ== X-Gm-Message-State: ALoCoQmt4iHyBnk/5a/6R/gaA9pQ8x/2OlBnu6JKssIjhSoyKvty34Jp0KGipHBaReK+0zizgiJU MIME-Version: 1.0 X-Received: by 10.66.183.235 with SMTP id ep11mr48003524pac.22.1421112761208; Mon, 12 Jan 2015 17:32:41 -0800 (PST) Received: by 10.66.135.164 with HTTP; Mon, 12 Jan 2015 17:32:41 -0800 (PST) X-Originating-IP: [71.191.38.92] Date: Mon, 12 Jan 2015 20:32:41 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc171a516508050c7e9996 Archived-At: Subject: [urn] roadmap for WGLC of draft-ietf-urnbis-rfc2141bis-urn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:32:43 -0000 --047d7bdc171a516508050c7e9996 Content-Type: text/plain; charset=UTF-8 All, as the working group has now found focus, we ask that all participants read draft-ietf-urnbis-rfc2141bis-urn-08 and provide comments on it. Several issues have already been noted, and group discussion is required to move this document to completion. We, the chairs, would like to see this document given a working group last call and sent to the IESG before the next IETF meeting in March. -andy --047d7bdc171a516508050c7e9996 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All, as the working group ha= s now found focus, we ask that all participants read=C2=A0draft-ietf-urnbis-rfc2141bis-urn-08 and p= rovide comments on it. Several issues have already been noted, and group di= scussion is required to move this document to completion.

We, the chairs, would like to see this document giv= en a working group last call and sent to the IESG before the next IETF meet= ing in March.

-andy
--047d7bdc171a516508050c7e9996-- From nobody Mon Jan 12 19:40:05 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4C1A8A05 for ; Mon, 12 Jan 2015 19:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 oX0S-BJykoT8 for ; Mon, 12 Jan 2015 19:40:01 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418281A8A01 for ; Mon, 12 Jan 2015 19:40:01 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id z10so947206pdj.0 for ; Mon, 12 Jan 2015 19:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SEf9QG5Y0odEih3tDHn91fW1xGvcGftSIVV8rNUiVO4=; b=S+N+pcZjVl/Yt2ZAuNy/kew0qWbtwm2xT+qrKofBSSPWxW/uRGblHOi5nO4c3dQBfJ c0N8+wS4f3rA9F1OFrERTYjeZ7bLTHsQjFs6u+ylWivDBziBmlc5f227Qo639vJa2bFN 7GRwTjRI9f6V95HfloXdzS/GzcvpqTYR1iM0MnAvo2UHSrw3rN/HY1xWrarelBR8HLBo HL+jx1dvIgsQKDaRNG4AzKFBXCCHE9JvR7npHkC8xK0uiHThc+QhNzTH+3B16jahpqhA p8hlMoLA7ml7ajCsFIA9tqGo7dNpiKYocgiST/sRgFCEQDfOQSHaVQmk8pBl84TNEKzp TPhw== X-Received: by 10.66.183.235 with SMTP id ep11mr48558863pac.22.1421120400404; Mon, 12 Jan 2015 19:40:00 -0800 (PST) Received: from spandex.local (63-140-104-62.dynamic.dsl.acsalaska.net. [63.140.104.62]) by mx.google.com with ESMTPSA id c9sm15579447pdj.52.2015.01.12.19.39.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 19:39:59 -0800 (PST) Message-ID: <54B4938E.2040509@gmail.com> Date: Mon, 12 Jan 2015 18:39:58 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> In-Reply-To: <54AB506E.1060208@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:40:04 -0000 On 1/5/15 6:03 PM, "Martin J. Dürst" wrote: > On 2015/01/05 20:23, Juha Hakala wrote: >> On 25.12.2014 8:28, John C Klensin wrote: >>> The first part of Section 7, "Defining a URN Namespace", >>> outlines broad requirements. Under item (2), it seems >>> worthwhile to clarify that the status of *-components be >>> specified here (it is explained in more detail in Section 7.2, >>> as promised). >>> >>> Suggestion: >>> >>> Old: >>> 2. The syntax of URNs assigned within the namespace. >>> >>> New: >>> 2. The syntax of URNs assigned within the namespace, >>> including whether p-, q-, and/or f-components are >>> allowed. >> >> + 1. >> >> The downside of this is that people creating registration requests must >> find out what the implications of these components are for their >> identifier systems. But it should be easy both to supply this >> information, and to check if the information provided in the >> registration request is OK. >> >> Namespaces which do not intend to support resolution services should not >> allow q-component. Namespaces which deal with digital manifestations may >> be able to support f-component. > > We should make sure we write so in the draft. > > Regards, Martin. If nobody has any issues with this, we'll consider it closed. The resolution is that the draft will include John's "New" text along with some text along the lines of what Juha specified. Melinda From nobody Mon Jan 12 19:45:03 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1591A1BB7 for ; Mon, 12 Jan 2015 19:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 kJ-RlAqxh3E3 for ; Mon, 12 Jan 2015 19:44:58 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994FF1A8872 for ; Mon, 12 Jan 2015 19:44:58 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id fl12so908654pdb.11 for ; Mon, 12 Jan 2015 19:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ffbNPmAZLqr7d/1Y8m6GUUFn+HbnqiDefvEJwDBSR2E=; b=hGJ6fyVIwZQrny3chPjZileg2n+A3OjOEcgqaSVmWpDA+5etAKtAbgtZo6beWMal5W s0jC4xx1KMOJ9ABIbOQBQ8eTPUyrDOfrkxDeRHElxC3nwEcFYtEN4PuaDWbmIqhaeNvz mN4SP09xN1rmc1bfUGWS3Ufd3zXTm3lbrEUswTE6cfXoqcF+VEzABev1BT668IujnjMK 1Bt+GKjdeBk+ee8OAkhfnSbhKGlMJhHO6Mybe1c/LA+aGyRxNTBoiKCUEb/PO2udHbdH E5OS9yjLC/RgAjVcLtbl99oW7w/gstvCPJKpogC+zys0gRxNHdSU6EeAfah8SYV4/18r sYaA== X-Received: by 10.70.123.97 with SMTP id lz1mr49186637pdb.150.1421120697824; Mon, 12 Jan 2015 19:44:57 -0800 (PST) Received: from spandex.local (63-140-104-62.dynamic.dsl.acsalaska.net. [63.140.104.62]) by mx.google.com with ESMTPSA id hn4sm15572784pdb.77.2015.01.12.19.44.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 19:44:57 -0800 (PST) Message-ID: <54B494B7.5030601@gmail.com> Date: Mon, 12 Jan 2015 18:44:55 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] IANA considerations and interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:45:00 -0000 This is regarding http://www.ietf.org/mail-archive/web/urn/current/msg02680.html. We haven't seen any feedback on John's question - do people feel that more needs to be said or that it's fine as-is? Thanks, Melinda From nobody Mon Jan 12 20:12:14 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE6C1A8845 for ; Mon, 12 Jan 2015 20:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WwgkSZ5CVihT for ; Mon, 12 Jan 2015 20:12:10 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4381A1B29 for ; Mon, 12 Jan 2015 20:12:09 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4FF7232E52E; Tue, 13 Jan 2015 13:11:24 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399f_6179_ca77e40e_7f1e_43d0_8219_c12a4672bb6d; Tue, 13 Jan 2015 13:11:23 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id BEA33BFEDA; Tue, 13 Jan 2015 13:11:23 +0900 (JST) Message-ID: <54B49AEA.1040906@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 13:11:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Melinda Shore , "urn@ietf.org" References: <54B494B7.5030601@gmail.com> In-Reply-To: <54B494B7.5030601@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] IANA considerations and interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 04:12:11 -0000 On 2015/01/13 12:44, Melinda Shore wrote: > This is regarding > http://www.ietf.org/mail-archive/web/urn/current/msg02680.html. > > We haven't seen any feedback on John's question - do people feel > that more needs to be said or that it's fine as-is? I'd agree with what John said, which would mean that we need some more text. Regards, Martin. From nobody Mon Jan 12 22:09:19 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0311A89EB for ; Mon, 12 Jan 2015 22:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 p6YXWf5_g4wl for ; Mon, 12 Jan 2015 22:09:12 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE441A1BB7 for ; Mon, 12 Jan 2015 22:09:11 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0D698nY012910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Jan 2015 08:09:08 +0200 Message-ID: <54B4B684.6070400@helsinki.fi> Date: Tue, 13 Jan 2015 08:09:08 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "urn@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Reference rot paper X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 06:09:16 -0000 Hello, Herbert Van de Sompel et al. have published a paper which investigates the reference rot problem in STM (Science, Technology and Medicine) articles: Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot Klein M, Van de Sompel H, Sanderson R, Shankar H, Balakireva L, et al. (2014) Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot.PLoS ONE 9(12): e115253. http://dx.doi.org/10.1371/journal.pone.0115253 This is not the first scientific analysis of the actual life span of HTTP URIs, but IMO it is the most thorough one so far. The results are alarming: when considering only those STM articles that contain references to Web resources, seven out of ten articles suffer from reference rot. The authors suggest that in order to safeguard the long-term integrity of the web-based scholarly record, robust solutions to to combat the reference rot problem are required. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Tue Jan 13 00:15:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CE91A005B for ; Tue, 13 Jan 2015 00:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 fkHzoe_BSBOe for ; Tue, 13 Jan 2015 00:15:46 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 01D511A8A46 for ; Tue, 13 Jan 2015 00:15:43 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 7584A8AF26; Tue, 13 Jan 2015 09:15:42 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-cb-54b4d42ec0a3 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 79.DF.15323.E24D4B45; Tue, 13 Jan 2015 09:15:42 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Tue, 13 Jan 2015 09:15:41 +0100 From: "Svensson, Lars" To: =?Windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , Melinda Shore , "urn@ietf.org" Thread-Topic: [urn] IANA considerations and interoperability Thread-Index: AQHQLuNR5qvuMffSGEatH0/hwOXE0Jy9X3AAgABUtMA= Date: Tue, 13 Jan 2015 08:15:41 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6A2FB@dnbf-ex1.AD.DDB.DE> References: <54B494B7.5030601@gmail.com> <54B49AEA.1040906@it.aoyama.ac.jp> In-Reply-To: <54B49AEA.1040906@it.aoyama.ac.jp> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.161] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Tf0yMcRzHfe95uvt27ptv1119O0UeY1ZzysxuIWahVH5sN1N/yFP36E7X lXvuUv4K42hJxOhkhRtjTMpQCCcsoyz+CMtmmiITs5jZmud57i5P/vvs9Xm/38/7s+8eSGl/ qgzQ5nBxTgdrZ5RqWr1q+dh846vr5uSGM7Emz8ArlWn/fi9tOr73m2IFldHuHVBl+Hy/FRl7 Xp5UbKDy1EstnN1WzjkXpG1VWxtHOhRlT6iKfW03qCowpKgG4ZDgRaRrqIMOzNHkxburymqg hlr8EJC+nruSSItvAjL2x1ENVFCJE8moVZTocD0gh34cVoqSKLyEHN1zVpp1eCl58PoAFZhT yYk3F1XiTOM5xNNWL0RCiHAm6RgoCaRnkYb6WkkSjheQru7vkhXgeNLS0ivNFI4hrR9/hQVq YuK7E+AE68mnD+NBnkAO1F0IC+iTyWhPU9CbRM6fGZFmhCNJd8MgXQf0XlmsV2bxyixemaUZ 0JdABF9SlGJkLUaLpcBo4VpB4FGGboHavnQ/wBAwGnRsx3WzNowt5ytL/GA9VDB65L0toIiC UkulleWt+U63neMZHVrdJ2A0gQvc9mJmBro20mLWxkxQ3s2X2QptpW4+3+20+wGBlGBNaxSt FrZyF+csDQT6wXRIMzHoyO3dZi0uYl1cMceVcc7QdjOEDEFTXgrGSCdXxFVss9ldobXg8+e0 CT75Rio0C8UWC4UM8sX/nRQw3A+yoUYolirmI76MLeFtRcHsKLRDvFQTolJuPEr7IuRGh+Dk zKcgHzZ77jUotLSj1MEZYpBbDMai2up2TPQ2RKNn40LMNNlCjDckoBk1wj2xMj75C59BpvBc UWizmKsRfrN/fbVobq8ApwahVDcO5Yp19UH2f1a28M46dM7TJh7vYl3y4wdFqgnR4PESjA7B yXGGKmDqckzddd+adSHTNA5unVqzpflgOZfoW5e6Yvgzc8WTs9Z/cOFs0pRTE9G5+Ou89XVz WztP94zfzWt/3N/5zWjWb8qfcvb9vekZcOx13sqKt3G/PrVXz8yunObbGbkq987WqmHl9+eF PuWs/kWmy7r4pP70ZYPb9blNo8nKB4+ubFzMMDRvZVMSKSfP/gXzhVyXiQQAAA== Archived-At: Subject: Re: [urn] IANA considerations and interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:15:49 -0000 Tuesday, January 13, 2015 5:11 AM, Martin wrote: > On 2015/01/13 12:44, Melinda Shore wrote: > > This is regarding > > http://www.ietf.org/mail-archive/web/urn/current/msg02680.html. > > > > We haven't seen any feedback on John's question - do people feel > > that more needs to be said or that it's fine as-is? >=20 > I'd agree with what John said, which would mean that we need some more te= xt. I agree with that, too. Best, Lars=20 From nobody Tue Jan 13 00:21:54 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6941A8A45 for ; Tue, 13 Jan 2015 00:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 XDHKx8JhMPVH for ; Tue, 13 Jan 2015 00:21:48 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B71A8A43 for ; Tue, 13 Jan 2015 00:21:48 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id B493E8AE3C; Tue, 13 Jan 2015 09:21:47 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-f5-54b4d59b6d22 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 90.EF.15323.B95D4B45; Tue, 13 Jan 2015 09:21:47 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Tue, 13 Jan 2015 09:21:47 +0100 From: "Svensson, Lars" To: Melinda Shore , "urn@ietf.org" Thread-Topic: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs Thread-Index: AQHQLuKgItq6vowTEk+iV1uSZfE+j5y9tgFA Date: Tue, 13 Jan 2015 08:21:47 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6A31C@dnbf-ex1.AD.DDB.DE> References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> In-Reply-To: <54B4938E.2040509@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.161] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHPXte145eNzePK8UWQWn5iAIh0f7I0jAqk8qw7Npu23A63d1k VpClWUwrLYNcDxVtvah8VVZCtR5kRaZm0Es0pYdaC3uYRdK9e9jV/84+v9/3c7+HwzCupFeo wLTZRtKQTeiUAhFPFB/3Y/7x7uaUyIqxOdHFxVZe9NHCr5wlnITr1rfChLq6Mc5qzkZRjIrU afNIQ0TsFpFm8PFFYU6f2Fxe3yIsAF+8LcAbQ/hC1NVbzned5ehZz2WBBYgwCX4XIEfRWfeP awBV9FZxLECICfBQ5NAw+/74CnTlxhEuc5bia9C9czbg4sno56mrPAvA6PMCdL8smsE8fDY6 UNcpYM4QT0Q9fz5zXfYTAP1qKOIz+974XDRqcWoAHoTq69udei4egBrfj7pr4qiu1cURLkOf +sfdPATtLzvDd+1HIsfTKnc2DNlqhriu7/qhtsoBXhmQWVlaKytiZUWsrEg14J0HPlSWOiqc UIWrVBnhKrIRuJ7iQws42LnUDnAMKMWwIrc5RcIn8qj8LDtYhXGUMih9TiOfDL0qX0NQmnSD SUdSSn843EVjOIEzTLpMZTBsGKpPkQRMUMpE5Wi3avUmKt1k0NkBwrh0NPYEE1UR+dtJg94l tIPpGE8ZAMtv7k6R4GrCSGaSZA5p8Ew3YJgSwXdMFT8DqSbN27Q6o2dM5+wrm+gce+IsNBMG ZtKFFOzB1E4czNsOkjAxXayf8UMqh8iitGq3WwpzO2kq9lCnNwjGDtNeuQdOdj4CaxUB8AIj w5kNjSl7oqtCDp+M01Ff1oBRKkJgcCl9h0AWn2wdBIn0E0lhH+MV03+o/x0l8BbzGtPc0Flx BkxlKsrcbKoriX5bf1i7r4m5sJEwsi88wFCxh7ov7IRyD5ysUxSAypoIve1x8s4Sge1zW/W6 tMPd3Q9DX/AvlX6vzDUtf3Ds47Jd5jMx0t/dd9LGks3y9j822d7XJyMcO9aWvGzbExdDxvt+ 4876OjLyZodQ9fP2yVeZ6V5ke8ffgdrU2s3k303rx7IHzUEEdnpxXuuhea3aaV7b+XGz1w91 aBaFPetwFCp5lIaICuUaKOIfJOAE6nMEAAA= Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:21:51 -0000 On Tuesday, January 13, 2015 4:40 AM, Melinda wrote: > On 1/5/15 6:03 PM, "Martin J. D=FCrst" wrote: > > On 2015/01/05 20:23, Juha Hakala wrote: > >> On 25.12.2014 8:28, John C Klensin wrote: > >>> The first part of Section 7, "Defining a URN Namespace", > >>> outlines broad requirements. Under item (2), it seems > >>> worthwhile to clarify that the status of *-components be > >>> specified here (it is explained in more detail in Section 7.2, > >>> as promised). > >>> > >>> Suggestion: > >>> > >>> Old: > >>> 2. The syntax of URNs assigned within the namespace. > >>> > >>> New: > >>> 2. The syntax of URNs assigned within the namespace, > >>> including whether p-, q-, and/or f-components are > >>> allowed. > >> > >> + 1. > >> > >> The downside of this is that people creating registration requests mus= t > >> find out what the implications of these components are for their > >> identifier systems. But it should be easy both to supply this > >> information, and to check if the information provided in the > >> registration request is OK. > >> > >> Namespaces which do not intend to support resolution services should n= ot > >> allow q-component. Namespaces which deal with digital manifestations m= ay > >> be able to support f-component. > > > > We should make sure we write so in the draft. > > > > Regards, Martin. >=20 > If nobody has any issues with this, we'll consider it closed. The > resolution is that the draft will include John's "New" text along with > some text along the lines of what Juha specified. Looks good to me. Best, Lars=20 From nobody Tue Jan 13 00:32:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4991A0032; Tue, 13 Jan 2015 00:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 uSDs5MOZHF0v; Tue, 13 Jan 2015 00:32:28 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2190D1A8984; Tue, 13 Jan 2015 00:32:28 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 73C828AE3C; Tue, 13 Jan 2015 09:32:27 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-3a-54b4d81b089b Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id DA.EF.15323.B18D4B45; Tue, 13 Jan 2015 09:32:27 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Tue, 13 Jan 2015 09:32:26 +0100 From: "Svensson, Lars" To: Barry Leiba , Juha Hakala Thread-Topic: [urn] continued use of urn-nid@ietf.org list Thread-Index: AQHQLogS2ALEh/T4xEu5bJvpCAXjj5y9uVdw Date: Tue, 13 Jan 2015 08:32:25 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6A387@dnbf-ex1.AD.DDB.DE> References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <1D6DD11066A060EED966B640@JcK-HP8200.jck.com> <54B3A05B.1030809@helsinki.fi> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.161] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIcWRmVeSWpSXmKPExsXC5Wr/VVf6xpYQgxu/JCwOLb7EanHv9EJm i6ZP7ewWpx4dYba4suYEq8XU5g9MDmwe5+5cY/doWdXL7NG/cj+7x5IlP5kCWKK4bFJSczLL Uov07RK4Mi4daWQq+MpacbPlGXsD4yWWLkYODgkBE4mtH226GDmBTDGJC/fWs4HYQgKHGSVe v+fuYuQCsrczSjzcsZK5i5Gdg01AS+J9BkiJiECQxLczrawgJcwCGxgl1nfvYAFJCAtYSny+ O4cFoshKYtmJqYwQtpHEvAfHWUFsFgFVibXPz4Ht4hXwlPhx4Co7xN7bzBKbjguAnMYpECjx +kM4SJhRQFZiw4bzzCA2s4C4xKZn31khThaQWLIHIi4hICrx8vE/qLiCRMeE5awQ9QYS78/N h+rVlli28DUzxFpBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUjX3FuuqFeYopeSkqSXkrq JkZInD3fwdh3yeUQowAHoxIP75TCLSFCrIllxZW5hxj9OZiURHmFrwCF+JLyUyozEosz4otK c1KLlUR4m64BhXnhwkmlOdlKcrwbX28IERKHixaXFhdkJmfmlxbHlxblHGKU4GAGarWbA9Ka klhZlVqUDzHwEKM0B4uSOO/E3Y0hQgLpiSWp2ampBalFMNkIDg4lCV7z60CNgkWp6akVaZk5 JTBpoL5DvpuB+pBlwA5S5JXMBjpIClkC3U1MHJyHGH04eIAOqwSZz1tckJhbnJkONVuY98tV oCgPTBRsriyv3RuguWIwQVQzTzHGcyxo3z+TSYglLz8vVUqc1w1ksABIdUZpHtzdUmK8Z/4B jeFHkgAZL6XAK9cD9I8kkjiqDa8YPYHRJcybBYoEHmAuRLhXiHf/ZaAgN1QQ7FwZ3kiQc0Wh Yuhm+QDjWYR3cftmkOdLEkuQPf8EJMoDE4V6HiwoBhNENU6qgXH1K9Yiy3aRaW+WGKys5p7w ssd8/Ycsg06fJxEbX7QszNq0uXZPYdrHnSfZ5bYZObcx53va+jdYCYV/CHhn49Z2I/IMr8XX f4ZpH1xsxALrIl8U5OwNmHVPurHm0cZ6ze2nlwnIKHA53Q/erO9fesfJ6uvEe/E+v1qvT7gZ lXGl7tP6pg3PGZVYijMSDbWYi4oTAWva8dSoBAAA Archived-At: Cc: Helmi-Kanerva Tuori , "urn-nid@ietf.org" , "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] continued use of urn-nid@ietf.org list X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 08:32:30 -0000 On Monday, January 12, 2015 5:52 PM, Barry wrote: > > This should apply to the revision of existing namespaces - such as ISBN= and > > NBN - as well. But once the URN syntax has been updated, I'll provide n= ew > > versions of namespace registration requests for these identifiers. > ... > > Depends on how long it will be necessary to wait. The National Library = of > > Finland wishes to register a URN namespace for International Standard > > Collection Identifier (ISCI), but we can wait a few weeks / months. >=20 > Thanks, Juha: this is very helpful. The same applies to the German National Library: We have some registration = requests in the pipeline, but we don't need to have them processed by tomor= row. Best, Lars=20 From nobody Tue Jan 13 01:32:58 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4F1ACE34 for ; Tue, 13 Jan 2015 01:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=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 lt-H94elqu40 for ; Tue, 13 Jan 2015 01:32:48 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FC51ACDF4 for ; Tue, 13 Jan 2015 01:32:48 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 048A422E26B for ; Tue, 13 Jan 2015 04:32:46 -0500 (EST) Message-ID: <54B4E5FB.4080602@seantek.com> Date: Tue, 13 Jan 2015 01:31:39 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> In-Reply-To: <54B4938E.2040509@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 09:32:51 -0000 On 1/12/2015 7:39 PM, Melinda Shore wrote: > On 1/5/15 6:03 PM, "Martin J. D=FCrst" wrote: >> On 2015/01/05 20:23, Juha Hakala wrote: >>> On 25.12.2014 8:28, John C Klensin wrote: >>>> The first part of Section 7, "Defining a URN Namespace", >>>> outlines broad requirements. Under item (2), it seems >>>> worthwhile to clarify that the status of *-components be >>>> specified here (it is explained in more detail in Section 7.2, >>>> as promised). >>>> >>>> Suggestion: >>>> >>>> Old: >>>> 2. The syntax of URNs assigned within the namespace. >>>> >>>> New: >>>> 2. The syntax of URNs assigned within the namespace, >>>> including whether p-, q-, and/or f-components are >>>> allowed. >>> + 1. >>> >>> The downside of this is that people creating registration requests mu= st >>> find out what the implications of these components are for their >>> identifier systems. But it should be easy both to supply this >>> information, and to check if the information provided in the >>> registration request is OK. >>> >>> Namespaces which do not intend to support resolution services should = not >>> allow q-component. Namespaces which deal with digital manifestations = may >>> be able to support f-component. >> We should make sure we write so in the draft. >> >> Regards, Martin. > If nobody has any issues with this, we'll consider it closed. The > resolution is that the draft will include John's "New" text along with > some text along the lines of what Juha specified. Ehhhhhhhhhhh...........I have some issues with this. "Namespaces which deal with digital manifestations may be able to=20 support f-component." Does this imply that namespaces which deal with digital manifestations=20 must describe how the f-component is used, in order to be syntactically=20 valid or otherwise usable? (What are the consequences of tacking on an=20 f-component anyway?) Does this imply that namespaces which do not deal with digital=20 manifestations, do not support f-component? Consider f-components for urn:oid and urn:uuid. OIDs are assigned to=20 arbitrary objects, including documents, standards, and the like. UUIDs=20 are assigned to arbitrary objects as well, including (especially)=20 specific instances of digital data. In my organization, every document gets at least one OID (actually=20 multiple OIDs, depending on the version of the document). In some=20 standards organizations (e.g., ISO, ITU-T), standards get an OID or OID a= rc. Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Euro = currency. (ISO 4217 is the standard for currency identifiers.) Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs=20 refers to the Microsoft Answers forum thread started January 6, 2015,=20 with the subject "Weather module on my Home Page doesn't remember my=20 location". It is served at=20 =20 as Content-Type: text/html, and has an anchor "tabs" in the HTML. To my=20 knowledge (extended by Google, heh), nobody else in the universe is=20 using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose. Make sense? Overall I do not believe that these use cases of URNs (in urn:oid and=20 urn:uuid) should be foreclosed. Even if the URN NID registration does=20 not envision the use of f-components, an application (e.g., a database=20 or content management system) should be able to use f-components for its = purposes when it knows some specific stuff about the identifier. This is = especially important for generic NID registrations like oid and uuid,=20 where the identifier can identify pretty much any arbitrary thing. I have nothing good to say about q-components, and therefore have no=20 comment on that production. Sean From nobody Tue Jan 13 04:45:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954771A8AB3 for ; Tue, 13 Jan 2015 04:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AIjz7TFvaFoE for ; Tue, 13 Jan 2015 04:45:33 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920C21A8AB1 for ; Tue, 13 Jan 2015 04:45:29 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0DCjNHk004307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 14:45:24 +0200 Message-ID: <54B51363.2000804@helsinki.fi> Date: Tue, 13 Jan 2015 14:45:23 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Svensson, Lars" , =?windows-1252?Q?=22Martin_J=2E?= =?windows-1252?Q?_D=FCrst=22?= , Melinda Shore , "urn@ietf.org" References: <54B494B7.5030601@gmail.com> <54B49AEA.1040906@it.aoyama.ac.jp> <24637769D123E644A105A0AF0E1F92EFFAC6A2FB@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC6A2FB@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] IANA considerations and interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 12:45:35 -0000 Hello, Concerning this: > Under IANA Considerations - URI Scheme, Section 10.1, the text > says > > "Interoperability Considerations: There are no known > interoperability concerns related to use of the 'urn' > URI scheme." > > IMO, this is not strictly true because the whole discussion of > whether URNs can be (or should be, or are meaningful in) various > contexts and/or in relative URI form is ultimately about > interoperability considerations. One could argue that almost > everything else that RFC 3986 considers a per-scheme issue and > that we have made per-NID for URNs falls into the same category. > > Should more be said in that line item and, if so, what? I agree that what's written in the I-D at the moment is probably an oversimplification. Instead of just saying that there are no known interoperability concerns, we could admit that some namespaces (but not all) may have them in the future, and add to the existing text something like this: "If interoperability concerns arise during the registration of a URN namespace due to e.g. syntax or scope of an identifier system, they should be resolved in the namespace registration request." Since we do not know either what kind of identifier systems will have URN namespaces in the future, or what kind of technical infrastructure they will rely on (in the distant future), there is no way to produce an exhaustive list of concerns in 2141bis. Rather than trying it is better to offload this responsibility to the registrants. Juha On 13.1.2015 10:15, Svensson, Lars wrote: > Tuesday, January 13, 2015 5:11 AM, Martin wrote: >> On 2015/01/13 12:44, Melinda Shore wrote: >>> This is regarding >>> http://www.ietf.org/mail-archive/web/urn/current/msg02680.html. >>> >>> We haven't seen any feedback on John's question - do people feel >>> that more needs to be said or that it's fine as-is? >> I'd agree with what John said, which would mean that we need some more text. > I agree with that, too. > > Best, > > Lars > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Tue Jan 13 21:52:33 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333281A8A03 for ; Tue, 13 Jan 2015 21:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=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 UsBPyS8Pwrbh for ; Tue, 13 Jan 2015 21:52:29 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AE71A897E for ; Tue, 13 Jan 2015 21:52:29 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so7753253pdb.10 for ; Tue, 13 Jan 2015 21:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=P57Dq8Jdqsg1Xdg+lZnqrrkm4dj4SnL/c52R7TFFNBc=; b=i+DPYDBGWmxAp9E00JeKt518lgrx8suVZS2+r+NWL2YMnG3yPSeT18I9DtlKj+QT3x IAfDmebhAm1/kR2pDDIlTOHcS9T2yRs3hOUZPOrNB6jQ0TmORYdT+8bMjYOyTs2SdCM0 nst4/Z/RuZNByFYwvMaP5hJKoTCVcCeZ1yBFUnY3muqxyRVMAz0mYhcs4Px/lsXscSYK vXXdG69XjtDDpCyrtD4qG4BG1GwA7cQCiUwb9q5LVFfLZiVx0EAoeHTOM+3yR4uhy+7A oZ4RmM5/SNuXJk+5QH4RFOyM/2Cld9fC0MuwwV/Y0ovR3mzfdrPnYChmWy1/nQg/6r75 m2Pw== X-Received: by 10.70.47.161 with SMTP id e1mr2995421pdn.55.1421214748726; Tue, 13 Jan 2015 21:52:28 -0800 (PST) Received: from spandex.local (63-140-104-62.dynamic.dsl.acsalaska.net. [63.140.104.62]) by mx.google.com with ESMTPSA id lb11sm18769060pab.0.2015.01.13.21.52.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 21:52:27 -0800 (PST) Message-ID: <54B60417.7040004@gmail.com> Date: Tue, 13 Jan 2015 20:52:23 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> In-Reply-To: <54B4E5FB.4080602@seantek.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 05:52:31 -0000 We haven't seen any responses to Sean's comments and I'm not sure whether to read that as agreement, disagreement, or "meh." Thoughts? Melinda On 1/13/15 12:31 AM, Sean Leonard wrote: > Ehhhhhhhhhhh...........I have some issues with this. > > "Namespaces which deal with digital manifestations may be able to > support f-component." > > Does this imply that namespaces which deal with digital manifestations > must describe how the f-component is used, in order to be syntactically > valid or otherwise usable? (What are the consequences of tacking on an > f-component anyway?) > > Does this imply that namespaces which do not deal with digital > manifestations, do not support f-component? > > > Consider f-components for urn:oid and urn:uuid. OIDs are assigned to > arbitrary objects, including documents, standards, and the like. UUIDs > are assigned to arbitrary objects as well, including (especially) > specific instances of digital data. > > In my organization, every document gets at least one OID (actually > multiple OIDs, depending on the version of the document). In some > standards organizations (e.g., ISO, ITU-T), standards get an OID or OID > arc. > > Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Euro > currency. (ISO 4217 is the standard for currency identifiers.) > > Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs > refers to the Microsoft Answers forum thread started January 6, 2015, > with the subject "Weather module on my Home Page doesn't remember my > location". It is served at > > as Content-Type: text/html, and has an anchor "tabs" in the HTML. To my > knowledge (extended by Google, heh), nobody else in the universe is > using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose. > > > Make sense? > > Overall I do not believe that these use cases of URNs (in urn:oid and > urn:uuid) should be foreclosed. Even if the URN NID registration does > not envision the use of f-components, an application (e.g., a database > or content management system) should be able to use f-components for its > purposes when it knows some specific stuff about the identifier. This is > especially important for generic NID registrations like oid and uuid, > where the identifier can identify pretty much any arbitrary thing. > > I have nothing good to say about q-components, and therefore have no > comment on that production. From nobody Tue Jan 13 22:45:22 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE61A89A5 for ; Tue, 13 Jan 2015 22:45:20 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 tSGsTBzkgqwO for ; Tue, 13 Jan 2015 22:45:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2A71A896D for ; Tue, 13 Jan 2015 22:45:15 -0800 (PST) Received: from [192.168.2.175] ([93.217.90.135]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MCcja-1Y1yIH0Q30-009Rjh; Wed, 14 Jan 2015 07:45:11 +0100 Message-ID: <54B61071.3080106@gmx.de> Date: Wed, 14 Jan 2015 07:45:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard , "urn@ietf.org" References: <54B22CF0.8090002@seantek.com> In-Reply-To: <54B22CF0.8090002@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0ce7MDoP41s5nG6GO1svx6Tgb1+9z6fk3oBCgtB4pmG0WTROl6H V7uTMtTFpsZ1CbL7FwqsPcOzF3evTtvrxOg3WFtxBXL69rtubzq6DvIZFYTNKXVCzuID/9O XqPWHr0Ke4clHgO5peGhgeWOpbpPZXKoEaB9OdWXTw8pTGNu2aL2WNi1T7bHRnRB/Gq3+v/ Oc9R6fnCEptxZNOh7myeg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn-08 mostly okay, except "basic Latin" X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 06:45:21 -0000 On 2015-01-11 08:57, Sean Leonard wrote: > ... > At broad-scope, it appears that the UTF-8/Unicode assumption in urn: > URIs is softened in this draft, compared to RFC 2141. Maybe I missed > something awhile back, but why is that? I thought that all URNs are > UTF-8/Unicode, and that made everything nice and consistent. > ... I thought URNs are RFC3986-URIs, in which case they are limited to the characters allowed per RFC 3986. Am I missing something here? Best regards, Julian From nobody Wed Jan 14 02:21:46 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93AD1ACE52 for ; Wed, 14 Jan 2015 02:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oc6cGJ8fH9JL for ; Wed, 14 Jan 2015 02:21:41 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABD1ACDDE for ; Wed, 14 Jan 2015 02:21:41 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 27B3832E567; Wed, 14 Jan 2015 19:20:56 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 5d06_4a3e_56e01ea0_716d_4562_88fd_3000eda8013d; Wed, 14 Jan 2015 19:20:55 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 48125BF4DB; Wed, 14 Jan 2015 19:20:55 +0900 (JST) Message-ID: <54B64306.9030106@it.aoyama.ac.jp> Date: Wed, 14 Jan 2015 19:20:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Melinda Shore , urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> <54B60417.7040004@gmail.com> In-Reply-To: <54B60417.7040004@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 10:21:44 -0000 Hello Melinda, On 2015/01/14 14:52, Melinda Shore wrote: > We haven't seen any responses to Sean's comments and I'm not > sure whether to read that as agreement, disagreement, or "meh." > Thoughts? I started to write an answer yesterday, but got stuck. I agree with Sean. While there will be some correlation between URN namespaces and fragment identifiers (f-components for those who prefer that term), as Sean says, fragment identifiers and their interpretation is defined by the MIME media type of a resource obtained when resolving an URI, and therefore any mention in a namespace registration document can and should only be advisory, if at all. Regards, Martin. > Melinda > > > On 1/13/15 12:31 AM, Sean Leonard wrote: >> Ehhhhhhhhhhh...........I have some issues with this. >> >> "Namespaces which deal with digital manifestations may be able to >> support f-component." >> >> Does this imply that namespaces which deal with digital manifestations >> must describe how the f-component is used, in order to be syntactically >> valid or otherwise usable? (What are the consequences of tacking on an >> f-component anyway?) >> >> Does this imply that namespaces which do not deal with digital >> manifestations, do not support f-component? >> >> >> Consider f-components for urn:oid and urn:uuid. OIDs are assigned to >> arbitrary objects, including documents, standards, and the like. UUIDs >> are assigned to arbitrary objects as well, including (especially) >> specific instances of digital data. >> >> In my organization, every document gets at least one OID (actually >> multiple OIDs, depending on the version of the document). In some >> standards organizations (e.g., ISO, ITU-T), standards get an OID or OID >> arc. >> >> Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Euro >> currency. (ISO 4217 is the standard for currency identifiers.) >> >> Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs >> refers to the Microsoft Answers forum thread started January 6, 2015, >> with the subject "Weather module on my Home Page doesn't remember my >> location". It is served at >> >> as Content-Type: text/html, and has an anchor "tabs" in the HTML. To my >> knowledge (extended by Google, heh), nobody else in the universe is >> using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose. >> >> >> Make sense? >> >> Overall I do not believe that these use cases of URNs (in urn:oid and >> urn:uuid) should be foreclosed. Even if the URN NID registration does >> not envision the use of f-components, an application (e.g., a database >> or content management system) should be able to use f-components for its >> purposes when it knows some specific stuff about the identifier. This is >> especially important for generic NID registrations like oid and uuid, >> where the identifier can identify pretty much any arbitrary thing. >> >> I have nothing good to say about q-components, and therefore have no >> comment on that production. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Thu Jan 15 04:53:42 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FF41B2BED for ; Thu, 15 Jan 2015 04:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Rg--3ptG235m for ; Thu, 15 Jan 2015 04:53:37 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F041B2BEC for ; Thu, 15 Jan 2015 04:53:36 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0FCrXAK010188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 15 Jan 2015 14:53:34 +0200 Message-ID: <54B7B84D.9050709@helsinki.fi> Date: Thu, 15 Jan 2015 14:53:33 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> <54B60417.7040004@gmail.com> In-Reply-To: <54B60417.7040004@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 12:53:40 -0000 Hello Sean, Some thoughts below. On 14.1.2015 7:52, Melinda Shore wrote: > We haven't seen any responses to Sean's comments and I'm not > sure whether to read that as agreement, disagreement, or "meh." > Thoughts? > > Melinda > > > On 1/13/15 12:31 AM, Sean Leonard wrote: >> Ehhhhhhhhhhh...........I have some issues with this. >> >> "Namespaces which deal with digital manifestations may be able to >> support f-component." >> >> Does this imply that namespaces which deal with digital manifestations >> must describe how the f-component is used, in order to be syntactically >> valid or otherwise usable? (What are the consequences of tacking on an >> f-component anyway?) IMO it is not really necessary to describe how the f-component is used. F-component and q-components are not part of the NSS and have no role in identification, so any guidelines the community may have about the use of the identifier can exclude these components. On the other hand, using the f-component is easy and works in the same way in each namespace which deals with manifestations of digital resources: if the identified resource has fragments, a user can attach the f-component to the URN. It will have zero impact to the resolution of the URN; the identified resource will be retrieved, and the client will apply the fragment to it. >> >> Does this imply that namespaces which do not deal with digital >> manifestations, do not support f-component? I don't see how they could. Of course that depends on how we define manifestation. My definition is fairly exhaustive. Be that as it may, people who register namespaces should know if f-component is applicable or not. For instance, it cannot be used in a meaningful way in e.g. ISSN namespace, since ISSNs identifies the entire serial, not its individual volumes / issues / articles. >> >> >> Consider f-components for urn:oid and urn:uuid. OIDs are assigned to >> arbitrary objects, including documents, standards, and the like. UUIDs >> are assigned to arbitrary objects as well, including (especially) >> specific instances of digital data. OK. I assume that some of these objects will support fragments, some won't. In this respect OID and UUID are no different from ISBN. There is no requirement that all manifestations which are within the scope of the identifier will support f-component. In fact, it is unlikely that there are namespaces out there which would guarantee f-component support for each identified resource. That is not a problem; f-component is an add-on which provides some additional functionality on the client side but has zero impact on e.g. URN resolution (or identification). >> >> In my organization, every document gets at least one OID (actually >> multiple OIDs, depending on the version of the document). In some >> standards organizations (e.g., ISO, ITU-T), standards get an OID or OID >> arc. >> >> Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Euro >> currency. (ISO 4217 is the standard for currency identifiers.) >> >> Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs >> refers to the Microsoft Answers forum thread started January 6, 2015, >> with the subject "Weather module on my Home Page doesn't remember my >> location". It is served at >> >> as Content-Type: text/html, and has an anchor "tabs" in the HTML. To my >> knowledge (extended by Google, heh), nobody else in the universe is >> using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose. >> >> >> Make sense? Yes, of course, although I am afraid that the URN identifying that discussion will not remain actionable for long. >> >> Overall I do not believe that these use cases of URNs (in urn:oid and >> urn:uuid) should be foreclosed. Even if the URN NID registration does >> not envision the use of f-components, an application (e.g., a database >> or content management system) should be able to use f-components for its >> purposes when it knows some specific stuff about the identifier. This is >> especially important for generic NID registrations like oid and uuid, >> where the identifier can identify pretty much any arbitrary thing. Yes, if the scope of the namespace is very broad, it is likely that there are at least some resources which may support fragments. >> >> I have nothing good to say about q-components, and therefore have no >> comment on that production. I hope that in the future you'll find some uses for q-components as well. All the best, Juha > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Thu Jan 15 12:20:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41E81B325A for ; Thu, 15 Jan 2015 12:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 894L_eqEkhos for ; Thu, 15 Jan 2015 12:19:59 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C5F1B3226 for ; Thu, 15 Jan 2015 12:19:59 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so18242683pdb.4 for ; Thu, 15 Jan 2015 12:19:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RTPXflpo/hWD3bPvhEBZNn07lmPk7r5xeX1F/OLM07o=; b=CV/ghMHeRoJt8APZXO2e6HkYpxwtNWt1KFn0wxQwMBkB1MJS9xxF0c2JB8/tFh+HhE aLQHFaEhvDB/DOSYEh+nXDmufro4SZj9pKr1U3W25r6aNcygBiRXE1Pph5xI242sVTmi 3+GuaeHpgbfqq5jnsB+vemzCR7uj4ROca0hfpe7zwYY5Jlpl7DT+Csb7lVikRTUngAEO mEwRX6wgntycc++Ld42rE6c1wN83QMKBMDx6UHA/rGX4QKOesVMVNDKSJZj3PS9Jo3S3 9NFTbueHH5U18eTqz+0Z0bI8WlVF2SqdsvSn8RG1fIIYD/w1c3yOYx+YwDD81bkIbQSA 8dfw== X-Gm-Message-State: ALoCoQn4CkVUnzy55TWDVZaeQ9u5dxmBfCljtNi9vGtH56HRJlWBe97GQuMo49NQK0Hj46hAfjIu MIME-Version: 1.0 X-Received: by 10.70.38.71 with SMTP id e7mr7995105pdk.130.1421353198987; Thu, 15 Jan 2015 12:19:58 -0800 (PST) Received: by 10.66.135.164 with HTTP; Thu, 15 Jan 2015 12:19:58 -0800 (PST) X-Originating-IP: [2001:500:4:15:645c:7356:a7be:5096] Date: Thu, 15 Jan 2015 15:19:58 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfe9d3a86c4c3050cb69420 Archived-At: Subject: [urn] Session Requested for IETF 92 in Dallas, TX, US X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 20:20:02 -0000 --047d7bfe9d3a86c4c3050cb69420 Content-Type: text/plain; charset=UTF-8 All, We have requested a session for the URNBIS working group during the IETF 92 meeting (March 22-27, 2015) in Dallas, TX, US. -andy --047d7bfe9d3a86c4c3050cb69420 Content-Type: text/html; charset=UTF-8
All,

We have requested a session for the URNBIS working group during the IETF 92 meeting (March 22-27, 2015) in Dallas, TX, US.

-andy
--047d7bfe9d3a86c4c3050cb69420-- From nobody Mon Jan 19 03:23:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8471B2A2E for ; Mon, 19 Jan 2015 03:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 PdQrYXd4ZIeA for ; Mon, 19 Jan 2015 03:23:31 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2619E1B2A29 for ; Mon, 19 Jan 2015 03:23:30 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 917CE8AFE0; Mon, 19 Jan 2015 12:23:29 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-5e-54bce9313340 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 20.20.15323.139ECB45; Mon, 19 Jan 2015 12:23:29 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Mon, 19 Jan 2015 12:23:29 +0100 From: "Svensson, Lars" To: Andrew Newton Thread-Topic: [urn] Session Requested for IETF 92 in Dallas, TX, US Thread-Index: AQHQMQCw8oOwoEzoiEejYUeV5d3JQZzHUkCw Date: Mon, 19 Jan 2015 11:23:28 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6CD34@dnbf-ex1.AD.DDB.DE> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.227] Content-Type: multipart/alternative; boundary="_000_24637769D123E644A105A0AF0E1F92EFFAC6CD34dnbfex1ADDDBDE_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TbUhTURjHObubu1seO12dO820HAlZpC0l7NXohYyMChdFVOvqvbrhnLK7 RRaEEVnOshILGqVW9kJgmn1Il5Td3iiJpAwjySxLs4jsg0n0su7dvdq1bw+/53n+5//n4ZAE FdSaSIfLw7pdtNMcplfrV6YPz7YMtlrnPO+NS7vY9lyTdmL/kGqpKuPI8ZUZdXU/VOtVW/SL GNbp2Mm6k5fs0Nsv/z6kLhqhd/nbBzUl4KzNB3QkRqmYH/yslupo3NHTEOYDepJCdwG+Xv1a IzYodAPgdyNrfUBLhqGZ+KtdpFFoKv7ecDW0SqB43PSmSiXWkWgZ7uztVkszy3FV7xPgA6RQ z8UdNToRq1ECbmop1YgYotW4rCdCemc9DrYPaUWsQxswf84oYoBicWPjU0J6yIib+kc0kl+E 61oljpEBD/b9kXk8bivrkudd+NunQMgYRJPwo1Pv1ceAwa+Q8ivG/Ioxv+CCQIm4IZDslyNW lb/VSvUMfOD0Ga2S1wLtFRDBFeRZkmgmiWGykxi2CUiXGmgGFc9W8ACRwBwOD2e1WikNvZMr LuDBOlJlNsBV3QKKyC5kiu00Z7e5vU6WM0fBmI8ChmM42+vMN8fB1IBAjWOU83JFjhxHoZez ed1OHmCSEFZBh7jK0MW7WXehJMiDGFJtNsLjN/dZKZRHe9h8li1i3aPdzSRpxtAivjnJzeax u3IdTs9oW9hbkBgQ9pSdkKF4yGe2WCmTsvG/JxWp40EmGS4Ymx7KxBXRBZwjT9aOhEcHBBo+ SkO6sbBdDBo9CsdrPgZZJiN8Jq4hccLudY15NUXDlHtCY6KiIUqapsGs4ptWarKCj1f9BFYL J4qEc0ST4cJ/++eRgjkfBDhBhiGLU+BL0aJBZv9rZQq3jYLRgVBgD+1RBnYEQoFlKge2S4Fl OF7OVAJiei+8/enaCB6suZ4/37Yv1pKWfn/WhOq++Dstdx7XP/wVfDTc5Uxj9CindIDY2vJ7 cXPwZEL9B6onZfurmrW5H28NXMyq/7KJWNTdt6Pz9qqXlczeytfzzhQQ1xZuO1hhqzZcSt1T OnLAbu1MbG57GnW+36svX8FfTn/w0/eidvuFXLOas9OWmYSbo/8CC2Q/AZIEAAA= Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Session Requested for IETF 92 in Dallas, TX, US X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 11:23:34 -0000 --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD34dnbfex1ADDDBDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCg0KVGhhbmtzIGZvciBtb3ZpbmcgdGhpcyBmb3J3YXJkLiBJdCB3b3VsZCBiZSBncmVh dCBpZiAoZ2l2ZW4gdGhhdCB0aGUgc2Vzc2lvbiBpcyBhcHByb3ZlZCkgcmVtb3RlIHBhcnRpY2lw YXRpb24gY291bGQgYmUgb3JnYW5pc2VkLg0KDQpCZXN0LA0KDQpMYXJzDQoNCioqKiBMZXNlbi4g SMO2cmVuLiBXaXNzZW4uIERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayAqKioNCi0tDQpEci4g TGFycyBHLiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZvcm1hdGlv bnNpbmZyYXN0cnVrdHVyIHVuZCBCZXN0YW5kZXJoYWx0dW5nDQpBZGlja2VzYWxsZWUgMQ0KRC02 MDMyMiBGcmFua2Z1cnQgYW0gTWFpbg0KVGVsZWZvbjogKzQ5LTY5LTE1MjUtMTc1Mg0KVGVsZWZh eDogKzQ5LTY5LTE1MjUtMTc5OQ0KbWFpbHRvOmwuc3ZlbnNzb25AZG5iLmRlDQpodHRwOi8vd3d3 LmRuYi5kZQ0KDQpGcm9tOiB1cm4gW21haWx0bzp1cm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFuZHJldyBOZXd0b24NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDk6 MjAgUE0NClRvOiB1cm5AaWV0Zi5vcmcNClN1YmplY3Q6IFt1cm5dIFNlc3Npb24gUmVxdWVzdGVk IGZvciBJRVRGIDkyIGluIERhbGxhcywgVFgsIFVTDQoNCkFsbCwNCg0KV2UgaGF2ZSByZXF1ZXN0 ZWQgYSBzZXNzaW9uIGZvciB0aGUgVVJOQklTIHdvcmtpbmcgZ3JvdXAgZHVyaW5nIHRoZSBJRVRG IDkyIG1lZXRpbmcgKE1hcmNoIDIyLTI3LCAyMDE1KSBpbiBEYWxsYXMsIFRYLCBVUy4NCg0KLWFu ZHkNCg== --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD34dnbfex1ADDDBDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRS1NYWls Rm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keSw8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgbW92aW5nIHRoaXMgZm9yd2FyZC4gSXQg d291bGQgYmUgZ3JlYXQgaWYgKGdpdmVuIHRoYXQgdGhlIHNlc3Npb24gaXMgYXBwcm92ZWQpIHJl bW90ZQ0KIHBhcnRpY2lwYXRpb24gY291bGQgYmUgb3JnYW5pc2VkLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxhcnM8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4qKiogTGVzZW4uIEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxp b3RoZWsgKioqDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkRyLiBMYXJzIEcuIFN2ZW5zc29uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E ZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZm9y bWF0aW9uc2luZnJhc3RydWt0dXIgdW5kIEJlc3RhbmRlcmhhbHR1bmc8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFkaWNrZXNhbGxlZSAxPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJW ZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ELTYwMzIy IEZyYW5rZnVydCBhbSBNYWluPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJWZXJkYW5h Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UZWxlZm9uOiAmIzQz OzQ5LTY5LTE1MjUtMTc1MjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVmVyZGFuYSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGVsZWZheDogJiM0Mzs0 OS02OS0xNTI1LTE3OTk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm1haWx0bzpsLnN2ZW5zc29u QGRuYi5kZQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5odHRwOi8vd3d3LmRuYi5kZTxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+ PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gdXJuDQogW21haWx0bzp1cm4tYm91bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZiA8L3NwYW4+DQo8L2I+QW5kcmV3 IE5ld3Rvbjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bh bj48L2I+IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDk6MjAgUE08YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gdXJuQGlldGYub3JnPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW3Vy bl0gU2Vzc2lvbiBSZXF1ZXN0ZWQgZm9yIElFVEYgOTIgaW4gRGFsbGFzLCBUWCwgVVM8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldlIGhhdmUgcmVxdWVzdGVkIGEgc2Vzc2lvbiBmb3Ig dGhlIFVSTkJJUyB3b3JraW5nIGdyb3VwIGR1cmluZyB0aGUgSUVURiA5MiBtZWV0aW5nIChNYXJj aCAyMi0yNywgMjAxNSkgaW4gRGFsbGFzLCBUWCwgVVMuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4tYW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD34dnbfex1ADDDBDE_-- From nobody Mon Jan 19 03:38:36 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB21B2A26 for ; Mon, 19 Jan 2015 03:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 jhUVlKSrNjjE for ; Mon, 19 Jan 2015 03:38:33 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560B71B2A2E for ; Mon, 19 Jan 2015 03:38:33 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so7776850pad.8 for ; Mon, 19 Jan 2015 03:38:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x2kJIUNv3CHWvxhAPMSdlJyuwJlqNhQaJS/Mq1ibvGs=; b=Ykl0wZ0t7z4tWmi+cLdkYl5+m/0H23eOK/QxVMJWJJH8oJXw8imHUxyyWkyXx0VB10 YgWrhA2RArhNmoGL6M8Eul4xir08gUOfUnpbjLYwgrT84eT6jmoLHvHurJ3lLyX9vmnc h9QiP+4KHv2XFwOQ6BKnuiUz9XVykWB3Ur8qIPh4nX+UwFKSJ5NM8QRbEkf0YEXTPTLm WNHy0Wbtg+TaOBtuR8fEaKNVZPd4t47XlceQQkjvLY7OStWj/rGRdimo+tAB4Kg9VDUc e3XXtUkkssSb4uSxexujoj2oM25nQjE874ejmPc/ArAZLKYAgrrfq0Fvkf1Z0I3bYokq KvAw== X-Gm-Message-State: ALoCoQltQSZIs8NWSM7cuGAKr5wUJDxgTyjqqNyfBqaIS2UVgqGyRFcXfnDwLQO2YwVftW9mn0iJ MIME-Version: 1.0 X-Received: by 10.70.6.164 with SMTP id c4mr43884331pda.63.1421667512689; Mon, 19 Jan 2015 03:38:32 -0800 (PST) Received: by 10.66.135.164 with HTTP; Mon, 19 Jan 2015 03:38:32 -0800 (PST) X-Originating-IP: [200.7.85.248] In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC6CD34@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC6CD34@dnbf-ex1.AD.DDB.DE> Date: Mon, 19 Jan 2015 09:38:32 -0200 Message-ID: From: Andrew Newton To: "Svensson, Lars" Content-Type: multipart/alternative; boundary=047d7bd770ce15400a050cffc3ba Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Session Requested for IETF 92 in Dallas, TX, US X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 11:38:35 -0000 --047d7bd770ce15400a050cffc3ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Lars. I'll look into it and request remote access. -andy On Mon, Jan 19, 2015 at 9:23 AM, Svensson, Lars wrote: > Andy, > > > > Thanks for moving this forward. It would be great if (given that the > session is approved) remote participation could be organised. > > > > Best, > > > > Lars > > > > *** Lesen. H=C3=B6ren. Wissen. Deutsche Nationalbibliothek *** > > -- > > Dr. Lars G. Svensson > > Deutsche Nationalbibliothek > > Informationsinfrastruktur und Bestanderhaltung > > Adickesallee 1 > > D-60322 Frankfurt am Main > > Telefon: +49-69-1525-1752 > > Telefax: +49-69-1525-1799 > > mailto:l.svensson@dnb.de > > http://www.dnb.de > > > > *From:* urn [mailto:urn-bounces@ietf.org] *On Behalf Of *Andrew Newton > *Sent:* Thursday, January 15, 2015 9:20 PM > *To:* urn@ietf.org > *Subject:* [urn] Session Requested for IETF 92 in Dallas, TX, US > > > > All, > > > > We have requested a session for the URNBIS working group during the IETF > 92 meeting (March 22-27, 2015) in Dallas, TX, US. > > > > -andy > --047d7bd770ce15400a050cffc3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Lars. I'll look into it and request remote acce= ss.

-andy

On Mon, Jan 19, 2015 at 9:23 AM, Svensson, Lars <L.= Svensson@dnb.de> wrote:

Andy,

=C2=A0

Thanks for moving this forward. It would be= great if (given that the session is approved) remote participation could be organised.

=C2=A0

Best,

=C2=A0

Lars

=C2=A0

= *** Lesen. H=C3=B6ren. Wissen. Deutsche Nationalb= ibliothek ***

= --

= Dr. Lars G. Svensson<= /p>

= Deutsche Nationalbibliothek<= /font>

= Informationsinfrastruktur und Bestanderhaltung=

= Adickesallee 1

= D-60322 Frankfurt am Main

= Telefon: +49-69-1525-1752

= Telefax: +49-69-1525-1799

= mailto:l.svensson@dnb.de

= h= ttp://www.dnb.de

=C2=A0

urn [mailto:urn-boun= ces@ietf.org] On Behalf Of Andrew Newton
Sent: Thursday, January 15, = 2015 9:20 PM
To: urn@ietf.org
Subject: [urn] Session Reque= sted for IETF 92 in Dallas, TX, US

=C2=A0

All,

=C2=A0

We have requested a session for the URNBIS working g= roup during the IETF 92 meeting (March 22-27, 2015) in Dallas, TX, US.

=C2=A0

-andy


--047d7bd770ce15400a050cffc3ba-- From nobody Mon Jan 19 03:41:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC61B2A18 for ; Mon, 19 Jan 2015 03:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 Bx-ymNdBvKvs for ; Mon, 19 Jan 2015 03:41:47 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B81B2A26 for ; Mon, 19 Jan 2015 03:41:47 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 63D188AFE6; Mon, 19 Jan 2015 12:41:46 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-ac-54bced7ae7ee Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 2A.20.15323.A7DECB45; Mon, 19 Jan 2015 12:41:46 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Mon, 19 Jan 2015 12:41:45 +0100 From: "Svensson, Lars" To: Andrew Newton Thread-Topic: [urn] Session Requested for IETF 92 in Dallas, TX, US Thread-Index: AQHQMQCw8oOwoEzoiEejYUeV5d3JQZzHUkCw///z4gCAABGYAA== Date: Mon, 19 Jan 2015 11:41:45 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6CD69@dnbf-ex1.AD.DDB.DE> References: <24637769D123E644A105A0AF0E1F92EFFAC6CD34@dnbf-ex1.AD.DDB.DE> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.227] Content-Type: multipart/alternative; boundary="_000_24637769D123E644A105A0AF0E1F92EFFAC6CD69dnbfex1ADDDBDE_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TWUwTURSGczuFDrVXL6Wl1yoqNRIlgWrwgbihqLEkuFLFqAkOdmyrbSGd 1ghPRePC4kaqEURFRU0UxfCApOJWUeMWFkUkuAYXRFwSRTAR49zOAIW3c79zzn/+MydDU8od tJa2Olys08HYdKFyqXxxUk9c7tc64/SS+vDEc7eehiQe3vlDMl9i2HdosaGi4o9khWSdfI6J tVm3sU79vI1yy/PrbVR2/k2w3Xu/RuIBeT5QAMJojGbi4lP9lBBH4sbXVaEFQE4r0R2Aj9Qc lQmPqwA3fLvIP2R0KIrF3y2kXoUm4t9Vl6UkplA0rn7jlZA4AiXjZ2/bpULNQux9+4SfRfNx Mv7VbCdYiqbgds+jEIIhSsEnXqqEQa0A7y26F7AThlbi2ye7AjYBisJXrjRQwigNrv7YGyJY RriirkG0r8afO/6JPBrfym+liD6FHPjv+XiCIQrHD0reSw8CdWmQUulQVWlQlYCn4SqfvlRc 0Vv4TibEU/GusuOyYF4OZBfAaM5unhHPmOJNpsx4E1sNhGN9qgX7mxf5AaKBTgGL0uqMyhBm G5dj94PltESnhqldPBqdmWXKsTCcJcPptrGcTgVbv/AYDuJMt22rbgKc6eOpZpBybi7busma 5eYy3E6bH2Ca4ltBI2k1MTm5rDNLEPSDcbRUp4GHruUZlcjMuNitLJvNOgeya2lah6Gxm28M d7Jmdvtmq801kOb72jr5DArOBAxFwxjiXhucGOlJQof5QSqt4I2VEX3IZTN2zmoWtSNgEqGK ARrQjYKPyKKRA3C45kOQptXAZaQNkQqL2zHoVRsJE+r5xJigBJHUToJpOdeMyrFBfLhqF0jh TxQBe8iHV/C/3JBHJVxPho0SYcDiePiCWFSLbKRWKn9bFYz0BRZ2Ma7gha2+wMIiFRe2CAuL cLic1gPONFUuXW26FK32tPzsS48q+BVzrMlRm6JNiW2pfxYR4w1vuVvIrPrd0Tt79/swfX+l Y4v+cUOqZ0lt9/XynnUVH1bfWNU2ZaH+VMvlsZ29j+faz5Z8Mexp9xzoVqxp3dB0esEsW8Ir l6HSQIdWJawpfjrZ1dcRZ04v03xUnU5ProGNOilnYWbEUk6O+Q/yQXfzlQQAAA== Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Session Requested for IETF 92 in Dallas, TX, US X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 11:41:49 -0000 --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD69dnbfex1ADDDBDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXQsIHRoYW5rcyBBbmR5Lg0KDQpMYXJzDQoNCioqKiBMZXNlbi4gSMO2cmVuLiBXaXNzZW4u IERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayAqKioNCi0tDQpEci4gTGFycyBHLiBTdmVuc3Nv bg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZvcm1hdGlvbnNpbmZyYXN0cnVrdHVy IHVuZCBCZXN0YW5kZXJoYWx0dW5nDQpBZGlja2VzYWxsZWUgMQ0KRC02MDMyMiBGcmFua2Z1cnQg YW0gTWFpbg0KVGVsZWZvbjogKzQ5LTY5LTE1MjUtMTc1Mg0KVGVsZWZheDogKzQ5LTY5LTE1MjUt MTc5OQ0KbWFpbHRvOmwuc3ZlbnNzb25AZG5iLmRlDQpodHRwOi8vd3d3LmRuYi5kZQ0KDQpGcm9t OiBBbmRyZXcgTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdDQpTZW50OiBNb25kYXksIEphbnVh cnkgMTksIDIwMTUgMTI6MzkgUE0NClRvOiBTdmVuc3NvbiwgTGFycw0KQ2M6IHVybkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt1cm5dIFNlc3Npb24gUmVxdWVzdGVkIGZvciBJRVRGIDkyIGluIERh bGxhcywgVFgsIFVTDQoNClRoYW5rcyBMYXJzLiBJJ2xsIGxvb2sgaW50byBpdCBhbmQgcmVxdWVz dCByZW1vdGUgYWNjZXNzLg0KDQotYW5keQ0KDQpPbiBNb24sIEphbiAxOSwgMjAxNSBhdCA5OjIz IEFNLCBTdmVuc3NvbiwgTGFycyA8TC5TdmVuc3NvbkBkbmIuZGU8bWFpbHRvOkwuU3ZlbnNzb25A ZG5iLmRlPj4gd3JvdGU6DQpBbmR5LA0KDQpUaGFua3MgZm9yIG1vdmluZyB0aGlzIGZvcndhcmQu IEl0IHdvdWxkIGJlIGdyZWF0IGlmIChnaXZlbiB0aGF0IHRoZSBzZXNzaW9uIGlzIGFwcHJvdmVk KSByZW1vdGUgcGFydGljaXBhdGlvbiBjb3VsZCBiZSBvcmdhbmlzZWQuDQoNCkJlc3QsDQoNCkxh cnMNCg0KKioqIExlc2VuLiBIw7ZyZW4uIFdpc3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90 aGVrICoqKg0KLS0NCkRyLiBMYXJzIEcuIFN2ZW5zc29uDQpEZXV0c2NoZSBOYXRpb25hbGJpYmxp b3RoZWsNCkluZm9ybWF0aW9uc2luZnJhc3RydWt0dXIgdW5kIEJlc3RhbmRlcmhhbHR1bmcNCkFk aWNrZXNhbGxlZSAxDQpELTYwMzIyIEZyYW5rZnVydCBhbSBNYWluDQpUZWxlZm9uOiArNDktNjkt MTUyNS0xNzUyPHRlbDolMkI0OS02OS0xNTI1LTE3NTI+DQpUZWxlZmF4OiArNDktNjktMTUyNS0x Nzk5PHRlbDolMkI0OS02OS0xNTI1LTE3OTk+DQptYWlsdG86bC5zdmVuc3NvbkBkbmIuZGU8bWFp bHRvOmwuc3ZlbnNzb25AZG5iLmRlPg0KaHR0cDovL3d3dy5kbmIuZGUNCg0KRnJvbTogdXJuIFtt YWlsdG86dXJuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnVybi1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEFuZHJldyBOZXd0b24NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAy MDE1IDk6MjAgUE0NClRvOiB1cm5AaWV0Zi5vcmc8bWFpbHRvOnVybkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFt1cm5dIFNlc3Npb24gUmVxdWVzdGVkIGZvciBJRVRGIDkyIGluIERhbGxhcywgVFgsIFVT DQoNCkFsbCwNCg0KV2UgaGF2ZSByZXF1ZXN0ZWQgYSBzZXNzaW9uIGZvciB0aGUgVVJOQklTIHdv cmtpbmcgZ3JvdXAgZHVyaW5nIHRoZSBJRVRGIDkyIG1lZXRpbmcgKE1hcmNoIDIyLTI3LCAyMDE1 KSBpbiBEYWxsYXMsIFRYLCBVUy4NCg0KLWFuZHkNCg0K --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD69dnbfex1ADDDBDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TcHJlY2hibGFzZW50ZXh0WmNobg0KCXtt c28tc3R5bGUtbmFtZToiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U3ByZWNoYmxhc2VudGV4dDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6REU7fQ0Kc3Bhbi5F LU1haWxGb3JtYXR2b3JsYWdlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdyZWF0LCB0aGFua3MgQW5keS48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5MYXJzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4qKiogTGVzZW4uIEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxp b3RoZWsgKioqDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkRyLiBMYXJzIEcuIFN2ZW5zc29uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E ZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZm9y bWF0aW9uc2luZnJhc3RydWt0dXIgdW5kIEJlc3RhbmRlcmhhbHR1bmc8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFkaWNrZXNhbGxlZSAxPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJW ZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ELTYwMzIy IEZyYW5rZnVydCBhbSBNYWluPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJWZXJkYW5h Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UZWxlZm9uOiAmIzQz OzQ5LTY5LTE1MjUtMTc1MjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVmVyZGFuYSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGVsZWZheDogJiM0Mzs0 OS02OS0xNTI1LTE3OTk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm1haWx0bzpsLnN2ZW5zc29u QGRuYi5kZQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5odHRwOi8vd3d3LmRuYi5kZTxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+ PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQW5kcmV3DQogTmV3dG9uIFttYWlsdG86YW5keUBoeHIudXNdIDxicj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IE1vbmRheSwg SmFudWFyeSAxOSwgMjAxNSAxMjozOSBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBTdmVuc3NvbiwgTGFyczxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiB1cm5AaWV0Zi5vcmc8YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW3Vy bl0gU2Vzc2lvbiBSZXF1ZXN0ZWQgZm9yIElFVEYgOTIgaW4gRGFsbGFzLCBUWCwgVVM8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhhbmtzIExhcnMuIEknbGwgbG9v ayBpbnRvIGl0IGFuZCByZXF1ZXN0IHJlbW90ZSBhY2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+LWFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPk9uIE1vbiwgSmFuIDE5LCAyMDE1IGF0IDk6MjMgQU0sIFN2ZW5z c29uLCBMYXJzICZsdDs8YSBocmVmPSJtYWlsdG86TC5TdmVuc3NvbkBkbmIuZGUiIHRhcmdldD0i X2JsYW5rIj5MLlN2ZW5zc29uQGRuYi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keSw8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIG1vdmluZyB0aGlzIGZvcndhcmQuIEl0IHdv dWxkDQogYmUgZ3JlYXQgaWYgKGdpdmVuIHRoYXQgdGhlIHNlc3Npb24gaXMgYXBwcm92ZWQpIHJl bW90ZSBwYXJ0aWNpcGF0aW9uIGNvdWxkIGJlIG9yZ2FuaXNlZC48L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5CZXN0LDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxhcnM8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIx IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+KioqIExlc2VuLiBIw7ZyZW4uIFdpc3Nlbi4gRGV1dHNjaGUgTmF0 aW9uYWxiaWJsaW90aGVrDQogKioqIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJW ZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLQ0KPC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQg c2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRyLiBMYXJzIEcuIFN2ZW5zc29uPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlazwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjEiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JbmZvcm1hdGlvbnNpbmZyYXN0cnVrdHVyIHVuZCBCZXN0YW5kZXJoYWx0 dW5nPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFkaWNrZXNhbGxlZSAxPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkQtNjAzMjIgRnJhbmtmdXJ0IGFtIE1haW48L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIxIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGVsZWZvbjoNCjxhIGhyZWY9InRlbDolMkI0OS02OS0xNTI1LTE3NTIiIHRh cmdldD0iX2JsYW5rIj4mIzQzOzQ5LTY5LTE1MjUtMTc1MjwvYT48L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIxIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGVsZWZheDoNCjxhIGhyZWY9InRlbDolMkI0OS02OS0xNTI1LTE3OTkiIHRhcmdl dD0iX2JsYW5rIj4mIzQzOzQ5LTY5LTE1MjUtMTc5OTwvYT48L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsLnN2ZW5zc29uQGRuYi5kZSIgdGFyZ2V0PSJf YmxhbmsiPmwuc3ZlbnNzb25AZG5iLmRlPC9hPg0KPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9Imh0dHA6Ly93d3cuZG5iLmRlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5k bmIuZGU8L2E+PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxmb250IHNpemU9 IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiB1cm4gW21haWx0bzo8YSBocmVmPSJtYWls dG86dXJuLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51cm4tYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9m IDwvc3Bhbj48L2I+QW5kcmV3IE5ld3Rvbjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDk6MjAg UE08YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4g PGEgaHJlZj0ibWFpbHRvOnVybkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdXJuQGlldGYu b3JnPC9hPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwv c3Bhbj48L2I+IFt1cm5dIFNlc3Npb24gUmVxdWVzdGVkIGZvciBJRVRGIDkyIGluIERhbGxhcywg VFgsIFVTPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbGws PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldlIGhhdmUgcmVx dWVzdGVkIGEgc2Vzc2lvbiBmb3IgdGhlIFVSTkJJUyB3b3JraW5nIGdyb3VwIGR1cmluZyB0aGUg SUVURiA5MiBtZWV0aW5nIChNYXJjaCAyMi0yNywgMjAxNSkgaW4gRGFsbGFzLA0KIFRYLCBVUy48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4tYW5k eTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_24637769D123E644A105A0AF0E1F92EFFAC6CD69dnbfex1ADDDBDE_-- From nobody Mon Jan 19 06:31:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEAC1B2A84 for ; Mon, 19 Jan 2015 06:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 DozRGdtsBTcH for ; Mon, 19 Jan 2015 06:30:55 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB941AD10A for ; Mon, 19 Jan 2015 06:30:55 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 546F58AF7A; Mon, 19 Jan 2015 15:30:54 +0100 (CET) X-AuditID: 0a453fe7-f79a26d000003bdb-1a-54bd151e1dcd Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id EA.C0.15323.E151DB45; Mon, 19 Jan 2015 15:30:54 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0181.006; Mon, 19 Jan 2015 15:30:53 +0100 From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" Thread-Topic: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs Thread-Index: AQHQLuKgItq6vowTEk+iV1uSZfE+j5y9uO6AgAFVEYCAAggBgIAGcKMQ Date: Mon, 19 Jan 2015 14:30:52 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFFAC6CF53@dnbf-ex1.AD.DDB.DE> References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> <54B60417.7040004@gmail.com> <54B7B84D.9050709@helsinki.fi> In-Reply-To: <54B7B84D.9050709@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.227] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TWUwTURSGc6cDvVQujkNbrnVlFB9UEJdEokQJcQHEKFqNMUYcmJFOLG0z 0xpreKgYo1ZUfNDEGnckgDGiiWK0RC3EDcUtKEgkJm64ENSgog/oTKfFwbcz33/Of/6Tm4E6 ukdvgYLDzYsO1s7EGkjDwvnfU8eaGq3p37oSMsq/7dRnHNz+hcgicvbXXtfnVFX9IpYTaw2Z HG8XNvPitHkbDLbgpW696/7ULf03u2J8wDfRD+Igpmbhz80vCbU240dd52P9wABpqgng2z0d OvWjAeAT7RdIP9DDWGoy7rUp/UYqB4f67wClTqQKcHNtNVD5Cvzj2GVSrRfhxt339X4AIUml 4LMtcxWMqFzc2v6AUN1/AVy190I4Qxw1BT+9dUiv1IAag+vrH+qUWkcl4YvvfsaoOSlcFVQ5 pkz4w+uBCE/GN3Y/j/Sn497W45F6Cq4++UmnLh6B7x5+Q1YCU0BjG9CMBDQjAc3ICUDWgQSp tGR6GsulcVxRGsdfBOpbvL8C9j1ZEAIUBEw8qlgZtNIx7GbJWxoCyyDBmFBbTKOVTihycl4b K9kKRY+dlxgjWmeUMRrERR77JmYsmnVVnk8apJJHcgnFgtMjFXpEewhgqJNHl/fJTYhjvVt5 0akahsAoSDJJ6MC1bVaaKmHd/Caed/FiVF0DIYNRV6K8c4TIl/BbNgp2d1SW5zq6ZUtKq4QD JaNJH2XBohX+z0TAuBDIh/FysBeKP5JcbKkklES8E9E45dL4KA37jkEtyqHmKBzqeQ8UwtCR 4GGCJh1OB29JQv2KMaV02zyOwdwWM5rZLNsM1wiKvWU8Wum9ZqVHavjQDR9BrvxciSg1HE3+ u/7lpVGWAodFYDjuaNSuxDVF2P9e+fI7G5FZaUGSm3VrjxcUGh+lkeNt6vERONTO4gMNFT19 mX3c2/U1j1evmtNNZ2dD4+nA7Akd/lMvj5bbf+A6i+/V/NF3Fq//be7MO1VW/MbJ/SkoG+Uc aOktyGpLydwxccbNdR/yKoWmbh+T5s591fizM+Erd67zWdOGncMrzY8KSlvfQyvTVrMrVC9s dS/ZU/xnKSfG6focZw55rzOkZGOnT9aJEvsX+tSAb4AEAAA= Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 14:30:58 -0000 Hello Juha and Sean, On Thursday, January 15, 2015 1:54 PM, Juha wrote: =20 > Hello Sean, >=20 > Some thoughts below. >=20 [...] > > On 1/13/15 12:31 AM, Sean Leonard wrote: > >> Ehhhhhhhhhhh...........I have some issues with this. > >> > >> "Namespaces which deal with digital manifestations may be able to > >> support f-component." > >> > >> Does this imply that namespaces which deal with digital manifestations > >> must describe how the f-component is used, in order to be syntacticall= y > >> valid or otherwise usable? (What are the consequences of tacking on an > >> f-component anyway?) =20 I think the operative word is "may": " Namespaces which deal with digital m= anifestations may be able to support f-component." I don't read anything th= at *only* namespaces that deal with digital manifestations may use f-compon= ents, nor that all such namespaces *must* support it. > IMO it is not really necessary to describe how the f-component is used. > F-component and q-components are not part of the NSS and have no role in > identification, so any guidelines the community may have about the use > of the identifier can exclude these components. Yup. > On the other hand, using the f-component is easy and works in the same > way in each namespace which deals with manifestations of digital > resources: if the identified resource has fragments, a user can attach > the f-component to the URN. It will have zero impact to the resolution > of the URN; the identified resource will be retrieved, and the client > will apply the fragment to it. I think this depends on how your resolution service works. It's true for ht= tp-based resolvers (which probably will be the most common ones for the nex= t future). I don't think it would be the same for an ftp-based resolver, si= nce to my knowledge ftp-URIs are not aware of fragment identifiers (rfc 959= precedes 3986...). > >> Does this imply that namespaces which do not deal with digital > >> manifestations, do not support f-component? >=20 > I don't see how they could. Of course that depends on how we define > manifestation. My definition is fairly exhaustive. Be that as it may, > people who register namespaces should know if f-component is applicable > or not. For instance, it cannot be used in a meaningful way in e.g. ISSN > namespace, since ISSNs identifies the entire serial, not its individual > volumes / issues / articles. > >> > >> > >> Consider f-components for urn:oid and urn:uuid. OIDs are assigned to > >> arbitrary objects, including documents, standards, and the like. UUIDs > >> are assigned to arbitrary objects as well, including (especially) > >> specific instances of digital data. >=20 > OK. I assume that some of these objects will support fragments, some > won't. In this respect OID and UUID are no different from ISBN. There is > no requirement that all manifestations which are within the scope of the > identifier will support f-component. In fact, it is unlikely that there > are namespaces out there which would guarantee f-component support for > each identified resource. That is not a problem; f-component is an > add-on which provides some additional functionality on the client side > but has zero impact on e.g. URN resolution (or identification). I guess there will be namespaces that definitely will not support f-compone= nts, some that definitely will and some that will leave the question open (= e. g. OID and UUID). If the namespace does not intend to support resolution= , it really will not matter. > >> In my organization, every document gets at least one OID (actually > >> multiple OIDs, depending on the version of the document). In some > >> standards organizations (e.g., ISO, ITU-T), standards get an OID or OI= D > >> arc. > >> > >> Thus, in the abstract, urn:oid:1.0.4217#EUR could well refer to the Eu= ro > >> currency. (ISO 4217 is the standard for currency identifiers.) > >> > >> Thus, concretely, urn:uuid:62f2ac03-9422-43b6-a599-c712be931d4a#tabs > >> refers to the Microsoft Answers forum thread started January 6, 2015, > >> with the subject "Weather module on my Home Page doesn't remember my > >> location". It is served at > >> iewindows8_1/weather-module-on-my-home-page-doesnt-remember- > my/62f2ac03-9422-43b6-a599-c712be931d4a#tabs> > >> as Content-Type: text/html, and has an anchor "tabs" in the HTML. To m= y > >> knowledge (extended by Google, heh), nobody else in the universe is > >> using 62f2ac03-9422-43b6-a599-c712be931d4a for any other purpose. > >> > >> > >> Make sense? > Yes, of course, although I am afraid that the URN identifying that > discussion will not remain actionable for long. >=20 > >> > >> Overall I do not believe that these use cases of URNs (in urn:oid and > >> urn:uuid) should be foreclosed. Even if the URN NID registration does > >> not envision the use of f-components, an application (e.g., a database > >> or content management system) should be able to use f-components for i= ts > >> purposes when it knows some specific stuff about the identifier. This = is > >> especially important for generic NID registrations like oid and uuid, > >> where the identifier can identify pretty much any arbitrary thing. > Yes, if the scope of the namespace is very broad, it is likely that > there are at least some resources which may support fragments. Yes. And this discussion shows me, that the issue probably is trickier than= I had thought and that we must try to provide as much guidance as we can t= o future namespace registrants. Best, Lars From nobody Mon Jan 19 21:11:00 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AED1AD05C for ; Mon, 19 Jan 2015 21:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 uH4LP4OMO3WC for ; Mon, 19 Jan 2015 21:10:54 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D314C1ACF5B for ; Mon, 19 Jan 2015 21:10:53 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E6C3B32E57E; Tue, 20 Jan 2015 14:10:08 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6993_2fd0_00dc9232_f41a_4b6a_b72d_832d29b70c9a; Tue, 20 Jan 2015 14:10:08 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 50D49BF8EE; Tue, 20 Jan 2015 14:10:08 +0900 (JST) Message-ID: <54BDE32F.1040202@it.aoyama.ac.jp> Date: Tue, 20 Jan 2015 14:10:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Svensson, Lars" , Juha Hakala , "urn@ietf.org" References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> <54B60417.7040004@gmail.com> <54B7B84D.9050709@helsinki.fi> <24637769D123E644A105A0AF0E1F92EFFAC6CF53@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFFAC6CF53@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 05:10:56 -0000 On 2015/01/19 23:30, Svensson, Lars wrote: > Hello Juha and Sean, > > On Thursday, January 15, 2015 1:54 PM, Juha wrote: >> On the other hand, using the f-component is easy and works in the same >> way in each namespace which deals with manifestations of digital >> resources: if the identified resource has fragments, a user can attach >> the f-component to the URN. It will have zero impact to the resolution >> of the URN; the identified resource will be retrieved, and the client >> will apply the fragment to it. > > I think this depends on how your resolution service works. It's true for http-based resolvers (which probably will be the most common ones for the next future). I don't think it would be the same for an ftp-based resolver, since to my knowledge ftp-URIs are not aware of fragment identifiers (rfc 959 precedes 3986...). Resolution of the fragment identifier depends on the (MIME) media type of what you get back, not on the protocol. The problem with ftp may be that it doesn't have a way to indicated the content type. But if a browser guesses the content type as HTML, it would definitely apply the fragment identifier to that document. Regards, Martin. From nobody Wed Jan 21 04:35:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062281A1A2E for ; Wed, 21 Jan 2015 04:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KzDJf8xstwyJ for ; Wed, 21 Jan 2015 04:34:59 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 EA06F1A1A2D for ; Wed, 21 Jan 2015 04:34:58 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDuUr-000J1v-62; Wed, 21 Jan 2015 07:34:57 -0500 Date: Wed, 21 Jan 2015 07:34:52 -0500 From: John C Klensin To: Peter Saint-Andre - &yet Message-ID: <837290450927013EB42CCC8B@JcK-HP8200.jck.com> In-Reply-To: <5499B521.80407@andyet.net> References: <5499B521.80407@andyet.net> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (1) Section 3.2 Namespace specific string syntax X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:35:01 -0000 Since there has been no other response to this one... --On Tuesday, December 23, 2014 11:32 -0700 Peter Saint-Andre - &yet wrote: > On 12/23/14, 10:12 AM, John C Klensin wrote: >... >> Section 3.2 Namespace specific string syntax, doesn't seem >> completely clear when p-, q-, or f-components are possible, > > As I understand it, the NSS is part of the assigned-name, so > those components don't occur within the NSS. See below. > Perhaps did you mean to reference Section 3.3 for this note? > Or by referencing Section 3.2 did you mean to imply that > 2141bis needs to be more clear about rules or guidelines for > when those components are allowed ("possible") in the context > of a given namespace? More the former, but the issue is a combination of several things that I probably should have separated: (1) It isn't clear when p-, q-, and/or f-components are allowed. That may be a matter for the Registration material in Section 8 and/or the template in Appendix A. Or not. (2) Unless we separate it very carefully, the question of "what is the NSS" is very closely connected to how we interpret 3986 syntax components (incorporating both the recent 3896 flap and urnbis-semantics-clarif by reference and the question of whether two URNs are equal. >> nor >> is it clear about any syntax issues within those components. > > To date, we have simply pointed to RFC 3986 regarding the > *syntax* of those components. The recent controversy about the use of 3986 fragments for file purposes confirms my impression that doing so is a bad idea. > Here again, we might provide some guidelines about how a given > namespace would best handle syntax within those components. Or > we could leave it completely up to the namespace definition, > as long as the syntax is consistent with the RFC 3986 > definitions. > > I would prefer the latter. So would I. My impression is that some of the 3986 advocates claim that we can't do that except on a per-scheme basis. If we can't, we may have other problems. I personally also prefer to leave it to the namespace definitions, but then we need a bit more text about those definitions. And I am still very concerned about the implications of the Hamza mess to anything based on the IDNA model (which PRECIS was both before and after the definitional change). We might need to talk about that. john From nobody Wed Jan 21 06:12:15 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681F01A1AB8 for ; Wed, 21 Jan 2015 06:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9EPYNbYYzzDn for ; Wed, 21 Jan 2015 06:12:08 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 5D9F51A1AAB for ; Wed, 21 Jan 2015 06:12:07 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDw0n-000JEr-UT; Wed, 21 Jan 2015 09:12:01 -0500 Date: Wed, 21 Jan 2015 09:11:56 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Andrew Newton Message-ID: In-Reply-To: <54ABABB1.1020000@it.aoyama.ac.jp> References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <54ABABB1.1020000@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:12:13 -0000 (top post and summary)=20 Martin, Thanks (and apologies for the delayed response). It was precisely the syntax in Section 3.4 that led to my comment/ question. Peter and Andy, Just to review what the ABNF in 3986 actually says: URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] (from the top of Section 3). Note that the "?" that introduces the query is _not_ part of the query. query =3D *( pchar / "/" / "?" ) (from the middle of Section 3.4 and as quoted by Martin) Unless I'm having _really_ severe reading problems, that means that "?" may freely appear in query parts without quoting. =20 Note that the production for above allows both foo:hier-part-stuff?# and foo:hier-part-stuff?// I wonder how many URI parsers and systems can really deal with those forms and whether we should be as permissive? =20 I'm pushing this for a specific reason, discussed at length on the list some months ago. If we really need the flexibility that having a number of different communities of URN uses seems to imply, especially if we anticipate communities and uses that haven't been heard from yet, there are really strong arguments for allowing the query string to be a series of name-value pairs. As I read 3986, nothing prevents establishing that principle on a per-scheme basis. Even if we decided that, for URN purposes, there were two types of queries -- unstructured ones and name-value pairs, we could have ABNF of=20 URN-query =3D unstructured-URN-query / nv-URN-query unstructured-URN-query =3D *( pchar / "/" ) nv-URN-query =3D nv-pair *( "?" nv-pair ) nv-pair =3D name "=3D" value with some reasonable definition of "name" and "value". If we didn't feel a need to allow both, we could eliminate unstructured-URN-query and collapse the productions. Note that the above would conform to 3986 syntax because the union of the two forms conforms to the 3986 definition of "query". =20 As a final piece of this, Peter wrote: >... > I think the p-component is not part of the NSS. >=20 > namestring =3D assigned-name > [ p-component ] > [ q-component ] > [ f-component ] > assigned-name =3D "urn" ":" NID ":" NSS >=20 It seems to me that is our choice and that we could, as easily and without violating anything about 3986 syntax, define the above as: I think the p-component is not part of the NSS. namestring =3D assigned-name [ q-component ] [ f-component ] assigned-name =3D "urn" ":" NID ":" NSS [ q-component ] It would be a funny way to overlay 3986's syntax but, AFAICT, completely valid, especially given the issues with hier-part and the RHS-matching for , which are not allowed by ABNF. So I think the question is still open although my preference is more clear than it was when I asked. john =20 --On Tuesday, January 06, 2015 18:32 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >>> Is that roughly correct? What we want? >>>=20 >>=20 >> >>=20 >> Using my possibly faulty recollection of 3986, I thought "?" >> was a general delimiter >=20 > That's correct, see > http://tools.ietf.org/html/rfc3986#section-2.2. >=20 >> and those needed to be escaped no matter what when not being >> used as a delimiter. >=20 > No. See http://tools.ietf.org/html/rfc3986#section-3.4 and > http://tools.ietf.org/html/rfc3986#section-3.5. >=20 >> From an implementation standpoint, certainly escaping "?" >> everywhere is easier than only escaping it in certain >> portions of the UR*. >=20 > It depends. Certainly, you don't want to escape the '?' that > starts the q-component itself. >=20 > Regards, Martin. >=20 > P.S.: Checking the spec beats recollection (faulty or not) > every time. From nobody Wed Jan 21 06:37:32 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D081A1ABB for ; Wed, 21 Jan 2015 06:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xmITKVQlxUq5 for ; Wed, 21 Jan 2015 06:37:28 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 B44DC1A001C for ; Wed, 21 Jan 2015 06:37:28 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDwPP-000JGn-EI; Wed, 21 Jan 2015 09:37:27 -0500 Date: Wed, 21 Jan 2015 09:37:22 -0500 From: John C Klensin To: Peter Saint-Andre - &yet , urn@ietf.org Message-ID: <124B24958D718C38C6ACEB64@JcK-HP8200.jck.com> In-Reply-To: <5499B8E5.7080909@andyet.net> References: <5499B8E5.7080909@andyet.net> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:37:31 -0000 --On Tuesday, December 23, 2014 11:48 -0700 Peter Saint-Andre - &yet wrote: >> Independent of the terminology it uses, the text in 3986 >> specifies that the characters that follow "%" in >> percent-encoding must be converted to upper case and that >> scheme names (and the host component) must be converted to >> lower case. The text in the current version of 2141bis says >> (construct 4) that the p-component is to have "case >> normalization" applied, but doesn't specify upper case, lower >> case, or case folding. We either need to get p-components out >> of that list, making them case-sensitive, or need to choose >> one of the three. > > I lean toward removing it from the list, but I'd like to think > about it more. I lean that way too. Have you thought further about this? Does anyone else have comments? >> Note that, >> because of situations like "what happens with accent marks >> when converting to upper case" (and its opposite of an >> accent-free upper case character potentially mapping to two >> or more lower case characters), arguments that >> position-dependent characters in Arabic or other scripts >> should really be treated as case variations, etc., this is >> not a trivial decision. > ASCII only mitigates that concern. Indeed. > We are using the syntax from RFC 3986, not RFC 3987. The recent discussion on the IETF list calls that distinction into question. Just as the ties between RFC 2141 and RFC 1630 has caused us some confusion and problems since RFC 3986 was adopted, it would be good to not be tightly bound to 3986 if it is going to be replaced by one or more specifications with 3097 (or some other i18n treatment) rolled in. >> If we care >> about consistency with the reasoning of IDNA and probably >> PRECIS, we should probably (but only probably) preserve >> case-sensitivity as much as possible. > > For p, q, and f components, I think that makes the most sense. See above. Again, anyone want to express another opinion? john From nobody Wed Jan 21 07:13:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3802E1A1AE5 for ; Wed, 21 Jan 2015 07:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 gFaXnP-nx0yL for ; Wed, 21 Jan 2015 07:13:07 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7FE1A1AE1 for ; Wed, 21 Jan 2015 07:13:07 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so40674085lab.11 for ; Wed, 21 Jan 2015 07:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5SgsWu7Zap7Ihlsro4/Z59bnzYbyFwKhKNs+BX6pezs=; b=yYaCz9ZL8LcLGBCUo7QAmmkeISWzh9+sC9rJFoaUdoZA3ulsmuj9qEK+M96HctHYkj ymzxUxrgKs1TO+elHfJDFxQdVrJio3bDcltO3NFC6DOij+5QyjQ0DmDbmbDoRuAlFs6b T/HWI0tbbHKITmT2Dcfnaj7wMLHfOHxjUVnzopiFvjaP4eC5CIdlXjTC2adjWyhBAhVB ob0p0YsurOni7YKO2UaJI4BiD9ewirrMhjqTEBHMnZMtirGNnqvy0XkHeXeHSgWhcHm8 5AIUfaWIjX5aNYZIxIjVI3MtucLWnLb9F9vM9TrMz9bT7tFa2isuiwvfutbMnZdgT5j6 byMA== X-Received: by 10.112.167.228 with SMTP id zr4mr44809977lbb.20.1421853185494; Wed, 21 Jan 2015 07:13:05 -0800 (PST) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.152.10.67 with HTTP; Wed, 21 Jan 2015 07:12:45 -0800 (PST) In-Reply-To: <124B24958D718C38C6ACEB64@JcK-HP8200.jck.com> References: <5499B8E5.7080909@andyet.net> <124B24958D718C38C6ACEB64@JcK-HP8200.jck.com> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Wed, 21 Jan 2015 16:12:45 +0100 X-Google-Sender-Auth: aB0qZIl0b9_IibpUitmxPWiOv_s Message-ID: To: urn@ietf.org Content-Type: multipart/alternative; boundary=001a11c2432a0b560f050d2afe5d Archived-At: Cc: Peter Saint-Andre - &yet Subject: Re: [urn] 2141bis questions - (3) Section 4.1 "normalization" comment X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:13:10 -0000 --001a11c2432a0b560f050d2afe5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable While the situation with casing is not trivial, it is not as complicated as sometimes portrayed. Unicode does have a 'case normalization', called "case folding", which erases case differences, and is widely deployed. In a few instances, it does not always match local conventions for casing (I can go into details if desired). Like normalization, it has stability guarantees ( http://unicode.org/policies/stability_policy.html#Case_Folding). There are some cases where case folding does interact with NFKC, so there is a special folding (normalization) that combines the two, called NFKC_CF. These are described in Section 3.13 Default Case Algorithms of the Unicode Standard (R4, R5) =E2=80=94 http://www.unicode.org/versions/Unicode7.0.0/ch= 03.pdf. There are also common libraries, such as ICU, that supply APIs for these. =E2=80=8BI do not wish to weigh in on whether comparison or storage should = be case-sensitive or insensitive=E2=80=8B; just wanted to point out that there= is not a technical barrier if case-insensitivity is desired. --001a11c2432a0b560f050d2afe5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While the situation with casing is not trivial, it= is not as complicated as sometimes portrayed.=C2=A0

Unicode does have a 'case normalization', called "cas= e folding", which erases case differences, and is widely deployed. In = a few instances, it does not always match local conventions for casing (I c= an go into details if desired). Like normalization, it has stability guaran= tees (http://unicode.org/policies/stability_policy.html#Case_Folding).= =C2=A0

There are some cases where case foldi= ng does interact with NFKC, so there is a special folding (normalization) t= hat combines the two, called NFKC_CF.

These = are described in Section 3.13 Default Case Algorithms of the Unicode Standa= rd (R4, R5) =E2=80=94 http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf. The= re are also common libraries, such as ICU, that supply APIs for these.

=E2=80=8BI do not wish to weigh in on whether = comparison or storage should be case-sensitive or insensitive=E2=80=8B; jus= t wanted to point out that there is not a technical barrier if case-insensitivity is desired.
--001a11c2432a0b560f050d2afe5d-- From nobody Wed Jan 21 08:51:21 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E942D1A1B1F for ; Wed, 21 Jan 2015 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H_u_uwjbmBKT for ; Wed, 21 Jan 2015 08:51:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 1C4521A1B1E for ; Wed, 21 Jan 2015 08:51:15 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDyUr-000JV9-Dp; Wed, 21 Jan 2015 11:51:13 -0500 Date: Wed, 21 Jan 2015 11:51:08 -0500 From: John C Klensin To: Peter Saint-Andre - &yet Message-ID: In-Reply-To: <5499B93D.5050209@andyet.net> References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 16:51:18 -0000 --On Tuesday, December 23, 2014 11:49 -0700 Peter Saint-Andre - &yet wrote: > On 12/23/14, 10:44 AM, John C Klensin wrote: >> We've had some on-list discussion about the wording of parts >> of Section 5 of 2141bis. I think we've reached general >> agreement about some of the language in the first paragraph >> or two and Peter or I will post draft text sometime soon to >> see if it is actually what the WG intends. >> >> However, a careful reading of the rest of that section turns >> up several related issues. Before trying to write and >> circulate draft text, I want to verify that it is the view of >> the URN WG that precise rules (and constraints and >> restrictions) for the use of URNs embedded in various >> contexts is the job of the definitions for those contexts, >> not 2141bis or other generic URN documents. >... >> On particular, while 2141bis can (and probably should) offer >> general guidance for issues a context/usage designer should >> think about, decisions about what can, or cannot, appear with >> href in elements are a matter for HTML, not this >> specification. > > Very much +1. > >> Is the WG in enough agreement about that to allow us to draft >> text? > > Yes, please. Having heard from no one other than Peter, I propose the following text as the first part of Section 5 on Conformance: 5. URI Conformance Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (e.g., an XML namespace name [XML-NAMES]). However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN may not specify the location of a resource or even point indirectly to one, it may not be appropriate to place a URN in a URI protocol slot that points to a resource (examples include the 'href' and 'src' attributes and the element in HTML, as well as the 'xml:base' attribute in XML [XML-BASE]). Ultimately, specifications of where URNs, or URNs that reference particular namespaces, are the responsibility of descriptions of individual URI schemes and contexts; this specification cannot possibly anticipate all of the relevant cases. That paragraph incorporates not only the "pointer to somewhere else" suggested by this question but also contains the adjustments suggested by Julian and others for the prior "makes sense" language. Tuning or other suggestions welcome. john From nobody Wed Jan 21 09:05:40 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAE21A1B1E for ; Wed, 21 Jan 2015 09:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 KlsJL3UF3vyT for ; Wed, 21 Jan 2015 09:05:28 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 5A4F61A1B22 for ; Wed, 21 Jan 2015 09:05:28 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDyic-000JWZ-6m; Wed, 21 Jan 2015 12:05:26 -0500 Date: Wed, 21 Jan 2015 12:05:21 -0500 From: John C Klensin To: Juha Hakala Message-ID: In-Reply-To: <54AA8552.9050606@helsinki.fi> References: <5499B9E4.8010609@andyet.net> <54AA8552.9050606@helsinki.fi> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 17:05:31 -0000 --On Monday, January 05, 2015 14:36 +0200 Juha Hakala wrote: >... >>> Question 1: It is our intent to keep URN-like objects based >>> on unregistered namespace invalid, right? >> >> I think so. URNs are a managed process. If someone starts >> creating URNs under urn:klensin:* and no one ever registered >> "klensin" as a NID, then they're out of bounds. > > + 1. > > There are at least two different cases here. Anyone who knows > anything about usage of standard identifiers would see that > urn:klensin:* URNs are (and probably will be) invalid. But it > is more difficult to work out the status of URNs which look > valid. For instance, even some librarians might think that > urn:isrc:* are OK (ISRC = International Standard Recording > Code, http://isrc.ifpi.org/en/), especially if those URNs are > actionable (they might be). But without formal namespace > registration urn:isrc:*'s are still as invalid as > urn:klensin:* ones, even though it is not likely that NID > "ISRC" will be assigned to some other identifier system than > ISRC. Unless the International Society of Rat Catchers decides to create a namepace to identify their members, species or population information about rats, etc. That further example is of no interest except as evidence of the really good reason why someone expecting to create and use an ISRC URN had best pay careful and early attention to registration. I don't think it needs to be reflected in the document although I'd be open to adding a comment if someone else thought it was important and wanted to add text. >>> Question 2: The last paragraph of the Section 6 introduction >>> (before Section 6.1 starts) disposes of "experimental" >>> namespaces. I believe it should be made clear that continued >>> use of such namespaces with URN-like syntax does not make >>> them valid URNs (because they are unregistered). If anyone >>> disagrees, please speak up not. >> >> Agreed. > > + 1. Since no one has disagreed, the working draft that will eventually turn into -09 now explicitly indicates that previous experimental namespaces are not part of valid URNs. john From nobody Wed Jan 21 09:09:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137281A1AFA for ; Wed, 21 Jan 2015 09:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zo3YdU5mTpPv for ; Wed, 21 Jan 2015 09:09:06 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 DFFA61A1B25 for ; Wed, 21 Jan 2015 09:09:05 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YDym8-000JWt-Vo; Wed, 21 Jan 2015 12:09:04 -0500 Date: Wed, 21 Jan 2015 12:08:59 -0500 From: John C Klensin To: Juha Hakala , urn@ietf.org Message-ID: <368001B52813D748A5022DAE@JcK-HP8200.jck.com> In-Reply-To: <54AA762D.1030803@helsinki.fi> References: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> <54AA762D.1030803@helsinki.fi> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] 2141bis questions - (6) NID syntax for informal namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 17:09:07 -0000 --On Monday, January 05, 2015 13:31 +0200 Juha Hakala wrote: > I am in favour of John's Option 1, since IMO it makes our > lives easier in the future, and does not create problems with > the informal NIDs already approved. Per your comments and Martin's, and with no other comments received, the ABNF for numeric NIDs (Informal Namespaces) has been modified in the working version that will become -09 to disallow leading zeros. If anyone wants to make a case _for_ leading zeros, this would be a good time to speak up. john From nobody Wed Jan 21 10:29:10 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47EA1A1BBD for ; Wed, 21 Jan 2015 10:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 cmvu3jNUinWU for ; Wed, 21 Jan 2015 10:29:06 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C231A1BA3 for ; Wed, 21 Jan 2015 10:28:40 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8824722E265 for ; Wed, 21 Jan 2015 13:28:39 -0500 (EST) Message-ID: <54BFEF7B.6070701@seantek.com> Date: Wed, 21 Jan 2015 10:27:07 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: urn@ietf.org References: <4899D91E7D548E26E088DAF5@JcK-HP8200.jck.com> <54ABABB1.1020000@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:29:08 -0000 On 1/21/2015 6:11 AM, John C Klensin wrote: > [query stuff] > > > I'm pushing this for a specific reason, discussed at length on > the list some months ago. If we really need the flexibility > that having a number of different communities of URN uses seems > to imply, especially if we anticipate communities and uses that > haven't been heard from yet, there are really strong arguments > for allowing the query string to be a series of name-value > pairs. As I read 3986, nothing prevents establishing that > principle on a per-scheme basis. [...] Hate to put a wet blanket on all these desiderata, but honestly, who=20 really needs or wants to use q-components in URNs? Let's say you can use q-components, but any common structure will only=20 be considered when actual use cases and communities materialize. Until=20 then, percent-encode the "?" in a NSS. The thing is that the definition of URN is that the NSS is basically an=20 opaque identifier. As I have argued, NSSes have "dividers", but not=20 "hierarchy" (e.g.: urn:ietf:rfc:3986 -- the : in rfc:3986 is just a=20 divider for convenience). q-components shouldn't be part of the NSS=20 since they represent parameter thingies. "Worry about stuff that matters, when it matters." Sean From nobody Wed Jan 21 10:56:06 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0312D1A1A54 for ; Wed, 21 Jan 2015 10:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 kxaZoAKPaoDH for ; Wed, 21 Jan 2015 10:56:02 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 3AAF81A6F2E for ; Wed, 21 Jan 2015 10:56:02 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YE0RN-000JiV-UZ; Wed, 21 Jan 2015 13:55:45 -0500 Date: Wed, 21 Jan 2015 13:55:40 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Melinda Shore , urn@ietf.org Message-ID: <693D212911D488774E978CED@JcK-HP8200.jck.com> In-Reply-To: <54B64306.9030106@it.aoyama.ac.jp> References: <5AD755E15F20777149102DFD@JcK-HP8200.jck.com> <54AA7428.4080301@helsinki.fi> <54AB506E.1060208@it.aoyama.ac.jp> <54B4938E.2040509@gmail.com> <54B4E5FB.4080602@seantek.com> <54B60417.7040004@gmail.com> <54B64306.9030106@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] 2141bis questions - (7) Defining namespaces - Syntax of URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:56:04 -0000 --On Wednesday, January 14, 2015 19:20 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > Hello Melinda, >=20 > On 2015/01/14 14:52, Melinda Shore wrote: >> We haven't seen any responses to Sean's comments and I'm not >> sure whether to read that as agreement, disagreement, or >> "meh." Thoughts? >=20 > I started to write an answer yesterday, but got stuck. I agree > with Sean. While there will be some correlation between URN > namespaces and fragment identifiers (f-components for those > who prefer that term), as Sean says, fragment identifiers and > their interpretation is defined by the MIME media type of a > resource obtained when resolving an URI, and therefore any > mention in a namespace registration document can and should > only be advisory, if at all. I don't have a really strong opinion about what should happen with URN fragments, although I'd encourage those who want to engage in this discussion to read through the thread about 3986 and "file"-scheme fragments on the apps-discuss list. However, we've had extended discussions, starting at the Toronto meeting, and at least one very clear consensus statement from Andy about the syntax-only binding between URNs and 3986. If the binding is syntax-only, then claims about what this WG is required to do because of relationships between f-components (whether they appear to be "fragment identifiers" or not) and MIME media types ought to be out of scope. We can, of course, open the "syntax-only" topic again, but, in the interest of progress, I hope we can avoid doing so unless someone has compelling new arguments. Absent reopening it, comments that contradict that conclusion should not have any further standing in WG discussions. I may have a little more to say directly to Sean's comment when I have been able to think about this more. However, it appears to me that we have a substantive disagreement that we will need to figure out either how to resolve or how to push off into namespace definitions and ignore. While Sean has "nothing good to say about q-components", urn:oid:1.0.4217?code=3DEUR makes = far more sense to me than urn:oid:1.0.4217#EUR. In either case, the decision between those options must be made by the OID registration authority or similar entity who can speak for and commit the whole namespace because having one interpretation in one arc and another in a different one could cause a mess of epic proportions. =20 I _think_ that part of my problem is that I'm concerned about URNs that are not interpreted or resolved at all, URNs that may be interpreted but not resolved, and the kind of URNs that seem to underlie at least parts of Sean's note, i.e., those that provide a location-independent identifier that resolves into a conventional URL and for which the purpose of f-components (and maybe q-components) is just to provide a string that is passed through into the URL without processing as part of the URN. I think that, if we make a scheme-wide decision about that sort of pass-through model, we'd better make it very carefully and better be sure we have at least some things that don't pass through (which drags the whole discussion about whether some values in a q-component/ query can be dependent on the resolution, others can actually specify the resolution service/mechanism, and still others may be independent of whether resolution occurs at all. john From nobody Wed Jan 21 22:21:01 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF061AC419 for ; Wed, 21 Jan 2015 22:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4AIfQE_dmEId for ; Wed, 21 Jan 2015 22:20:56 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9EF1AC411 for ; Wed, 21 Jan 2015 22:20:54 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0M6KoxT005802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jan 2015 08:20:50 +0200 Message-ID: <54C096C1.7060304@helsinki.fi> Date: Thu, 22 Jan 2015 08:20:49 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin References: <5499B9E4.8010609@andyet.net> <54AA8552.9050606@helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (5) Section 6 and valid and invalid URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 06:20:59 -0000 Hello, On 21.1.2015 19:05, John C Klensin wrote: > > --On Monday, January 05, 2015 14:36 +0200 Juha Hakala > wrote: > > >> >> There are at least two different cases here. Anyone who knows >> anything about usage of standard identifiers would see that >> urn:klensin:* URNs are (and probably will be) invalid. But it >> is more difficult to work out the status of URNs which look >> valid. For instance, even some librarians might think that >> urn:isrc:* are OK (ISRC = International Standard Recording >> Code, http://isrc.ifpi.org/en/), especially if those URNs are >> actionable (they might be). But without formal namespace >> registration urn:isrc:*'s are still as invalid as >> urn:klensin:* ones, even though it is not likely that NID >> "ISRC" will be assigned to some other identifier system than >> ISRC. > Unless the International Society of Rat Catchers decides to > create a namepace to identify their members, species or > population information about rats, etc. That further example > is of no interest except as evidence of the really good reason > why someone expecting to create and use an ISRC URN had best pay > careful and early attention to registration. I don't think it > needs to be reflected in the document although I'd be open to > adding a comment if someone else thought it was important and > wanted to add text. Not all communities using (ISO) standard identifiers will register URN namespaces for themselves early on, and it may take a while before URN namespace registration becomes a standard procedure. There is no way IETF could force for instance the ISRC community into registering a namespace, and if the International Society of Rat Catchers wish to register NID "ISRC" now, there is nothing in rfc2141 or rfc2141bis to prevent that, or even inform them that trying to register that NID might not be a good idea. However, it is easy to reserve NIDs which match acronyms of relevant ISO / industry standards to these standards. All it takes is a comment to this effect in the RFC. Then the International Society of Rat Catchers be required to check in advance if the NID ISRC is available using Google or perhaps a list of reserved NIDs maintained by e.g. IANA as an annex to the list of registered NIDs. And if the registrant fails to make such a check, the expert reviewing the registration request should do that, and when necessary ask the registrant to change the proposed NID. Juha > >>>> Question 2: The last paragraph of the Section 6 introduction >>>> (before Section 6.1 starts) disposes of "experimental" >>>> namespaces. I believe it should be made clear that continued >>>> use of such namespaces with URN-like syntax does not make >>>> them valid URNs (because they are unregistered). If anyone >>>> disagrees, please speak up not. >>> Agreed. >> + 1. > Since no one has disagreed, the working draft that will > eventually turn into -09 now explicitly indicates that previous > experimental namespaces are not part of valid URNs. > > john > > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Jan 23 01:02:08 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AA71A1A25; Fri, 23 Jan 2015 01:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 mlOeVaUCEWSP; Fri, 23 Jan 2015 01:02:01 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431AE1A00ED; Fri, 23 Jan 2015 01:02:01 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BED4322E268; Fri, 23 Jan 2015 04:01:59 -0500 (EST) Message-ID: <54C20E06.50104@seantek.com> Date: Fri, 23 Jan 2015 01:01:58 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "rfc-interest@rfc-editor.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: media-types@ietf.org, "urn@ietf.org" Subject: [urn] v3imp #1 Control over spacing and line-breaking X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 09:02:04 -0000 [this is to rfc-interest@, as well as to media-types@ and urn@, due to the need for
in registration templates in the xml2rfc v3 vocabulary] Improvement Need #1 Control over spacing and line-breaking This improvement calls for greater control over spacing and line-breaking in the spec-text. This includes being able to preserve exact spacing {@xml:space="preserve" or equivalents}, and setting arbitrary non-paragraph separating line breaks
. Furthermore, the vocabulary needs to be able to identify places where line breaks are prohibited { equivalent} or optionally allowed { or equivalent}. I note that
has been adopted in the vocabulary, which is a good thing. However, it seems to be limited to tables. It should be allowed in elements, as well as possibly in other places where unstructured text is permitted. My main request is in elements, however. Extensive examples of the need are in draft-josefsson-pkix-textual (see draft-josefsson-pkix-textual-10 txt and pdf), which has been approved by the IESG for RFC publication. Further examples are in I-Ds and RFCs that include registration templates, including draft-ietf-appsawg-text-markdown-05 (media type registrations) and URN registrations of all kinds. In pkix-textual, there are protocol elements that are mentioned in the spec-text ("text") where spacing and line-breaking are *absolutely critical, non-negotiable properties* of the textual productions. Furthermore, the text takes pains not to invent new and unnecssary terms out of whole cloth. Thus there are productions "-----BEGIN ", "-----END ", "-----", etc. that need to be kept exactly as-is, with no line breaks between any hyphens, and exactly one space between the "BEGIN" and "END" characters and the end of the string. I made heroic efforts to use existing xml2rfc tools to make these things work out, to no avail. Ultimately I gave up and modified the xml2rfc source myself to support various existing semi-documented (e.g., ) and novel commands. The use of NSBP (NON-BREAKING SPACE) and NBHY (NON-BREAKING HYPHEN) Unicode characters are inappropriate. The repertoire of these protocol elements is US-ASCII; if someone copied and pasted the "-----" and " " characters out of the (PDF or XML) document, they would get the incorrect code points. Furthermore, xml2rfc had a stubborn tendency to strip off whitespace characters from the ends of plain text XML fragments. Authors know what they are doing, and if a protocol or an in-text discussion requires exactly one space, two spaces, ten spaces with hyphens, Unicode EM spaces or figure dashes or ideographic spaces or what-have-you, it is the author's choice to use those characters. The vocabulary really cannot prohibit these things at a technical level. Regarding line breaks: I now have a lot more experience filling out registration templates. Many registration templates use line breaks to separate field names from field values, such as the RFC 6838-mandated text: Additional information: Deprecated alias names for this type: Magic number(s): File extension(s): Macintosh file type code(s): Stuffing the entire registration template in a
is absurd and borders on actually being insulting. When over 50% of the RFC is ensconced in a single figure, you know you have a problem. Templates such as media type and URN registrations are "structured spec-text", i.e., specification text intended for humans to read that is broken up in a regularized way. Whether a
or a new paragraph is appropriate depends on context; the editorial process can sort this out. Note that if you allow authors to preserve spacing and linebreaks, e.g., with @xml:space="preserve" or an equivalent, the author can always stuff a CRLF into the space-preserved text. So if you're going to allow one, you may as well allow the other one. What ended up happening with a lot of these drafts, such as the xmlns and rdf URN registration and the text/markdown media type registration, is that I gave up on xml2rfc entirely and authored them in nroff. I encourge other authors to revolt similarly until
and other appropriate constructs are in the v3 vocabulary. Because white-space controls can be a fundamental property of certain kinds of text, I encourage an attribute @white-space to apply to all text-containing elements, with similar values to CSS : {normal}, {pre}, {nowrap}, {pre-wrap}, and {pre-line}. Nevertheless, I would be satisfied if white-space controls are limited to certain elements, such as the elements discussed in Improvement #3 (forthcoming). I would be partially satisfied if white-space controls are limited to two options: "default" ≈ "normal" and "preserve" ≈ "pre" (which roughly correspond to the values of xml:space). Sean From nobody Fri Jan 23 01:28:32 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68D1A020D; Fri, 23 Jan 2015 01:28:28 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 qF81OLzZs3Mv; Fri, 23 Jan 2015 01:28:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5D01A01D8; Fri, 23 Jan 2015 01:28:27 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mhhr5-1Y1AY92xd5-00MpdU; Fri, 23 Jan 2015 10:28:22 +0100 Message-ID: <54C2142A.1000303@gmx.de> Date: Fri, 23 Jan 2015 10:28:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sean Leonard , "rfc-interest@rfc-editor.org" References: <54C20E06.50104@seantek.com> In-Reply-To: <54C20E06.50104@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KibYXqRAxyC67yYn4UG732fG68sPDaQGXXFHeW92dS0deqxO1Vf Llu7InTHZAr6fHc5KiqR+tdwqWUv1bNkPYooJ4nR0W3viP8h+fDpKYqvvANsTLEThh9Orj3 wCoIX5t3P4d2o8ZASgBsbXycafBf4iSmh56jyG3rrJTxhS8wEsfamqUTgE4ExW/W45wIuIq thDUrfZ356RhzNll8yNng== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: media-types@ietf.org, "urn@ietf.org" Subject: Re: [urn] [media-types] v3imp #1 Control over spacing and line-breaking X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 09:28:29 -0000 On 2015-01-23 10:01, Sean Leonard wrote: > ... > Extensive examples of the need are in draft-josefsson-pkix-textual (see > draft-josefsson-pkix-textual-10 txt and pdf), which has been approved by > the IESG for RFC publication. Further examples are in I-Ds and RFCs that > include registration templates, including > draft-ietf-appsawg-text-markdown-05 (media type registrations) and URN > registrations of all kinds. > ... I'll comment just on the registration templates things right now. There is no problem. There's no need to reproduce the template exactly. I have authored multiple RFCs that included media type registrations, and it just never has been a problem. Best regards, Julian From nobody Sat Jan 24 19:07:51 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A130B1A1EEA for ; Sat, 24 Jan 2015 19:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 35bi4LfwIv4A for ; Sat, 24 Jan 2015 19:07:46 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE861A1EEF for ; Sat, 24 Jan 2015 19:07:46 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id y20so3660461ier.1 for ; Sat, 24 Jan 2015 19:07:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j/lBTqnbG9v9B9kB/ok78tLAAw0FfBOQG+BFFWvuqEM=; b=dzkcBwe4U/1dcKghqd65/vGQ9MGTlASstiRva8hPHM1Eq6np1s/X3BUPH6l1ptE5yW mr6Tsvfz0tULLVY4pSZ9uDoepX0QlkIvMgPdQhleJVRaRmg2HSvuFPMxPIs9QiFXu5aR gefuoSjY74rQhA2X0gAm8ZopfmDXpHdC0V4y+ACV1x1k38ft75kR2Cr7jp3qmEVUhKQB W4Hbjo59Mi6xpgde+Sk/9jDKVR1QR9K8LzcD5z2MZoGK+hXLq2sBys1OkHvPDSUkpdMW XMuZ9EpJwKyL52SaBtZgdnZW/k+06Tf55oIKq6GEOwDuMp8uDRBGkSGm1Pv+dT0tE+zs BBKg== X-Gm-Message-State: ALoCoQlEwM6qO/6jLDhYIl5y1iOitIL4c0s02QKxP4VGKovt7dHeAyY1jo9h497iEHu6DcODi3Cf X-Received: by 10.50.254.99 with SMTP id ah3mr9849763igd.12.1422155265665; Sat, 24 Jan 2015 19:07:45 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:9032:51dc:f270:3796]) by mx.google.com with ESMTPSA id s17sm3509639igr.2.2015.01.24.19.07.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 19:07:44 -0800 (PST) Message-ID: <54C45DFF.3000900@andyet.net> Date: Sat, 24 Jan 2015 20:07:43 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Juha Hakala , urn@ietf.org References: <4AEA9634620DA149DF74EDBC@JcK-HP8200.jck.com> <54AA762D.1030803@helsinki.fi> <368001B52813D748A5022DAE@JcK-HP8200.jck.com> In-Reply-To: <368001B52813D748A5022DAE@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (6) NID syntax for informal namespaces X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 03:07:48 -0000 On 1/21/15 10:08 AM, John C Klensin wrote: > > > --On Monday, January 05, 2015 13:31 +0200 Juha Hakala > wrote: > >> I am in favour of John's Option 1, since IMO it makes our >> lives easier in the future, and does not create problems with >> the informal NIDs already approved. > > Per your comments and Martin's, and with no other comments > received, the ABNF for numeric NIDs (Informal Namespaces) has > been modified in the working version that will become -09 to > disallow leading zeros. For the record, I concur with this decision. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sat Jan 24 19:10:46 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602871A1EEE for ; Sat, 24 Jan 2015 19:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 HFt8_JuTO8mu for ; Sat, 24 Jan 2015 19:10:41 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0780C1A1EEB for ; Sat, 24 Jan 2015 19:10:41 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so2819035igb.0 for ; Sat, 24 Jan 2015 19:10:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kt8T8KOEbQ7aWkMtyd37talgnLiK7XaC9xf6xqjJKe0=; b=VqL8lMGVV+iEpGc7nm4yvI5vbtiE9RWmCvGVeXy3+jKwMu4mRONfxd9oVZlRtP1/8Z xenerH11iJt8cJDBzcom6LnXHe0+56OVeNElaGm4RwGq8IT9bOmHMYYswGDT+GbO09PK knrMVFUWPX9rMfnwzSp0hukWZyjlzvOhypxR6QyEOU1R93dEAbMxN4lLHOb+8cToTjBG NaqVCwjyuPLmtIyow1mpcu3pfG4cyeDGCSHPKIAxei52MukNivKQPyZaeRehj6JtzCx6 zpmm8M6PIOm5FsNSON0Z8JK79LvFNdMp5jyL0XlqzK7c/hLSkJNqVNXJweEE+8QPGoiF YOaQ== X-Gm-Message-State: ALoCoQmAbjRQOBp+MjytwWfUg/DYfQWyNPIZFDLBCgQovAGpfpESptXV3l82zgrg6FXKpNZg9qVp X-Received: by 10.107.133.37 with SMTP id h37mr11516102iod.87.1422155440437; Sat, 24 Jan 2015 19:10:40 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n4sm3498294igr.15.2015.01.24.19.10.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 19:10:39 -0800 (PST) Message-ID: <54C45EAE.40209@andyet.net> Date: Sat, 24 Jan 2015 20:10:38 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (8) Equivalence rules X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 03:10:43 -0000 On 12/24/14 11:31 PM, John C Klensin wrote: > In Section 7.2, item 3, there is a sentence that reads: > > If it is appropriate and helpful, reference can be made > to the equivalence rules defined in the URI > specification [RFC3986]. > > Given all of the controversy we have had about those rules and > what is required, suggested, ordered or unordered, etc., I > suggest the above is looking for trouble. How would people feel > about > > "... reference can be made to specific equivalence rules > defined..." > > as a way to get around that without making a big deal of it? That seems acceptable to me. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sat Jan 24 19:13:50 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3E01A1EEE for ; Sat, 24 Jan 2015 19:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 h4JuAHRfZwgl for ; Sat, 24 Jan 2015 19:13:47 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D201A1EEB for ; Sat, 24 Jan 2015 19:13:47 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so3637745iec.7 for ; Sat, 24 Jan 2015 19:13:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+SBYlKtJLXlKWcH+wOKnoOt9RejnwN5ZPxfd+OedBnw=; b=BwdSPhNihxLR0uCpISYpWM26oV4mHFqccIvCcYMvIf3keb7Y+56Dvrib9n60R3oy1S rbipth8zKV/ds56cOE9P4DJY7bgnZHpYvSDuN7YXgT5ywtV7+7eHgx+oNAMrsMXChYtw bDfAJWHnbpPxJelBs7NKE7uXGHZ15dE5RKOhVSeEXwj5on8MX/XqVoomt7tJI3GnpkDZ rxlXlNb3uwg9FmDlcNQDrgYJfLFS6UXUfdwjSNAhviTgoSfGlvCdgXtkU1Oq+kfKJv9y lIfOmuYVJuym+GAFjkFL/Y8jt2VQXyTObj3tyF+FvTKn++mZ0n4dnp6b+RBr1pmiRmlZ dNcQ== X-Gm-Message-State: ALoCoQnqV8VdjKp23Lpef0Xn02bjKwFg8Sb4FHIcagYMg622y0v0I73uE/pqzCJm0nn41fu8ta9c X-Received: by 10.107.133.203 with SMTP id p72mr11595857ioi.31.1422155626702; Sat, 24 Jan 2015 19:13:46 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:9032:51dc:f270:3796]) by mx.google.com with ESMTPSA id j79sm3667813ioi.20.2015.01.24.19.13.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 19:13:46 -0800 (PST) Message-ID: <54C45F68.8000509@andyet.net> Date: Sat, 24 Jan 2015 20:13:44 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <7AA292AD3338AE2BC429F266@JcK-HP8200.jck.com> In-Reply-To: <7AA292AD3338AE2BC429F266@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] 2141bis questions - (9) Expert review (addendum) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 03:13:49 -0000 On 12/25/14 12:06 AM, John C Klensin wrote: > Sorry... didn't read my notes carefully enough. > > I should have added that Section 9 does discuss some of the > issue and should be pointed to in, or merged with, the first > paragraph of Section 8.1 (an editorial matter), but Section 9 > still somewhat contradicts the language of RFC 2226. On the editorial matter, I had been trying to keep §8.1 and §8.2 as brief as possible to provide a very short overview of the steps that a registrant would follow. I agree that more completed text would be good in §9. I can work on proposed text. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sat Jan 24 19:14:22 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7B1A1EEF for ; Sat, 24 Jan 2015 19:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 SpXxyTJi5gg9 for ; Sat, 24 Jan 2015 19:14:18 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601D61A1EEB for ; Sat, 24 Jan 2015 19:14:18 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so3529066igk.1 for ; Sat, 24 Jan 2015 19:14:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=X2XhJzbhAburR5IdzNEhOSvDlpAvnBLzlkmVR2Gy+/0=; b=WFjm+1DKr/vVHtewfrhklFTQLGTLp+WAwxZBLOYNtxu61p99u5hYQeD44ZSymSImBM qEaVgS8UriqsQgvQDvfL8GbAI5xqzc+AbcxpMiBGqHsvbo4N76b2YtdlH5U9bj8thvFX z9MxQJBigvKfNHoGIGRvZCHZaxKHz1bUffgrP4ry6TJv2BaH6OFqzefueoYfrIF4g9YX ID9UQJ2w8fcWIzbCwva+v+iy3CET0FFsCl3q4VzjLMB2gRezplW1eJGLNtBcDvXiuymM NvNGDIpGxu35TwthmdfjfxPt0L038vXzx5x14kGP+FzlCN/tHOczG4wnQLvFv0t6Xhv2 ry3g== X-Gm-Message-State: ALoCoQnhwODRXnom7r80UKW6z4fQ+3RNxmluUut/BmlFlSG1wNDS28hlvNCvEzPsBZP18TOwryGy X-Received: by 10.50.67.18 with SMTP id j18mr9847601igt.26.1422155657868; Sat, 24 Jan 2015 19:14:17 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:9032:51dc:f270:3796]) by mx.google.com with ESMTPSA id n99sm3656890ioe.37.2015.01.24.19.14.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 19:14:17 -0800 (PST) Message-ID: <54C45F87.30608@andyet.net> Date: Sat, 24 Jan 2015 20:14:15 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <54AA709D.2050107@helsinki.fi> In-Reply-To: <54AA709D.2050107@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (10) Backward compatibility X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 03:14:20 -0000 On 1/5/15 4:08 AM, Juha Hakala wrote: > Hello, > > On 25.12.2014 9:01, John C Klensin wrote: >> The registration procedures for formal and informal namespaces >> (Sections 8.1 and 8.2) both provide for revisions of the >> registration by updating the template. Especially given some >> discussions in the WG, I think we should impose an explicit >> requirement for a description of differences from prior versions >> and/or backward compatibility in updated registrations. >> >> Do others agree? > + 1 Good idea. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sat Jan 24 19:17:38 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5566C1A1A48 for ; Sat, 24 Jan 2015 19:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OkVVz437qUEb for ; Sat, 24 Jan 2015 19:17:33 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BFF1A008F for ; Sat, 24 Jan 2015 19:17:33 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id rl12so3681150iec.0 for ; Sat, 24 Jan 2015 19:17:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Am9AjdDVu8HkXArbkSOBSCanbo7uXxcAyuzLoRzSFzA=; b=SGD5pb7C5H9CaGWskZDJZKP5biECz8Ix1cuy9CFh+NT/Jp3JH4J8H3ftPY92gC7Y8j ygc8M8+lFFVQ0iTztEU8hbySJKxJcmm3eRAB/iHdMVyhBv/5HPu+KzziZJjJpMkHDmiu BWd6SnJbwSodocUvCLoTI9H02JsYtJ+XqPlDI1qwJWTXQQkIeN90+zZ5xO4CTDKP5hwS 3m8J1nCcZVIs+ob7vcvsebvquqiQnaedmmLR4v6KDtG+Br+ttBFaA6E5MQCzoUOCG97u Dgc1YL4V4QJXsV9fiSKy+qi8hxfj0hTnGISfQBRpGf4cKjhBgQyHZ6/ZhH49oT13Ad2y A0gA== X-Gm-Message-State: ALoCoQksXdANjwQ8FvM4BcWJ4Sv25SnU3CUYFIxtbDesQpMmS2bFGvNjrfyn++hql+zapFij6JwU X-Received: by 10.107.168.214 with SMTP id e83mr12052155ioj.37.1422155853263; Sat, 24 Jan 2015 19:17:33 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:9032:51dc:f270:3796]) by mx.google.com with ESMTPSA id l20sm3668909iol.25.2015.01.24.19.17.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 19:17:32 -0800 (PST) Message-ID: <54C4604B.40203@andyet.net> Date: Sat, 24 Jan 2015 20:17:31 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 03:17:36 -0000 On 1/21/15 9:51 AM, John C Klensin wrote: > > > --On Tuesday, December 23, 2014 11:49 -0700 Peter Saint-Andre - > &yet wrote: > >> On 12/23/14, 10:44 AM, John C Klensin wrote: >>> We've had some on-list discussion about the wording of parts >>> of Section 5 of 2141bis. I think we've reached general >>> agreement about some of the language in the first paragraph >>> or two and Peter or I will post draft text sometime soon to >>> see if it is actually what the WG intends. >>> >>> However, a careful reading of the rest of that section turns >>> up several related issues. Before trying to write and >>> circulate draft text, I want to verify that it is the view of >>> the URN WG that precise rules (and constraints and >>> restrictions) for the use of URNs embedded in various >>> contexts is the job of the definitions for those contexts, >>> not 2141bis or other generic URN documents. >> ... >>> On particular, while 2141bis can (and probably should) offer >>> general guidance for issues a context/usage designer should >>> think about, decisions about what can, or cannot, appear with >>> href in elements are a matter for HTML, not this >>> specification. >> >> Very much +1. >> >>> Is the WG in enough agreement about that to allow us to draft >>> text? >> >> Yes, please. > > Having heard from no one other than Peter, I propose the > following text as the first part of Section 5 on Conformance: > > 5. URI Conformance > > Because a URN is, syntactically, a URI under the "urn" > scheme, in theory a URN can be placed in any protocol slot > that allows for a URI (e.g., an XML namespace name > [XML-NAMES]). However, this does not imply that, > semantically, it always makes sense in practice to place a > URN in a given URI protocol slot; in particular, because a > URN may not specify the location of a resource or even point > indirectly to one, it may not be appropriate to place a URN > in a URI protocol slot that points to a resource (examples > include the 'href' and 'src' attributes and the > element in HTML, as well as the 'xml:base' attribute in XML > [XML-BASE]). Ultimately, specifications of where URNs, or > URNs that reference particular namespaces, are the > responsibility of descriptions of individual URI schemes and > contexts; this specification cannot possibly anticipate all > of the relevant cases. > > That paragraph incorporates not only the "pointer to somewhere > else" suggested by this question but also contains the > adjustments suggested by Julian and others for the prior "makes > sense" language. That looks good to me. Personally I'd change "may not" to "might not" in both instances, but then avoiding lowercased versions of RFC 2119 keywords is one of my hobbyhorses. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Sun Jan 25 01:38:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB64E1A0211 for ; Sun, 25 Jan 2015 01:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IFK3ASfV6Pfk for ; Sun, 25 Jan 2015 01:38:33 -0800 (PST) Received: from bsa2.jck.com (bsa2.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 338C81A01FA for ; Sun, 25 Jan 2015 01:38:33 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YFJeJ-0009CB-Fj; Sun, 25 Jan 2015 04:38:31 -0500 Date: Sun, 25 Jan 2015 04:38:26 -0500 From: John C Klensin To: Peter Saint-Andre - &yet Message-ID: <8B9E41EF1A28EDF8157C00AD@JcK-HP8200.jck.com> In-Reply-To: <54C4604B.40203@andyet.net> References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> <54C4604B.40203@andyet.net> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 09:38:35 -0000 --On Saturday, January 24, 2015 20:17 -0700 Peter Saint-Andre - &yet wrote: >... >> 5. URI Conformance >> >> Because a URN is, syntactically, a URI under the "urn" >> scheme, in theory a URN can be placed in any protocol slot >> that allows for a URI (e.g., an XML namespace name >> [XML-NAMES]). However, this does not imply that, >> semantically, it always makes sense in practice to place a >> URN in a given URI protocol slot; in particular, because a >> URN may not specify the location of a resource or even >> point indirectly to one, it may not be appropriate to >> place a URN in a URI protocol slot that points to a >> resource (examples include the 'href' and 'src' >> attributes and the element in HTML, as well as >> the 'xml:base' attribute in XML [XML-BASE]). Ultimately, >> specifications of where URNs, or URNs that reference >> particular namespaces, are the responsibility of >> descriptions of individual URI schemes and contexts; this >> specification cannot possibly anticipate all of the >> relevant cases. >> >> That paragraph incorporates not only the "pointer to somewhere >> else" suggested by this question but also contains the >> adjustments suggested by Julian and others for the prior >> "makes sense" language. > > That looks good to me. Personally I'd change "may not" to > "might not" in both instances, but then avoiding lowercased > versions of RFC 2119 keywords is one of my hobbyhorses. Both instances changed in my working copy. Wait until you find out about my hobbyhorses :-) john From nobody Sun Jan 25 01:58:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739441A0233 for ; Sun, 25 Jan 2015 01:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 25dBKbK_l2dM for ; Sun, 25 Jan 2015 01:58:40 -0800 (PST) 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 593D31A01F4 for ; Sun, 25 Jan 2015 01:58:40 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YFJxk-0009DB-GQ; Sun, 25 Jan 2015 04:58:36 -0500 Date: Sun, 25 Jan 2015 04:58:31 -0500 From: John C Klensin To: Peter Saint-Andre - &yet , Juha Hakala , urn@ietf.org Message-ID: <83A5A9CF54B42BA6D710080F@JcK-HP8200.jck.com> In-Reply-To: <54C45F87.30608@andyet.net> References: <54AA709D.2050107@helsinki.fi> <54C45F87.30608@andyet.net> 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.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] 2141bis questions - (10) Backward compatibility X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 09:58:41 -0000 --On Saturday, January 24, 2015 20:14 -0700 Peter Saint-Andre - &yet wrote: > On 1/5/15 4:08 AM, Juha Hakala wrote: >> Hello, >> >> On 25.12.2014 9:01, John C Klensin wrote: >>> The registration procedures for formal and informal >>> namespaces (Sections 8.1 and 8.2) both provide for revisions >>> of the registration by updating the template. Especially >>> given some discussions in the WG, I think we should impose >>> an explicit requirement for a description of differences >>> from prior versions and/or backward compatibility in updated >>> registrations. >>> >>> Do others agree? >> + 1 > > Good idea. I rarely object to making a requirement stronger. In the working draft, ast sentence of section 8.1 tentatively revised to read: "A revised registration MUST describe differences from prior versions and SHOULD make special note of any relevant changes in the underlying technologies or namespace management processes." and a new template section added (A.10) to provide an explicit slot for revision information. That work? john From nobody Sun Jan 25 05:04:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151151A19E9 for ; Sun, 25 Jan 2015 05:04:28 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 kvK02SAReomb for ; Sun, 25 Jan 2015 05:04:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3351A036F for ; Sun, 25 Jan 2015 05:04:26 -0800 (PST) Received: from [192.168.2.175] ([93.217.106.47]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MSIf1-1Y9TyB2GHT-00TYKI; Sun, 25 Jan 2015 14:04:20 +0100 Message-ID: <54C4E9C9.7090408@gmx.de> Date: Sun, 25 Jan 2015 14:04:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BUCHbocyedvaC5N3Yqaaq+HN6BtCU/4JWvYYq2wJvlS1LOQu7sk M2YTIFCLKQULFf0NzDSXnjvJX+uEE3oIMUnuLiFUDG+lvuD2kFcbosoz+dO6vMr9FDtL10l VxaVM++LiHwzu0ApliuT0CPHtV3GtH4Db1E4n5pmEh7iqGaVSEn+DiMappgBkkutO+Li53U /sys8Vi5jMBqBx94KZIcQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 13:04:28 -0000 On 2015-01-21 17:51, John C Klensin wrote: > ... >>> Is the WG in enough agreement about that to allow us to draft >>> text? >> >> Yes, please. > > Having heard from no one other than Peter, I propose the > following text as the first part of Section 5 on Conformance: > > 5. URI Conformance > > Because a URN is, syntactically, a URI under the "urn" > scheme, in theory a URN can be placed in any protocol slot > that allows for a URI (e.g., an XML namespace name > [XML-NAMES]). However, this does not imply that, > semantically, it always makes sense in practice to place a > URN in a given URI protocol slot; in particular, because a > URN may not specify the location of a resource or even point > indirectly to one, it may not be appropriate to place a URN > in a URI protocol slot that points to a resource (examples > include the 'href' and 'src' attributes and the > element in HTML, as well as the 'xml:base' attribute in XML > [XML-BASE]). Ultimately, specifications of where URNs, or > URNs that reference particular namespaces, are the > responsibility of descriptions of individual URI schemes and > contexts; this specification cannot possibly anticipate all > of the relevant cases. > > That paragraph incorporates not only the "pointer to somewhere > else" suggested by this question but also contains the > adjustments suggested by Julian and others for the prior "makes > sense" language. > > Tuning or other suggestions welcome. > ... I believe I asked this before when a variation of this text was proposed before: why wouldn't be appropriate to have a URN in a/@href? Best regards, Julian From nobody Sun Jan 25 20:03:15 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364E91A1BE4 for ; Sun, 25 Jan 2015 20:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ceomCojCu6fY for ; Sun, 25 Jan 2015 20:03:11 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 360181A1BE0 for ; Sun, 25 Jan 2015 20:03:10 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7287732E54A; Mon, 26 Jan 2015 13:02:24 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 71a5_4409_a82a8028_c74f_4a29_b9ae_fad8b8bfd50f; Mon, 26 Jan 2015 13:02:24 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D6E5EBF4DF; Mon, 26 Jan 2015 13:02:23 +0900 (JST) Message-ID: <54C5BC4F.8080306@it.aoyama.ac.jp> Date: Mon, 26 Jan 2015 13:02:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Reschke , John C Klensin , Peter Saint-Andre - &yet References: <7055D09D2AD255F5827B4F95@JcK-HP8200.jck.com> <5499B93D.5050209@andyet.net> <54C4E9C9.7090408@gmx.de> In-Reply-To: <54C4E9C9.7090408@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org Subject: Re: [urn] 2141bis questions - (4) Section 5 on URI Conformance X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 04:03:13 -0000 On 2015/01/25 22:04, Julian Reschke wrote: > On 2015-01-21 17:51, John C Klensin wrote: >> ... >>>> Is the WG in enough agreement about that to allow us to draft >>>> text? >>> >>> Yes, please. >> >> Having heard from no one other than Peter, I propose the >> following text as the first part of Section 5 on Conformance: >> >> 5. URI Conformance >> >> Because a URN is, syntactically, a URI under the "urn" >> scheme, in theory a URN can be placed in any protocol slot >> that allows for a URI (e.g., an XML namespace name >> [XML-NAMES]). However, this does not imply that, >> semantically, it always makes sense in practice to place a >> URN in a given URI protocol slot; in particular, because a >> URN may not specify the location of a resource or even point >> indirectly to one, it may not be appropriate to place a URN >> in a URI protocol slot that points to a resource (examples >> include the 'href' and 'src' attributes and the >> element in HTML, as well as the 'xml:base' attribute in XML >> [XML-BASE]). Ultimately, specifications of where URNs, or >> URNs that reference particular namespaces, are the >> responsibility of descriptions of individual URI schemes and >> contexts; this specification cannot possibly anticipate all >> of the relevant cases. >> >> That paragraph incorporates not only the "pointer to somewhere >> else" suggested by this question but also contains the >> adjustments suggested by Julian and others for the prior "makes >> sense" language. >> >> Tuning or other suggestions welcome. >> ... > > I believe I asked this before when a variation of this text was proposed > before: why wouldn't be appropriate to have a URN in a/@href? I think it might be appropriate for some, but not for others. So I suggest to change the text to (including Peter's change) "it might not be appropriate to place a certain URN" or some such. Regards, Martin. From nobody Sun Jan 25 21:21:40 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525E1A1BF2 for ; Sun, 25 Jan 2015 21:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GhRd347z2OG9 for ; Sun, 25 Jan 2015 21:21:37 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E09E1A1BED for ; Sun, 25 Jan 2015 21:21:36 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t0Q5LV3j016651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jan 2015 07:21:32 +0200 Message-ID: <54C5CEDB.6060003@helsinki.fi> Date: Mon, 26 Jan 2015 07:21:31 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , Peter Saint-Andre - &yet , urn@ietf.org References: <54AA709D.2050107@helsinki.fi> <54C45F87.30608@andyet.net> <83A5A9CF54B42BA6D710080F@JcK-HP8200.jck.com> In-Reply-To: <83A5A9CF54B42BA6D710080F@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (10) Backward compatibility X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 05:21:39 -0000 Hello, on the basis of experiences gathered during the revision of ISBN and NBN namespace registration requests, the revised text below works fine. It is important to include changes both in namespace management processes and in underlying technologies, since a technological change may have a major impact on the management of the namespace (for instance, a change in the syntax of the identifier may alter the way in which the URNs can be resolved). Juha On 25.1.2015 11:58, John C Klensin wrote: > > --On Saturday, January 24, 2015 20:14 -0700 Peter Saint-Andre - > &yet wrote: > >> On 1/5/15 4:08 AM, Juha Hakala wrote: >>> Hello, >>> >>> On 25.12.2014 9:01, John C Klensin wrote: >>>> The registration procedures for formal and informal >>>> namespaces (Sections 8.1 and 8.2) both provide for revisions >>>> of the registration by updating the template. Especially >>>> given some discussions in the WG, I think we should impose >>>> an explicit requirement for a description of differences >>>> from prior versions and/or backward compatibility in updated >>>> registrations. >>>> >>>> Do others agree? >>> + 1 >> Good idea. > I rarely object to making a requirement stronger. In the > working draft, ast sentence of section 8.1 tentatively revised > to read: > > "A revised registration MUST describe differences from > prior versions and SHOULD make special note of any > relevant changes in the underlying technologies or > namespace management processes." > > and a new template section added (A.10) to provide an explicit > slot for revision information. > > That work? > > john > > > > > -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Wed Jan 28 10:01:47 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C701A1B82 for ; Wed, 28 Jan 2015 10:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, TVD_FW_GRAPHIC_NAME_MID=0.095] autolearn=ham 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 79umThucde2d for ; Wed, 28 Jan 2015 10:01:41 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226E11A1F02 for ; Wed, 28 Jan 2015 10:01:41 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3F36622E265; Wed, 28 Jan 2015 13:01:39 -0500 (EST) Message-ID: <54C92403.2000406@seantek.com> Date: Wed, 28 Jan 2015 10:01:39 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: rfc-interest@rfc-editor.org References: <54C20E8D.1080807@seantek.com> <54C27942.60702@att.com> <54C4A4D5.9020305@it.aoyama.ac.jp> In-Reply-To: <54C4A4D5.9020305@it.aoyama.ac.jp> Content-Type: multipart/mixed; boundary="------------070408000504070008060204" Archived-At: Cc: "urn@ietf.org" , Russ Housley Subject: Re: [urn] [rfc-i] v3imp #4 Ruby text X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 18:01:44 -0000 This is a multi-part message in MIME format. --------------070408000504070008060204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/25/2015 12:09 AM, "Martin J. D=C3=BCrst" wrote: > [...]Sean to give an actual example of where he thinks ruby are needed = > in IDs/RFCs. For those not familiar, "ruby characters" are small, annotative glosses=20 that can be placed above or to the right of other characters. These=20 annotations are used as pronunciation guides for characters that are=20 likely to be unfamiliar to the reader.=20 The term "furigana" (=E6=8C= =AF=E3=82=8A=20 =E4=BB=AE=E5=90=8D) is used in Japan. Since this construct is used for pr= onunciation=20 guides, its use for IPA phonetic symbols or other characters has become=20 increasingly common. Pictorial examples are attached. Unicode uses U+FFF9 U+FFFA U+FFFB to delineate interlinear annotation.=20 Interestingly, ISO/IEC 6429 (ECMA-48) also defines the ANSI escape code=20 PARALLEL TEXTS (PTX) {CSI \} along with six parameter values for the=20 same purpose. As an international organization (IETF) and document series (RFC=20 Editor), the premise that non-US-ASCII codes should be included has been = widely accepted, even though the prose specification text is still=20 limited to (US-)English. Since this series attracts document authors=20 from all over the world, educating others on appropriate pronunciation=20 is a reasonable goal. Let's look at draft-flanagan-nonascii-03 and match up: Section 3.1. "Where the use of non-ASCII characters is purely as part of an example=20 and not otherwise required for correct protocol operation, escaping the=20 Unicode character is not required." If an example includes Unicode characters, such as {SIP/2.0 200 = =3D 2**3 * 5**2 =D0=BD=D0=BE =D1=81=D1=82=D0=BE =D0=B4=D0=B5=D0=B2=D1=8F=D0= =BD=D0=BE=D1=81=D1=82=D0=BE =D0=B4=D0=B5=D0=B2=D1=8F=D1=82=D1=8C - =D0=BF= =D1=80=D0=BE=D1=81=D1=82=D0=BE=D0=B5}, one should=20 expect interlinear annotation. Furthermore, if the example is provided=20 in the spec-text, such as {blah blah blah SIP/2.0 200 =3D 2**3 *=20 5**2 =D0=BD=D0=BE =D1=81=D1=82=D0=BE =D0=B4=D0=B5=D0=B2=D1=8F=D0=BD=D0=BE= =D1=81=D1=82=D0=BE =D0=B4=D0=B5=D0=B2=D1=8F=D1=82=D1=8C - =D0=BF=D1=80=D0= =BE=D1=81=D1=82=D0=BE=D0=B5 is a sample response.},=20 interlinear annotation should be anticipated as well. Section 3.2. Authors, Contributors, and Acknowledgements "Person names may appear in several places within an RFC. In all cases, = valid Unicode is required. For names that include non-ASCII characters, = an author-provided, ASCII-only identifier is required to assist in search= and indexing of the document." An example is given in what would be the block. Overall,=20 we should anticipate that authors with names with unusual pronunciations = will want the affordance of stating how they want their names to be=20 pronounced. In the example in draft-flanagan-nonascii =E9=99=88=E6=99=BA=E6=98=8C (Wi= lliam Chan), the=20 US-ASCII name is the author's chosen English name--it does not reflect=20 his preferred pronunciation in Chinese or other languages (e.g.,=20 Japanese and Chinese names can use the same characters, but have=20 markedly different pronunciations). To this day I know of several=20 prominent security implementers who still refer to him as "Russ=20 HOOOS-lee" or "Russ HOSE-lee". I also know of a prominent physician in=20 the Los Angeles area whose name is Ph=C3=BAc. Well guess what, if you don= 't=20 speak Vietnamese and try to pronounce her name, you are in for a serious = /faux pas/. (The right way to pronounce this name, by the way, is like=20 FOOK.) Section 3.3. Company Names Same thing as Section 3.2. I am sure that a lot of employees of Huawei=20 are quite sick of having to explain how to pronounce their corporate name= =2E Section 3.4: Body of the document "When the mention of non-ASCII characters is required for correct=20 protocol operation and understanding, the characters' Unicode character=20 name or code point MUST be included in the text. [...] Use of the actual = UTF-8 character (e.g., =CE=94) is encouraged so that a reader can more ea= sily=20 see what the character is, if their device can render the text." Well obviously if the protocol operation makes use of the interlinear=20 annotation characters, you are encouraged to put those in. The same goes = for all general-purpose Unicode control characters. 3.5. Tables Tables are interesting because an alternate way to include ruby is to=20 stuff the characters into adjacent cells--the ruby on the top cell and=20 the main text on the bottom cell. This throws off the semantic intent of = a table-based layout if you have data that you want to annotate. 3.7. Bibliographic text Bibliographic text can contain names, so all the name stuff above=20 applies. Frequently there may be names without widely accepted US-ASCII=20 equivalents, so picking any particular US-ASCII-based name will make it=20 more difficult to search and index the reference. Titles of works and=20 such can also have ruby, such as ONE PIECE=EF=BC=88=E3=83=AF=E3=83=B3=E3=83= =94=E3=83=BC=E3=82=B9=EF=BC=89(to take an=20 offhand non-sequitur example). --- An example of an I-D where ruby would have been extremely useful is=20 draft-duerst-ruby-01 .= Another example is found in the desired standardized pronunciation of=20 certain acronyms, such as URL / URI / URN. To this day most people in=20 the real world call it url, as in "duke of earl"=20 . Furthermore uri ("ur-ee"= =20 or "yur-ee") and urn (as in, the container for human remains) are quite=20 common. Why is it that URI must be spelled out, but most people=20 pronounce PKIX as "PEE - kicks"? Nothing in RFC 3986 or RFC 2141 preclude these pronunciations, yet=20 certain individuals in this organization insist on correcting folks when = they say uree instead of YOU - ARE - EYE. Look, people are going to say=20 what they say. /t=C9=99=CB=88me=C9=AAto=CA=8A/, /t=C9=99=CB=88m=C9=91=CB=90= t=C9=99=CA=8A/. If this issue is so important=20 that someone wants to make a normative or suggestive statement, put it=20 in ruby at the first instance of the acronym: /ju=CB=90 =C9=91(=C9=B9) a=C9=AA/ The URI is a Uniform Resource Identifier=E2=80=A6 Furthermore, the use of interlinear annotation markers /assists/ search=20 and index engines, because it is possible to search through the RFC (or=20 any other) series to extract such annotated terms of art. Having=20 dedicated interlinear annotation markers also helps with UI affordances: = for example, a term annotated with IPA could have a text-to-speech=20 generator with a little speaker icon, to help users know how to=20 pronounce the thing. Sean --------------070408000504070008060204 Content-Type: image/gif; name="tokyo.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tokyo.gif" R0lGODlhWgBJAMQAAPn5+QAAAOGjVVWj4QCEwsKEAPnChITC+aPh+fn54QAAVcL5+fn5wqNV APnho4QAAAAAhOH5+VUAAABVo1UAVYSj4eHh4cKEhISEVcKEVQBVVeHCwuHh+cKjo8LC+QAA ACH/C1hNUCBEYXRhWE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpy ZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iQWRvYmUgWE1QIENvcmUgNS4zLWMwMTEgNjYuMTQ1NjYxLCAyMDEyLzAyLzA2LTE0 OjU2OjI3ICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1s bnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJl ZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIgeG1wTU06T3Jp Z2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjc3QTQyRDU3MEZBN0U0MTFBNkEzQzk2NkM5ODhB RDJEIiB4bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjY5MzM4REM4QTcwRjExRTQ5MUYxRjUx MUE1ODdGNTZBIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjY5MzM4REM3QTcwRjExRTQ5 MUYxRjUxMUE1ODdGNTZBIiB4bXA6Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDUzYg KFdpbmRvd3MpIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5p aWQ6NzdBNDJENTcwRkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiIHN0UmVmOmRvY3VtZW50SUQ9 InhtcC5kaWQ6NzdBNDJENTcwRkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiLz4gPC9yZGY6RGVz Y3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4B //79/Pv6+fj39vX08/Lx8O/u7ezr6uno5+bl5OPi4eDf3t3c29rZ2NfW1dTT0tHQz87NzMvK ycjHxsXEw8LBwL++vby7urm4t7a1tLOysbCvrq2sq6qpqKempaSjoqGgn56dnJuamZiXlpWU k5KRkI+OjYyLiomIh4aFhIOCgYB/fn18e3p5eHd2dXRzcnFwb25tbGtqaWhnZmVkY2JhYF9e XVxbWllYV1ZVVFNSUVBPTk1MS0pJSEdGRURDQkFAPz49PDs6OTg3NjU0MzIxMC8uLSwrKiko JyYlJCMiISAfHh0cGxoZGBcWFRQTEhEQDw4NDAsKCQgHBgUEAwIBAAAh+QQAAAAAACwAAAAA WgBJAAAF/yAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgs7gKrgNKGZC5zTZbyCYveplZZ FoicGlNbHHb8lUqxs3CMzCR50e40wHvawkdqV5OaVI3ZYFU1dHpyfoJpeYFaSYSHjIZ+f3OP hWuDfSaOJYqalzSdinmdcZ+RKKScm5UvqXUtrpQiq56JVbF8i7K5eLGof1m0Z4BuvMW+ZcnK y8zNzs/Q0dLT1NXWQBsRRgkc0AIBEAtECQ0BB87fGhVF5AET2svfAykMD+c6DhLmzPIo9Ur3 chRQgCDFwIIx/gFbyHBKwBsO1qEooITgj344KDbcCMxiD4zXamRAWALkiHoEQv+20MjxzzuV Kig+FGFShIEAKWsUCNciH08dMk3UBHAzJ41vLbG8FLivZIB5JYraGHpC6o6gTqGSsHr0aQuu TJNiMTqDqgmwGZuSGIo2htmoOHlgXesVLlkZb7fGvap2BNu9XbWqaGuDpVjAZQ8jTvsQ6dML 4kbcFCyDIuVvdwnXgEwinwIMTw3czTgac7J2A+SRm3lxMZFv7/o5oEBSx82ApmkuBeJTHEYB P3MohJrbZl8e9TxiJBfcRrtwFmguLr6jHe66ADzXpkFxNwDq0pvfIOdRuuB8rmFQLO26XXnn Dd5/xy4CPf0Xlk+AF/FPvIx83plngkJKUBaTfH6lN99JcW4xKKB+WCBYAjneGabEaPw9IGEL KKnwFnORqTDbdpJhwZpkGK7kX1Y5dACPPw8oeAMDHrQQHUw45qjjjjz26OOPQAYpJA8hAAA7 --------------070408000504070008060204 Content-Type: image/gif; name="beijing.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="beijing.gif" R0lGODlhbgBHAMQAAPn5+QAAAPnho1UAAACEwuH5+QBVo+GjVfnChKPh+QAAVcKEAITC+VWj 4fn54aNVAAAAhML5+YQAAPn5wlUAVeHh4cKjo1VVo+Hh+aPCo4Sj4QAAAAAAAAAAAAAAAAAA ACH/C1hNUCBEYXRhWE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpy ZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iQWRvYmUgWE1QIENvcmUgNS4zLWMwMTEgNjYuMTQ1NjYxLCAyMDEyLzAyLzA2LTE0 OjU2OjI3ICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1s bnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJl ZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIgeG1wTU06T3Jp Z2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjc4QTQyRDU3MEZBN0U0MTFBNkEzQzk2NkM5ODhB RDJEIiB4bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjc3QzZCMTlBQTcwRjExRTQ4NTAyQzJB MkMzODkwMUFEIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjc3QzZCMTk5QTcwRjExRTQ4 NTAyQzJBMkMzODkwMUFEIiB4bXA6Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDUzYg KFdpbmRvd3MpIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5p aWQ6NzhBNDJENTcwRkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiIHN0UmVmOmRvY3VtZW50SUQ9 InhtcC5kaWQ6NzhBNDJENTcwRkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiLz4gPC9yZGY6RGVz Y3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4B //79/Pv6+fj39vX08/Lx8O/u7ezr6uno5+bl5OPi4eDf3t3c29rZ2NfW1dTT0tHQz87NzMvK ycjHxsXEw8LBwL++vby7urm4t7a1tLOysbCvrq2sq6qpqKempaSjoqGgn56dnJuamZiXlpWU k5KRkI+OjYyLiomIh4aFhIOCgYB/fn18e3p5eHd2dXRzcnFwb25tbGtqaWhnZmVkY2JhYF9e XVxbWllYV1ZVVFNSUVBPTk1MS0pJSEdGRURDQkFAPz49PDs6OTg3NjU0MzIxMC8uLSwrKiko JyYlJCMiISAfHh0cGxoZGBcWFRQTEhEQDw4NDAsKCQgHBgUEAwIBAAAh+QQAAAAAACwAAAAA bgBHAAAF/yAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJPC0gkab0NZEQpiSE IoEtHbayg6Hg03J7jkdjdghcYYJBAJpKrw9v1GIsMvviDDNxAYSFhnwjCIQMfikCFBkUZ3qI jTx7ZD1imQBtgQBVnyltayoLeZY6caWaiCZpeTaniWA8B3Q+mCmpM3a0kyQLhsOFsSNVxju6 KFWsNKGKhLU6C9M8sCu8MFWEfNo1cck6vivLOd80T1E/oSxpuDjoMorOmvAqaQGiNvIwiq45 uEkDxqKNvhv9qEggZujekTYAYyTsMmUixYsYM2rcyLGjx48gQ4ocSbKkyREOMP9gDFcCgUMk +fZJGeQq2ksj+SIuiQOQ5Uw5MncO6DlAXJJqBINZA8KTEwCfMzWkEBZg6Z+hTqHmYsi16zCr PJqS0HoyLNaxRU8cqFc2htgRZDstakvjrQiyBqsmlXXTRJy+N/IyJJon30Efgr0ecjrE7tO0 jw//INVCkdEgjlkKC6opANsTlpNkliNZCGUWoZGMvozYc2U3os/ChVzkdDbYqmXfpU3EtorU R1Y/VEyM9Q/hRoTVa2MMuBHkRWZ5wT0FekvOrY0/1/3Y6AHsCCUzH7FJSTTCKL77EFhqfKLS QqgSsE5iLZoHcyJUEOGePPWrA+2GnhOfyRIAQP35BxhsDYaVRt8I0lHzH38TApAPWDYg4xd3 jomQBoYyKKdWhaAstOAOo8Enl144IJUeiSuCZxZADXJV4AtpAESVIUZVAaJZLyVWiIwuPLIX ANHMhQIC2qlyAWNEWAAlCdw0SdeVWGap5ZZcdullCyEAADs= --------------070408000504070008060204 Content-Type: image/gif; name="vertical-layout.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vertical-layout.gif" R0lGODlhRQBlANUAAP///yUlJf//6q1iJer//yVirc///+qtYq3q/yWEz///zyUlYiUlhITP ///qrc+EJWIlJWKt6v/PhIQlJa1ihIQlYoRirf/q6mIlhIQlhM+EYq1iYur/6urq/2IlYs/q 6s/P/yWEhISt6oSEz4TPz4TP6uqtrf/Pz2JiYq3q6s/PhK2EhCViYmKEz+qthGKtrerqra2t 6s/qrerq6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C1hNUCBEYXRh WE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQi Pz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUg WE1QIENvcmUgNS4zLWMwMTEgNjYuMTQ1NjYxLCAyMDEyLzAyLzA2LTE0OjU2OjI3ICAgICAg ICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4 bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnht cD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVu dElEPSJ4bXAuZGlkOjc5QTQyRDU3MEZBN0U0MTFBNkEzQzk2NkM5ODhBRDJEIiB4bXBNTTpE b2N1bWVudElEPSJ4bXAuZGlkOjU3QjgyQ0RCQTcxMDExRTQ4QkYzRTk3OTNDN0Q5OEM1IiB4 bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjU3QjgyQ0RBQTcxMDExRTQ4QkYzRTk3OTNDN0Q5 OEM1IiB4bXA6Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIj4g PHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6NzlBNDJENTcw RkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiIHN0UmVmOmRvY3VtZW50SUQ9InhtcC5kaWQ6NzlB NDJENTcwRkE3RTQxMUE2QTNDOTY2Qzk4OEFEMkQiLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwv cmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz4B//79/Pv6+fj39vX0 8/Lx8O/u7ezr6uno5+bl5OPi4eDf3t3c29rZ2NfW1dTT0tHQz87NzMvKycjHxsXEw8LBwL++ vby7urm4t7a1tLOysbCvrq2sq6qpqKempaSjoqGgn56dnJuamZiXlpWUk5KRkI+OjYyLiomI h4aFhIOCgYB/fn18e3p5eHd2dXRzcnFwb25tbGtqaWhnZmVkY2JhYF9eXVxbWllYV1ZVVFNS UVBPTk1MS0pJSEdGRURDQkFAPz49PDs6OTg3NjU0MzIxMC8uLSwrKikoJyYlJCMiISAfHh0c GxoZGBcWFRQTEhEQDw4NDAsKCQgHBgUEAwIBAAAh+QQAAAAAACwAAAAARQBlAAAG/0CAcEgs Go/IpHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMFgoGjXJXYfmouYf0UJJ4VxUZgwMSCIQmEXZT B30FBEIHdVRsh0Z7AXJrFQhVFzAYBkaEAQuUTBeNSSaZZ4FXB51EZ4ZOZ5BKChMBKIpXZwyZ QhKpAA99v8DBfaZJhLhZqJ6xkQIdAHvESDNKB4aE0VknuRKREq9UD8QHx1IankjeAazekVCE 7QAu51CPwvZpyYJL+QCroYi89CHh56/IuFxDFMQQCNBTQSIPyA3xxUofwQEVJ7LgIyygnYsZ +2H899Air5Iia5kZyRAkgTNpYqkUGXKgvQAzmdzKBJLDgP8+CWJJpPmviCtsQ0BFSXczGAMZ EF5MYMZS4MGVIaHFMoXSTsRcKPek2VOn65sHFVGyQxQggtkyZ2qpPYnRZ001W4eg5PdMxFsy YvVWbWh0sBYHmJZIkIjya+GKcbDgQZjkgcrGQ4kKMQdrUpZlqgZ3fcg5iTekg4aWfLjK7iEB G+YZsfx56uNQceulKajAMxLElKtUK1qwXh/GLHfJhohaCnAjO4X4agv9J7DMuu4697AcgNBc jH5z5JTCWWF4DKMkKvLAY/okxp0Gf2/kwor59PPr38+/v///AAYo4IBlhCdQLE0l+It2AjLV HICEMAigK+gNSBaBs0nIxHQ5eeGuQAsAvGNFPe55gSB2USAYAIpcIEgCCFh4U6IXcWFYXYcE 1qjEXwLpWNlx+HERn4JEAqPhGz7auBKOVqBVFBdJSiEABSoEU8IATGIRpRQKjDAlWLGFseUU XwoxmZhYZlEmAHSIMaaUFORywINqpqllnMYEqcWbUaxJBp9QwNbdF4A+0dugNNp5hQPc4TVB lvttEgyk/k33jZIhzojpppx26umnoIYq6qiklmqqHUEAADs= --------------070408000504070008060204-- From nobody Fri Jan 30 16:26:40 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431AA1A802F for ; Fri, 30 Jan 2015 16:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 X9Twtx0rnv2v for ; Fri, 30 Jan 2015 16:26:35 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6EE1A079D for ; Fri, 30 Jan 2015 16:26:35 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so7231420igk.1 for ; Fri, 30 Jan 2015 16:26:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cwi39JQ+FYtq9QSogKArkFPhIv1NwtFw6OxhCGSPFHI=; b=f9kS6mpwt+If2BVO+6uJqDVZI65pxMvPw+PxgIg4DyqHNGtupW/1uYCYU9/yhydrOI vrYFeWxZBrDtEQYL8EiP3DGUhTxhdL5qrfFj4G3NjBF8T/awHYaGur9u6Z1oCThHJyLE m/nVf/XqitW/PO6OQtSpbDNI9yMD4ry1//Y9kIWlSGscPbYbbuSy247CqwWQBVaQZun2 Dg1YVGnUlMDgHax7sgOTFYb5f7cBkYVe58myUp7wolCZA/tz9I69mhNtYTdpc9h/TYO1 wnLi39qsvXR8Md1BG0pjjIPLCv+odswZD7jTIj7ZGykMR+q7nsO8RjS7bBpUjsXdgF4+ yOZQ== X-Gm-Message-State: ALoCoQnUPWXO4oxYki/8rmwiWcTIcbZtYj0jqdwHsE38DJEvxeGhD8qEHLSqmkhrB3CWKlg3cmks X-Received: by 10.107.137.25 with SMTP id l25mr5691226iod.9.1422663994460; Fri, 30 Jan 2015 16:26:34 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:f16e:813b:3f31:9298]) by mx.google.com with ESMTPSA id m5sm2013144ige.5.2015.01.30.16.26.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jan 2015 16:26:33 -0800 (PST) Message-ID: <54CC2138.4040206@andyet.net> Date: Fri, 30 Jan 2015 17:26:32 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , urn@ietf.org References: <5765CD04A2095D995D241104@JcK-HP8200.jck.com> In-Reply-To: <5765CD04A2095D995D241104@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] 2141bis questions - (11) IANA considerations and Interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 00:26:38 -0000 On 12/25/14 12:20 AM, John C Klensin wrote: > Under IANA Considerations - URI Scheme, Section 10.1, the text > says > > "Interoperability Considerations: There are no known > interoperability concerns related to use of the 'urn' > URI scheme." > > IMO, this is not strictly true because the whole discussion of > whether URNs can be (or should be, or are meaningful in) various > contexts and/or in relative URI form is ultimately about > interoperability considerations. One could argue that almost > everything else that RFC 3986 considers a per-scheme issue and > that we have made per-NID for URNs falls into the same category. > > Should more be said in that line item and, if so, what? We could either point to the existing Section 5 (URI Conformance) or summarize some of that text. Peter -- Peter Saint-Andre https://andyet.com/