From stpeter@stpeter.im Tue Jul 3 12:14:43 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCEA11E8109 for ; Tue, 3 Jul 2012 12:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2IxEbAA10TT for ; Tue, 3 Jul 2012 12:14:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7905611E80BE for ; Tue, 3 Jul 2012 12:14:42 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8B9854005A; Tue, 3 Jul 2012 13:33:07 -0600 (MDT) Message-ID: <4FF344A9.9090501@stpeter.im> Date: Tue, 03 Jul 2012 13:14:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Julian Reschke References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> In-Reply-To: <4FEC2B8C.4070604@gmx.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:14:43 -0000 On 6/28/12 4:01 AM, Julian Reschke wrote: > On 2012-06-28 11:42, Svensson, Lars wrote: >> Juha wrote: >> >>> But >>> I hope that RFC2141bis will say at least that fragments are not part of >>> the NSS but they can be used in those namespaces which specifically >>> allow that. >> >> I'll second that RFC 2141bis says that fragment identifiers are >> allowed in URNs but that they are not part of the NSS. Further, RFCs >> for new namespaces must specify if they allow the use of fragment >> identifiers or not but I guess that is something for RFC 3406bis. > > No. > > Namespace specifications define the namespace-specific part; nothing > else. Fragment syntax and semantics are defined by RFC 3986. > > A spec *can* point out that the URN does not identify something from > which a payload + media type can be retrieved, in which fragment > identifiers are not applicable. But that's different from disallowing them. Julian, by "spec" here do you mean a specification for a particular namespace identifier? (And would one result be that each NID spec would need to specify whether URNs issued within that NID identify entities from which a payload + media type can be retrieved?) Peter -- Peter Saint-Andre https://stpeter.im/ From julian.reschke@gmx.de Tue Jul 3 12:20:19 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D800F11E80CB for ; Tue, 3 Jul 2012 12:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.083 X-Spam-Level: X-Spam-Status: No, score=-105.083 tagged_above=-999 required=5 tests=[AWL=-2.484, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prcA5B-pM8j7 for ; Tue, 3 Jul 2012 12:20:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BF29B11E8195 for ; Tue, 3 Jul 2012 12:20:18 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:20:25 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp010) with SMTP; 03 Jul 2012 21:20:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/8N8EX7Hz8f3vuKxjn/z2vQ+8rpme1y5s3YFLo7U HbQmPdTcGUfijE Message-ID: <4FF345F5.5080300@gmx.de> Date: Tue, 03 Jul 2012 21:20:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FF344A9.9090501@stpeter.im> In-Reply-To: <4FF344A9.9090501@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:20:20 -0000 On 2012-07-03 21:14, Peter Saint-Andre wrote: > On 6/28/12 4:01 AM, Julian Reschke wrote: >> On 2012-06-28 11:42, Svensson, Lars wrote: >>> Juha wrote: >>> >>>> But >>>> I hope that RFC2141bis will say at least that fragments are not part of >>>> the NSS but they can be used in those namespaces which specifically >>>> allow that. >>> >>> I'll second that RFC 2141bis says that fragment identifiers are >>> allowed in URNs but that they are not part of the NSS. Further, RFCs >>> for new namespaces must specify if they allow the use of fragment >>> identifiers or not but I guess that is something for RFC 3406bis. >> >> No. >> >> Namespace specifications define the namespace-specific part; nothing >> else. Fragment syntax and semantics are defined by RFC 3986. >> >> A spec *can* point out that the URN does not identify something from >> which a payload + media type can be retrieved, in which fragment >> identifiers are not applicable. But that's different from disallowing them. > > Julian, by "spec" here do you mean a specification for a particular > namespace identifier? ... Yes > ...(And would one result be that each NID spec would > need to specify whether URNs issued within that NID identify entities > from which a payload + media type can be retrieved?) I'd prefer those specification to be simply silent on the issue, or alternatively that the URN spec contains a clarification the NID specifications can simply reference. Best regards, Julian From stpeter@stpeter.im Tue Jul 3 12:25:54 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB511E81C5 for ; Tue, 3 Jul 2012 12:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryDxx9qA5sBm for ; Tue, 3 Jul 2012 12:25:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8411E81BE for ; Tue, 3 Jul 2012 12:25:53 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 56C234005A; Tue, 3 Jul 2012 13:44:18 -0600 (MDT) Message-ID: <4FF34748.3010202@stpeter.im> Date: Tue, 03 Jul 2012 13:26:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Julian Reschke References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FF344A9.9090501@stpeter.im> <4FF345F5.5080300@gmx.de> In-Reply-To: <4FF345F5.5080300@gmx.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:25:54 -0000 On 7/3/12 1:20 PM, Julian Reschke wrote: > On 2012-07-03 21:14, Peter Saint-Andre wrote: >> On 6/28/12 4:01 AM, Julian Reschke wrote: >>> On 2012-06-28 11:42, Svensson, Lars wrote: >>>> Juha wrote: >>>> >>>>> But >>>>> I hope that RFC2141bis will say at least that fragments are not >>>>> part of >>>>> the NSS but they can be used in those namespaces which specifically >>>>> allow that. >>>> >>>> I'll second that RFC 2141bis says that fragment identifiers are >>>> allowed in URNs but that they are not part of the NSS. Further, RFCs >>>> for new namespaces must specify if they allow the use of fragment >>>> identifiers or not but I guess that is something for RFC 3406bis. >>> >>> No. >>> >>> Namespace specifications define the namespace-specific part; nothing >>> else. Fragment syntax and semantics are defined by RFC 3986. >>> >>> A spec *can* point out that the URN does not identify something from >>> which a payload + media type can be retrieved, in which fragment >>> identifiers are not applicable. But that's different from disallowing >>> them. >> >> Julian, by "spec" here do you mean a specification for a particular >> namespace identifier? ... > > Yes > >> ...(And would one result be that each NID spec would >> need to specify whether URNs issued within that NID identify entities >> from which a payload + media type can be retrieved?) > > I'd prefer those specification to be simply silent on the issue, or > alternatively that the URN spec contains a clarification the NID > specifications can simply reference. And what do you think that clarification would say? Perhaps something like "unless a particular URN namespace explicitly specifies otherwise, applications ought to assume that no payload or media type can be retrieved from the entity associated with a URN"? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 3 12:39:36 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985E611E81EC for ; Tue, 3 Jul 2012 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXD6h-k3QH0j for ; Tue, 3 Jul 2012 12:39:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91511E81EA for ; Tue, 3 Jul 2012 12:39:35 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6A86D4005A; Tue, 3 Jul 2012 13:58:00 -0600 (MDT) Message-ID: <4FF34A7E.8000206@stpeter.im> Date: Tue, 03 Jul 2012 13:39:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120627161737.08c30300@resistor.net> In-Reply-To: <6.2.5.6.2.20120627161737.08c30300@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc2141bis-urn-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:39:36 -0000 On 6/27/12 5:17 PM, SM wrote: > In Section 1.1: > > "Since this RFC will be of particular interest for groups and > individuals that are interested in persistent identifiers in general > and not in continuous contact with the IETF and the RFC series, this > section gives a brief outline of the evolution of the matter over > time. Appendix E gives hints on how to obtain RFCs and related > information." > > This is unnecessary. if a person cannot find RFC XXXX, it's unlikely > that the person would find this document. > > "Registration procedures for URI Schemes originally had been laid down > in RFC 2717 [RFC2717] and guidelines for the related specification > documents were given in RFC 2718 [RFC2718]. These documents have > been obsoleted and consolidated into BCP 35, RFC 4395 [RFC4395], which > is based on, and aligned with, RFC 3986." > > The history of the registration procedures is not as important. I > suggest moving it into an appendix if the author wants to keep that > information. I found the text informative but most readers won't share > that view. At the least, I agree that moving this information to an appendix would be better. I question whether it really belongs in this document at all. > In Section 1.2: > > "This section aims at quoting requirements as identified in the past; > it does not attempt to revise or redefine these requirements, but it > gives some hints where more than a decade of experience with URNs has > shed a different light on past views. The citations below are given > here to make this document self-contained and avoid normative down- > references to old work." > > Such information might only be informative for a small subset of IETF > participants. People reading a document about URN syntax might find it > confusing. This this is a stylistic nit. I suggest targeting the > average reader. Describe the properties of URNs and move the historical > information to an appendix if the author would like to keep that. I think Section 1.2 is positively misleading. Just say "High level requirements for URNs can be found in RFC 1738." > In Section 1.3: > > "RFC 2141 does not seamlessly match current Internet Standards. The > primary objective of this document is the alignment with the URI > standard [RFC3986] and URI Scheme guidelines [RFC4395], the ABNF > standard [RFC5234] and the current IANA Guidelines [RFC5226] in > general. > > The objective should be in the Introduction Section. Move the > Historical information to the section about history. > > "For advancing the URN specification on the Internet Standards-Track, > it needs to be based on documents of comparable maturity. Therefore, > to further advancements of the formal maturity level of this RFC, it > deliberately makes normative references only to documents at Full > Standard or Best Current Practice level." > > This above is not that useful in the context of this document. Agreed. I think all of Section 1 can be condensed into a few paragraphs instead of multiple pages, and that (as SM noted) the entire document could benefit from significant editing to remove unnecessary text. Peter -- Peter Saint-Andre https://stpeter.im/ From julian.reschke@gmx.de Tue Jul 3 12:40:07 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6611E81EE for ; Tue, 3 Jul 2012 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.959 X-Spam-Level: X-Spam-Status: No, score=-104.959 tagged_above=-999 required=5 tests=[AWL=-2.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxvTiHAYkaBf for ; Tue, 3 Jul 2012 12:40:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 67DF911E81EB for ; Tue, 3 Jul 2012 12:40:05 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:40:12 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp039) with SMTP; 03 Jul 2012 21:40:12 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/+/qA/K3j+RuwASeqvwFqGFge0L6xCl5tQPc8pDU MYtRle+1p0X74U Message-ID: <4FF34A98.1030304@gmx.de> Date: Tue, 03 Jul 2012 21:40:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FF344A9.9090501@stpeter.im> <4FF345F5.5080300@gmx.de> <4FF34748.3010202@stpeter.im> In-Reply-To: <4FF34748.3010202@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "urn@ietf.org" Subject: Re: [urn] Finalizing items from IETF 83 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:40:07 -0000 On 2012-07-03 21:26, Peter Saint-Andre wrote: > On 7/3/12 1:20 PM, Julian Reschke wrote: >> On 2012-07-03 21:14, Peter Saint-Andre wrote: >>> On 6/28/12 4:01 AM, Julian Reschke wrote: >>>> On 2012-06-28 11:42, Svensson, Lars wrote: >>>>> Juha wrote: >>>>> >>>>>> But >>>>>> I hope that RFC2141bis will say at least that fragments are not >>>>>> part of >>>>>> the NSS but they can be used in those namespaces which specifically >>>>>> allow that. >>>>> >>>>> I'll second that RFC 2141bis says that fragment identifiers are >>>>> allowed in URNs but that they are not part of the NSS. Further, RFCs >>>>> for new namespaces must specify if they allow the use of fragment >>>>> identifiers or not but I guess that is something for RFC 3406bis. >>>> >>>> No. >>>> >>>> Namespace specifications define the namespace-specific part; nothing >>>> else. Fragment syntax and semantics are defined by RFC 3986. >>>> >>>> A spec *can* point out that the URN does not identify something from >>>> which a payload + media type can be retrieved, in which fragment >>>> identifiers are not applicable. But that's different from disallowing >>>> them. >>> >>> Julian, by "spec" here do you mean a specification for a particular >>> namespace identifier? ... >> >> Yes >> >>> ...(And would one result be that each NID spec would >>> need to specify whether URNs issued within that NID identify entities >>> from which a payload + media type can be retrieved?) >> >> I'd prefer those specification to be simply silent on the issue, or >> alternatively that the URN spec contains a clarification the NID >> specifications can simply reference. > > And what do you think that clarification would say? Perhaps something > like "unless a particular URN namespace explicitly specifies otherwise, > applications ought to assume that no payload or media type can be > retrieved from the entity associated with a URN"? "URNs in general can not be used to retrieve a payload with an associated media type, thus URI fragment identifiers can not be used. However, they can become resolvable, in which case fragment identifiers will behave exactly the same way as for any other URL." Or something like that... From stpeter@stpeter.im Tue Jul 3 12:43:22 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180E611E81CD for ; Tue, 3 Jul 2012 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSKw6hU4P+ka for ; Tue, 3 Jul 2012 12:43:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8C21B11E8170 for ; Tue, 3 Jul 2012 12:43:21 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E30D54005A for ; Tue, 3 Jul 2012 14:01:46 -0600 (MDT) Message-ID: <4FF34B61.4050903@stpeter.im> Date: Tue, 03 Jul 2012 13:43:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "urn@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:43:22 -0000 I have mentioned this in the past, and I'll mention it again: I think the new bis specs need to include the authors of the original documents, with the new authors shown as editors. So, for instance, draft-ietf-urnbis-2141bis would have the following in the header: A. Hoenes, Ed. R. Moats Simply ripping the old authors out of the specs is disrespectful. Peter -- Peter Saint-Andre https://stpeter.im/ From mca@amundsen.com Tue Jul 3 12:46:52 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C3E11E81D4 for ; Tue, 3 Jul 2012 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.179 X-Spam-Level: X-Spam-Status: No, score=-4.179 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjgIsGFhbbFn for ; Tue, 3 Jul 2012 12:46:51 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B58D11E8170 for ; Tue, 3 Jul 2012 12:46:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6318109ghb.31 for ; Tue, 03 Jul 2012 12:47:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=40vgpetLpGecLMlShd3cc0CzNXypBFJwYb42H+4T7wc=; b=KAowmYHU3Ia8TxYfqSX6pSYl/fBtZRQu0l6qp3RCghK7nDYJEg+ndxYcmUcGjzYLnb bwt0FrVtSlwFJfAcLBGY2AW9RMyhyNsWIkNQahWzGbinKtzSRoWrdFXPVKU1XNMwKFFJ eRK6VpS3bG7mwxDOBdo6tNkk7j6oq10KZrvgxiMycJvnpgy3fFdWX9hjGy8Dp8/S2xpN IUZmzpC9aPOj6ooYstMHQk1bE/jiYh6ve/EJ4fWH+z46ZnDYcBagt4VgACS+EA2/et+v clCpArI/FHiYSzuTe+Nah5049gPz7BMh5eaOXJkKpJTl8+5Lgd4D7hofFqg06GI4Wptn lqdg== MIME-Version: 1.0 Received: by 10.236.75.6 with SMTP id y6mr22205948yhd.24.1341344819826; Tue, 03 Jul 2012 12:46:59 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.147.79.17 with HTTP; Tue, 3 Jul 2012 12:46:59 -0700 (PDT) In-Reply-To: <4FF34B61.4050903@stpeter.im> References: <4FF34B61.4050903@stpeter.im> Date: Tue, 3 Jul 2012 15:46:59 -0400 X-Google-Sender-Auth: jG_UH8q0BDQmSOPdYJxCs5zTCyI Message-ID: From: mike amundsen To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf300fb19b81cff404c3f22d06 X-Gm-Message-State: ALoCoQnyh0GPCtCUTG+Lsx1YnvPpmVIiQyyVXsj3I++hNYFIx+IZ6qGlAPkxO1kvBpSnberIXDta Cc: "urn@ietf.org" Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:46:52 -0000 --20cf300fb19b81cff404c3f22d06 Content-Type: text/plain; charset=ISO-8859-1 +1 mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Tue, Jul 3, 2012 at 3:43 PM, Peter Saint-Andre wrote: > I have mentioned this in the past, and I'll mention it again: I think > the new bis specs need to include the authors of the original documents, > with the new authors shown as editors. So, for instance, > draft-ietf-urnbis-2141bis would have the following in the header: > > A. Hoenes, Ed. > R. Moats > > Simply ripping the old authors out of the specs is disrespectful. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > --20cf300fb19b81cff404c3f22d06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Tue, Jul 3, 2012 at 3:43 PM, Peter Sa= int-Andre <stpeter@stpeter.im> wrote:
I have mentioned this in the past, and I'll mention it again: I think the new bis specs need to include the authors of the original documents, with the new authors shown as editors. So, for instance,
draft-ietf-urnbis-2141bis would have the following in the header:

A. Hoenes, Ed.
R. Moats

Simply ripping the old authors out of the specs is disrespectful.

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
urn mailing list
urn@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/urn

--20cf300fb19b81cff404c3f22d06-- From stpeter@stpeter.im Tue Jul 3 13:03:34 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1C521F8715 for ; Tue, 3 Jul 2012 13:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i3AAoVJfVXe for ; Tue, 3 Jul 2012 13:03:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 625AD21F84EB for ; Tue, 3 Jul 2012 13:03:32 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D3814005A; Tue, 3 Jul 2012 14:21:56 -0600 (MDT) Message-ID: <4FF3501A.2000307@stpeter.im> Date: Tue, 03 Jul 2012 14:03:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120627161749.08c30070@resistor.net> In-Reply-To: <6.2.5.6.2.20120627161749.08c30070@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] Comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:03:34 -0000 On 6/27/12 5:17 PM, SM wrote: > Hi, > > This comments are on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02. The > Abstract Section is too long. The draft is about procedures to register > a URN namespace. > > In the Introduction Section: > > "URNs are part of the larger Uniform Resource Identifier (URI) family > (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF > STD 66, RFC 3986 [RFC3986]) with the specific goal of providing > persistent naming of resources." > > The first line is useful; the rest is unnecessary information. Good edit. > "To actually leverage the potential synergetic advantage of this > unification" > > This is not a document about pharmaceuticals. :-) Yes, that's some kind of marketing-speak. > 'The purpose of this document is to outline a mechanism and provide a > template for explicit URN Namespace definition, as well as provide > the mechanism for associating an identifier (called a "Namespace ID", > or NID), which is registered with the Internet Assigned Numbers > Authority (IANA) [IANA] in the URN Namespaces registry maintained at > [IANA-URN].' > > Could this text be made shorter? Sure it could: "This document defines procedures for registering URN Namepace Identifiers (NIDs) with IANA." > "The URN Namespace definition and registration mechanisms originally > have been specified in RFC 2611 [RFC2611], which has been obsoleted > by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing > IANA procedures have been revised as well over the years, and at the > time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative > document. This document is a revision of RFC 3406 based on the > revised URN Syntax specification RFC 2141bis > [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226." > > There is ample historical information. Is it necessary in the > introduction? I don't think so. > The discussion about URN namespace (Section 2) should be moved to > draft-ietf-urnbis-rfc2141bis-urn-02. That seems sensible. > In Section 3.1: > > "No provision is made for avoiding collision of experimental NIDs; > they are intended for use within internal or limited experimental > contexts. However, as described below in Section 4.1, these are > designated by a specific form of the NID to allow differentiation > (without preexisting knowledge of details) from the other URN > Namespace types." > > This could be formulated as guidance about when NIDs should be > registered. Given the discussion about X- for other protocols, it's > better to also drop it here. I think it would be helpful to register the 'example' NID (urn:example:*) and deprecate the experimental NIDs. I'd be happy to write an I-D registering the NID. > In Section 4: > > "The IANA Considerations Guidelines document (BCP 26 [RFC5226]) > suggests the need to specify update mechanisms for registrations -- > who is given the authority to do so, from time to time, and what are > the processes." > > Why is this text needed in this draft? I doubt it. > "The official list of registered URN Namespaces is currently > maintained by IANA at [IANA-URN]." > > The "who" is not important. What is important is to point the reader to > the location of the list of URN Namespaces. Sure. > In Section 4.3: > > "The designated expert(s) for URN Namespace registrations are > nominated by the IESG, and their role adheres to the regulations > in BCP 26, unless specified otherwise below." > > BCPs are not about regulations. I suggest using the term "guidelines". Good point. > 'Applicants, in concert with the IANA experts, should ensure that > the sought NID strings are "proper" for the designated purpose, > according to common sense (and applicable legal rules).' > > Who are the IANA experts? Perhaps the author meant the designated experts. > '"IETF Review" (per [RFC5226]) means that the Formal NID application > is made via submission to the IETF of an Internet-Draft that contains > the Namespace definition and targets publication as an RFC of > Informational or Standards-Track category, which needs to be approved > by the IESG after performing an IETF Last Call on the document and > evaluating review comments. The applicant can be an individual or an > IETF working group, in alignment with the designation of the > Internet-Draft. The actual choice should be properly considered by > applicants, but it is RECOMMENDED that the registration documents for > NIDs belonging to an established standard namespace aim at Standards- > Track, whereas other applications aim at Informational RFC.' > > There is a reference to RFC 5226 in this draft. The reader interested > in the details of "IETF Review" can find the information in that RFC. I > don't think that it is a good idea to explain about IETF process in this > draft. Agreed. > In Section 4.4.3: > > 'According to the general procurements for RFCs, URN Namespace > definition documents must include a "Security Considerations" section > (cf. BCP 72 [RFC3552]). That section has to identify the security > considerations specific to the subject URN Namespace.' > > The above should be trimmed. Provide the reader with actionable > information so that the person knows what security issues to look out for. > > Why is Section 4.4.4 needed? This should be more about how to devise an > appropriate registration request. This section seems like registration > guidelines. Yeah, there's a lot of step-by-step information here. I'm not sure how useful it is. I'd prefer to tell people the general rules and then recommend that they look at some of the recent registration documents. > In Section 6: > > "Until recently, that registry has been available in HTML, XML, and > plain text from the generic web page at > [IANA-URN]" > > Why is it important to tell IANA that the registry is available in three > formats? It isn't. > Appendix A is informative for the registrant. I suggest separating the > template and the "how to fill" information. > > AppendiX B reminds me of another RFC where the WG replicated information > about procedures to help future authors. The draft should be about the > registration steps in practice instead of a "formal" section and the > actual steps. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Tue Jul 3 13:53:50 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B755B21F86E8 for ; Tue, 3 Jul 2012 13:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUU8D5CwS0Vh for ; Tue, 3 Jul 2012 13:53:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A8111E80A2 for ; Tue, 3 Jul 2012 13:53:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q63Kro39023963; Tue, 3 Jul 2012 13:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341348835; bh=QCPD84CMcZMBeakF8jJnQAGLQ+z+fZuwMdnxVOPoP/0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P1EEhdJQPpImILYdU0Kb9k7QC3GG4pd5zipyZnhS4hdHlYGLVJM76So60fko/5F+i pu9IwK35L3GiIme57jnhR8CLu5bUbfoI+bGSpCGm5A29oQDvKEficywwL7kUT2WeF9 WMCnMRxNukiPqPLuvteXKa2MKjOhzQtEV4G5JVYw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341348835; i=@resistor.net; bh=QCPD84CMcZMBeakF8jJnQAGLQ+z+fZuwMdnxVOPoP/0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I/Jcg5C/hA8yqQM1HVJHZYZoBrrePnUeF7QnEjzSngDwXg71TRssh0Q46/2lRTTBI ApoaAm7gatHvyGn5t/gXFyJX/ZW7jf8nrBGETFP40APtdYYFRmUVPxH/a2/ZCwNR+Q 4RU7BD8N80rIppxAw1PnCOOlbVu8C/OF1BwEjskc= Message-Id: <6.2.5.6.2.20120703132316.08d588b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jul 2012 13:37:36 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4FF34B61.4050903@stpeter.im> References: <4FF34B61.4050903@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: urn@ietf.org Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:53:50 -0000 Hi Peter, At 12:43 03-07-2012, Peter Saint-Andre wrote: >I have mentioned this in the past, and I'll mention it again: I think >the new bis specs need to include the authors of the original documents, >with the new authors shown as editors. So, for instance, >draft-ietf-urnbis-2141bis would have the following in the header: > >A. Hoenes, Ed. >R. Moats > >Simply ripping the old authors out of the specs is disrespectful. I don't like not listing previous authors as they deserve credit for most of the work. There is an acknowledgement in draft-ietf-urnbis-rfc2141bis-urn-02. One of the questions which would have to be answered is how to get sign-off during AUTH48 (I am aware of the exception clause). I suggest contacting the previous authors instead of adding their names. There was an issue (unrelated to URN) when an author was listed without his approval. Regards, -sm P.S. The unrelated question is about providing the motivation to get work done. From duerst@it.aoyama.ac.jp Tue Jul 3 17:38:52 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBD721F8627 for ; Tue, 3 Jul 2012 17:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.539 X-Spam-Level: X-Spam-Status: No, score=-99.539 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMrt00+NYguL for ; Tue, 3 Jul 2012 17:38:52 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7821F8623 for ; Tue, 3 Jul 2012 17:38:51 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q640ctYd020272 for ; Wed, 4 Jul 2012 09:38:55 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 66eb_3e04_a2c551aa_c570_11e1_9ed0_001d096c566a; Wed, 04 Jul 2012 09:38:54 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33700) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 4 Jul 2012 09:38:59 +0900 Message-ID: <4FF3909B.7040304@it.aoyama.ac.jp> Date: Wed, 04 Jul 2012 09:38:51 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4FF34B61.4050903@stpeter.im> In-Reply-To: <4FF34B61.4050903@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 00:38:53 -0000 I agree. Regards, Martin. On 2012/07/04 4:43, Peter Saint-Andre wrote: > I have mentioned this in the past, and I'll mention it again: I think > the new bis specs need to include the authors of the original documents, > with the new authors shown as editors. So, for instance, > draft-ietf-urnbis-2141bis would have the following in the header: > > A. Hoenes, Ed. > R. Moats > > Simply ripping the old authors out of the specs is disrespectful. > > Peter > From juha.hakala@helsinki.fi Tue Jul 3 22:00:46 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3062F21F86EC for ; Tue, 3 Jul 2012 22:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FctWWrd93lO6 for ; Tue, 3 Jul 2012 22:00:44 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A97921F86E4 for ; Tue, 3 Jul 2012 22:00:43 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q6450oeo026259 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 4 Jul 2012 08:00:50 +0300 Message-ID: <4FF3CE02.7040503@helsinki.fi> Date: Wed, 04 Jul 2012 08:00:50 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: urn@ietf.org References: <4FF34B61.4050903@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 05:00:46 -0000 Hello +1, except that "editor" gives a wrong idea of Alfred Hoenes' role, his contribution is more important than that. Much of what was there in RFC2141 has been deleted or significantly modifed, and the document has been extended a lot. I recommend A. Hoenes R. Moats We must ask Ryan Moats if he still wants to be listed as an author. He might not approve some of the new things that have been incorporated in the rfc2141bis. I will contact Hartmut Walravens (the second author of rfc3187) and ask if he wants to be listed as one of the authors of rfc3187bis. Best regards, Juha On 3.7.2012 22:46, mike amundsen wrote: > +1 > > mca > http://amundsen.com/blog/ > http://twitter.com@mamund > http://mamund.com/foaf.rdf#me > > > > > On Tue, Jul 3, 2012 at 3:43 PM, Peter Saint-Andre > wrote: > > I have mentioned this in the past, and I'll mention it again: I think > the new bis specs need to include the authors of the original documents, > with the new authors shown as editors. So, for instance, > draft-ietf-urnbis-2141bis would have the following in the header: > > A. Hoenes, Ed. > R. Moats > > Simply ripping the old authors out of the specs is disrespectful. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > 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, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From barryleiba.mailing.lists@gmail.com Wed Jul 4 06:47:28 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1346421F87D8 for ; Wed, 4 Jul 2012 06:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.213 X-Spam-Level: X-Spam-Status: No, score=-103.213 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OJ68hlct3oR for ; Wed, 4 Jul 2012 06:47:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76F21F86C6 for ; Wed, 4 Jul 2012 06:47:27 -0700 (PDT) Received: by bkty8 with SMTP id y8so6847214bkt.31 for ; Wed, 04 Jul 2012 06:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oL1PdyKM165nGaEPsCRqXToFyvOr2AlaYwpYX2qbZ6M=; b=mvyRBtvfPdPhJsivGJ8F7Bpk5hBomL8uvsmLstDGZouJgR5UGcJOv9uYy0ihYjTVCi OtFdpr5jofbP5Q49ZHJ+idXC7K95tiiiUPkpS3cFOhEVb13uMGLLb0PajBqvcBMk83cO NcosQx54Vyx1k0RzEfIKGQiDpQTpDyZvnywa2ZOU4HA6xKJs5iKCzk9gn5RCSypdQbjQ dOigWTgEWhmiBOsX2K4wp1IgtBKOsDrv3R3P6gMs7d3N80l5FhemkvLOkxTxUjcfhpgY gPllER4VKwgL0qQJshQRSL0kE9kf2IjHFhf9XS3P4Xbs7qUI7vOUTfGRoq8gUYfNy/V9 barQ== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr21859804lab.2.1341409657208; Wed, 04 Jul 2012 06:47:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Wed, 4 Jul 2012 06:47:37 -0700 (PDT) In-Reply-To: <4FF34B61.4050903@stpeter.im> References: <4FF34B61.4050903@stpeter.im> Date: Wed, 4 Jul 2012 09:47:37 -0400 X-Google-Sender-Auth: 6_2-3yFbrnLDEsgg7IzIi4ulj08 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 13:47:28 -0000 > I have mentioned this in the past, and I'll mention it again: I think > the new bis specs need to include the authors of the original documents, > with the new authors shown as editors. So, for instance, > draft-ietf-urnbis-2141bis would have the following in the header: > > A. Hoenes, Ed. > R. Moats > > Simply ripping the old authors out of the specs is disrespectful. Well, yes and no -- it's not that simple. First, I agree that the complete removal of the name of someone who contributed substantially to a document in any phase of its life (including a prior edition) would, indeed, be disrespectful... and unethical. But: 1. 2141bis (for example) is a product of the urnbis working group, and the chairs have complete control over who is listed at the top of the document. They can remove someone's name for any defensible reason (subject, of course, to appeal), including that the person is no longer participating in the document's development. 2. Everyone who appears at the top of the document has to be reachable and responsive during AUTH48. An AD can override that, but we prefer to avoid that and to list only those who we *do* expect to handle the AUTH48 process promptly. 3. An "Authors" section can and should be added to recognize the contributions of those who are or were authors of some version of the document, but who are no longer listed at the top. This is where we can give due respect to a former author who is no longer active. Of course, as Juha says, it would be reasonable to ask the authors of prior versions how they would like to be recognized (and, I'll add, whether they will be available to review the final version and sign off during AUTH48). That can certainly be input to the chairs' decision. And anyway, if contacting a former author might bring more experienced eyes on the document and get more reviews and input, that's a good thing. If we specifically think a former author will disapprove of where we've gone, that is NOT a reason to exclude him... in fact, it's that much more of a reason to get the input for consideration. Also, in this case, we have the odd situation that one of the chairs is far more active as a document editor than is usual, leaving it solely to the other chair to make these decisions. Barry From sm@resistor.net Wed Jul 4 09:30:27 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F378E21F8715; Wed, 4 Jul 2012 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atrpCMw6jYle; Wed, 4 Jul 2012 09:30:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5B21F8710; Wed, 4 Jul 2012 09:30:24 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q64GUO6I025060; Wed, 4 Jul 2012 09:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341419431; bh=076Nv2hHn6isCJFRWD4xiRYtxJnB1nSf9eqomnk2DOo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Sx3KgCfW39DVMirDwa52aNImGwUAENZN/SabuQhV6rZ3/SDUytbDTCaSUKdm1AevQ Nnw+UmmzjYQRnqs4R3AT7V4yypJnwpjS0Mpvp8UARhE+ccpx3+duJ+mn/zVe+DhrKR EyfGPS45lEQq6yKBnfKeUDp1iRZWpFnOU0z+vXFU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341419431; i=@resistor.net; bh=076Nv2hHn6isCJFRWD4xiRYtxJnB1nSf9eqomnk2DOo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fNKfNR2eksNaGBTQaS2WNAlyTROtPvhIWxfwIwJdf/4rRkKJt9+9HB99JidQQvycF Dlx781hgOZRCOgH51gB/H10D5XogFrRpdotVCpA1GESNjs4nInLiWbhqwLclJO9+Ei BLdgThdNFlhhh8rTWz/0X8uzb3R+iBC0CKVzXHN8= Message-Id: <6.2.5.6.2.20120704071517.09069f48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jul 2012 09:13:52 -0700 To: urn@ietf.org From: SM In-Reply-To: References: <4FF34B61.4050903@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Barry Leiba , ietf@ietf.org Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 16:30:27 -0000 Hi Barry, [Cc to ietf@ as the question is pertinent to other working groups too] At 06:47 04-07-2012, Barry Leiba wrote: >Well, yes and no -- it's not that simple. Agreed. >First, I agree that the complete removal of the name of someone who >contributed substantially to a document in any phase of its life >(including a prior edition) would, indeed, be disrespectful... and >unethical. There was a message from Fred Baker on December 12, 2011 to ietf@ about a similar question: "Checking the acknowledgements, you'll see that I listed Warren and his professor as co-authors, although to be honest they at most made a few comments on the actual paper. Why? It is a variation on his original idea, and I'm giving him full credit for the idea. Tim and his student get mentioned as making a suggestion, because they did some work and it was a good suggestion. Others are listed as commenting, because they did." We could diff a -bis document to determine whether the change is substantial or not. That's more of a measure than an assessment of an idea. Long-standing authors tend to "give credit where credit is due" whereas new authors tend to look at it in terms of lines of text provided. >But: > >1. 2141bis (for example) is a product of the urnbis working group, and >the chairs have complete control over who is listed at the top of the >document. They can remove someone's name for any defensible reason >(subject, of course, to appeal), including that the person is no >longer participating in the document's development. There is a subtlety here. The chairs have complete control on the selection of the document editor. The document editor has editorial discretion. I'll argue that the individual also has a say in keeping the name of the author of the previous version of the document. >2. Everyone who appears at the top of the document has to be reachable >and responsive during AUTH48. An AD can override that, but we prefer >to avoid that and to list only those who we *do* expect to handle the >AUTH48 process promptly. Yes. >3. An "Authors" section can and should be added to recognize the >contributions of those who are or were authors of some version of the >document, but who are no longer listed at the top. This is where we >can give due respect to a former author who is no longer active. You may have meant "Contributors" here. There are RFC Editor guidelines about that ( http://www.rfc-editor.org/policy.html ). >Of course, as Juha says, it would be reasonable to ask the authors of >prior versions how they would like to be recognized (and, I'll add, >whether they will be available to review the final version and sign >off during AUTH48). That can certainly be input to the chairs' >decision. And anyway, if contacting a former author might bring more >experienced eyes on the document and get more reviews and input, >that's a good thing. If we specifically think a former author will >disapprove of where we've gone, that is NOT a reason to exclude him... >in fact, it's that much more of a reason to get the input for >consideration. The IETF has formal processes for listed authors due to IPR. Given that I will not be provided any assistance when things go wrong, I prefer to follow the cautious path where I only add a person's name with their agreement. There was a case where a listed author asked to have his name removed as author. This may come as a surprise to some participants; some people prefer not to have their name attached to a bad idea as they consider that as more important than having a name on a RFC. It's up to each and anyone to see whether it is worthwhile to make that good faith effort to contact the former author and have them involved in the work to update a specification. It's better to do that early instead of having a "fait accompli" where the former author is not given much latitude to disapprove. It is up to the author to assess whether getting more review and input is important. Having a working group does not mean that the work will get adequate review. Soliciting comments does not necessarily make it happen. If everyone is listed as author, the question that comes to mind is who is going to review the work. Regards, -sm From A.Hoenes@TR-Sys.de Wed Jul 4 11:21:31 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AC221F872A for ; Wed, 4 Jul 2012 11:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.579 X-Spam-Level: X-Spam-Status: No, score=-98.579 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMfmNgZHvT6X for ; Wed, 4 Jul 2012 11:21:30 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6621F86EC for ; Wed, 4 Jul 2012 11:21:29 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA158875997; Wed, 4 Jul 2012 20:19:57 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA04031; Wed, 4 Jul 2012 20:19:56 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201207041819.UAA04031@TR-Sys.de> To: barryleiba@computer.org Date: Wed, 4 Jul 2012 20:19:55 +0200 (MESZ) In-Reply-To: from Barry Leiba at Jul "4, " 2012 "09:47:37" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 18:21:31 -0000 Barry, speaking as the acting editor of multiple URNbis WG documents, I fully share your point of view. The IETF is not academia where formal authorship is sought for visibility, to increase publication counts, even if the actual contribution to the work leading to a publication is more at the spiritual level than at the actual craftmanship in preparing the document on behalf of a working group. In the IETF, authors grant the IETF the right to prepare any kind of derivative work (and they have always done so); of course, previous work needs to be fully acknowledged, and that's what the (mandatory) Acknowledgements and (optional) Contributors sections in RFCs are for. This all is backed by the RFC Editor's "Instructions for Request for Comments (RFC) Authors" (instructions2authors.txt, aka draft-rfc-editor-rfc2223bis-08.txt), which say: * in Section 2 (1st para): | [...] RFC authors | should obtain the latest RFC editorial policy statements from the RFC | Editor web page [RFCed]. where the Normative Reference is: [RFCed] RFC Editor web page, "http://www.rfc-editor.org". * in Section 2.12, "Authors Listed on RFC": | The IESG and IETF have ratified a policy of limiting the number of | authors listed in the first page header of an RFC. The specific | policy is as follows: | | (1) A small set of author names, with affiliations, may appear on | the front page header. These should be the lead author(s) | who are most responsible for the actual text. When there are | many contributors, the best choice will be to list the person | or (few) persons who acted as document editor(s) (e.g.,"Tom | Smith, Editor"). | | There is no rigid limit on the size of this set, but there is | likely to be a discussion if the set exceeds five authors, in | which case the right answer is probably to list one editor. | | The RFC Editor will hold all the people listed on the front | page equally responsible for the final form and content of | the published RFC. In particular, the "Author's 48 Hours" | final approval period will require signoff from all listed | authors. | | (2) An RFC may include a Contributors section, listing those | contributors who deserve significant credit for the document | contents. The Contributors section is intended to provide a | level of recognition greater than an acknowledgment and | nearly equal to listing on the front page. The choice of | either, both, or none of Contributor and Acknowledgment | sections in a particular RFC depends upon the circumstance. | | (3) The body of an RFC may include an Acknowledgements section, | in addition to or instead of a Contributors section. An | Acknowledgments section may be lengthy, and it may explain | scope and nature of contributions. It may also specify | affiliations. | | [...] Barry, I assume that in item 3 below you intended to refer to the "Acknowledgements" or "Contributors" section as described above. All versions of both the rfc2141bis and the rfc3406bis I-Ds contained explicit verbiage to acknowledge previous authors and contributors, in accordance with these instructions. The primary target should be a smooth process when during IESG review and RFC Editor AUTH48 stage authors are required to be responsive. After the discussion on the list around IETF in Paris, I've considered adding Leslie Daigle to the authors list of the 3406bis I-D, hoping for her to agree to participate in the process -- just as you say in item 3 below. I have observed working groups with strict policy that only actual "working" authors can be listed on the front page of their documents; OTOH, in some cases I have seen documents stuck for years since it had been decided to keep authors of previous work on the authors list while they did not interact with the process. I also recall a case where an I-D has been stuck in AUTH48 for more than a year because an author was irresponsive, and the IESG or the responsible AD were very hesitant to declare an overriding exception. The individual drafts for rfc2141bis, rfc3187bis and rfc3188bis were in extended existence before the installation of the WG, and these have been adopted as a WG draft by the WG charter. Therefore, the present WG drafts all have simply followed the same author list policy as these I-Ds. If the WG now prefers to list previous authors in a "Contributors" section, then of course I have no problem with accommodating that in the upcoming next draft revisions. Kind regards, Alfred. Barry Leiba wrote: [[ PSA said: ]] >> I have mentioned this in the past, and I'll mention it again: I >> think the new bis specs need to include the authors of the original >> documents, with the new authors shown as editors. So, for instance, >> draft-ietf-urnbis-2141bis would have the following in the header: >> >> A. Hoenes, Ed. >> R. Moats >> >> Simply ripping the old authors out of the specs is disrespectful. > > Well, yes and no -- it's not that simple. > > First, I agree that the complete removal of the name of someone who > contributed substantially to a document in any phase of its life > (including a prior edition) would, indeed, be disrespectful... and > unethical. > > But: > > 1. 2141bis (for example) is a product of the urnbis working group, and > the chairs have complete control over who is listed at the top of the > document. They can remove someone's name for any defensible reason > (subject, of course, to appeal), including that the person is no > longer participating in the document's development. > > 2. Everyone who appears at the top of the document has to be reachable > and responsive during AUTH48. An AD can override that, but we prefer > to avoid that and to list only those who we *do* expect to handle the > AUTH48 process promptly. > > 3. An "Authors" section can and should be added to recognize the > contributions of those who are or were authors of some version of the > document, but who are no longer listed at the top. This is where we > can give due respect to a former author who is no longer active. > > Of course, as Juha says, it would be reasonable to ask the authors of > prior versions how they would like to be recognized (and, I'll add, > whether they will be available to review the final version and sign > off during AUTH48). That can certainly be input to the chairs' > decision. And anyway, if contacting a former author might bring more > experienced eyes on the document and get more reviews and input, > that's a good thing. If we specifically think a former author will > disapprove of where we've gone, that is NOT a reason to exclude him... > in fact, it's that much more of a reason to get the input for > consideration. > > Also, in this case, we have the odd situation that one of the chairs > is far more active as a document editor than is usual, leaving it > solely to the other chair to make these decisions. > > Barry > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From A.Hoenes@TR-Sys.de Thu Jul 5 02:27:39 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDFC21F85B8 for ; Thu, 5 Jul 2012 02:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.298 X-Spam-Level: X-Spam-Status: No, score=-98.298 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d1kp3VD5fS7 for ; Thu, 5 Jul 2012 02:27:38 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1C921F8440 for ; Thu, 5 Jul 2012 02:27:36 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA173260369; Thu, 5 Jul 2012 11:26:09 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA08015; Thu, 5 Jul 2012 11:26:08 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201207050926.LAA08015@TR-Sys.de> To: urn@ietf.org Date: Thu, 5 Jul 2012 11:26:08 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: [urn] A way forward for rfc2141bis and rfc3406bis -- was: Finalizing items ... X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 09:27:39 -0000 URN folks, thanks to all for reviving the discussion on the rfx2141bis and rfc3406bis I-Ds. As the editor of both drafts, I try to sum up below and provide a perspective for a way forward; I'll respond individually in more detail ASAP (see endnote). ** general ** Unfortunately, stakeholders of URN Namespaces for various reasons seem to feel discouraged to participate in the on-list discussion, which now has been majorized by few long-time "IETF professional" contributors. Part of the frustration I observe also seems to be based on the lack of constructive proposals on the list so far, as replacement solutions for the options being voted against. We should not forget that the prime target audience of these URN core documents is the rather divers family of (present and) prospective stakeholders of URN Namespaces, which frequently have not been in contact with the IETF, but possibly with other persistent ID schemes, _or_ which are working within the IETF, but with a focus on a particular technology and mostly unaware of relevant work for URNs. Hence, the goal of the "core URN documents" should be to give concise guidance to _that_ audience, in order to help avoid to have to explain the same context again and again individually (as I have done in the past couple of years). This IMO needs to include a bit of a "marketing" effort for the URN framework against other, concurring identifier systems. Recently, being able to point prospective applicants of new URN Namespaces (from inside and outside of the IETF) to the material in the present Introductions of the rfc2141bis and rfc3406bis drafts has been very helpful in giving guidance on technical/document/historical context; such material is sought by prospective stakeholders in the core documents. ** towards a way forward ** We face several general kinds of problems to deal with. One stems from the chartered restriction to not revise the "strategical" RFCs laying the foundation of URNs and to presently obstain from work on services/methods and details of URN resolution and URN services. There seems to be consensus that some parts of these RFCs are outdated by more than a decade of experience with URNs. Since we aim our work towards bringing our documents forward on the Standards Track, we cannot make Normative references to past, Informational RFCs. So, as elaborated upon in the URNbis chartering discussion, we need to incorporate selected text from, e.g. RFC 1737, verbatim in order to remind the readers (including prospective stakeholders of URN Namespaces) of what we now deem still particularly valid and important for URNs. Likewise, experience shows that we need to provide a more precise framework for the establishment of URN services for URN Namespaces, in order to further a uniform style -- to the benefit of generic URN handling applications. Unlike for other URIs, URNs in general are dedicated to be media- and technology-independent, as almost necessitated by the target of long-term, global scope, uniqueness, and persistence (RFC 1737, Section 2). Since there are various services applicable to URNs, resolution of a URN does not have the same media orientation properties like it is common in a HTTP/HTML context. The objects/resources named by URNs might be structured, complex, and inter-related with the details perhaps evolving over time, whereas the abstract object and its naming (as done by the assignement of {NID}:{NSS}) needs to be stable. Our effort has been driven by a major class of mass URN "customers", the bibliographic community. That community has identified the urgent need to identify in a uniform way, in the URN resolution process, object/resource components and/or related resources. The description in the first paragraph of Section 3.5 in RFC 3986 has lead to a URN service/resolution implementation attempt based on the usage of fragment identifiers, and that has been reflected in the rfc2141bis draft since its beginning as an individual I-D. In the meantime, it has become clear that the subsequent text in Section 3.5 of RFC 3986 is incompatible with the goals, since it calls for URI users to strip the fragment identifier component before forwarding a URI reference for resolution, and to apply the fragment identifier, in a media-type dependent manner, to the returned content. In the bibliographic context, components might be archived in different media items over time to maintain their accessability, and they might be subject to diverse distribution restrictions; so in general, it will be impossible or impractical to return an all-encompassing response and allow the client to select the required part. An additional restriction of the use of fragment identifiers is that, in practice, media types and/or common browsers do not support to "pick a component" from the returned resource, but represent the whole resource, pointing to a particular spot therein, such maintain the user perception of a "fragment identifier" essentially being used as a pointer to a particular point in the returned media, not a particular part of the resource. The IETF has recently put emphasis on this particular, strict media-type dependence of the fragment part of URIs, and we need to accomodate that and established practice in browsers. In order to avoid recurrence of this issue, explaining text on fragment use with URNs IMO needs to be present in rfc2141bis, _and_ we need to provide a uniform working scheme for the identified requirements. ** the proposal ** Study of RFCs and off-list conversations with folks from the bibliographic community has lead to a model how these goals could be achieved by a common-style usage of the URI part, and I want to present this to the WG as a way forward for discussion before going to work out the details in the next version of the rfc2141bis and rfc3406bis I-Ds. Let me explain the idea with a very hypothetical (intentionally invalid) example: Say a book has been assigned the ISBN (ISBN-13) 987-65-4321-678-9. Thus, per the rfc3187bis I-D, it gets assigned the URN, urn:isbn:987-65-4321-678-9 A resolution service might be able to provide the bibliographic record of the book and point to reproductions of selected parts of it, say - an image of the front page (cover page), - a text version of the table of contents, - some rich text copy (e.g. HTML or PDF) of the foreword, - the list of references included in the book (e.g. in the form of a set of shortened bibligraphic records), all of the above available for free, without restrictions to anyone; and - the Introduction section of the book (in PDF) available to registered (authenticated and authorized) users of a specific community only. Then, specific URI references to the above URN can direct its consumer to steer the resolution process, using the fragment part of the URI reference: urn:isbn:987-65-4321-678-9 returns the metadata for the book (default); urn:isbn:987-65-4321-678-9?s=I2R&c=toc returns the table of contents; urn:isbn:987-65-4321-678-9?s=I2L&c=foreword returns a URL for the foreword of the book; urn:isbn:987-65-4321-678-9?s=I2Ns&c=reflist returns a URI list (text/uri-list per RFC 2483) with the URNs of the references included in the book; urn:isbn:987-65-4321-678-9?s=I2L&c=sec.1 returns a URL pointing to the Introduction (Section 1) of the book, which can only be resolved by authorized users. This solution, in a nutshell, would consist of the following elements for rfc2141bis and rfc3406bis: o rfc2141bis specifies - the forms-like syntax of the component in URN references, as a sequence of keyword=value items separated by "&" chars; I suggest that for simplicity both and should be simple fixed tokens (or follow simple patterns), i.e. kind of enumerated value protocol elements, and hence not subject to internationalization (s are case-insensitive, in the spirit of RFC 1737, s should preferably be case-insensitive as well, but namespace-specific considerations might dictate allowance for case-sensitivity); - the handling rules: single instance of items with a particular only, semantics independent of order of the items, items with unknown (or falsely repeated) are to be ignored by the resolution service, "sensical" fallback in case of unknown / unsupported / not applicable needed (these rules will support easy introduction and future extension of the repertoire supported by URN services); - a new IANA registry of "URN Resolution Query Tokens" with a sub-registry for s to be used with URI references to URNs -- either for general use or specific to particular URN Namespaces --, which will be initialized with two entries explained below; - the "s" (Service) to indicate the label of the desired URN resolution service; - the "c" (component) to indicate the desire to obtain information about a particular component of the object/resource designated by the base URN; - another sub-registry of the above new IANA registry for s used for the "s" keyword, (i.e. the "service labels"), which will be provisionally populated by the service identifiers from RFC 2483 -- leaving details to a future rfc2483bis; - that supported "c=" values need to be specified per URN namespace. Further, rfc2141bis will indicate that future URN Namespace registration documents (as per rfc3406bis) need to specify the support of the above syntax by its resolution service(s), supported/applicable services, the default service provided, and the usage of "c=" (if applicable) and any other potential keywords for that URN Namespace and supported service. Explanatory material related to the issues (described above) with the use of identifiers as in some recent prototype URN service implementations will stay in Appendices of rfc2141bis; this includes the mention of the choices URN namespace designers have for support of hierarchical (and cross-linked) resources: - include component identifier in registered identifier, making it a (perhaps distinguishable) part of the NSS; - support/use with "c=", so the NSS registry for the namespace doesn't have to deal with the component information (which will be added value by the resolution services); - use (if media types returned for particular NID are long-term stable and allow to support that). The proper use of will be emphasized in the main body of rfc2141bis, with pointers to other specs, including the work-in-progress RFC 4288bis from APPSAWG. o rfc3406bis specifies the details for the above scheme expected to be specified in registration documents, including new entries in the URN Namespace registration template for supported services (per the "s" value IANA registry) and the usage and rules for "c=" (if applicable) and any other keywords, including possible IANA registration of new keywords. o The definition of new service labels, and an update to the existing definitions is left to future work on a rfc2483bis document. The inofficial rfc2482bis pre-draft circulated can be stripped of the definition of the URN service label IANA registry (then done in rfc2141bis) and focus on updates of service descriptions and the new services that have been identified in practice as being needed. Please discuss this constructive proposal for a way forward -- preferably by on-list comments. Since I'll be unable to go online for the rest of July, I'll evaluate the list discussion and comments sent in private communications subsequently ASAP, and then provide feedback and update the drafts accordingly; so please stay patient. Best regards, Alfred. From juha.hakala@helsinki.fi Fri Jul 6 02:18:36 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0D21F86BE for ; Fri, 6 Jul 2012 02:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.192 X-Spam-Level: X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIRixbH0eqm4 for ; Fri, 6 Jul 2012 02:18:35 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7123D21F86BD for ; Fri, 6 Jul 2012 02:18:34 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q669IlYG003095 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 6 Jul 2012 12:18:48 +0300 Message-ID: <4FF6AD77.2090803@helsinki.fi> Date: Fri, 06 Jul 2012 12:18:47 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: urn@ietf.org References: <201207050926.LAA08015@TR-Sys.de> In-Reply-To: <201207050926.LAA08015@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to general issues X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 09:18:36 -0000 Hello, Alfred has brought up several important issues in this message. I'll not respond to everything at once, but will discuss the general points, the way forward and the proposal separately. This message concentrates on the general issues. On 5.7.2012 12:26, Alfred wrote: > URN folks, > > thanks to all for reviving the discussion on the rfx2141bis and > rfc3406bis I-Ds. As the editor of both drafts, I try to sum up > below and provide a perspective for a way forward; I'll respond > individually in more detail ASAP (see endnote). > > > ** general ** > > Unfortunately, stakeholders of URN Namespaces for various reasons > seem to feel discouraged to participate in the on-list discussion, > which now has been majorized by few long-time "IETF professional" > contributors. Part of the frustration I observe also seems to be > based on the lack of constructive proposals on the list so far, > as replacement solutions for the options being voted against. There are not that many librarians, publishers etc. who are involved with standards work. And most of these standards activists concentrate on developing ISO standards. IETF as a whole, and the way in which it develops standards, is unfamiliar to book trade and libraries. So even if the URN system is vitally important for those organisations who use it, we have only a limited number of mainly technical people following the URNbis process. > > We should not forget that the prime target audience of these URN > core documents is the rather divers family of (present and) > prospective stakeholders of URN Namespaces, which frequently > have not been in contact with the IETF, but possibly with other > persistent ID schemes, _or_ which are working within the IETF, > but with a focus on a particular technology and mostly unaware > of relevant work for URNs. There are on the one hand technical people who write, implement and maintain URN resolvers (among other tools), and on the other hand people who use URNs to identify resources. The former are familiar with RFCs, and will look for technical information from them. The latter must be familiar with the functionality of the URN system in general level, and the local URN policy in the detailed level. They cannot find the latter from RFCs, and they should get former from other sources than RFCs. As an aside, there seems to be a misconception that developing a URN resolver is complicated. This is not the case; the resolver software used by the national library of Finland consists of 18 lines of Python code (including four blank lines). But we should be careful in not making the business of resolution too complex. > Hence, the goal of the "core URN documents" should be to give > concise guidance to _that_ audience, in order to help avoid to > have to explain the same context again and again individually > (as I have done in the past couple of years). I do not insist upon removal of the generic guidance information from URNbis documents (potential readers can skip the sections they don't need), but if we want e.g. librarians to read this information, it should be made available at (or linked to) places where librarians etc. go to find information about preservation of digital resources in general, such as http://www.digitalpreservation.gov/. > This IMO needs to include a bit of a "marketing" effort for the > URN framework against other, concurring identifier systems. Choosing a persistent identifier system is a decision one has to live with for a long time. IMHO it is a big responsibility to tell somebody that you should use this or that persistent identifier. Moreover, no matter what the experts say, the choice is often based on the availability of software package which allows one to start Handle / DOI / URN assignment easily, or mandates one of these systems (like e.g. DSpace requires Handles). To be honest, currently it really does not matter whether the persistent identifier is endorsed by IETF or not, or even whether the technical requirements such as URI Generic Syntax are followed. There is a major project which started assigning Handles in which the fragment identifier and the rest of the identifier string in Handle suffix are separated by "@" (@ was selected because Handle syntax has not reserved it; the fact that it is reserved in URI syntax did not matter). Given that the overall situation in PID assignment is a bit chaotic, it is important that after the revision of the URN system we can say that URNs follow strictly the requirements of e.g. RFC 3986, and that the RFCs which specify key features such as URN syntax are on standards track. Since no other PID system is a true Internet standard, this will give URN credibility compared to other PIDs. Of course, in order to gain more users, easy to use open source URN software package(s) are needed. > Recently, being able to point prospective applicants of > new URN Namespaces (from inside and outside of the IETF) to > the material in the present Introductions of the rfc2141bis > and rfc3406bis drafts has been very helpful in giving guidance > on technical/document/historical context; such material is > sought by prospective stakeholders in the core documents. True, and we will be even better off when this information is available in more accessible documents, and perhaps also in multiple languages. Juha > > Best regards, > Alfred. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From juha.hakala@helsinki.fi Fri Jul 6 05:31:27 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E064921F8707 for ; Fri, 6 Jul 2012 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, J_BACKHAIR_31=1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti45oEJwm5Fk for ; Fri, 6 Jul 2012 05:31:26 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id BCE7A21F86F8 for ; Fri, 6 Jul 2012 05:31:25 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q66CVdTF027990 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 6 Jul 2012 15:31:40 +0300 Message-ID: <4FF6DAAB.8090800@helsinki.fi> Date: Fri, 06 Jul 2012 15:31:39 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: urn@ietf.org References: <201207050926.LAA08015@TR-Sys.de> In-Reply-To: <201207050926.LAA08015@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 12:31:28 -0000 Hello, This is the second part of my comments. On 5.7.2012 12:26, Alfred � wrote: > URN folks, > > thanks to all for reviving the discussion on the rfx2141bis and > rfc3406bis I-Ds. As the editor of both drafts, I try to sum up > below and provide a perspective for a way forward; I'll respond > individually in more detail ASAP (see endnote). > > ** towards a way forward ** > > We face several general kinds of problems to deal with. The trick is to select and solve only those problems that the charter requires us to solve, and leave the rest for later WGs or individual contributions. Having said this, I need to add that there is not that much that we can definitely leave for later in this message. > One stems from the chartered restriction to not revise the > "strategical" RFCs laying the foundation of URNs and to presently > obstain from work on services/methods and details of URN resolution > and URN services. There seems to be consensus that some parts of > these RFCs are outdated by more than a decade of experience with > URNs. True. There are for instance many resolution services that are definitely relevant but which are not defined in RFC 2483. But we do not need to solve this problem now, and the charter does not have a mandate for that. I have been working on an individual contribution which will specify a novel way of establishing URN resolution services, but that work can / should wait until 2141bis and 3406bis have been completed. Since we aim our work towards bringing our documents > forward on the Standards Track, we cannot make Normative > references to past, Informational RFCs. So, as elaborated upon > in the URNbis chartering discussion, we need to incorporate > selected text from, e.g. RFC 1737, verbatim in order to remind > the readers (including prospective stakeholders of URN Namespaces) > of what we now deem still particularly valid and important for URNs. OK. > Likewise, experience shows that we need to provide a more precise > framework for the establishment of URN services for URN Namespaces, > in order to further a uniform style -- to the benefit of generic > URN handling applications. Creating the technical framework for establishment of URN resolution services has been one of the weaknesses of the URN effort. There is no widely used open source software package like the one that has existed for many years for the Handle system. And locally developed resolvers usually provide only the basic URN resolution services, such as mapping the URN to (single) URL. > Unlike for other URIs, URNs in general are dedicated to be media- > and technology-independent, as almost necessitated by the target > of long-term, global scope, uniqueness, and persistence (RFC 1737, > Section 2). I agree on technology independence, but media independence is a more complex issue. Many traditional identifier systems are media dependent. For instance, each manifestation of a book (hard back, paperback, PDF) must get its own ISBN. So any URN:ISBN will be forever tied to a single manifestation of the book. When the book in PDF is migrated to a more modern format, that updated manifestation shall receive a new ISBN. These two ISBNs / URN:ISBNs will be interlinked in metadata so the users can travel forward and backward in time, depending on their preferences. The national libraries are of course storing all the versions, so as to protect ourselves from mistakes made during migrations. There are also identifiers which relate to immaterial works and are therefore media dependent. ISTC (International Standard Text Code) is an example of this. URN:ISTC therefore fulfills the spirit of RFC 1737 fully. Those URNs will link to the metadata record which contains links to all the manifestations. However, the URN system as a whole is only functional when it combines the work level and manifestation level identifiers. > Since there are various services applicable to URNs, resolution > of a URN does not have the same media orientation properties like > it is common in a HTTP/HTML context. The objects/resources named > by URNs might be structured, complex, and inter-related with the > details perhaps evolving over time, whereas the abstract object > and its naming (as done by the assignement of {NID}:{NSS}) needs > to be stable. Based on what I said above, I cannot agree with this. In all those namespaces which belong to manifestation identifiers such as ISBN, resolution is very much media oriented but however stable. National libraries and archives will have users who, for the sake of authenticity, even after hundreds of years, still want the original version of the digital document. Naming of these documents, given the assignment policy of ISBN and other systems, is as stable as it gets. > Our effort has been driven by a major class of mass URN "customers", > the bibliographic community. That community has identified the > urgent need to identify in a uniform way, in the URN resolution > process, object/resource components and/or related resources. > The description in the first paragraph of Section 3.5 in RFC 3986 > has lead to a URN service/resolution implementation attempt based > on the usage of fragment identifiers, and that has been reflected > in the rfc2141bis draft since its beginning as an individual I-D. In fact there are two different approaches. Each namespace may have its own policy for identification of logical fragments which are not fragments in the URI syntax sense. For instance, both the entire book and its each chapter may receive ISBNs. When these chapters are published as individual files, resolving those URN:ISBNs to URLs is piece of cake. When the entire book is published as a single structured file, there will be one ISBN for the book. Then it is possible to use fragments to specify the beginning of each chapter. This is based on physical fragments in the URI syntax sense of the word. From the ISBN point of view, no new ISBNs have been assigned. From URN point of view, there is only single URN since fragment is not part of the NSS. In principle the chapters may receive ISBNs also in the second case. But using them as URN:ISBNs would not make much sense, since all these URN:ISBNs would resolve to the same resource. > > In the meantime, it has become clear that the subsequent text > in Section 3.5 of RFC 3986 is incompatible with the goals, since > it calls for URI users to strip the fragment identifier component > before forwarding a URI reference for resolution, and to apply > the fragment identifier, in a media-type dependent manner, to the > returned content. As I see it, section 3.5, or the way HTTP deals with the fragments, is not incompatible with the goals of the bibliographic community. We would not use fragments to actually identify anything, but to help the user to get into a certain location within the identified resource. This would be very helpful for e.g. citing purposes. In the bibliographic context, components might > be archived in different media items over time to maintain their > accessability, and they might be subject to diverse distribution > restrictions; so in general, it will be impossible or impractical > to return an all-encompassing response and allow the client to > select the required part. This applies to logical fragments, but it is not our intention to apply URI fragments to them. URI fragments will be applied to physical fragments of documents, to which they are applicable. An additional restriction of the use > of fragment identifiers is that, in practice, media types and/or > common browsers do not support to "pick a component" from the > returned resource, but represent the whole resource, pointing to > a particular spot therein, such maintain the user perception of > a "fragment identifier" essentially being used as a pointer to > a particular point in the returned media, not a particular part > of the resource. Yes, this is why fragment is not part of the NSS, and why, if you have a base urn:isbn and you attach 10 different fragments to it, you will still have just one URN, but you have access to 10 different places within that particular manifestation of a resource. And this is also why you should never use fragment in those URN namespaces where the identifier is not tied to particular manifestation of a resource or the identifier does not identify single documents. This means no fragments for ISCI (International Standard Collection Identifier) or ISSN (identifier for serials). The IETF has recently put emphasis on this > particular, strict media-type dependence of the fragment part > of URIs, and we need to accomodate that and established practice > in browsers. The relevant text portions in rfc2141bis and elsewhere need to be clarified. The most important thing is to say that the fragment is not part of the NSS, and draw conclusions from that. > > In order to avoid recurrence of this issue, explaining text on > fragment use with URNs IMO needs to be present in rfc2141bis, > _and_ we need to provide a uniform working scheme for the > identified requirements. > > > ** the proposal ** > > Study of RFCs and off-list conversations with folks from the > bibliographic community has lead to a model how these goals could > be achieved by a common-style usage of the URI part, > and I want to present this to the WG as a way forward for > discussion before going to work out the details in the next > version of the rfc2141bis and rfc3406bis I-Ds. Sorry - I am unwilling to put any fragment related data into query. > Let me explain the idea with a very hypothetical (intentionally > invalid) example: > > Say a book has been assigned the ISBN (ISBN-13) 987-65-4321-678-9. > Thus, per the rfc3187bis I-D, it gets assigned the URN, > urn:isbn:987-65-4321-678-9 This ISBN would belong to a particular manifestation of a book, say a PDF version, in its entirety. > > A resolution service might be able to provide the bibliographic > record of the book and point to reproductions of selected parts > of it, say > - an image of the front page (cover page), > - a text version of the table of contents, > - some rich text copy (e.g. HTML or PDF) of the foreword, > - the list of references included in the book > (e.g. in the form of a set of shortened bibligraphic records), > all of the above available for free, without restrictions to anyone; > and > - the Introduction section of the book (in PDF) > available to registered (authenticated and authorized) users > of a specific community only. I am afraid that the URN resolution service would not and will not be able do all of this. For the time being they are simple tools with only a limited supporting role. Resolution service may help the user to retrieve a bibliographic record describing the book, and those records nowadays often provide a link to the image of the book. Table of contents may be part of the bibliographic record, and the record may also contain links to Amazon and elsewhere where excerpts of the book are stored. Adjusting the resolution services and bibliographic information systems in such a way that the user could request various data elements one at the time may be technically possible, but libraries probably prefer to supply this information from bibliographic systems, and not to extend radically the role of the resolution services. > > Then, specific URI references to the above URN can direct its consumer > to steer the resolution process, using the fragment part of the URI > reference: > > urn:isbn:987-65-4321-678-9 > returns the metadata for the book (default); While no default behaviour has been specified, this would usually return the entire book. If the user wants just information about the book, asking for metadata (and you can have descriptive, administrative, and structural metadata) is a good start. > urn:isbn:987-65-4321-678-9?s=I2R&c=toc > returns the table of contents; > urn:isbn:987-65-4321-678-9?s=I2L&c=foreword > returns a URL for the foreword of the book; In some situations, the same effect can be achieved by > urn:isbn:987-65-4321-678-9#toc > takes the user to the beginning of the table of contents; > urn:isbn:987-65-4321-678-9#foreword > takes the user to the beginning of the the foreword. Suitable structural elements could be harvested from the source document, and the resolver could be made aware of them. If the resource is not structured in the URI syntax sense, or the wanted structural elements are missing, metadata in the library system may contain the toc and reveal the location of the foreword. Alas, maintaining these URLs (pointing to e.g. the publisher's web site) will be difficult in the long term. > urn:isbn:987-65-4321-678-9?s=I2Ns&c=reflist > returns a URI list (text/uri-list per RFC 2483) > with the URNs of the references included in the book; > urn:isbn:987-65-4321-678-9?s=I2L&c=sec.1 > returns a URL pointing to the Introduction (Section 1) > of the book, which can only be resolved by authorized users. Libraries use another mechanism (OpenURL) for dynamic linking which checks whether the users are authorized to use the resource. > This solution, in a nutshell, would consist of the following elements > for rfc2141bis and rfc3406bis: This is a rather large nutshell :-). > > o rfc2141bis specifies > - the forms-like syntax of the component in URN references, > as a sequence of keyword=value items separated by "&" chars; > I suggest that for simplicity both and should > be simple fixed tokens (or follow simple patterns), i.e. kind of > enumerated value protocol elements, and hence not subject to > internationalization > (s are case-insensitive, in the spirit of RFC 1737, > s should preferably be case-insensitive as well, but > namespace-specific considerations might dictate allowance for > case-sensitivity); Some of the URN resolution services may become complex. For instance, when a user asks for metadata about the resource, this metadata may come in many different formats, and the user may need to specify her preference. So the mechanism suggested here will be relevant in any case, with or without fragment functionality. > - the handling rules: single instance of items with a particular > only, semantics independent of order of the items, > items with unknown (or falsely repeated) are to be > ignored by the resolution service, "sensical" fallback in case > of unknown / unsupported / not applicable needed > (these rules will support easy introduction and future extension > of the repertoire supported by URN services); This information will also be relevant for people who develop resolver applications. > - a new IANA registry of "URN Resolution Query Tokens" with a > sub-registry fors to be used with URI references > to URNs -- either for general use or specific to particular > URN Namespaces --, which will be initialized with two entries > explained below; > - the "s" (Service) to indicate the label of the desired > URN resolution service; > - the "c" (component) to indicate the desire to obtain > information about a particular component of the object/resource > designated by the base URN; > - another sub-registry of the above new IANA registry for > s used for the "s" keyword, (i.e. the "service labels"), > which will be provisionally populated by the service identifiers > from RFC 2483 -- leaving details to a future rfc2483bis; We need this registry as well. At the moment services are carved in stone in RFC 2483, but during the 10+ years since it was written technology has changed, and there are many more services needed now. > - that supported "c=" values need to be specified per URN namespace. I am not sure if it is a good idea to do this, given that the list of services and service components will grow. But there must be a way with which a user can check from the resolver which services and service components it supports. > Further, rfc2141bis will indicate that future URN Namespace > registration documents (as per rfc3406bis) need to specify the > support of the above syntax by its resolution service(s), > supported/applicable services, the default service provided, > and the usage of "c=" (if applicable) and any other potential > keywords for that URN Namespace and supported service. Namespace registrations should make it clear if fragment usage is allowed. This is based on what is being identified. If the target is a single manifestation of a resource, fine. If the identified object can be anything, then common sense can be used. If the object can never be something to which URI fragments in the RFC 3986 sense can be applied, forget it. The registration can also list other services that may be supported. I don't know if we can say that some services must be supported. > Explanatory material related to the issues (described above) with > the use of identifiers as in some recent prototype URN > service implementations will stay in Appendices of rfc2141bis; > this includes the mention of the choices URN namespace designers > have for support of hierarchical (and cross-linked) resources: > - include component identifier in registered identifier, > making it a (perhaps distinguishable) part of the NSS; This will be a common approach for logical fragments. In many namespaces the component identifiers will be identical to identifiers assigned to whole documents, and - of course - always part of the NSS. > - support/use with "c=", so the NSS registry for the > namespace doesn't have to deal with the component information > (which will be added value by the resolution services); I am not sure - yet - how useful this might be. > - use (if media types returned for particular NID > are long-term stable and allow to support that). There will be namespaces and documents to which this functionality is very useful. > The proper use of will be emphasized in the main body > of rfc2141bis, with pointers to other specs, including the > work-in-progress RFC 4288bis from APPSAWG. I'll draft something to this effect. > o rfc3406bis specifies the details for the above scheme expected to > be specified in registration documents, including new entries in > the URN Namespace registration template for supported services > (per the "s" value IANA registry) and the usage and rules for > "c=" (if applicable) and any other keywords, including > possible IANA registration of new keywords. OK. > > o The definition of new service labels, and an update to the > existing definitions is left to future work on a rfc2483bis > document. The inofficial rfc2482bis pre-draft circulated > can be stripped of the definition of the URN service label > IANA registry (then done in rfc2141bis) and focus on updates > of service descriptions and the new services that have been > identified in practice as being needed. Once we have agreed that this is the way to go, I will modify the rfc2483bis accordingly. Best regards, Juha > > > Please discuss this constructive proposal for a way forward -- > preferably by on-list comments. > > Since I'll be unable to go online for the rest of July, I'll > evaluate the list discussion and comments sent in private > communications subsequently ASAP, and then provide feedback and > update the drafts accordingly; so please stay patient. > > > Best regards, > Alfred. > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From L.Svensson@dnb.de Tue Jul 10 07:10:39 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4068E21F8766 for ; Tue, 10 Jul 2012 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.949 X-Spam-Level: X-Spam-Status: No, score=-10.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k19RLQydBe+U for ; Tue, 10 Jul 2012 07:10:38 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB621F8763 for ; Tue, 10 Jul 2012 07:10:36 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 729FBD5D76 for ; Tue, 10 Jul 2012 16:11:03 +0200 (CEST) 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.01.0355.002; Tue, 10 Jul 2012 16:11:03 +0200 From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: More comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 Thread-Index: AQHNVLwoWLv9HIJPPEyM/6+kZZg0g5cX4t8AgAqpiSA= Date: Tue, 10 Jul 2012 14:11:02 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF24694BBA@dnbf-ex1.AD.DDB.DE> References: <6.2.5.6.2.20120627161749.08c30070@resistor.net> <4FF3501A.2000307@stpeter.im> In-Reply-To: <4FF3501A.2000307@stpeter.im> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [urn] More comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:10:39 -0000 All, I have some more comments on 3406bis: Introduction: "I.e., not all syntactically correct URN Namespaces (per the URN syntax definition) are valid URN Namespaces. A URN Namespace must have a recognized definition in order to be valid." Is it enough for a URN Namespace to have a recognized definition to be vali= d or does it have to be registered somewhere? If recognized is enough: reco= gnized by whom? Sec. 4.1: Experimental namespaces If we desire to register example as a NID, this whole section will probably= not be needed any more. As a corollary, sec 4.3 needs to change: "NIDs for Formal URN Namespaces MUST NOT have the forms indicated in the preceding two sections for the other two Namespace types. (The detailed formal rules are given below in Section 4.4.4.) Applicants, in concert with the IANA experts, should ensure that the sought NID strings are "proper" for the designated purpose, according to common sense (and applicable legal rules)." Proposed text (moving parts from 4.4.4 to 4.3): "NIDs for Formal URN Namespaces MUST adhere to the following constraints: - not be an already-registered NID; - not start with "urn-" (see Section 4.1 above); - not start with "X-" (see NOTE below); - not start with "xy-", where xy is any combination of 2 ASCII letters (see NOTE below); - not be equal to or start with "example" (see NOTE below); - be more than 2 characters long. NOTE: All two-letter combinations as well as two-letter combinations followed by "-" and any sequence of valid NID characters are reserved for potential future use as countrycode-based NIDs for eventual national registrations of URN Namespaces. The definition and scoping of rules for allocation of responsibility for such Namespaces is beyond the scope of this document. Further, to avoid confusion, "urn" is not allowed as an NID string; To allow neutral example URNs in code and documentation, NID strings starting with "example" are set aside for use in documentation; IANA has permanently reserved these string to prohibit assignment. Earlier versions of this RFC [RFC 2141] defined NID strings starting with "X-" as belonging to the class of experimental namespaces. In order to avoid confusion, the registration of NIDs starting with "X-" is prohibited." 4.4.4 IANA Considerations in Registration Documents "According to the general procurements for RFCs, URN Namespace definitions documents must include an "IANA Considerations" section (cf. BCP 26 [RFC5226]). That section has to indicate that the document includes a URN Namespace registration that is to be entered into the IANA registry of Formal URN Namespaces." This might not be correct if the registration request is for an informal na= mespace... Further, I suggest that constraints on NIDs are moved to 4.3. Suggested wor= ding of 4.4.4: "According to the general procurements for RFCs, URN Namespace definitions documents must include an "IANA Considerations" section (cf. BCP 26 [RFC5226]). That section has to indicate that the document includes a URN Namespace registration that is to be entered into the IANA registry of informal or formal URN Namespaces, respectively. Registration documents for formal URN Namespaces will provide a particular, unique, desired NID string, and this will be assigned by the Standards/Protocol Action of the IESG that approves the publication of the registration document as an RFC. RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII strings that are interpreted in a case-insensitive manner, but the NID string SHALL be registered in the capitalization form preferred by the registrant. The proposed NID string MUST conform with the syntax rule in Section 2.1 of RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to constraints=20 specified in sec 4.3, above. Applicants and the IANA experts have to ensure that the sought NID strings are suitable and proper for the designated purpose and not misleading, according to common sense and applicable legal rules. The IETF Review process gives interested parties the opportunity to rise concerns if they want to challenge proposed strings; the final approval decision still remains with the IESG. Registrations may be revised by updating the RFC through standard IETF RFC update processes. In any case, a revised document, in the form of a new Internet-Draft, must be published, and the proposed updated template must be circulated on the urn-nid discussion list, allowing for a four-week review period before pursuing RFC publication of the new document." Thanks and all the best, Lars ***Lesen. H=F6ren. Wissen. 100 Jahre Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. A century of the German National Libr= ary*** --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de http://www.dnb.de/100jahre From leslie@thinkingcat.com Wed Jul 11 18:17:29 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FFD11E816F for ; Wed, 11 Jul 2012 18:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO4mmKL-g1IL for ; Wed, 11 Jul 2012 18:17:28 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8B811E8161 for ; Wed, 11 Jul 2012 18:17:27 -0700 (PDT) Received: from Macintosh.local ([::ffff:142.167.233.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 11 Jul 2012 21:17:57 -0400 id 015D8170.4FFE25C5.000017E5 Message-ID: <4FFE25C6.4020303@thinkingcat.com> Date: Wed, 11 Jul 2012 21:17:58 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF34B61.4050903@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] listed authors X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 01:17:29 -0000 Hi, In the general case, indeed, there are many potential complexities. In these particular cases, most of them don't apply. The "new" documents are largely the same as the old ones: they are not rewritten from the ground up. Instead, they have been updated to reflect particular points this group is discussing as changes to the spec -- not all of which may be kept for this WG's final version of the document. I, as one implicated author, and as chair of the original WG that produced these documents, would indeed find it very disrespectful to fail to acknowledge that properly in the updated documents. And, I don't think it's reasonable to suggest that the IETF should support a WG rewriting that holus bolus as part of its process. I think it's quite reasonable to list the current folks working on the documents as authors if they are authoring. I think it's quite reasonable to see if the original authors are willing and able to continue to be listed (and responsive, eg during AUTH48) and responsible for document content. I'm happy to help try to reach the various authors at current addresses. (Since they've already been asking _me_ about the outcome of this issue...). Leslie. On 7/4/12 9:47 AM, Barry Leiba wrote: >> I have mentioned this in the past, and I'll mention it again: I think >> the new bis specs need to include the authors of the original documents, >> with the new authors shown as editors. So, for instance, >> draft-ietf-urnbis-2141bis would have the following in the header: >> >> A. Hoenes, Ed. >> R. Moats >> >> Simply ripping the old authors out of the specs is disrespectful. > > Well, yes and no -- it's not that simple. > > First, I agree that the complete removal of the name of someone who > contributed substantially to a document in any phase of its life > (including a prior edition) would, indeed, be disrespectful... and > unethical. > > But: > > 1. 2141bis (for example) is a product of the urnbis working group, and > the chairs have complete control over who is listed at the top of the > document. They can remove someone's name for any defensible reason > (subject, of course, to appeal), including that the person is no > longer participating in the document's development. > > 2. Everyone who appears at the top of the document has to be reachable > and responsive during AUTH48. An AD can override that, but we prefer > to avoid that and to list only those who we *do* expect to handle the > AUTH48 process promptly. > > 3. An "Authors" section can and should be added to recognize the > contributions of those who are or were authors of some version of the > document, but who are no longer listed at the top. This is where we > can give due respect to a former author who is no longer active. > > Of course, as Juha says, it would be reasonable to ask the authors of > prior versions how they would like to be recognized (and, I'll add, > whether they will be available to review the final version and sign > off during AUTH48). That can certainly be input to the chairs' > decision. And anyway, if contacting a former author might bring more > experienced eyes on the document and get more reviews and input, > that's a good thing. If we specifically think a former author will > disapprove of where we've gone, that is NOT a reason to exclude him... > in fact, it's that much more of a reason to get the input for > consideration. > > Also, in this case, we have the odd situation that one of the chairs > is far more active as a document editor than is usual, leaving it > solely to the other chair to make these decisions. > > Barry > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From L.Svensson@dnb.de Fri Jul 13 02:49:28 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39EA21F85BB for ; Fri, 13 Jul 2012 02:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifub3pQmaZqs for ; Fri, 13 Jul 2012 02:49:27 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9906D21F853A for ; Fri, 13 Jul 2012 02:49:26 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 66540D5B4E; Fri, 13 Jul 2012 11:50:00 +0200 (CEST) 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.01.0355.002; Fri, 13 Jul 2012 11:50:00 +0200 From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" Thread-Topic: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal Thread-Index: AQHNW3NQHoiszHIz+k+LfQ+cidsNyJcm/ysQ Date: Fri, 13 Jul 2012 09:49:59 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF24697EA4@dnbf-ex1.AD.DDB.DE> References: <201207050926.LAA08015@TR-Sys.de> <4FF6DAAB.8090800@helsinki.fi> In-Reply-To: <4FF6DAAB.8090800@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: =?utf-8?B?S2V0dCwgSsO8cmdlbg==?= , "Geipel, Markus" Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 09:49:29 -0000 SnVoYSwgYWxsLA0KDQpNdWNoIG9mIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gLS0gcGFydGljdWxh cmx5IHRoZSB1c2Ugb2YgZnJhZ21lbnRzIC0tIHJldm9sdmVzIGFyb3VuZCB0aGUgY29uc2VxdWVu Y2VzIGZvciB1cm46aXNibiAoUkZDIDMxODdiaXMpLiBJbiBteSBvcGluaW9uLCB0aGF0IGRpc2N1 c3Npb24gcHJldmVudHMgdXMgZnJvbSBtYWtpbmcgcHJvZ3Jlc3MgaW4gb3RoZXIgYXJlYXMuIElu IHNob3J0LCBJIGNvbnNpZGVyIHRoZSB1c2Ugb2YgSVNCTnMgdG8gY3JlYXRlIFVSTnMgZmxhd2Vk IGFuZCBzdWdnZXN0IHRoYXQgd2UgZm9yIHRoZSB0aW1lIGJlaW5nIGlnbm9yZSByZXF1aXJlbWVu dHMgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdXJuOmlzYm4uDQoNCkxvbmdlciB2ZXJzaW9uOg0K DQpBcyBhbiBhbnN3ZXIgdG8gQWxmcmVkLCBKdWhhIHdyb3RlOg0KPiA+IFVubGlrZSBmb3Igb3Ro ZXIgVVJJcywgVVJOcyBpbiBnZW5lcmFsIGFyZSBkZWRpY2F0ZWQgdG8gYmUgbWVkaWEtIA0KPiA+ IGFuZCB0ZWNobm9sb2d5LWluZGVwZW5kZW50LCBhcyBhbG1vc3QgbmVjZXNzaXRhdGVkIGJ5IHRo ZSB0YXJnZXQgb2YgDQo+ID4gbG9uZy10ZXJtLCBnbG9iYWwgc2NvcGUsIHVuaXF1ZW5lc3MsIGFu ZCBwZXJzaXN0ZW5jZSAoUkZDIDE3MzcsIA0KPiA+IFNlY3Rpb24gMikuDQo+IA0KPiBJIGFncmVl IG9uIHRlY2hub2xvZ3kgaW5kZXBlbmRlbmNlLCBidXQgbWVkaWEgaW5kZXBlbmRlbmNlIGlzIGEg bW9yZSANCj4gY29tcGxleCBpc3N1ZS4gTWFueSB0cmFkaXRpb25hbCBpZGVudGlmaWVyIHN5c3Rl bXMgYXJlIG1lZGlhIGRlcGVuZGVudC4NCj4gRm9yIGluc3RhbmNlLCBlYWNoIG1hbmlmZXN0YXRp b24gb2YgYSBib29rIChoYXJkIGJhY2ssIHBhcGVyYmFjaywgUERGKSANCj4gbXVzdCBnZXQgaXRz IG93biBJU0JOLiBTbyBhbnkgVVJOOklTQk4gd2lsbCBiZSBmb3JldmVyIHRpZWQgdG8gYSANCj4g c2luZ2xlIG1hbmlmZXN0YXRpb24gb2YgdGhlIGJvb2suIFdoZW4gdGhlIGJvb2sgaW4gUERGIGlz IG1pZ3JhdGVkIHRvIA0KPiBhIG1vcmUgbW9kZXJuIGZvcm1hdCwgdGhhdCB1cGRhdGVkIG1hbmlm ZXN0YXRpb24gc2hhbGwgcmVjZWl2ZSBhIG5ldyBJU0JOLg0KPiBUaGVzZSB0d28gSVNCTnMgLyBV Uk46SVNCTnMgd2lsbCBiZSBpbnRlcmxpbmtlZCBpbiBtZXRhZGF0YSBzbyB0aGUgDQo+IHVzZXJz IGNhbiB0cmF2ZWwgZm9yd2FyZCBhbmQgYmFja3dhcmQgaW4gdGltZSwgZGVwZW5kaW5nIG9uIHRo ZWlyIA0KPiBwcmVmZXJlbmNlcy4NCg0KVGhpcyBzdGF0ZW1lbnQgaXMgZGVwZW5kZW50IG9uIHR3 byBheGlvbXMvYXNzdW1wdGlvbnMgc3BlY2lmaWVkIGluIFVSTiBkb2N1bWVudHM6DQoNCgkoMSkJ Ikdsb2JhbCB1bmlxdWVuZXNzOiBUaGUgc2FtZSBVUk4gd2lsbCBuZXZlciBiZSBhc3NpZ25lZCB0 byB0d28gZGlmZmVyZW50DQoJCXJlc291cmNlcy4iIChSRkMgMjE0MWJpcy0wMiBzZWMgMS4yKQ0K DQoJKDIpCSJBc3N1bXB0aW9uICMxOiAgQXNzaWdubWVudCBvZiBhIFVSTiBpcyBhIG1hbmFnZWQg cHJvY2Vzcy7igJ0gKFJGQyAzNDA2YmlzLTAyKQ0KCQlUbyBtZSB0aGlzIG1lYW5zIHRoYXQgaWYg d2UgY3JlYXRlIChhc3NpZ24pIFVSTnMgbWVyZWx5IGJ5IHByZWZpeGluZyBhbg0KCQlleGlzdGlu ZyBpZGVudGlmaWVyIOKAkyBhcyBieSBwdXR0aW5nIOKAnHVybjppc3NuOuKAnSBpbiBmcm9udCBv ZiBhbiBleGlzdGluZyBJU1NODQoJCeKAkyB0aGUgcHJvY2VzcyBhc3NpZ25pbmcgdGhlIGFscmVh ZHkgZXhpc3RpbmcgaWRlbnRpZmllciBuZWVkcyB0byBiZSBtYW5hZ2VkDQoJCWFzIHdlbGwuDQoN Ck15IHRha2UgaXMgdGhhdCB1cm46aXNibiBkb2VzIG5vdCBhZGhlcmUgdG8gYW55IG9mIHRob3Nl IGNyaXRlcmlhLCBhdCBsZWFzdCBub3QgZ2xvYmFsbHkuDQoxKQlVbmlxdWVuZXNzOiBBbiBhbmFs eXNpcyBvZiBJU0JOcyBpbiB0aGUgY2F0YWxvZ3VlIG9mIHRoZSBEZXV0c2NoZSBOYXRpb25hbGJp Ymxpb3RoZWsgKEdlcm1hbiBOYXRpb25hbCBMaWJyYXJ5LCBETkIpIHJldmVhbGVkIG1vcmUgdGhh biAyMDAsMDAwIElTQk5zIHdoZXJlIG1vcmUgdGhhbiBvbmUgYmlibGlvZ3JhcGhpYyByZWNvcmQg c2hhcmVkIHRoZSBzYW1lIElTQk4uIFNvbWUgb2YgdGhvc2UgaW5zdGFuY2VzIGFyZSBPSyBhY2Nv cmRpbmcgdG8gdGhlIElTQk4gTWFudWFsIFtJU0JOIE1hbnVhbF0sIHdoZXJlYnkgaXQgbXVzdCBi ZSBub3RlZCwgdGhhdCAtLSBmb3Igc29tZW9uZSB1c2VkIHRvIHRoZSBsYW5ndWFnZSBvZiBSRkMg MjExOSAtLSB0aGUgSVNCTiBNYW51YWwncyBsYW5ndWFnZSBpcyBzb21ld2hhdCBmdXp6eSwgdXNp bmcgYSBtaXh0dXJlIG9mIHNoYWxsLCBzaG91bGQsIG11c3QgZXRjIHdoZXJlIGFuIElFVEYgZG9j dW1lbnQgd291bGQgdXNlIE1VU1QuIE5vbmV0aGVsZXNzLCBhbiBhcHBsaWNhdGlvbiBidWlsZGlu ZyBvbiB0aGUgdW5pcXVlbmVzcyBvZiB1cm46aXNibiB3b3VsZCB0aGVuIGVudGFpbCB0aGF0IGFs bCByZWNvcmRzIGhhdmluZyB0aGUgc2FtZSBJU0JOIGFyZSB0aGUgc2FtZSByZXNvdXJjZSwgd2hp Y2ggaXMgbm90IHRydWUuDQoyKQlNYW5hZ2VkIHByb2Nlc3M6IFRoZSBhc3NpZ25tZW50IG9mIElT Qk5zIHRvIGluZGl2aWR1YWwgcHVibGljYXRpb25zIGlzIGluIG1hbnkgKG1vc3Q/KSBqdXJpc2Rp Y3Rpb25zIHNwZWNpZmllZCBieSB0aGUgSVNCTiBNYW51YWwgW0lTQk4gTWFudWFsXSBidXQgZGVs ZWdhdGVkIHRvIHRoZSBwdWJsaXNoZXIuIEEgcHVibGlzaGVyIHdpc2hpbmcgdG8gdXNlIElTQk5z IHRvIGlkZW50aWZ5IGhpcyBwdWJsaWNhdGlvbnMgYnV5cyBhIG51bWJlciByYW5nZSBmcm9tIGEg bmF0aW9uYWwgSVNCTiBjZW50cmUuIEluIG1hbnkgY2FzZXMsIHRoZSBuYXRpb25hbCBjZW50cmUg aGFzIG5vIGNvbnRyb2wgb3ZlciBob3cgdGhlIHB1Ymxpc2hlciB1c2VzIHRoZSBhc3NpZ25lZCBu dW1iZXIgcmFuZ2UgYW5kIGlmIGhlICh3aWxsaW5nbHkgb3Igbm90KSBhc3NpZ25zIHRoZSBzYW1l IElTQk4gbW9yZSB0aGFuIG9uY2UuIEEgbmF0aW9uYWwgbGlicmFyeSBfY291bGRfIGJlIGEgY29u dHJvbCBwb2ludCwgYnV0IHRoYXQgYXNzdW1lcyB0aGF0IGEpIGxlZ2FsIGRlcG9zaXQgaXMgaW4g cGxhY2UsIHNvIHRoYXQgdGhlIG5hdGlvbmFsIGxpYnJhcnkgY2FuIGJlIGNlcnRhaW4gdGhhdCBf YWxsXyBwdWJsaWNhdGlvbnMgY2FuIGJlIGNoZWNrZWQgYW5kIGIpIHRoYXQgdGhlIG5hdGlvbmFs IGxpYnJhcnkgaXMgaW4gYSBwb3NpdGlvbiB0byBjaGVjayBJU0JOcyBfYmVmb3JlXyB0aGUgYm9v ayBpcyBwdWJsaXNoZWQuIE5hdGlvbmFsIGxpYnJhcmllcyBhcmUgZ2VuZXJhbGx5IGRvY3VtZW50 YXRpb24gY2VudHJlcyAoaS4gZS4gd2UgZG9jdW1lbnQgd2hhdCBoYXMgYmVlbiBwdWJsaXNoZWQp IHNvIHdoZW4gYSBwdWJsaWNhdGlvbiBhcnJpdmVzIGl0IGlzIG9mdGVuIHRvbyBsYXRlIHRvIGNo YW5nZSBhbiBpbXByb3BlciBJU0JOIGFueXdheS4uLg0KDQpUaGUgYWJvdmUgc3RhdGVtZW50cyBh Ym91dCB1bmlxdWVuZXNzIGFyZSBiYXNlZCBvbiBhbiBhZCBob2MtYW5hbHlzaXMgb2YgZGF0YSBm cm9tIHRoZSBETkIuIFRoZSBmaXJzdCBzdGVwIHdhcyB0byBjb2xsZWN0IGFsbCBpbnRlcm5hbCBy ZWNvcmQgaWRlbnRpZmllcnMgc2hhcmluZyBhIGNvbW1vbiBJU0JOIGFuZCB0byBvdXRwdXQgYSBs aXN0IG9mIElTQk5zIHBvaW50aW5nIHRvIG1vcmUgdGhhbiBvbmUgaW50ZXJuYWwgaWRlbnRpZmll ci4gVGhlIHNlY29uZCBzdGVwIHdhcyB0byBtYW51YWxseSBldmFsdWF0ZSBhIHJhbmRvbWx5IGNo b3NlbiBzZXQgb2YgaWRlbnRpZmllcnMgYW5kIHNlZSBpZiB0aGUgaWRlbnRpZmllZCByZWNvcmRz IGFjdHVhbGx5IGFyZSBkaWZmZXJlbnQgb3Igbm90LiBJIGNvdWxkIGlkZW50aWZ5IChhdCBsZWFz dCkgZml2ZSBkaWZmZXJlbnQgY2FzZXM6DQoxKQlUaGUgcHVibGlzaGVyIGhhcyByZS11c2VkIGFu IElTQk4gZm9yIHR3byBlbnRpcmVseSBkaWZmZXJlbnQgcHVibGljYXRpb25zLiBFeGFtcGxlOiB1 cm46aXNibjozLTMzMi0wMDA3OS05IHdvdWxkIGlkZW50aWZ5IFsxXSBhbmQgWzJdLiBUaGlzIHZp b2xhdGVzIDUuMSBvZiB0aGUgSVNCTiBNYW51YWwgW0lTQk4gTWFudWFsXQ0KMikJVGhlIHB1Ymxp c2hlciBoYXMgcmUtdXNlZCBhbiBJU0JOIGZvciB0aGUgc2FtZSBwdWJsaWNhdGlvbiBpbiB0d28g ZGlmZmVyZW50IGZvcm1hdHMgKGUuIGcuIHByaW50IGFuZCBlbGVjdHJvbmljKS4gRXhhbXBsZTog dXJuOmlzYm46My04MjcyLTY5ODYtNSB3b3VsZCBpZGVudGlmeSBbM10gYW5kIFs0XS4gVGhpcyB2 aW9sYXRlcyA1LjQgb2YgdGhlIElTQk4gTWFudWFsLg0KMykJVGhlIHB1Ymxpc2hlciBoYXMgdXNl ZCB0aGUgc2FtZSBJU0JOIGZvciB0d28gZWRpdGlvbnMgb2YgYSBwdWJsaWNhdGlvbiwgd2hlcmUg dGhlcmUgaGFzIGJlZW4gbm8gY2hhbmdlIG9mIGNvbnRlbnQgKHVuY2hhbmdlZCByZXByaW50cyku IEV4YW1wbGU6IHVybjppc2JuOjMtMTAtMDQ4MTk4LTQgd291bGQgaWRlbnRpZnkgWzVdIGFuZCBb Nl0uIFRoaXMgaXMgT0sgYWNjb3JkaW5nIHRvIDUuMiBvZiB0aGUgSVNCTiBNYW51YWwuDQo0KQlU aGUgcHVibGlzaGVyIGhhcyB1c2VkIHRoZSBzYW1lIElTQk4gZm9yIHR3byBlZGl0aW9ucyBvZiBh IHB1YmxpY2F0aW9uIHdoZXJlIHRoZXJlIGhhcyBiZWVuIGEgKHNpZ25pZmljYW50KSBjaGFuZ2Ug aW4gdGhlIGNvbnRlbnQgKGF1Z21lbnRlZCBvciByZXZpc2VkIHJlcHJpbnRzKS4gRXhhbXBsZTog dXJuOmlzYm46My05MjE4ODUtMzAtMiB3b3VsZCBpZGVudGlmeSBbN10gYW5kIFs4XS4gVGhpcyB2 aW9sYXRlcyA1LjIgb2YgdGhlIElTQk4gTWFudWFsLg0KNSkJVGhlIHB1Ymxpc2hlciBoYXMgYXNz aWduZWQgYW4gSVNCTiB0byBhIG1lZGlhIGJ1bmRsZSAoZS4gZy4gYSBib29rIHdpdGggYW4gYWNj b21wYW55aW5nIENEIG9yIGEgY29sbGVjdGlvbiBvZiBib29rcyBzb2xkIGFzIGEgYnVuZGxlLCBz dWNoIGFzIHRoZSBjb21wbGV0ZSBXb3JrcyBvZiBXaWxsaWFtIFNoYWtlc3BlYXJlKS4gRXhhbXBs ZXM6IHVybjppc2JuOjk3OC0zLTYwOS02MjM5NC04IHdvdWxkIGlkZW50aWZ5IHRoZSBtZWRpYSBi dW5kbGUgWzldIGNvbnNpc3Rpbmcgb2YgWzEwXSBhbmQgWzExXSAoYSBib29rIHdpdGggYSBDRC1S T00pLiBUaGlzIGlzIE9LIGFjY29yZGluZyB0byA1LjYgb2YgdGhlIElTQk4gTWFudWFsLg0KDQpB IG1vcmUgdGhvcm91Z2ggZXZhbHVhdGlvbiB3aWxsIHByb3ZpZGUgZGF0YSBvbiB0aGUgcmVsYXRp dmUgZnJlcXVlbmNpZXMgb2YgdGhvc2UgZm91ciBjYXNlcyBhbmQgcG9zc2libHkgaWRlbnRpZnkg ZnVydGhlciBvbmVzLiBBbmQgeWVzLCB0aGUgZGF0YSBpbmRpY2F0ZXMgdGhhdCBzb21lIHB1Ymxp c2hlcnMgYXJlIG1vcmUgbm90b3Jpb3VzIHRoYW4gb3RoZXJzLi4uDQoNClNvIHdoYXQgZG9lcyB0 aGlzIG1lYW4/DQoxKQlXZSBzaG91bGQgc3RvcCB1c2luZyB1cm46aXNibnMgYXMgZ2xvYmFsbHkg dW5pcXVlIGlkZW50aWZpZXJzLCBiZWNhdXNlIHRoZXkgYXJlbuKAmXQuIFRoZSBvbmx5IHN0YXRl bWVudCB3ZSBjYW4gbWFrZSBpcyB0aGF0IHVybjppc2JuOnh4eHggaWRlbnRpZmllcyB3aGF0ZXZl ciB0aGUgb3duZXIgb2YgeHh4eCBzYXlzIGl0IGlkZW50aWZpZXMsIHdoaWNoIG1pZ2h0IG5vdCBi ZSB1bmlxdWVseSBkZXRlcm1pbmVkLiBUaGVyZSBpcyBubyB3YXkgdGhlIHVybiBjb21tdW5pdHks IHRoZSBJRVRGIG9yIGFueSBvdGhlciBhZ2VuY3kgY2FuIGdsb2JhbGx5IGNvbnRyb2wgSVNCTiBh c3NpZ25tZW50IGFuZCBtdWNoIGxlc3MgZW5mb3JjZSB0aGUgcnVsZXMgbGFpZCBkb3duIGluIHRo ZSBJU0JOIE1hbnVhbCBbSVNCTiBNYW51YWxdLiBJZiB5b3UgY2Fubm90IGNvbnRyb2wgdW5pcXVl bmVzcywgeW91IHNob3VsZCBub3QgcmVndWxhdGUgaXQgKGFuZCBtdWNoIGxlc3MgeW91IHNob3Vs ZCBidWlsZCBhcHBsaWNhdGlvbnMgdGhhdCBkZXBlbmQgb24gaXQpLg0KMikJSSBwcm9wb3NlIHRo YXQgd2UgZGVwcmVjYXRlIFJGQyAzMTg3IGFuZCBjZWFzZSB3b3JrIG9uIDMxODdiaXMsIGF0IGxl YXN0IHVudGlsIHRoZSBxdWVzdGlvbnMgb2YgdW5pcXVlbmVzcyBhbmQgcHJvY2VzcyBtYW5hZ2Vt ZW50IGhhdmUgYmVlbiBjbGFyaWZpZWQuIFRoZSBwcm9jZXNzIHF1ZXN0aW9uIHJlcXVpcmVzIGNs b3NlIGNvLW9wZXJhdGlvbiB3aXRoIHRoZSBJbnRlcm5hdGlvbmFsIElTQk4gQWdlbmN5ICh3aGlj aCBKdWhhIGRvZXMgYW55d2F5LCBhcyBmYXIgYXMgSSBrbm93KS4gQWx0ZXJuYXRpdmVseSwgUkZD IDMxODdiaXMgY2FuIHN0YXRlIHRoYXQgdGhlIHVzZSBvZiB1cm46aXNibiBpcyByZXN0cmljdGVk IHRvIGNlcnRhaW4gcmVnaXN0cmF0aW9uIGdyb3VwIGVsZW1lbnRzIChlLiBnLiA5NTEgYW5kIDk1 MiBzaW5jZSBpdCBzZWVtcyB0byB3b3JrIGluIEZpbmxhbmQpLCBidXQgSSBkb3VidCB0aGF0IHRo YXQgaXMgZmVhc2libGUuDQozKQlXaGVuIGRpc2N1c3NpbmcgdGhlIHVzZSBvZiBmcmFnbWVudCBp ZGVudGlmaWVycyBpbiBSRkMgMjE0MWJpcywgd2Ugc2hvdWxkIGlnbm9yZSBwb3RlbnRpYWwgdXNl IGNhc2VzIHN0ZW1taW5nIGZyb20gdGhlIHVzZSBvZiB1cm46aXNibi4NCg0KQWxsIHRoZSBiZXN0 LA0KDQpMYXJzDQoNClsxXSBodHRwOi8vZC1uYi5pbmZvLzg3MDY4NzE1OA0KWzJdIGh0dHA6Ly9k LW5iLmluZm8vODgxMjIxMTEyDQpbM10gaHR0cDovL2QtbmIuaW5mby8xMDE1NzE2Njk1DQpbNF0g aHR0cDovL2QtbmIuaW5mby85NzY4MTgwMTkNCls1XSBodHRwOi8vZC1uYi5pbmZvLzk0NjI4MTU5 OQ0KWzZdIGh0dHA6Ly9kLW5iLmluZm8vODcwMzc5MTE5DQpbN10gaHR0cDovL2QtbmIuaW5mby84 MDAyMjg0NjQNCls4XSBodHRwOi8vZC1uYi5pbmZvLzgxMDQzMzkyMw0KWzldIGh0dHA6Ly9kLW5i LmluZm8vOTg4NDk1NDMwDQpbMTBdIGh0dHA6Ly9kLW5iLmluZm8vOTg2NDc4OTcwDQpbMTFdIGh0 dHA6Ly9kLW5iLmluZm8vOTg4NDk1NTg5DQpbSVNCTiBNYW51YWxdIElTQk4gVXNlcidzIE1hbnVh bC4gSW50ZXJuYXRpb25hbCBFZGl0aW9uLiBTaXh0aCBFZGl0aW9uLiBMb25kb24gMjAxMi4gaHR0 cDovL3d3dy5pc2JuLWludGVybmF0aW9uYWwub3JnL3BhZ2VzL21lZGlhL1VzZXJtYW51YWxzL0lT Qk4lMjBNYW51YWwlMjAyMDEyJTIwLWNvcnIucGRmICAgDQoNCioqKkxlc2VuLiBIw7ZyZW4uIFdp c3Nlbi4gMTAwIEphaHJlIERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayoqKiAqKipSZWFkaW5n LiBMaXN0ZW5pbmcuIFVuZGVyc3RhbmRpbmcuIEEgY2VudHVyeSBvZiB0aGUgR2VybWFuIE5hdGlv bmFsIExpYnJhcnkqKioNCg0KLS0NCkRyLiBMYXJzIEcuIFN2ZW5zc29uDQpEZXV0c2NoZSBOYXRp b25hbGJpYmxpb3RoZWsgLyBJbmZvcm1hdGlvbnN0ZWNobmlrIGh0dHA6Ly93d3cuZG5iLmRlLyBs LnN2ZW5zc29uQGRuYi5kZSBodHRwOi8vd3d3LmRuYi5kZS8xMDBqYWhyZQ0KDQo= From L.Svensson@dnb.de Fri Jul 13 08:43:40 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA3E21F87AA for ; Fri, 13 Jul 2012 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.682 X-Spam-Level: X-Spam-Status: No, score=-9.682 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBupJqR7R8Wb for ; Fri, 13 Jul 2012 08:43:33 -0700 (PDT) Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id D254E21F8513 for ; Fri, 13 Jul 2012 08:43:32 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 7F172D5F28; Fri, 13 Jul 2012 17:44:04 +0200 (CEST) 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.01.0355.002; Fri, 13 Jul 2012 17:44:04 +0200 From: "Svensson, Lars" To: Juha Hakala , "urn@ietf.org" Thread-Topic: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal Thread-Index: AQHNW3NQHoiszHIz+k+LfQ+cidsNyJcnVkKg Date: Fri, 13 Jul 2012 15:44:01 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF2469815D@dnbf-ex1.AD.DDB.DE> References: <201207050926.LAA08015@TR-Sys.de> <4FF6DAAB.8090800@helsinki.fi> In-Reply-To: <4FF6DAAB.8090800@helsinki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:43:40 -0000 SnVoYSwgYWxsLA0KDQpPbiBKdWx5IDYsIEp1aGEgd3JvdGU6DQoNCj4gVGhpcyBpcyB0aGUgc2Vj b25kIHBhcnQgb2YgbXkgY29tbWVudHMuDQoNCkFuZCBvZiBteSBjb21tZW50cywgdG9vLiBUaGV5 IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgb2ZmLXB1dHRpbmcsIGJ1dCBzaW1wbHkgYW4gYXR0ZW1w dCB0byBuYWlsIGRvd24gcHJvYmxlbXMgc28gdGhhdCB3ZSBjYW4gbW92ZSBmb3J3YXJkLg0KIA0K PiBPbiA1LjcuMjAxMiAxMjoyNiwgQWxmcmVkICAgd3JvdGU6DQoNClsuLi5dDQo+ID4gT25lIHN0 ZW1zIGZyb20gdGhlIGNoYXJ0ZXJlZCByZXN0cmljdGlvbiB0byBub3QgcmV2aXNlIHRoZQ0KPiA+ ICJzdHJhdGVnaWNhbCIgUkZDcyBsYXlpbmcgdGhlIGZvdW5kYXRpb24gb2YgVVJOcyBhbmQgdG8g cHJlc2VudGx5DQo+ID4gb2JzdGFpbiBmcm9tIHdvcmsgb24gc2VydmljZXMvbWV0aG9kcyBhbmQg ZGV0YWlscyBvZiBVUk4gcmVzb2x1dGlvbg0KPiA+IGFuZCBVUk4gc2VydmljZXMuICBUaGVyZSBz ZWVtcyB0byBiZSBjb25zZW5zdXMgdGhhdCBzb21lIHBhcnRzIG9mDQo+ID4gdGhlc2UgUkZDcyBh cmUgb3V0ZGF0ZWQgYnkgbW9yZSB0aGFuIGEgZGVjYWRlIG9mIGV4cGVyaWVuY2Ugd2l0aA0KPiBV Uk5zLg0KPiANCj4gVHJ1ZS4gVGhlcmUgYXJlIGZvciBpbnN0YW5jZSBtYW55IHJlc29sdXRpb24g c2VydmljZXMgdGhhdCBhcmUNCj4gZGVmaW5pdGVseSByZWxldmFudCBidXQgd2hpY2ggYXJlIG5v dCBkZWZpbmVkIGluIFJGQyAyNDgzLg0KDQpZZXMsIGFuZCBBbGZyZWQgZ2l2ZXMgdXMgYSB2ZXJ5 IG5pY2Ugc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgUkZDIDI0ODNiaXMgYmVsb3cuDQoNClsuLi5d DQo+ID4gU2luY2Ugd2UgYWltIG91ciB3b3JrIHRvd2FyZHMgYnJpbmdpbmcgb3VyIGRvY3VtZW50 cw0KPiA+IGZvcndhcmQgb24gdGhlIFN0YW5kYXJkcyBUcmFjaywgd2UgY2Fubm90IG1ha2UgTm9y bWF0aXZlIHJlZmVyZW5jZXMNCj4gdG8NCj4gPiBwYXN0LCBJbmZvcm1hdGlvbmFsIFJGQ3MuICBT bywgYXMgZWxhYm9yYXRlZCB1cG9uIGluIHRoZSBVUk5iaXMNCj4gPiBjaGFydGVyaW5nIGRpc2N1 c3Npb24sIHdlIG5lZWQgdG8gaW5jb3Jwb3JhdGUgc2VsZWN0ZWQgdGV4dCBmcm9tLA0KPiBlLmcu DQo+ID4gUkZDIDE3MzcsIHZlcmJhdGltIGluIG9yZGVyIHRvIHJlbWluZCB0aGUgcmVhZGVycyAo aW5jbHVkaW5nDQo+ID4gcHJvc3BlY3RpdmUgc3Rha2Vob2xkZXJzIG9mIFVSTiBOYW1lc3BhY2Vz KSBvZiB3aGF0IHdlIG5vdyBkZWVtIHN0aWxsDQo+ID4gcGFydGljdWxhcmx5IHZhbGlkIGFuZCBp bXBvcnRhbnQgZm9yIFVSTnMuDQo+IA0KPiBPSy4NCg0KQWdyZWVkLg0KIA0KPiA+IExpa2V3aXNl LCBleHBlcmllbmNlIHNob3dzIHRoYXQgd2UgbmVlZCB0byBwcm92aWRlIGEgbW9yZSBwcmVjaXNl DQo+ID4gZnJhbWV3b3JrIGZvciB0aGUgZXN0YWJsaXNobWVudCBvZiBVUk4gc2VydmljZXMgZm9y IFVSTiBOYW1lc3BhY2VzLA0KPiBpbg0KPiA+IG9yZGVyIHRvIGZ1cnRoZXIgYSB1bmlmb3JtIHN0 eWxlIC0tIHRvIHRoZSBiZW5lZml0IG9mIGdlbmVyaWMgVVJODQo+ID4gaGFuZGxpbmcgYXBwbGlj YXRpb25zLg0KPiANCj4gQ3JlYXRpbmcgdGhlIHRlY2huaWNhbCBmcmFtZXdvcmsgZm9yIGVzdGFi bGlzaG1lbnQgb2YgVVJOIHJlc29sdXRpb24NCj4gc2VydmljZXMgaGFzIGJlZW4gb25lIG9mIHRo ZSB3ZWFrbmVzc2VzIG9mIHRoZSBVUk4gZWZmb3J0LiBUaGVyZSBpcyBubw0KPiB3aWRlbHkgdXNl ZCBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBwYWNrYWdlIGxpa2UgdGhlIG9uZSB0aGF0IGhhcyBleGlz dGVkDQo+IGZvciBtYW55IHllYXJzIGZvciB0aGUgSGFuZGxlIHN5c3RlbS4gQW5kIGxvY2FsbHkg ZGV2ZWxvcGVkIHJlc29sdmVycw0KPiB1c3VhbGx5IHByb3ZpZGUgb25seSB0aGUgYmFzaWMgVVJO IHJlc29sdXRpb24gc2VydmljZXMsIHN1Y2ggYXMgbWFwcGluZw0KPiB0aGUgVVJOIHRvIChzaW5n bGUpIFVSTC4NCg0KSSBiZWxpZXZlIHRoYXQgbW9zdCBpbnN0aXR1dGlvbnMgaW50ZXJlc3RlZCBp biB0aGlzIHdhaXQgZm9yIHRoZSBSRkMgMjQ4M2JpcyBzbyB0aGF0IHRoZXkga25vdyB3aGljaCBz ZXJ2aWNlcyB0byBwcm92aWRlLiBJdCdzIHByb2JhYmx5IGEgY2hpY2tlbi9lZ2ctcHJvYmxlbSwg ZXZlcnlvbmUgd2FpdGluZyBmb3IgdGhlIG90aGVyIG9uZSB0byBtYWtlIHRoZSBmaXJzdCBtb3Zl Lg0KDQo+ID4gVW5saWtlIGZvciBvdGhlciBVUklzLCBVUk5zIGluIGdlbmVyYWwgYXJlIGRlZGlj YXRlZCB0byBiZSBtZWRpYS0gYW5kDQo+ID4gdGVjaG5vbG9neS1pbmRlcGVuZGVudCwgYXMgYWxt b3N0IG5lY2Vzc2l0YXRlZCBieSB0aGUgdGFyZ2V0IG9mDQo+ID4gbG9uZy10ZXJtLCBnbG9iYWwg c2NvcGUsIHVuaXF1ZW5lc3MsIGFuZCBwZXJzaXN0ZW5jZSAoUkZDIDE3MzcsDQo+ID4gU2VjdGlv biAyKS4NCj4gDQo+IEkgYWdyZWUgb24gdGVjaG5vbG9neSBpbmRlcGVuZGVuY2UsIGJ1dCBtZWRp YSBpbmRlcGVuZGVuY2UgaXMgYSBtb3JlDQo+IGNvbXBsZXggaXNzdWUuIE1hbnkgdHJhZGl0aW9u YWwgaWRlbnRpZmllciBzeXN0ZW1zIGFyZSBtZWRpYSBkZXBlbmRlbnQuDQo+IEZvciBpbnN0YW5j ZSwgZWFjaCBtYW5pZmVzdGF0aW9uIG9mIGEgYm9vayAoaGFyZCBiYWNrLCBwYXBlcmJhY2ssIFBE RikNCj4gbXVzdCBnZXQgaXRzIG93biBJU0JOLiBTbyBhbnkgVVJOOklTQk4gd2lsbCBiZSBmb3Jl dmVyIHRpZWQgdG8gYSBzaW5nbGUNCj4gbWFuaWZlc3RhdGlvbiBvZiB0aGUgYm9vay4gV2hlbiB0 aGUgYm9vayBpbiBQREYgaXMgbWlncmF0ZWQgdG8gYSBtb3JlDQo+IG1vZGVybiBmb3JtYXQsIHRo YXQgdXBkYXRlZCBtYW5pZmVzdGF0aW9uIHNoYWxsIHJlY2VpdmUgYSBuZXcgSVNCTi4NCj4gVGhl c2UgdHdvIElTQk5zIC8gVVJOOklTQk5zIHdpbGwgYmUgaW50ZXJsaW5rZWQgaW4gbWV0YWRhdGEg c28gdGhlDQo+IHVzZXJzIGNhbiB0cmF2ZWwgZm9yd2FyZCBhbmQgYmFja3dhcmQgaW4gdGltZSwg ZGVwZW5kaW5nIG9uIHRoZWlyDQo+IHByZWZlcmVuY2VzLg0KDQpJIGNvbW1lbnRlZCBvbiB0aGlz IGluIG15IHByZXZpb3VzIG1haWw6IEluIG9yZGVyIHRvIGdvIGZvcndhcmQgd2Ugc2hvdWxkIGln bm9yZSBJU0JOIGZvciB0aGUgdGltZSBiZWluZy4NCg0KPiBUaGUgbmF0aW9uYWwgbGlicmFyaWVz IGFyZSBvZiBjb3Vyc2Ugc3RvcmluZyBhbGwgdGhlIHZlcnNpb25zLCBzbyBhcyB0bw0KPiBwcm90 ZWN0IG91cnNlbHZlcyBmcm9tIG1pc3Rha2VzIG1hZGUgZHVyaW5nIG1pZ3JhdGlvbnMuDQo+IA0K PiBUaGVyZSBhcmUgYWxzbyBpZGVudGlmaWVycyB3aGljaCByZWxhdGUgdG8gaW1tYXRlcmlhbCB3 b3JrcyBhbmQgYXJlDQo+IHRoZXJlZm9yZSBtZWRpYSBkZXBlbmRlbnQuIElTVEMgKEludGVybmF0 aW9uYWwgU3RhbmRhcmQgVGV4dCBDb2RlKSBpcw0KPiBhbiBleGFtcGxlIG9mIHRoaXMuIFVSTjpJ U1RDIHRoZXJlZm9yZSBmdWxmaWxscyB0aGUgc3Bpcml0IG9mIFJGQyAxNzM3DQo+IGZ1bGx5LiBU aG9zZSBVUk5zIHdpbGwgbGluayB0byB0aGUgbWV0YWRhdGEgcmVjb3JkIHdoaWNoIGNvbnRhaW5z IGxpbmtzDQo+IHRvIGFsbCB0aGUgbWFuaWZlc3RhdGlvbnMuDQo+IA0KPiBIb3dldmVyLCB0aGUg VVJOIHN5c3RlbSBhcyBhIHdob2xlIGlzIG9ubHkgZnVuY3Rpb25hbCB3aGVuIGl0IGNvbWJpbmVz DQo+IHRoZSB3b3JrIGxldmVsIGFuZCBtYW5pZmVzdGF0aW9uIGxldmVsIGlkZW50aWZpZXJzLg0K DQpBcyBhbiBhc2lkZTogSVNUQyB3b3JrcyBvbiB0aGUgZnJicjpFeHByZXNzaW9uIGxldmVsIChk aWZmZXJlbnQgbGFuZ3VhZ2UgdmVyc2lvbnMgcmVjZWl2ZSBkaWZmZXJlbnQgSVNUQ3MpIGNmLiBJ U1RDIE1hbnVhbCBbSVNUQyBNYW51YWxdIFNlYyA3LjEuDQoNCj4gPiBTaW5jZSB0aGVyZSBhcmUg dmFyaW91cyBzZXJ2aWNlcyBhcHBsaWNhYmxlIHRvIFVSTnMsIHJlc29sdXRpb24gb2YgYQ0KPiA+ IFVSTiBkb2VzIG5vdCBoYXZlIHRoZSBzYW1lIG1lZGlhIG9yaWVudGF0aW9uIHByb3BlcnRpZXMg bGlrZSBpdCBpcw0KPiA+IGNvbW1vbiBpbiBhIEhUVFAvSFRNTCBjb250ZXh0LiBUaGUgb2JqZWN0 cy9yZXNvdXJjZXMgbmFtZWQgYnkgVVJOcw0KPiA+IG1pZ2h0IGJlIHN0cnVjdHVyZWQsIGNvbXBs ZXgsIGFuZCBpbnRlci1yZWxhdGVkIHdpdGggdGhlIGRldGFpbHMNCj4gPiBwZXJoYXBzIGV2b2x2 aW5nIG92ZXIgdGltZSwgd2hlcmVhcyB0aGUgYWJzdHJhY3Qgb2JqZWN0IGFuZCBpdHMNCj4gbmFt aW5nDQo+ID4gKGFzIGRvbmUgYnkgdGhlIGFzc2lnbmVtZW50IG9mIHtOSUR9OntOU1N9KSBuZWVk cyB0byBiZSBzdGFibGUuDQo+IA0KPiBCYXNlZCBvbiB3aGF0IEkgc2FpZCBhYm92ZSwgSSBjYW5u b3QgYWdyZWUgd2l0aCB0aGlzLiBJbiBhbGwgdGhvc2UNCj4gbmFtZXNwYWNlcyB3aGljaCBiZWxv bmcgdG8gbWFuaWZlc3RhdGlvbiBpZGVudGlmaWVycyBzdWNoIGFzIElTQk4sDQo+IHJlc29sdXRp b24gaXMgdmVyeSBtdWNoIG1lZGlhIG9yaWVudGVkIGJ1dCBob3dldmVyIHN0YWJsZS4gTmF0aW9u YWwNCj4gbGlicmFyaWVzIGFuZCBhcmNoaXZlcyB3aWxsIGhhdmUgdXNlcnMgd2hvLCBmb3IgdGhl IHNha2Ugb2YNCj4gYXV0aGVudGljaXR5LCBldmVuIGFmdGVyIGh1bmRyZWRzIG9mIHllYXJzLCBz dGlsbCB3YW50IHRoZSBvcmlnaW5hbA0KPiB2ZXJzaW9uIG9mIHRoZSBkaWdpdGFsIGRvY3VtZW50 LiBOYW1pbmcgb2YgdGhlc2UgZG9jdW1lbnRzLCBnaXZlbiB0aGUNCj4gYXNzaWdubWVudCBwb2xp Y3kgb2YgSVNCTiBhbmQgb3RoZXIgc3lzdGVtcywgaXMgYXMgc3RhYmxlIGFzIGl0IGdldHMuDQoN ClRoaXMgaXMgb25seSB0cnVlIGlmIHdlIGNhbiByZWx5IG9uIGV2ZXJ5b25lIHBsYXlpbmcgYWNj b3JkaW5nIHRvIHRoZSBydWxlcy4gU2luY2Ugd2UgY2FuJ3QsIHdlIHNob3VsZCBub3QgcmVseSBv biBhbiBJU0JOIGJlaW5nIGNvdXBsZWQgdG8gYW4gb2JqZWN0IG9mIGEgc3BlY2lmaWMgbWVkaWEg dHlwZS4NCg0KWy4uLl0gPFNuaXBwZWQgZGlzY3Vzc2lvbiBhYm91dCB1cm46aXNibj4NCg0KPiA+ IEluIHRoZSBtZWFudGltZSwgaXQgaGFzIGJlY29tZSBjbGVhciB0aGF0IHRoZSBzdWJzZXF1ZW50 IHRleHQgaW4NCj4gPiBTZWN0aW9uIDMuNSBvZiBSRkMgMzk4NiBpcyBpbmNvbXBhdGlibGUgd2l0 aCB0aGUgZ29hbHMsIHNpbmNlIGl0DQo+IGNhbGxzDQo+ID4gZm9yIFVSSSB1c2VycyB0byBzdHJp cCB0aGUgZnJhZ21lbnQgaWRlbnRpZmllciBjb21wb25lbnQgYmVmb3JlDQo+ID4gZm9yd2FyZGlu ZyBhIFVSSSByZWZlcmVuY2UgZm9yIHJlc29sdXRpb24sIGFuZCB0byBhcHBseSB0aGUgZnJhZ21l bnQNCj4gPiBpZGVudGlmaWVyLCBpbiBhIG1lZGlhLXR5cGUgZGVwZW5kZW50IG1hbm5lciwgdG8g dGhlIHJldHVybmVkDQo+IGNvbnRlbnQuDQo+IA0KPiBBcyBJIHNlZSBpdCwgc2VjdGlvbiAzLjUs IG9yIHRoZSB3YXkgSFRUUCBkZWFscyB3aXRoIHRoZSBmcmFnbWVudHMsIGlzDQo+IG5vdCBpbmNv bXBhdGlibGUgd2l0aCB0aGUgZ29hbHMgb2YgdGhlIGJpYmxpb2dyYXBoaWMgY29tbXVuaXR5LiBX ZQ0KPiB3b3VsZCBub3QgdXNlIGZyYWdtZW50cyB0byBhY3R1YWxseSBpZGVudGlmeSBhbnl0aGlu ZywgYnV0IHRvIGhlbHAgdGhlDQo+IHVzZXIgdG8gZ2V0IGludG8gYSBjZXJ0YWluIGxvY2F0aW9u IHdpdGhpbiB0aGUgaWRlbnRpZmllZCByZXNvdXJjZS4NCj4gVGhpcyB3b3VsZCBiZSB2ZXJ5IGhl bHBmdWwgZm9yIGUuZy4gY2l0aW5nIHB1cnBvc2VzLg0KDQpJIGFncmVlIHRoYXQgdGhlIHBvc3Np YmlsaXR5IHRvIHVzZSBhIHBlcnNpc3RlbnQgaWRlbnRpZmllciB0byBwb2ludCB0byBhIHBhcnRp Y3VsYXIgbG9jYXRpb24gaW4gYSByZXNvdXJjZSB3aWxsIGJlIF9leHRyZW1lbHlfIGhlbHBmdWwg dG8gcmVzZWFyY2hlcnMgYW5kIG90aGVyIHBlb3BsZSB3aG8gd2FudCB0byBjaXRlIHRoZSBzb3Vy Y2VzIHRoZXkgdXNlLiBIb3dldmVyLCBpZiB3ZSBkbyBub3QgdXNlIHRoZSBmcmFnbWVudCB0byBp ZGVudGlmeSBhbnl0aGluZywgd2Ugc2hvdWxkIGZpbmQgYW5vdGhlciBuYW1lIHRoYW4gImZyYWdt ZW50IGlkZW50aWZpZXIiLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgd2Ugd2FudCB0byBoZWxwIHRo ZSB1c2VyIHRvIGdldCBpbnRvIGEgY2VydGFpbiBsb2NhdGlvbiB3aXRoaW4gdGhlIHJlc291cmNl LCB3ZSBuZWVkIGEgc29tZXRoaW5nIHNvIHRoYXQgdGhlIHN5c3RlbSBjYW4gZmluZCB0aGF0IGxv Y2F0aW9uLiBUaGF0IHNvbWV0aGluZyBpcyBhbiBpZGVudGlmaWVyIChpZGVudGlmeWluZyB0aGF0 IGxvY2F0aW9uKS4NCiANCj4gSW4gdGhlIGJpYmxpb2dyYXBoaWMgY29udGV4dCwgY29tcG9uZW50 cyBtaWdodA0KPiA+IGJlIGFyY2hpdmVkIGluIGRpZmZlcmVudCBtZWRpYSBpdGVtcyBvdmVyIHRp bWUgdG8gbWFpbnRhaW4gdGhlaXINCj4gPiBhY2Nlc3NhYmlsaXR5LCBhbmQgdGhleSBtaWdodCBi ZSBzdWJqZWN0IHRvIGRpdmVyc2UgZGlzdHJpYnV0aW9uDQo+ID4gcmVzdHJpY3Rpb25zOyBzbyBp biBnZW5lcmFsLCBpdCB3aWxsIGJlIGltcG9zc2libGUgb3IgaW1wcmFjdGljYWwgdG8NCj4gPiBy ZXR1cm4gYW4gYWxsLWVuY29tcGFzc2luZyByZXNwb25zZSBhbmQgYWxsb3cgdGhlIGNsaWVudCB0 byBzZWxlY3QNCj4gdGhlDQo+ID4gcmVxdWlyZWQgcGFydC4NCj4gDQo+IFRoaXMgYXBwbGllcyB0 byBsb2dpY2FsIGZyYWdtZW50cywgYnV0IGl0IGlzIG5vdCBvdXIgaW50ZW50aW9uIHRvIGFwcGx5 DQo+IFVSSSBmcmFnbWVudHMgdG8gdGhlbS4gVVJJIGZyYWdtZW50cyB3aWxsIGJlIGFwcGxpZWQg dG8gcGh5c2ljYWwNCj4gZnJhZ21lbnRzIG9mIGRvY3VtZW50cywgdG8gd2hpY2ggdGhleSBhcmUg YXBwbGljYWJsZS4NCg0KV2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgImxvZ2ljYWwg ZnJhZ21lbnQiLCBhICJVUkkgZnJhZ21lbnQiLCBhbmQgYSAicGh5c2ljYWwgZnJhZ21lbnQiPyBX aGljaCBpcyB0aGUgb25lIHJlZmVycmVkIHRvIGluIFJGQyAzOTg2IHNlYyAzLjU/DQoNCj4gQW4g YWRkaXRpb25hbCByZXN0cmljdGlvbiBvZiB0aGUgdXNlDQo+ID4gb2YgZnJhZ21lbnQgaWRlbnRp ZmllcnMgaXMgdGhhdCwgaW4gcHJhY3RpY2UsIG1lZGlhIHR5cGVzIGFuZC9vcg0KPiA+IGNvbW1v biBicm93c2VycyBkbyBub3Qgc3VwcG9ydCB0byAicGljayBhIGNvbXBvbmVudCIgZnJvbSB0aGUN Cj4gcmV0dXJuZWQNCj4gPiByZXNvdXJjZSwgYnV0IHJlcHJlc2VudCB0aGUgd2hvbGUgcmVzb3Vy Y2UsIHBvaW50aW5nIHRvIGEgcGFydGljdWxhcg0KPiA+IHNwb3QgdGhlcmVpbiwgc3VjaCBtYWlu dGFpbiB0aGUgdXNlciBwZXJjZXB0aW9uIG9mIGEgImZyYWdtZW50DQo+ID4gaWRlbnRpZmllciIg ZXNzZW50aWFsbHkgYmVpbmcgdXNlZCBhcyBhIHBvaW50ZXIgdG8gYSBwYXJ0aWN1bGFyIHBvaW50 DQo+ID4gaW4gdGhlIHJldHVybmVkIG1lZGlhLCBub3QgYSBwYXJ0aWN1bGFyIHBhcnQgb2YgdGhl IHJlc291cmNlLg0KPiANCj4gWWVzLCB0aGlzIGlzIHdoeSBmcmFnbWVudCBpcyBub3QgcGFydCBv ZiB0aGUgTlNTLCBhbmQgd2h5LCBpZiB5b3UgaGF2ZQ0KPiBhIGJhc2UgdXJuOmlzYm4gYW5kIHlv dSBhdHRhY2ggMTAgZGlmZmVyZW50IGZyYWdtZW50cyB0byBpdCwgeW91IHdpbGwNCj4gc3RpbGwg aGF2ZSBqdXN0IG9uZSBVUk4sIGJ1dCB5b3UgaGF2ZSBhY2Nlc3MgdG8gMTAgZGlmZmVyZW50IHBs YWNlcw0KPiB3aXRoaW4gdGhhdCBwYXJ0aWN1bGFyIG1hbmlmZXN0YXRpb24gb2YgYSByZXNvdXJj ZS4NCj4gDQo+IEFuZCB0aGlzIGlzIGFsc28gd2h5IHlvdSBzaG91bGQgbmV2ZXIgdXNlIGZyYWdt ZW50IGluIHRob3NlIFVSTg0KPiBuYW1lc3BhY2VzIHdoZXJlIHRoZSBpZGVudGlmaWVyIGlzIG5v dCB0aWVkIHRvIHBhcnRpY3VsYXIgbWFuaWZlc3RhdGlvbg0KPiBvZiBhIHJlc291cmNlIG9yIHRo ZSBpZGVudGlmaWVyIGRvZXMgbm90IGlkZW50aWZ5IHNpbmdsZSBkb2N1bWVudHMuDQo+IFRoaXMg bWVhbnMgbm8gZnJhZ21lbnRzIGZvciBJU0NJIChJbnRlcm5hdGlvbmFsIFN0YW5kYXJkIENvbGxl Y3Rpb24NCj4gSWRlbnRpZmllcikgb3IgSVNTTiAoaWRlbnRpZmllciBmb3Igc2VyaWFscykuDQoN Ck9yIElTQk4sIGJlY2F1c2Ugbm8tb25lIGNhbiBlbnN1cmUgdGhhdCB0aGVyZSBpcyBhIGJpamVj dGlvbiBiZXR3ZWVuIGFuIElTQk4gYW5kIGEgcGFydGljdWxhciBtYW5pZmVzdGlvbi4NCg0KPiBU aGUgSUVURiBoYXMgcmVjZW50bHkgcHV0IGVtcGhhc2lzIG9uIHRoaXMNCj4gPiBwYXJ0aWN1bGFy LCBzdHJpY3QgbWVkaWEtdHlwZSBkZXBlbmRlbmNlIG9mIHRoZSBmcmFnbWVudCBwYXJ0IG9mDQo+ IFVSSXMsDQo+ID4gYW5kIHdlIG5lZWQgdG8gYWNjb21vZGF0ZSB0aGF0IGFuZCBlc3RhYmxpc2hl ZCBwcmFjdGljZSBpbiBicm93c2Vycy4NCj4gDQo+IFRoZSByZWxldmFudCB0ZXh0IHBvcnRpb25z IGluIHJmYzIxNDFiaXMgYW5kIGVsc2V3aGVyZSBuZWVkIHRvIGJlDQo+IGNsYXJpZmllZC4gVGhl IG1vc3QgaW1wb3J0YW50IHRoaW5nIGlzIHRvIHNheSB0aGF0IHRoZSBmcmFnbWVudCBpcyBub3QN Cj4gcGFydCBvZiB0aGUgTlNTLCBhbmQgZHJhdyBjb25jbHVzaW9ucyBmcm9tIHRoYXQuDQoNClll cy4NCg0KPiA+DQo+ID4gSW4gb3JkZXIgdG8gYXZvaWQgcmVjdXJyZW5jZSBvZiB0aGlzIGlzc3Vl LCBleHBsYWluaW5nIHRleHQgb24NCj4gPiBmcmFnbWVudCB1c2Ugd2l0aCBVUk5zIElNTyBuZWVk cyB0byBiZSBwcmVzZW50IGluIHJmYzIxNDFiaXMsIF9hbmRfDQo+IHdlDQo+ID4gbmVlZCB0byBw cm92aWRlIGEgdW5pZm9ybSB3b3JraW5nIHNjaGVtZSBmb3IgdGhlIGlkZW50aWZpZWQNCj4gPiBy ZXF1aXJlbWVudHMuDQoNClllcy4NCg0KPiA+ICoqIHRoZSBwcm9wb3NhbCAqKg0KPiA+DQo+ID4g U3R1ZHkgb2YgUkZDcyBhbmQgb2ZmLWxpc3QgY29udmVyc2F0aW9ucyB3aXRoIGZvbGtzIGZyb20g dGhlDQo+ID4gYmlibGlvZ3JhcGhpYyBjb21tdW5pdHkgaGFzIGxlYWQgdG8gYSBtb2RlbCBob3cg dGhlc2UgZ29hbHMgY291bGQgYmUNCj4gPiBhY2hpZXZlZCBieSBhIGNvbW1vbi1zdHlsZSB1c2Fn ZSBvZiB0aGU8cXVlcnk+ICBVUkkgcGFydCwgYW5kIEkgd2FudA0KPiA+IHRvIHByZXNlbnQgdGhp cyB0byB0aGUgV0cgYXMgYSB3YXkgZm9yd2FyZCBmb3IgZGlzY3Vzc2lvbiBiZWZvcmUNCj4gZ29p bmcNCj4gPiB0byB3b3JrIG91dCB0aGUgZGV0YWlscyBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo ZSByZmMyMTQxYmlzIGFuZA0KPiA+IHJmYzM0MDZiaXMgSS1Ecy4NCj4gDQo+IFNvcnJ5IC0gSSBh bSB1bndpbGxpbmcgdG8gcHV0IGFueSBmcmFnbWVudCByZWxhdGVkIGRhdGEgaW50byBxdWVyeS4N Cg0KV2l0aCAiZnJhZ21lbnQiIGhlcmUsIGRvIHlvdSBtZWFuICJsb2dpY2FsIGZyYWdtZW50Iiwg IlVSSSBmcmFnbWVudCIsIG9yICJwaHlzaWNhbCBmcmFnbWVudCI/DQoNCj4gPiBMZXQgbWUgZXhw bGFpbiB0aGUgaWRlYSB3aXRoIGEgdmVyeSBoeXBvdGhldGljYWwgKGludGVudGlvbmFsbHkNCj4g PiBpbnZhbGlkKSBleGFtcGxlOg0KPiA+DQo+ID4gU2F5IGEgYm9vayBoYXMgYmVlbiBhc3NpZ25l ZCB0aGUgSVNCTiAoSVNCTi0xMykgOTg3LTY1LTQzMjEtNjc4LTkuDQo+ID4gVGh1cywgcGVyIHRo ZSByZmMzMTg3YmlzIEktRCwgaXQgZ2V0cyBhc3NpZ25lZCB0aGUgVVJOLA0KPiA+ICAgICAgICAg ICAgICB1cm46aXNibjo5ODctNjUtNDMyMS02NzgtOQ0KPiANCj4gVGhpcyBJU0JOIHdvdWxkIGJl bG9uZyB0byBhIHBhcnRpY3VsYXIgbWFuaWZlc3RhdGlvbiBvZiBhIGJvb2ssIHNheSBhDQo+IFBE RiB2ZXJzaW9uLCBpbiBpdHMgZW50aXJldHkuDQoNCk9yIGEgcHJpbnRlZCBib29rIGluIHlvdXIg Ym9va3NoZWxmLiBPciBhIHBhY2thZ2Ugb2YgYm9va3MgKGNvbXBsZXRlIHdvcmtzKSwgb3IgLS0g YWdhaW5zdCB0aGUgcnVsZXMgYnV0IGRvbmUgYW55d2F5IC0tIGEgcHJpbnRlZCBib29rIGFuZCBp dHMgZS1ib29rIHZlcnNpb24uDQoNCj4gPiBBIHJlc29sdXRpb24gc2VydmljZSBtaWdodCBiZSBh YmxlIHRvIHByb3ZpZGUgdGhlIGJpYmxpb2dyYXBoaWMNCj4gcmVjb3JkDQo+ID4gb2YgdGhlIGJv b2sgYW5kIHBvaW50IHRvIHJlcHJvZHVjdGlvbnMgb2Ygc2VsZWN0ZWQgcGFydHMgb2YgaXQsIHNh eQ0KPiA+ICAgICAgLSBhbiBpbWFnZSBvZiB0aGUgZnJvbnQgcGFnZSAoY292ZXIgcGFnZSksDQo+ ID4gICAgICAtIGEgdGV4dCB2ZXJzaW9uIG9mIHRoZSB0YWJsZSBvZiBjb250ZW50cywNCj4gPiAg ICAgIC0gc29tZSByaWNoIHRleHQgY29weSAoZS5nLiBIVE1MIG9yIFBERikgb2YgdGhlIGZvcmV3 b3JkLA0KPiA+ICAgICAgLSB0aGUgbGlzdCBvZiByZWZlcmVuY2VzIGluY2x1ZGVkIGluIHRoZSBi b29rDQo+ID4gICAgICAgIChlLmcuIGluIHRoZSBmb3JtIG9mIGEgc2V0IG9mIHNob3J0ZW5lZCBi aWJsaWdyYXBoaWMgcmVjb3JkcyksDQo+ID4gICAgICBhbGwgb2YgdGhlIGFib3ZlIGF2YWlsYWJs ZSBmb3IgZnJlZSwgd2l0aG91dCByZXN0cmljdGlvbnMgdG8NCj4gYW55b25lOw0KPiA+ICAgICAg YW5kDQo+ID4gICAgICAtIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiB0aGUgYm9vayAoaW4g UERGKQ0KPiA+ICAgICAgYXZhaWxhYmxlIHRvIHJlZ2lzdGVyZWQgKGF1dGhlbnRpY2F0ZWQgYW5k IGF1dGhvcml6ZWQpIHVzZXJzDQo+ID4gICAgICBvZiBhIHNwZWNpZmljIGNvbW11bml0eSBvbmx5 Lg0KPiANCj4gSSBhbSBhZnJhaWQgdGhhdCB0aGUgVVJOIHJlc29sdXRpb24gc2VydmljZSB3b3Vs ZCBub3QgYW5kIHdpbGwgbm90IGJlDQo+IGFibGUgZG8gYWxsIG9mIHRoaXMuIEZvciB0aGUgdGlt ZSBiZWluZyB0aGV5IGFyZSBzaW1wbGUgdG9vbHMgd2l0aCBvbmx5DQo+IGEgbGltaXRlZCBzdXBw b3J0aW5nIHJvbGUuDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHZlcnkgZ29vZCBzZXQgb2YgcmVxdWly ZW1lbnRzIGZvciByZXNvbHV0aW9uIHNlcnZpY2VzLg0KDQpJIHdpbGwgc25pcCB0aGUgcmVzdCBv ZiB0aGUgZGlzY3Vzc2lvbiBvbiByZXNvbHV0aW9uIHNlcnZpY2VzIGZvciB1cm46aXNibi4NCg0K PiBSZXNvbHV0aW9uIHNlcnZpY2UgbWF5IGhlbHAgdGhlIHVzZXIgdG8gcmV0cmlldmUgYSBiaWJs aW9ncmFwaGljIHJlY29yZA0KPiBkZXNjcmliaW5nIHRoZSBib29rLCBhbmQgdGhvc2UgcmVjb3Jk cyBub3dhZGF5cyBvZnRlbiBwcm92aWRlIGEgbGluayB0bw0KPiB0aGUgaW1hZ2Ugb2YgdGhlIGJv b2suIFRhYmxlIG9mIGNvbnRlbnRzIG1heSBiZSBwYXJ0IG9mIHRoZQ0KPiBiaWJsaW9ncmFwaGlj IHJlY29yZCwgYW5kIHRoZSByZWNvcmQgbWF5IGFsc28gY29udGFpbiBsaW5rcyB0byBBbWF6b24N Cj4gYW5kIGVsc2V3aGVyZSB3aGVyZSBleGNlcnB0cyBvZiB0aGUgYm9vayBhcmUgc3RvcmVkLg0K DQpXZSBjb3VsZCBpbnRlZ3JhdGUgdGhvc2Ugc2VydmljZXMgaW50byBvdXIgbGlicmFyeSBjYXRh bG9ndWVzLg0KDQo+IEFkanVzdGluZyB0aGUgcmVzb2x1dGlvbiBzZXJ2aWNlcyBhbmQgYmlibGlv Z3JhcGhpYyBpbmZvcm1hdGlvbiBzeXN0ZW1zDQo+IGluIHN1Y2ggYSB3YXkgdGhhdCB0aGUgdXNl ciBjb3VsZCByZXF1ZXN0IHZhcmlvdXMgZGF0YSBlbGVtZW50cyBvbmUgYXQNCj4gdGhlIHRpbWUg bWF5IGJlIHRlY2huaWNhbGx5IHBvc3NpYmxlLCBidXQgbGlicmFyaWVzIHByb2JhYmx5IHByZWZl ciB0bw0KPiBzdXBwbHkgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGJpYmxpb2dyYXBoaWMgc3lzdGVt cywgYW5kIG5vdCB0byBleHRlbmQNCj4gcmFkaWNhbGx5IHRoZSByb2xlIG9mIHRoZSByZXNvbHV0 aW9uIHNlcnZpY2VzLg0KDQpXaGF0IGlmIHNvbWVvbmUgZWxzZSBkZWNpZGVzIHRvIGJ1aWxkIGhp cyBvd24gbGlicmFyeSBjYXRhbG9ndWUgZnJvbSB0aGUgbGlua2VkIG9wZW4gZGF0YSBsaWJyYXJp ZXMgc3VwcGx5Pw0KDQpbLi4uXQ0KDQo+ID4gICAgICB1cm46aXNibjo5ODctNjUtNDMyMS02Nzgt OT9zPUkyUiZjPXRvYw0KPiA+ICAgICAgICByZXR1cm5zIHRoZSB0YWJsZSBvZiBjb250ZW50czsN Cj4gPiAgICAgIHVybjppc2JuOjk4Ny02NS00MzIxLTY3OC05P3M9STJMJmM9Zm9yZXdvcmQNCj4g PiAgICAgICAgcmV0dXJucyBhIFVSTCBmb3IgdGhlIGZvcmV3b3JkIG9mIHRoZSBib29rOw0KPiAN Cj4gSW4gc29tZSBzaXR1YXRpb25zLCB0aGUgc2FtZSBlZmZlY3QgY2FuIGJlIGFjaGlldmVkIGJ5 DQoNCkluIHdoaWNoIHNpdHVhdGlvbnM/DQoNCj4gID4gICAgICB1cm46aXNibjo5ODctNjUtNDMy MS02NzgtOSN0b2MNCj4gID4gICAgICAgIHRha2VzIHRoZSB1c2VyIHRvIHRoZSBiZWdpbm5pbmcg b2YgdGhlIHRhYmxlIG9mIGNvbnRlbnRzOw0KPiAgPiAgICAgIHVybjppc2JuOjk4Ny02NS00MzIx LTY3OC05I2ZvcmV3b3JkDQo+ICA+ICAgICAgICB0YWtlcyB0aGUgdXNlciB0byB0aGUgYmVnaW5u aW5nIG9mIHRoZSB0aGUgZm9yZXdvcmQuDQo+IA0KPiBTdWl0YWJsZSBzdHJ1Y3R1cmFsIGVsZW1l bnRzIGNvdWxkIGJlIGhhcnZlc3RlZCBmcm9tIHRoZSBzb3VyY2UNCj4gZG9jdW1lbnQsIGFuZCB0 aGUgcmVzb2x2ZXIgY291bGQgYmUgbWFkZSBhd2FyZSBvZiB0aGVtLiBJZiB0aGUgcmVzb3VyY2UN Cj4gaXMgbm90IHN0cnVjdHVyZWQgaW4gdGhlIFVSSSBzeW50YXggc2Vuc2UsIG9yIHRoZSB3YW50 ZWQgc3RydWN0dXJhbA0KPiBlbGVtZW50cyBhcmUgbWlzc2luZywgbWV0YWRhdGEgaW4gdGhlIGxp YnJhcnkgc3lzdGVtIG1heSBjb250YWluIHRoZQ0KPiB0b2MgYW5kIHJldmVhbCB0aGUgbG9jYXRp b24gb2YgdGhlIGZvcmV3b3JkLiBBbGFzLCBtYWludGFpbmluZyB0aGVzZQ0KPiBVUkxzIChwb2lu dGluZyB0byBlLmcuIHRoZSBwdWJsaXNoZXIncyB3ZWIgc2l0ZSkgd2lsbCBiZSBkaWZmaWN1bHQg aW4NCj4gdGhlIGxvbmcgdGVybS4NCj4gDQo+ID4gICAgICB1cm46aXNibjo5ODctNjUtNDMyMS02 NzgtOT9zPUkyTnMmYz1yZWZsaXN0DQo+ID4gICAgICAgIHJldHVybnMgYSBVUkkgbGlzdCAodGV4 dC91cmktbGlzdCBwZXIgUkZDIDI0ODMpDQo+ID4gICAgICAgIHdpdGggdGhlIFVSTnMgb2YgdGhl IHJlZmVyZW5jZXMgaW5jbHVkZWQgaW4gdGhlIGJvb2s7DQo+ID4gICAgICB1cm46aXNibjo5ODct NjUtNDMyMS02NzgtOT9zPUkyTCZjPXNlYy4xDQo+ID4gICAgICAgIHJldHVybnMgYSBVUkwgcG9p bnRpbmcgdG8gdGhlIEludHJvZHVjdGlvbiAoU2VjdGlvbiAxKQ0KPiA+ICAgICAgICBvZiB0aGUg Ym9vaywgd2hpY2ggY2FuIG9ubHkgYmUgcmVzb2x2ZWQgYnkgYXV0aG9yaXplZCB1c2Vycy4NCj4g DQo+IExpYnJhcmllcyB1c2UgYW5vdGhlciBtZWNoYW5pc20gKE9wZW5VUkwpIGZvciBkeW5hbWlj IGxpbmtpbmcgd2hpY2gNCj4gY2hlY2tzIHdoZXRoZXIgdGhlIHVzZXJzIGFyZSBhdXRob3JpemVk IHRvIHVzZSB0aGUgcmVzb3VyY2UuDQoNClRoYXQgY291bGQgYmUgaW50ZWdyYXRlZCBpbnRvIHRo ZSByZXNvbHZlci4gT3BlblVSTCBbT3BlblVSTF0gaXMgb25lIHdheSBvZiBkb2luZyB0aGF0IGFu ZCBub3QgYWxsIGxpYnJhcmllcyB1c2UgaXQuDQoNCj4gPiBUaGlzIHNvbHV0aW9uLCBpbiBhIG51 dHNoZWxsLCB3b3VsZCBjb25zaXN0IG9mIHRoZSBmb2xsb3dpbmcgZWxlbWVudHMNCj4gPiBmb3Ig cmZjMjE0MWJpcyBhbmQgcmZjMzQwNmJpczoNCg0KDQpbLi4uXSANCkFncmVlIHdpdGggdGhlIHNu aXBwZWQgdGV4dCBhbmQgSnVoYSdzIGNvbW1lbnRzLg0KIA0KPiA+ICAgICAtIHRoYXQgc3VwcG9y dGVkICJjPSIgdmFsdWVzIG5lZWQgdG8gYmUgc3BlY2lmaWVkIHBlciBVUk4NCj4gbmFtZXNwYWNl Lg0KPiANCj4gSSBhbSBub3Qgc3VyZSBpZiBpdCBpcyBhIGdvb2QgaWRlYSB0byBkbyB0aGlzLCBn aXZlbiB0aGF0IHRoZSBsaXN0IG9mDQo+IHNlcnZpY2VzIGFuZCBzZXJ2aWNlIGNvbXBvbmVudHMg d2lsbCBncm93LiBCdXQgdGhlcmUgbXVzdCBiZSBhIHdheSB3aXRoDQo+IHdoaWNoIGEgdXNlciBj YW4gY2hlY2sgZnJvbSB0aGUgcmVzb2x2ZXIgd2hpY2ggc2VydmljZXMgYW5kIHNlcnZpY2UNCj4g Y29tcG9uZW50cyBpdCBzdXBwb3J0cy4NCg0KV291bGQgaXQgd29yayB0aGF0IHRoZSBVUk4gbmFt ZXNwYWNlIHNwZWNpZmllcyBhIChjaGFuZ2luZykgZG9jdW1lbnQgd2hlcmUgdGhlIGNvbXBvbmVu dHMgYXJlIGxpc3RlZD8gVGhlbiB3ZSBkb24ndCBuZWVkIHRvIHVwZGF0ZSB0aGUgcmZjIGV2ZXJ5 IHRpbWUgc29tZXRoaW5nIGNoYW5nZXMuDQoNCj4gPiAgICAgRnVydGhlciwgcmZjMjE0MWJpcyB3 aWxsIGluZGljYXRlIHRoYXQgZnV0dXJlIFVSTiBOYW1lc3BhY2UNCj4gPiAgICAgcmVnaXN0cmF0 aW9uIGRvY3VtZW50cyAoYXMgcGVyIHJmYzM0MDZiaXMpIG5lZWQgdG8gc3BlY2lmeSB0aGUNCj4g PiAgICAgc3VwcG9ydCBvZiB0aGUgYWJvdmU8cXVlcnk+ICBzeW50YXggYnkgaXRzIHJlc29sdXRp b24gc2VydmljZShzKSwNCj4gPiAgICAgc3VwcG9ydGVkL2FwcGxpY2FibGUgc2VydmljZXMsIHRo ZSBkZWZhdWx0IHNlcnZpY2UgcHJvdmlkZWQsDQo+ID4gICAgIGFuZCB0aGUgdXNhZ2Ugb2YgImM9 IiAoaWYgYXBwbGljYWJsZSkgYW5kIGFueSBvdGhlciBwb3RlbnRpYWwNCj4gPiAgICAga2V5d29y ZHMgZm9yIHRoYXQgVVJOIE5hbWVzcGFjZSBhbmQgc3VwcG9ydGVkIHNlcnZpY2UuDQo+IA0KPiBO YW1lc3BhY2UgcmVnaXN0cmF0aW9ucyBzaG91bGQgbWFrZSBpdCBjbGVhciBpZiBmcmFnbWVudCB1 c2FnZSBpcw0KPiBhbGxvd2VkLiBUaGlzIGlzIGJhc2VkIG9uIHdoYXQgaXMgYmVpbmcgaWRlbnRp ZmllZC4gSWYgdGhlIHRhcmdldCBpcyBhDQo+IHNpbmdsZSBtYW5pZmVzdGF0aW9uIG9mIGEgcmVz b3VyY2UsIGZpbmUuIElmIHRoZSBpZGVudGlmaWVkIG9iamVjdCBjYW4NCj4gYmUgYW55dGhpbmcs IHRoZW4gY29tbW9uIHNlbnNlIGNhbiBiZSB1c2VkLiBJZiB0aGUgb2JqZWN0IGNhbiBuZXZlciBi ZQ0KPiBzb21ldGhpbmcgdG8gd2hpY2ggVVJJIGZyYWdtZW50cyBpbiB0aGUgUkZDIDM5ODYgc2Vu c2UgY2FuIGJlIGFwcGxpZWQsDQo+IGZvcmdldCBpdC4NCg0KQWNjb3JkaW5nIHRvIHdoYXQgSSB1 bmRlcnN0b29kLCBmcmFnbWVudHMgaW4gdGhlIFJGQyAzOTg2IHNlbnNlIGNhbiBhbHdheXMgYmUg dXNlZC4gVGhlIHF1ZXN0aW9uIGlzIGlmIHRoZXkgbWFrZSBzZW5zZSBmb3IgYWxsIHVybiBuYW1l c3BhY2VzLiBUaGUgbmFtZXNwYWNlIHJlZ2lzdHJhdGlvbiBzaG91bGQgbWFrZSB0aGF0IGNsZWFy Lg0KDQo+IFRoZSByZWdpc3RyYXRpb24gY2FuIGFsc28gbGlzdCBvdGhlciBzZXJ2aWNlcyB0aGF0 IG1heSBiZSBzdXBwb3J0ZWQuIEkNCj4gZG9uJ3Qga25vdyBpZiB3ZSBjYW4gc2F5IHRoYXQgc29t ZSBzZXJ2aWNlcyBtdXN0IGJlIHN1cHBvcnRlZC4NCg0KU29tZSBzZXJ2aWNlcyBwcm9iYWJseSBz aG91bGQgYmUgbWFuZGF0b3J5Lg0KDQo+ID4gICAgIEV4cGxhbmF0b3J5IG1hdGVyaWFsIHJlbGF0 ZWQgdG8gdGhlIGlzc3VlcyAoZGVzY3JpYmVkIGFib3ZlKSB3aXRoDQo+ID4gICAgIHRoZSB1c2Ug b2Y8ZnJhZ21lbnQ+ICBpZGVudGlmaWVycyBhcyBpbiBzb21lIHJlY2VudCBwcm90b3R5cGUgVVJO DQo+ID4gICAgIHNlcnZpY2UgaW1wbGVtZW50YXRpb25zIHdpbGwgc3RheSBpbiBBcHBlbmRpY2Vz IG9mIHJmYzIxNDFiaXM7DQo+ID4gICAgIHRoaXMgaW5jbHVkZXMgdGhlIG1lbnRpb24gb2YgdGhl IGNob2ljZXMgVVJOIG5hbWVzcGFjZSBkZXNpZ25lcnMNCj4gPiAgICAgaGF2ZSBmb3Igc3VwcG9y dCBvZiBoaWVyYXJjaGljYWwgKGFuZCBjcm9zcy1saW5rZWQpIHJlc291cmNlczoNCj4gPiAgICAg LSBpbmNsdWRlIGNvbXBvbmVudCBpZGVudGlmaWVyIGluIHJlZ2lzdGVyZWQgaWRlbnRpZmllciwN Cj4gPiAgICAgICBtYWtpbmcgaXQgYSAocGVyaGFwcyBkaXN0aW5ndWlzaGFibGUpIHBhcnQgb2Yg dGhlIE5TUzsNCj4gDQo+IFRoaXMgd2lsbCBiZSBhIGNvbW1vbiBhcHByb2FjaCBmb3IgbG9naWNh bCBmcmFnbWVudHMuIEluIG1hbnkNCj4gbmFtZXNwYWNlcyB0aGUgY29tcG9uZW50IGlkZW50aWZp ZXJzIHdpbGwgYmUgaWRlbnRpY2FsIHRvIGlkZW50aWZpZXJzDQo+IGFzc2lnbmVkIHRvIHdob2xl IGRvY3VtZW50cywgYW5kIC0gb2YgY291cnNlIC0gYWx3YXlzIHBhcnQgb2YgdGhlIE5TUy4NCg0K QWdhaW46IHdoYXQgYXJlIGxvZ2ljYWwgZnJhZ21lbnRzPw0KIA0KPiA+ICAgICAtIHN1cHBvcnQv dXNlPHF1ZXJ5PiAgd2l0aCAiYz0iLCBzbyB0aGUgTlNTIHJlZ2lzdHJ5IGZvciB0aGUNCj4gPiAg ICAgICBuYW1lc3BhY2UgZG9lc24ndCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgY29tcG9uZW50IGlu Zm9ybWF0aW9uDQo+ID4gICAgICAgKHdoaWNoIHdpbGwgYmUgYWRkZWQgdmFsdWUgYnkgdGhlIHJl c29sdXRpb24gc2VydmljZXMpOw0KPiANCj4gSSBhbSBub3Qgc3VyZSAtIHlldCAtIGhvdyB1c2Vm dWwgdGhpcyBtaWdodCBiZS4NCj4gDQo+ID4gICAgIC0gdXNlPGZyYWdtZW50PiAgKGlmIG1lZGlh IHR5cGVzIHJldHVybmVkIGZvciBwYXJ0aWN1bGFyIE5JRA0KPiA+ICAgICAgIGFyZSBsb25nLXRl cm0gc3RhYmxlIGFuZCBhbGxvdyB0byBzdXBwb3J0IHRoYXQpLg0KPiANCj4gVGhlcmUgd2lsbCBi ZSBuYW1lc3BhY2VzIGFuZCBkb2N1bWVudHMgdG8gd2hpY2ggdGhpcyBmdW5jdGlvbmFsaXR5IGlz DQo+IHZlcnkgdXNlZnVsLg0KPiANCj4gPiAgICAgVGhlIHByb3BlciB1c2Ugb2Y8ZnJhZ21lbnQ+ ICB3aWxsIGJlIGVtcGhhc2l6ZWQgaW4gdGhlIG1haW4gYm9keQ0KPiA+ICAgICBvZiByZmMyMTQx YmlzLCB3aXRoIHBvaW50ZXJzIHRvIG90aGVyIHNwZWNzLCBpbmNsdWRpbmcgdGhlDQo+ID4gICAg IHdvcmstaW4tcHJvZ3Jlc3MgUkZDIDQyODhiaXMgZnJvbSBBUFBTQVdHLg0KPiANCj4gSSdsbCBk cmFmdCBzb21ldGhpbmcgdG8gdGhpcyBlZmZlY3QuDQo+IA0KPiA+IG8gIHJmYzM0MDZiaXMgc3Bl Y2lmaWVzIHRoZSBkZXRhaWxzIGZvciB0aGUgYWJvdmUgc2NoZW1lIGV4cGVjdGVkIHRvDQo+ID4g ICAgIGJlIHNwZWNpZmllZCBpbiByZWdpc3RyYXRpb24gZG9jdW1lbnRzLCBpbmNsdWRpbmcgbmV3 IGVudHJpZXMgaW4NCj4gPiAgICAgdGhlIFVSTiBOYW1lc3BhY2UgcmVnaXN0cmF0aW9uIHRlbXBs YXRlIGZvciBzdXBwb3J0ZWQgc2VydmljZXMNCj4gPiAgICAgKHBlciB0aGUgInMiIHZhbHVlIElB TkEgcmVnaXN0cnkpIGFuZCB0aGUgdXNhZ2UgYW5kIHJ1bGVzIGZvcg0KPiA+ICAgICAiYz0iIChp ZiBhcHBsaWNhYmxlKSBhbmQgYW55IG90aGVyPHF1ZXJ5PiAga2V5d29yZHMsIGluY2x1ZGluZw0K PiA+ICAgICBwb3NzaWJsZSBJQU5BIHJlZ2lzdHJhdGlvbiBvZiBuZXcga2V5d29yZHMuDQo+IA0K PiBPSy4NCj4gPg0KPiA+IG8gIFRoZSBkZWZpbml0aW9uIG9mIG5ldyBzZXJ2aWNlIGxhYmVscywg YW5kIGFuIHVwZGF0ZSB0byB0aGUNCj4gPiAgICAgZXhpc3RpbmcgZGVmaW5pdGlvbnMgaXMgbGVm dCB0byBmdXR1cmUgd29yayBvbiBhIHJmYzI0ODNiaXMNCj4gPiAgICAgZG9jdW1lbnQuICBUaGUg aW5vZmZpY2lhbCByZmMyNDgyYmlzIHByZS1kcmFmdCBjaXJjdWxhdGVkDQo+ID4gICAgIGNhbiBi ZSBzdHJpcHBlZCBvZiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgVVJOIHNlcnZpY2UgbGFiZWwNCj4g PiAgICAgSUFOQSByZWdpc3RyeSAodGhlbiBkb25lIGluIHJmYzIxNDFiaXMpIGFuZCBmb2N1cyBv biB1cGRhdGVzDQo+ID4gICAgIG9mIHNlcnZpY2UgZGVzY3JpcHRpb25zIGFuZCB0aGUgbmV3IHNl cnZpY2VzIHRoYXQgaGF2ZSBiZWVuDQo+ID4gICAgIGlkZW50aWZpZWQgaW4gcHJhY3RpY2UgYXMg YmVpbmcgbmVlZGVkLg0KPiANCj4gT25jZSB3ZSBoYXZlIGFncmVlZCB0aGF0IHRoaXMgaXMgdGhl IHdheSB0byBnbywgSSB3aWxsIG1vZGlmeSB0aGUNCj4gcmZjMjQ4M2JpcyBhY2NvcmRpbmdseS4N Cj4gDQo+ID4gUGxlYXNlIGRpc2N1c3MgdGhpcyBjb25zdHJ1Y3RpdmUgcHJvcG9zYWwgZm9yIGEg d2F5IGZvcndhcmQgIC0tDQo+ID4gcHJlZmVyYWJseSBieSBvbi1saXN0IGNvbW1lbnRzLg0KDQpZ ZXMsIGEgdmVyeSBoZWxwZnVsIHByb3Bvc2FsIQ0KDQpBbGwgdGhlIGJlc3QsDQoNCkxhcnMNCg0K UC4gUy4gSSBzaGFsbCBiZSBvZmZsaW5lIHVudGlsIEF1Z3VzdCA4LCBzbyBkb24ndCBob2xkIHlv dXIgYnJlYXRocyBmb3IgYW5zd2VycyBmcm9tIG1lLi4uDQoNCltJU1RDIE1hbnVhbF0gaHR0cDov L3d3dy5pc3RjLWludGVybmF0aW9uYWwub3JnL2h0bWwvbXVsdGltZWRpYS9wZGZzL0lTVENfVXNl cl9NYW51YWxfMjAxMHYxLjIucGRmDQpbT3BlblVSTF0gaHR0cDovL3d3dy5uaXNvLm9yZy9hcHBz L2dyb3VwX3B1YmxpYy9kb3dubG9hZC5waHAvNjY0MC9UaGUlMjBPcGVuVVJMJTIwRnJhbWV3b3Jr JTIwZm9yJTIwQ29udGV4dC1TZW5zaXRpdmUlMjBTZXJ2aWNlcy5wZGYgDQoNCioqKkxlc2VuLiBI w7ZyZW4uIFdpc3Nlbi4gMTAwIEphaHJlIERldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayoqKg0K KioqUmVhZGluZy4gTGlzdGVuaW5nLiBVbmRlcnN0YW5kaW5nLiBBIGNlbnR1cnkgb2YgdGhlIEdl cm1hbiBOYXRpb25hbCBMaWJyYXJ5KioqDQoNCi0tIA0KRHIuIExhcnMgRy4gU3ZlbnNzb24NCkRl dXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlayAvIEluZm9ybWF0aW9uc3RlY2huaWsNCmh0dHA6Ly93 d3cuZG5iLmRlLw0KbC5zdmVuc3NvbkBkbmIuZGUNCmh0dHA6Ly93d3cuZG5iLmRlLzEwMGphaHJl DQoNCg== From juha.hakala@helsinki.fi Tue Jul 17 01:11:41 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF0421F8601 for ; Tue, 17 Jul 2012 01:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_05=-1.11, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDZu4+DUxqnH for ; Tue, 17 Jul 2012 01:11:39 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0421F85F1 for ; Tue, 17 Jul 2012 01:11:37 -0700 (PDT) Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q6H8CGSF013010 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 17 Jul 2012 11:12:20 +0300 Message-ID: <50051E60.90002@helsinki.fi> Date: Tue, 17 Jul 2012 11:12:16 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5 MIME-Version: 1.0 To: "Svensson, Lars" References: <201207050926.LAA08015@TR-Sys.de> <4FF6DAAB.8090800@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF24697EA4@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EF24697EA4@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Maarit Huttunen , =?UTF-8?B?IktldHQsIErDvHJnZW4i?= , "urn@ietf.org" , Stella Griffiths , "Geipel, Markus" Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to way forward & the proposal X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 08:11:42 -0000 Hello Lars, On 13.7.2012 12:49, Svensson, Lars wrote: > Juha, all, > > Much of the current discussion -- particularly the use of fragments -- revolves around the consequences for urn:isbn (RFC 3187bis). In my opinion, that discussion prevents us from making progress in other areas. In short, I consider the use of ISBNs to create URNs flawed and suggest that we for the time being ignore requirements arising from the use of urn:isbn. Your message is related to a much broader issue of what kind of usage of (traditional) identifiers is acceptable, generally and more specifically from the URN point of view. Because identifier assignment is usually a manual process, human errors are possible, and perhaps inevitable. ISBN is no exception in this respect, and taking a closer look at the problems within this namespace is useful. But these problems do not undermine the value of the ISBN system as a whole. The biggest challenge to the URN system are the namespaces where there is no control over identifier assignment at all. The ISBN community has detailed identifier assignment rules expressed in the ISBN manual, and national ISBN centers are responsible of communicating these rules to the publishers. In most countries these rules are well respected, but there are also countries where there has been pressures to cut corners, for instance as regards the requirement to give different ISBNs to different formats. In spite of its problems, ISBN is one of the best managed bibliographic identifier systems in use. When ISBNs are assigned according to the ISBN manual, there should be no serious conflicts with the URN principles, although in some areas the ISBN community should perhaps investigate more closely from the URN point of view the practical implications of the existing policies. Please see some comments below. > > Longer version: > > As an answer to Alfred, Juha wrote: >>> Unlike for other URIs, URNs in general are dedicated to be media- >>> and technology-independent, as almost necessitated by the target of >>> long-term, global scope, uniqueness, and persistence (RFC 1737, >>> Section 2). >> >> I agree on technology independence, but media independence is a more >> complex issue. Many traditional identifier systems are media dependent. >> For instance, each manifestation of a book (hard back, paperback, PDF) >> must get its own ISBN. So any URN:ISBN will be forever tied to a >> single manifestation of the book. When the book in PDF is migrated to >> a more modern format, that updated manifestation shall receive a new ISBN. >> These two ISBNs / URN:ISBNs will be interlinked in metadata so the >> users can travel forward and backward in time, depending on their >> preferences. > > This statement is dependent on two axioms/assumptions specified in URN documents: > > (1) "Global uniqueness: The same URN will never be assigned to two different > resources." (RFC 2141bis-02 sec 1.2) > > (2) "Assumption #1: Assignment of a URN is a managed process.” (RFC 3406bis-02) > To me this means that if we create (assign) URNs merely by prefixing an > existing identifier – as by putting “urn:issn:” in front of an existing ISSN > – the process assigning the already existing identifier needs to be managed > as well. > > My take is that urn:isbn does not adhere to any of those criteria, at least not globally. IMHO, it does - if the system is used correctly. This interpretation is of course dependent on how we understand "different": is an unaltered reprint of a book a different resource than the original or not? I would prefer not to elaborate in rfc2141bis the meaning of "different" in axiom 1, since too strict an interpretation might mean that some traditional identifiers would not be suitable URNs. And this would be harmful both to the URN system and these identifiers. > 1) Uniqueness: An analysis of ISBNs in the catalogue of the Deutsche Nationalbibliothek (German National Library, DNB) revealed more than 200,000 ISBNs where more than one bibliographic record shared the same ISBN. Some of those instances are OK according to the ISBN Manual [ISBN Manual], whereby it must be noted, that -- for someone used to the language of RFC 2119 -- the ISBN Manual's language is somewhat fuzzy, using a mixture of shall, should, must etc where an IETF document would use MUST. Nonetheless, an application building on the uniqueness of urn:isbn would then entail that all records having the same ISBN are the same resource, which is not true. For the sake of comparison, how many ISBNs have been correctly assigned? And of these 200.000, how many are OK according to the ISBN manual? > 2) Managed process: The assignment of ISBNs to individual publications is in many (most?) jurisdictions specified by the ISBN Manual [ISBN Manual] but delegated to the publisher. A publisher wishing to use ISBNs to identify his publications buys a number range from a national ISBN centre. In many cases, the national centre has no control over how the publisher uses the assigned number range and if he (willingly or not) assigns the same ISBN more than once. A national library _could_ be a control point, but that assumes that a) legal deposit is in place, so that the national library can be certain that _all_ publications can be checked and b) that the national library is in a position to check ISBNs _before_ the book is published. National libraries are generally documentation centres (i. e. we document what has been published) so when a publication arrives it is often too late to change an improper ISBN anyway... > > The above statements about uniqueness are based on an ad hoc-analysis of data from the DNB. The first step was to collect all internal record identifiers sharing a common ISBN and to output a list of ISBNs pointing to more than one internal identifier. The second step was to manually evaluate a randomly chosen set of identifiers and see if the identified records actually are different or not. I could identify (at least) five different cases: > 1) The publisher has re-used an ISBN for two entirely different publications. Example: urn:isbn:3-332-00079-9 would identify [1] and [2]. This violates 5.1 of the ISBN Manual [ISBN Manual] This is a human error and these cases should be rare. The national library or other organisation maintaining the national bibliography will spot these errors, and may have a policy for fixing them. > 2) The publisher has re-used an ISBN for the same publication in two different formats (e. g. print and electronic). Example: urn:isbn:3-8272-6986-5 would identify [3] and [4]. This violates 5.4 of the ISBN Manual. In the worst case (if the principles of the ISBN Manual are not followed) these cases may become increasingly common. The library community and book stores must try to convince the publishers that this practice may have dire consequences. > 3) The publisher has used the same ISBN for two editions of a publication, where there has been no change of content (unchanged reprints). Example: urn:isbn:3-10-048198-4 would identify [5] and [6]. This is OK according to 5.2 of the ISBN Manual. From the URN resolution point of view, this should not be a serious problem. There is no need to reprint a digital book. And if there are reprints of a printed book, there may be just one bibliographic record describing all of these versions. > 4) The publisher has used the same ISBN for two editions of a publication where there has been a (significant) change in the content (augmented or revised reprints). Example: urn:isbn:3-921885-30-2 would identify [7] and [8]. This violates 5.2 of the ISBN Manual. The publishers should not do this, so these cases ought to be relatively rare. The national library or other organisation maintaining the national bibliography should be able to spot these errors. > 5) The publisher has assigned an ISBN to a media bundle (e. g. a book with an accompanying CD or a collection of books sold as a bundle, such as the complete Works of William Shakespeare). Examples: urn:isbn:978-3-609-62394-8 would identify the media bundle [9] consisting of [10] and [11] (a book with a CD-ROM). This is OK according to 5.6 of the ISBN Manual. Individual parts of the bundle often receive their own ISBNs. An example of this is (book) series and its individual parts (e.g. The Lord of the rings and its three parts). There should be no problems in resolving these URN:ISBNs in an appropriate manner. If the parts do not have their own ISBNs, other identifiers can be assigned. > > A more thorough evaluation will provide data on the relative frequencies of those four cases and possibly identify further ones. And yes, the data indicates that some publishers are more notorious than others... I look forward to this additional information. Does the Deutsche Nationalbibliothek have plans to contact those publishers who are the worst offenders? I don't know if we could provide a comparable analysis of the situation in Finland. And I doubt it would be of interest on the urn list. > So what does this mean? > 1) We should stop using urn:isbns as globally unique identifiers, because they aren’t. The only statement we can make is that urn:isbn:xxxx identifies whatever the owner of xxxx says it identifies, which might not be uniquely determined. There is no way the urn community, the IETF or any other agency can globally control ISBN assignment and much less enforce the rules laid down in the ISBN Manual [ISBN Manual]. If you cannot control uniqueness, you should not regulate it (and much less you should build applications that depend on it). There will be no URN namespaces where IETF or any other organization can fully control the uniqueness and persistence of an identifier. If a traditional identifier can only get a URN namespace if the identifier cannot be misused, by mistake or by purpose, then URN system could never become popular. > 2) I propose that we deprecate RFC 3187 and cease work on 3187bis, at least until the questions of uniqueness and process management have been clarified. The process question requires close co-operation with the International ISBN Agency (which Juha does anyway, as far as I know). Alternatively, RFC 3187bis can state that the use of urn:isbn is restricted to certain registration group elements (e. g. 951 and 952 since it seems to work in Finland), but I doubt that that is feasible. IETF must not deprecate URN namespaces which are already in use. Any changes that would undermine existing URN services are out of scope of the URNbis. Any fundamental issues with a namespace concerning the uniqueness and persistence of the identifiers should be discussed in the namespace registration request. IMHO, human errors in identifier assignment are not such issues. In the namespace registration I would not go beyond telling if the community has rules of identifier assignment, and perhaps providing an overview of these principles. Obviously these rules should not be in conflict with the URN principles. In the case of ISBN, I see no such conflicts, although there are cases in which we should investigate the practical consequences of existing (acceptable) practices. The URN community may be able to support the ISBN international and the national ISBN centers in their work at enforcing the guidelines of the ISBN manual, by showing that if the same ISBN is given to different formats and / or editions of a book, URN resolution process can be compromised. > 3) When discussing the use of fragment identifiers in RFC 2141bis, we should ignore potential use cases stemming from the use of urn:isbn. This is fine with me. Best regards, Juha > > All the best, > > Lars > > [1] http://d-nb.info/870687158 > [2] http://d-nb.info/881221112 > [3] http://d-nb.info/1015716695 > [4] http://d-nb.info/976818019 > [5] http://d-nb.info/946281599 > [6] http://d-nb.info/870379119 > [7] http://d-nb.info/800228464 > [8] http://d-nb.info/810433923 > [9] http://d-nb.info/988495430 > [10] http://d-nb.info/986478970 > [11] http://d-nb.info/988495589 > [ISBN Manual] ISBN User's Manual. International Edition. Sixth Edition. London 2012. http://www.isbn-international.org/pages/media/Usermanuals/ISBN%20Manual%202012%20-corr.pdf > > ***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. A century of the German National Library*** > > -- > Dr. Lars G. Svensson > Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ l.svensson@dnb.de http://www.dnb.de/100jahre > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678 From stpeter@stpeter.im Wed Jul 18 15:19:20 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE9811E80C4 for ; Wed, 18 Jul 2012 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvN8KWR8qtHS for ; Wed, 18 Jul 2012 15:19:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0088D11E80C1 for ; Wed, 18 Jul 2012 15:19:18 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2F25F4005A; Wed, 18 Jul 2012 16:39:14 -0600 (MDT) Message-ID: <50073698.60409@stpeter.im> Date: Wed, 18 Jul 2012 16:20:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Svensson, Lars" References: <6.2.5.6.2.20120627161749.08c30070@resistor.net> <4FF3501A.2000307@stpeter.im> <24637769D123E644A105A0AF0E1F92EF24694BBA@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EF24694BBA@dnbf-ex1.AD.DDB.DE> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] More comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:19:20 -0000 On 7/10/12 8:11 AM, Svensson, Lars wrote: > All, > > I have some more comments on 3406bis: > > Introduction: > > "I.e., not all syntactically correct URN Namespaces (per the URN > syntax definition) are valid URN Namespaces. A URN Namespace must > have a recognized definition in order to be valid." > > Is it enough for a URN Namespace to have a recognized definition to > be valid or does it have to be registered somewhere? If recognized is > enough: recognized by whom? I tend to agree that the notion of validity used here is not well specified. Formal namespaces and informal namespaces do have recognized definitions, because they are registered with the IANA. Experimental namespaces (which personally I would prefer to deprecate, see the "example" namespace I-D that I will submit when the window opens again) do not have recognized definitions, I think. Perhaps: "A URN Namespace must be registered in accordance with the procedures specified in this document in order to be considered valid." > Sec. 4.1: Experimental namespaces > > If we desire to register example as a NID, this whole section will > probably not be needed any more. I hope so. I wrote the I-D, but I missed the submission deadline. > As a corollary, sec 4.3 needs to change: > > "NIDs for Formal URN Namespaces MUST NOT have the forms indicated in > the preceding two sections for the other two Namespace types. (The > detailed formal rules are given below in Section 4.4.4.) > Applicants, in concert with the IANA experts, should ensure that the > sought NID strings are "proper" for the designated purpose, according > to common sense (and applicable legal rules)." > > Proposed text (moving parts from 4.4.4 to 4.3): > > "NIDs for Formal URN Namespaces MUST adhere to the following > constraints: - not be an already-registered NID; Isn't it the responsibility of the expert reviewer and the IANA to ensure that people don't register duplicates? In any case, given that the NID is the "key" here, I don't see much danger in duplicates. > - not start with > "urn-" (see Section 4.1 above); - not start with "X-" (see NOTE > below); - not start with "xy-", where xy is any combination of 2 > ASCII letters (see NOTE below); - not be equal to or start with > "example" (see NOTE below); Actually I plan to register "urn:example" as a replacement for experimental namespaces. Why would we forbid that? Or would the I-D I wrote lock that down? > - be more than 2 characters long. > > NOTE: All two-letter combinations as well as two-letter combinations > followed by "-" and any sequence of valid NID characters are > reserved for potential future use as countrycode-based NIDs for > eventual national registrations of URN Namespaces. The definition > and scoping of rules for allocation of responsibility for such > Namespaces is beyond the scope of this document. Further, to avoid > confusion, "urn" is not allowed as an NID string; To allow neutral > example URNs in code and documentation, NID strings starting with > "example" are set aside for use in documentation; I think it's better to do that in the I-D I've written, not in the registration document. > IANA has > permanently reserved these string to prohibit assignment. Earlier > versions of this RFC [RFC 2141] defined NID strings starting with > "X-" as belonging to the class of experimental namespaces. In order > to avoid confusion, the registration of NIDs starting with "X-" is > prohibited." I suppose that's OK given the history behind the "X-" space here. > 4.4.4 IANA Considerations in Registration Documents > > "According to the general procurements for RFCs, URN Namespace > definitions documents must include an "IANA Considerations" section > (cf. BCP 26 [RFC5226]). That section has to indicate that the > document includes a URN Namespace registration that is to be entered > into the IANA registry of Formal URN Namespaces." > > This might not be correct if the registration request is for an > informal namespace... Corrent. > Further, I suggest that constraints on NIDs are moved to 4.3. > Suggested wording of 4.4.4: > > "According to the general procurements for RFCs, URN Namespace > definitions documents must include an "IANA Considerations" section > (cf. BCP 26 [RFC5226]). That section has to indicate that the > document includes a URN Namespace registration that is to be entered > into the IANA registry of informal or formal URN Namespaces, > respectively. > > Registration documents for formal URN Namespaces will provide a > particular, unique, desired NID string, and this will be assigned by > the Standards/Protocol Action of the IESG that approves the > publication of the registration document as an RFC. RFC 2141bis > [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are > ASCII strings that are interpreted in a case-insensitive manner, but > the NID string SHALL be registered in the capitalization form > preferred by the registrant. The proposed NID string MUST conform > with the syntax rule in Section 2.1 of RFC 2141bis > [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to constraints > specified in sec 4.3, above. > > Applicants and the IANA experts have to ensure that the sought NID > strings are suitable and proper for the designated purpose and not > misleading, according to common sense and applicable legal rules. The > IETF Review process gives interested parties the opportunity to rise > concerns if they want to challenge proposed strings; the final > approval decision still remains with the IESG. > > Registrations may be revised by updating the RFC through standard > IETF RFC update processes. In any case, a revised document, in the > form of a new Internet-Draft, must be published, and the proposed > updated template must be circulated on the urn-nid discussion list, > allowing for a four-week review period before pursuing RFC > publication of the new document." That all seems fine. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jul 18 15:29:08 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334F11E81D5 for ; Wed, 18 Jul 2012 15:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Git14qMhB9R for ; Wed, 18 Jul 2012 15:29:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BCDEE11E81C9 for ; Wed, 18 Jul 2012 15:29:07 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 68D384005A; Wed, 18 Jul 2012 16:49:03 -0600 (MDT) Message-ID: <500738E5.4050306@stpeter.im> Date: Wed, 18 Jul 2012 16:29:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Juha Hakala References: <201207050926.LAA08015@TR-Sys.de> <4FF6AD77.2090803@helsinki.fi> In-Reply-To: <4FF6AD77.2090803@helsinki.fi> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to general issues X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:29:08 -0000 On 7/6/12 3:18 AM, Juha Hakala wrote: > Hello, > > Alfred has brought up several important issues in this message. I'll not > respond to everything at once, but will discuss the general points, the > way forward and the proposal separately. > > This message concentrates on the general issues. > > On 5.7.2012 12:26, Alfred wrote: >> URN folks, >> >> thanks to all for reviving the discussion on the rfx2141bis and >> rfc3406bis I-Ds. As the editor of both drafts, I try to sum up >> below and provide a perspective for a way forward; I'll respond >> individually in more detail ASAP (see endnote). >> >> >> ** general ** >> >> Unfortunately, stakeholders of URN Namespaces for various reasons >> seem to feel discouraged to participate in the on-list discussion, >> which now has been majorized by few long-time "IETF professional" >> contributors. Part of the frustration I observe also seems to be >> based on the lack of constructive proposals on the list so far, >> as replacement solutions for the options being voted against. > > There are not that many librarians, publishers etc. who are involved > with standards work. And most of these standards activists concentrate > on developing ISO standards. IETF as a whole, and the way in which it > develops standards, is unfamiliar to book trade and libraries. So even > if the URN system is vitally important for those organisations who use > it, we have only a limited number of mainly technical people following > the URNbis process. Hi Juha, what I have observed is that the scope of our work in the URNBIS WG is actually quite small, and the topics are of interest to people who care about URIs, but not to librarians, publishers, and the like. Those folks are users of some URN namespaces, but they don't particularly care about URNs in general (nor should they, I think). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 31 09:23:22 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E944821F86F8 for ; Tue, 31 Jul 2012 09:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtph383S9JM5 for ; Tue, 31 Jul 2012 09:23:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09B21F86EB for ; Tue, 31 Jul 2012 09:23:20 -0700 (PDT) Received: from [64.101.72.45] (unknown [64.101.72.45]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEEE14009B for ; Tue, 31 Jul 2012 10:43:03 -0600 (MDT) Message-ID: <50180676.9090108@stpeter.im> Date: Tue, 31 Jul 2012 10:23:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "urn@ietf.org" References: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> In-Reply-To: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] Fwd: I-D Action: draft-saintandre-urn-example-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:23:22 -0000 FYI and as previously mentioned. If approved, this document might enable us to remove experimental namespace identifiers from 3406bis. Peter -------- Original Message -------- Subject: I-D Action: draft-saintandre-urn-example-00.txt Date: Tue, 31 Jul 2012 09:20:51 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Uniform Resource Name (URN) Namespace for Examples Author(s) : Peter Saint-Andre Filename : draft-saintandre-urn-example-00.txt Pages : 6 Date : 2012-07-31 Abstract: This document defines a Uniform Resource Name (URN) namespace identifier enabling generation of URNs that are appropriate for use in private testing, as examples in documentation, and the like. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-urn-example There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-urn-example-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt