From A.Hoenes@TR-Sys.de Thu Nov 1 03:10: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 1C54B21F854F for ; Thu, 1 Nov 2012 03:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.26 X-Spam-Level: X-Spam-Status: No, score=-97.26 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcBqQp0cjHZk for ; Thu, 1 Nov 2012 03:10:07 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id E594D21F854A for ; Thu, 1 Nov 2012 03:10:06 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA000944469; Thu, 1 Nov 2012 11:07:49 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA23456; Thu, 1 Nov 2012 11:07:48 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201211011007.LAA23456@TR-Sys.de> To: urn@ietf.org Date: Thu, 1 Nov 2012 11:07:48 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [urn] call for comments: an alternative 2141bis document 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, 01 Nov 2012 10:10:08 -0000 As noted previously, I have intentionally deferred speaking up on this matter in detail until *all* the revised WG draft versions are available, so they can all be properly referred to. The revised rfc3044bis (URN:ISSN) draft is expected to become available soon after I-D submission is open again next week. It doesn't seem proper to me to not seriously take into account all the dependencies upon draft-ietf-urnbis-rfc2141bis-urn-03 of the rfc3406bis draft and the namespace-specific WG drafts. Previous responses on this thread do not seem to do this. So please review the aforementioned drafts -- including the rfc3044bis draft revision, once available -- *before* making your mind up! Kind regards, Alfred. From internet-drafts@ietf.org Wed Nov 7 07:37:06 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 A51E921F8BCE; Wed, 7 Nov 2012 07:37:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3POJjTbPBXri; Wed, 7 Nov 2012 07:37:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E1521F8BDC; Wed, 7 Nov 2012 07:37:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121107153706.3238.3023.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 07:37:06 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3044bis-issn-urn-01.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: Wed, 07 Nov 2012 15:37:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Using International Standard Serial Numbers as Uniform R= esource Names Author(s) : Pierre Godefroy Filename : draft-ietf-urnbis-rfc3044bis-issn-urn-01.txt Pages : 20 Date : 2012-11-07 Abstract: The International Standard Serial Number, ISSN, has been the authoritative identifier for continuing resources (which include serials) for more than three decades. Since 2001, the URN (Uniform Resource Name) namespace "ISSN" has been reserved for ISSNs. The namespace registration was performed in RFC 3044. This document redefines -- in a backwards compatible manner -- how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). Moreover, additional syntax related information required by the RFC 2141[bis] has been included. An updated namespace registration is provided. This document replaces RFC 3044. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3044bis-issn-urn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3044bis-issn-urn-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3044bis-issn-urn-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Sat Nov 10 18:37:26 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 5449F21F88C7 for ; Sat, 10 Nov 2012 18:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8HslI2H7bt5 for ; Sat, 10 Nov 2012 18:37:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30721F88BD for ; Sat, 10 Nov 2012 18:37:25 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8A1F40062 for ; Sat, 10 Nov 2012 19:41:23 -0700 (MST) Message-ID: <509F0F67.70904@stpeter.im> Date: Sat, 10 Nov 2012 19:37:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "urn@ietf.org" References: <20121111022746.4782.9105.idtracker@ietfa.amsl.com> In-Reply-To: <20121111022746.4782.9105.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <20121111022746.4782.9105.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [urn] Fwd: I-D Action: draft-saintandre-urnbis-3406bis-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: Sun, 11 Nov 2012 02:37:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Following up on my alternative approach to revising RFC 2141, I have decided to submit a similar I-D for RFC 3406. One could argue, as Leslie Daigle did to me recently, that we don't absolutely need to revise RFC 3406. I am sympathetic to that argument. However, based on my work advising namespace registrants over the past few years, I found that they often were confused about the process. Thus in my alternative approach to revising RFC 3406 I have rearranged the content a bit and have clarified and streamlined the text here and there. IMHO the only truly substantive change is removal of experimental namespaces, in accordance with the recommendations of RFC 6648. Feedback is welcome. Peter - -------- Original Message -------- Subject: I-D Action: draft-saintandre-urnbis-3406bis-00.txt Date: Sat, 10 Nov 2012 18:27:46 -0800 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 : Uniform Resource Name (URN) Namespace Definitions Author(s) : Peter Saint-Andre Leslie Daigle Renato Iannella Filename : draft-saintandre-urnbis-3406bis-00.txt Pages : 16 Date : 2012-11-10 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-urnbis-3406bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-urnbis-3406bis-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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCfD2cACgkQNL8k5A2w/vxzJQCfcDByQdyTmhfEALLkdA3bAAHe 3QQAmwQI1eBuxQ6aZbDibcvttQMngxQE =cK5i -----END PGP SIGNATURE----- From masinter@adobe.com Sun Nov 11 00:13: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 17D2621F8564 for ; Sun, 11 Nov 2012 00:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvqW2Oxr7kZq for ; Sun, 11 Nov 2012 00:13:38 -0800 (PST) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id AB9BE21F841B for ; Sun, 11 Nov 2012 00:13:37 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUJ9eL6iOWoq+N+KMXDdUR1X4+Ul7EyJT@postini.com; Sun, 11 Nov 2012 00:13:37 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAB8DYHP025980; Sun, 11 Nov 2012 00:13:34 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAB8DXXL000265; Sun, 11 Nov 2012 00:13:33 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sun, 11 Nov 2012 00:13:32 -0800 From: Larry Masinter To: Andrew Newton , "urn@ietf.org" Date: Sun, 11 Nov 2012 00:13:31 -0800 Thread-Topic: [urn] call for comments: an alternative 2141bis document Thread-Index: Ac2y33xh3obkNH0pRBuqyy60JUdYaANAzmbg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [urn] call for comments: an alternative 2141bis document 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: Sun, 11 Nov 2012 08:13:39 -0000 For the record: Personally, I think that the definition of URNs in 2141 was a mistake, and = that santandre's document doesn't go far enough. URNs may have originally i= ntended to be "persistent" and "location independent", but in practice, the= y intrinsically no more or less persistent or location independent as any o= ther URL, they just happen to start with the "urn:" scheme and have a diffe= rent generic syntax. In fact, the only thing that distinguishes urns, in general, is that they f= orm a consistent way of important an externally managed namespace into the = URI space. So I would update 2141 to say that there is a URI scheme "urn:" which is us= eful when there is a naming authority which takes responsibility for determ= ining the interpretation of names. I might also note that there was some co= nfusion about the role of urns in the past, with the hope that they could p= rovide some "persistence", but the distinction is illusive. One could have= just made up URL schemes (use issn:.... instead of urn:issn:...) but the c= onsistency of knowing the nature of the URI might be useful and avoid proli= feration of schemes. I might apologize for Urn:uuid as a mistake (since there is no authority), = and point to a few URI schemes which are not normally thought as being "Int= ernet" (tel:, although that's increasingly resolvable.) > -----Original Message----- > From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of > Andrew Newton > Sent: Thursday, October 25, 2012 11:35 AM > To: urn@ietf.org > Subject: [urn] call for comments: an alternative 2141bis document >=20 > All, >=20 > We have received a request for this working group to consider an > alternative to its adopted 2141bis document > (draft-ietf-urnbis-rfc2141bis-urn-03). That alternative is > draft-saintandre-urnbis-2141bis-00 > (http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/). > Additionally, some reviewers of our adopted document have expressed > concern regarding its unnecessary wordiness, especially in comparison > with the alternative. >=20 > Can participants of this working group please review both documents > and express opinions and provide comments as to the direction desired > for this working group in regards to a 2141bis RFC? >=20 > The two documents can be found here: > http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > http://datatracker.ietf.org/doc/draft-saintandre-urnbis-2141bis/ >=20 > We will use the IETF standard of rough consensus to determine the way > forward. >=20 > Finally, should the working group desire an alternative approach, we > intend to preserve and publish the historical and non-normative > information found in our current document. This information is > valuable and important. >=20 > -andy > co-chair, URNBIS > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From ri@semanticidentity.com Tue Nov 13 16:55:23 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 BC20521F8525 for ; Tue, 13 Nov 2012 16:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beJQ+aB5dOfx for ; Tue, 13 Nov 2012 16:55:23 -0800 (PST) Received: from rigel.websiteactive.com (rigel.websiteactive.com [202.191.62.234]) by ietfa.amsl.com (Postfix) with ESMTP id CC51421F8481 for ; Tue, 13 Nov 2012 16:55:21 -0800 (PST) Received: from c211-31-16-178.rochd5.qld.optusnet.com.au ([211.31.16.178]:55085 helo=[192.168.1.3]) by rigel.websiteactive.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TYRG8-003dvY-4z; Wed, 14 Nov 2012 11:55:16 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Renato Iannella In-Reply-To: Date: Wed, 14 Nov 2012 10:55:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Larry Masinter X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rigel.websiteactive.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - semanticidentity.com X-Source: X-Source-Args: X-Source-Dir: Cc: urn@ietf.org Subject: Re: [urn] call for comments: an alternative 2141bis document 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, 14 Nov 2012 00:55:23 -0000 On 11 Nov 2012, at 18:13, Larry Masinter wrote: > Personally, I think that the definition of URNs in 2141 was a mistake, = and that santandre's document doesn't go far enough. URNs may have = originally intended to be "persistent" and "location independent", but = in practice, they intrinsically no more or less persistent or location = independent as any other URL, they just happen to start with the "urn:" = scheme and have a different generic syntax. Hi Larry....as we all know, it is impossible to say that _anything_ will = be persistent (even beyond our lifetimes) in this industry. But I think that at least URNs _try_ to highlight to URN operators that = they need to consider longevity (Sec 5.1 of RFC3406bis [1]) and the fact the URNs are not dependent on the DNS and the opaque NSS = help towards that goal....but still requires ORG support for this to be = realised (hence a dependency on ORG persistence). Perhaps we can update 3406bis and 2141bis along these lines. That is, = qualify the "persistent, location-independent" statement with = qualification.=20 Cheers... Renato Iannella Semantic Identity http://semanticidentity.com Mobile: +61 4 1313 2206 [1] http://tools.ietf.org/html/draft-saintandre-urnbis-3406bis-00= From masinter@adobe.com Mon Nov 19 01:58:53 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 4A1AB21F859D for ; Mon, 19 Nov 2012 01:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t9NCC9O1sZF for ; Mon, 19 Nov 2012 01:58:52 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 50A0D21F855E for ; Mon, 19 Nov 2012 01:58:47 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUKoC1j9RaUy3eZb6/Vd6Af1xJXxc0uRQ@postini.com; Mon, 19 Nov 2012 01:58:51 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAJ9wjHP025780; Mon, 19 Nov 2012 01:58:45 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAJ9whXL022981; Mon, 19 Nov 2012 01:58:44 -0800 (PST) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 19 Nov 2012 01:58:43 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Mon, 19 Nov 2012 01:58:43 -0800 From: Larry Masinter To: Renato Iannella Date: Mon, 19 Nov 2012 01:58:41 -0800 Thread-Topic: [urn] call for comments: an alternative 2141bis document Thread-Index: Ac3CAsOg49fkoc20RrOZBPf2a3a46AENqRmw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document 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: Mon, 19 Nov 2012 09:58:53 -0000 > Hi Larry....as we all know, it is impossible to say that _anything_ will = be > persistent (even beyond our lifetimes) in this industry. http://masinter.blogspot.com/2010/03/ozymandias-uri.html > But I think that at least URNs _try_ to highlight to URN operators that t= hey need > to consider longevity http://tools.ietf.org/html/draft-saintandre-urnbis-3406bis-00#section-5.1 There is no clear line between meeting the requirements for "formal" and no= t; we (the IETF reviewers) are being asked to judge something we have littl= e qualification to judge, namely the likely longevity of an organization's = ability to "resolve" names for some period of time (how long?), and whether= that registration and resolution service will remain "open" (in what way?)= for an indefinite amount of time (how long?). I like the criteria, just I'm uneasy about IETF judging them without bikesh= edding. > and the fact the URNs are not dependent on the DNS and the opaque NSS hel= p > towards that goal....but still requires ORG support for this to be realis= ed (hence > a dependency on ORG persistence). I assume you mean "organizational" by "ORG" and not something more formal. Of course URLs aren't all dependent on DNS either. You're not saying why t= el: is a URI scheme and not a URN namespace?=20 r I'm not sure what you mean by "opaque NSS". > Perhaps we can update 3406bis and 2141bis along these lines. That is, qua= lify the > "persistent, location-independent" statement with qualification. I think it's a mistake to believe that URNs accomplish either of those, and= people often skip the qualifications. URNs are not persistent. And "locati= on-independent" cannot be determined. From ted.ietf@gmail.com Mon Nov 19 08:39: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 88CD321F86AF for ; Mon, 19 Nov 2012 08:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOcJKEkB3iZ6 for ; Mon, 19 Nov 2012 08:39:08 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 008AB21F8687 for ; Mon, 19 Nov 2012 08:39:07 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5773112vbb.31 for ; Mon, 19 Nov 2012 08:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yPFvMj0Vt5AL60S35ycsIq4AWVkt42w0rCR/4sFe3NM=; b=QxJ5gleZQq9bBYMNxq2oBzXAlO9juyDQAMkdQI7G6VbfyV/zwmpwP+e3jxim4vSdJw NSgH0jROUB2hHW/07V/Q9kFbiH9JMc9ZYtg6CFrZ2iiMYm49582NLBmM5xIy6+DZPsrL Ilf8FAqPvmMSIsbsP6fBlwTDjzGXaBFi3kVkOu1J8IAEpG5AORCa1lXF5vVSbU5WCA5K WymlIfDAruVXwMFOgXTKLytw+TuNLde4oWDPJCv+9Db4eZR5clGxC4TzSAUssVi3qHqd HTsT5JC90ihBZdR6eic+VTwtci3eD8ccjjTO/ddK7LUnB+/MfzMZ+vx9+8u3pM/q1wHU kyZg== MIME-Version: 1.0 Received: by 10.58.161.113 with SMTP id xr17mr18072646veb.3.1353343146981; Mon, 19 Nov 2012 08:39:06 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 19 Nov 2012 08:39:06 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 08:39:06 -0800 Message-ID: From: Ted Hardie To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document 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: Mon, 19 Nov 2012 16:39:08 -0000 On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter wrote: >> Hi Larry....as we all know, it is impossible to say that _anything_ will be >> persistent (even beyond our lifetimes) in this industry. While I agree that there is no way to say that anything aiming to be persistent will succeed, I do think it is useful to capture the answer to the question: will this identifier ever by reassigned in the normal course of business? There are lots of reasons why you can be wrong in the answer you give, but the answer is useful. This is also, oddly enough, why I think UUID URNs are just fine, even though they do not have an organizational guarantee--the cryptographic guarantee they provide is at least as good as the typical human-managed system. So I can look at one in a system and understand that it is meant to be unique. Just my personal view, of course, Ted From masinter@adobe.com Sun Nov 25 04:48:06 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 CE70121F85B2 for ; Sun, 25 Nov 2012 04:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.335 X-Spam-Level: X-Spam-Status: No, score=-105.335 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vJpVrLdHWaM for ; Sun, 25 Nov 2012 04:48:06 -0800 (PST) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id B94E821F8471 for ; Sun, 25 Nov 2012 04:48:05 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKULITfQlRvay5UQlGZHtNhmp/D3CJOKdr@postini.com; Sun, 25 Nov 2012 04:48:05 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAPClsHP016164; Sun, 25 Nov 2012 04:47:54 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAPClqNc015424; Sun, 25 Nov 2012 04:47:52 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sun, 25 Nov 2012 04:47:52 -0800 From: Larry Masinter To: Ted Hardie Date: Sun, 25 Nov 2012 04:47:50 -0800 Thread-Topic: [urn] call for comments: an alternative 2141bis document Thread-Index: Ac3GdGa6CF5FUvDyRZyoMC2wCM4nNwENQL+g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document 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: Sun, 25 Nov 2012 12:48:06 -0000 I'm not sure how useful it is to "capture the answer to the question: will= this identifier ever by reassigned in the normal course of business?" I think the question was "why bother with the extra four 'urn:' letters, ra= ther than just invent a new scheme?" and it's as useful to say that about = blah:stuff as it is about urn:blah:stuff, and if you are handed a URL of t= he form "urn:blah:stuff" where you know nothing about "blah", you have no m= ore information than you would have given "blah:stuff". (blah =3D uuid & stuff cryptographically securely randomly generated or not= ). I think you will have trouble defining "reassigned" and "normal course of b= usiness"...=20 During the normal course of business http://host/path always means =20 >>> talk to the host named "host", using whatever protocol is currently = meant by "http", asking for "/path" <<<< You probably mean something else by "reassigned", but there's a devil in th= e details of what it means in operational terms that make sense. The theory I'm working on links persistence to meaning, in that, within a c= ommunication from Alice, through a repository R, to Bob, that includes a URL/URI/URN/IRI A --- U ---> R=20 R --- U --> B Where the two transactions are time-offset, that the intention of meaning b= y A for U is tied directly to the expected persistent behavior of B when in= terpreting U.=20 > -----Original Message----- > From: Ted Hardie [mailto:ted.ietf@gmail.com] > Sent: Monday, November 19, 2012 8:39 AM > To: Larry Masinter > Cc: Renato Iannella; urn@ietf.org > Subject: Re: [urn] call for comments: an alternative 2141bis document >=20 > On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter > wrote: > >> Hi Larry....as we all know, it is impossible to say that _anything_ wi= ll be > >> persistent (even beyond our lifetimes) in this industry. >=20 > While I agree that there is no way to say that anything aiming to be > persistent will succeed, I do think it is useful to capture the answer > to the question: will this identifier ever by reassigned in the > normal course of business? There are lots of reasons why you can be > wrong in the answer you give, but the answer is useful. >=20 > This is also, oddly enough, why I think UUID URNs are just fine, even > though they do not have an organizational guarantee--the cryptographic > guarantee they provide is at least as good as the typical > human-managed system. So I can look at one in a system and understand > that it is meant to be unique. >=20 > Just my personal view, of course, >=20 > Ted From ted.ietf@gmail.com Mon Nov 26 07:47:25 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 551E021F85C2 for ; Mon, 26 Nov 2012 07:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX4sP8teUiex for ; Mon, 26 Nov 2012 07:47:24 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2EF21F85A6 for ; Mon, 26 Nov 2012 07:47:24 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so8743515qca.31 for ; Mon, 26 Nov 2012 07:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hrOC9OXYLfTMG+gL6Q5UehYojI9DEZ6PpnJpV8yenC0=; b=oPQacsQvIoI1gVZQAf258hDstPTB1gNMtWUMsDljYrZ9IUD9gIlgii9aaxVFkBrarE hH0QKR3YNag425N+8RdW0osuSg+QV7pvWpOOkgSIomhNANr+VvnljE0GTqPbouHjCOQ8 ChFIMNBv5tK13Y62WfJxH1OkDJmw6AAIxJwalakWdpmdGPI5C4TSj4GxB3CkT2RRQWix 9fHcrlQa0Ie0ZXz+XiWmEbbhDl59acGq72oXZ5K8BhrwWliXKsO73Q2kiw690KZ1F4N1 UI97FL/7eUQZbJ2umLKHaykWgTFq2whoUp9ZIezMFMVb7EnHk1OuIEMDpM7rHgsiDh2b 0r1w== MIME-Version: 1.0 Received: by 10.49.71.163 with SMTP id w3mr4230534qeu.22.1353944844017; Mon, 26 Nov 2012 07:47:24 -0800 (PST) Received: by 10.49.121.100 with HTTP; Mon, 26 Nov 2012 07:47:23 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 07:47:23 -0800 Message-ID: From: Ted Hardie To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "urn@ietf.org" Subject: Re: [urn] call for comments: an alternative 2141bis document 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: Mon, 26 Nov 2012 15:47:25 -0000 On Sun, Nov 25, 2012 at 4:47 AM, Larry Masinter wrote: > I'm not sure how useful it is to "capture the answer to the question: wi= ll this identifier ever by reassigned in the normal course of business?" > > I think the question was "why bother with the extra four 'urn:' letters, = rather than just invent a new scheme?" and it's as useful to say that about= blah:stuff as it is about urn:blah:stuff, and if you are handed a URL of= the form "urn:blah:stuff" where you know nothing about "blah", you have no= more information than you would have given "blah:stuff". > If you mean, could the group have made "This is guaranteed not to change, for some value of guaranteed" part of the meta-data in the registration, rather than something signaled in the URI string, sure. But as I'm sure you remember, there were visions at the time of using a different resolution service to find instances of the thing-that-a-urn-represents; had that turned out to be a common resolution mechanism, then having a common signal to use it makes sense. That's not quite the language in RFC 2276, but I think the presumption of an RDS was a driver for using a unique string. Is it worth changing now, and converting existing URNs? Certainly not, as that would violate the principle they were built under. Could you now build a URI that had the same characteristics as a URN, but did not use the string? Yep. The IESG historically would have asked you "why isn't this a URN?", but since we're making registration highly permissive, I'm not sure that they would really need an answer. > (blah =3D uuid & stuff cryptographically securely randomly generated or n= ot). > > I think you will have trouble defining "reassigned" and "normal course of= business"... > > During the normal course of business http://host/path always means > >>> talk to the host named "host", using whatever protocol is currentl= y meant by "http", asking for "/path" <<<< > > You probably mean something else by "reassigned", but there's a devil in = the details of what it means in operational terms that make sense. > I mean "the registration authority, the laws of physics, or some mathematical principle state that if I have associated *this* URN with *that* resource, it will never be associated with a different resource during the likely lifetime of our civilization". DNS names are re-assigned far more frequently than that. regards, Ted > The theory I'm working on links persistence to meaning, in that, within a= communication from Alice, through a repository R, to Bob, > that includes a URL/URI/URN/IRI > > A --- U ---> R > R --- U --> B > > Where the two transactions are time-offset, that the intention of meaning= by A for U is tied directly to the expected persistent behavior of B when = interpreting U. > > > >> -----Original Message----- >> From: Ted Hardie [mailto:ted.ietf@gmail.com] >> Sent: Monday, November 19, 2012 8:39 AM >> To: Larry Masinter >> Cc: Renato Iannella; urn@ietf.org >> Subject: Re: [urn] call for comments: an alternative 2141bis document >> >> On Mon, Nov 19, 2012 at 1:58 AM, Larry Masinter >> wrote: >> >> Hi Larry....as we all know, it is impossible to say that _anything_ w= ill be >> >> persistent (even beyond our lifetimes) in this industry. >> >> While I agree that there is no way to say that anything aiming to be >> persistent will succeed, I do think it is useful to capture the answer >> to the question: will this identifier ever by reassigned in the >> normal course of business? There are lots of reasons why you can be >> wrong in the answer you give, but the answer is useful. >> >> This is also, oddly enough, why I think UUID URNs are just fine, even >> though they do not have an organizational guarantee--the cryptographic >> guarantee they provide is at least as good as the typical >> human-managed system. So I can look at one in a system and understand >> that it is meant to be unique. >> >> Just my personal view, of course, >> >> Ted From andy@hxr.us Tue Nov 27 12:37: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 7802821F8755 for ; Tue, 27 Nov 2012 12:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQccUuBMfRCg for ; Tue, 27 Nov 2012 12:37:34 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9B8E21F8760 for ; Tue, 27 Nov 2012 12:37:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so10577720lah.31 for ; Tue, 27 Nov 2012 12:37:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=q6mzIxqUq/0rpxW905cWHz/TS5LSRIa6ValBG1udDyY=; b=XoAXXaTBv8LP5rxn80beB4ebtp5jLe9ZaGEO516EpYhyZFlPQCdURbKiXdOM/vj/oW wFl5bg+29HRHHoz0zJgm9KS/yhFFFbxGCMHy4I2rcZ7qtPAnJUritvlJC3PzLxMMUhQS s3RrnTLESalB/r7wyKh99b6SoSJ7Y8c/H5iF7uKHJTVDIC00v4dLlJ3yJ9D6+TPGeUea Hod2Cb0uNflkxtbAl+R15t9qymkFCIOlpR2MmkX5Kt/ESpVIcdL1E0c0fADuFaPz6pmx Dv+tmnyUWhOxI9MHSeI+87FT21qF+SFHKdPzNvBl0kF3RRydRKHjszHIDE6nv5dtiRMy rveQ== MIME-Version: 1.0 Received: by 10.152.106.212 with SMTP id gw20mr15898275lab.8.1354048653285; Tue, 27 Nov 2012 12:37:33 -0800 (PST) Received: by 10.112.12.52 with HTTP; Tue, 27 Nov 2012 12:37:33 -0800 (PST) X-Originating-IP: [192.149.252.11] Date: Tue, 27 Nov 2012 15:37:33 -0500 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: multipart/alternative; boundary=f46d0420a695fcda4804cf8004d7 X-Gm-Message-State: ALoCoQkmOhCB81HTsISsrneKglFyRNZuHPRhiTwJ2DvMdmkf3IWUT6TrQvz2vnwv6xpKKSZrn+u/ Subject: [urn] Transition of 2141bis and 3406bis 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, 27 Nov 2012 20:37:36 -0000 --f46d0420a695fcda4804cf8004d7 Content-Type: text/plain; charset=ISO-8859-1 All, With respect to moving to a new, smaller document encompassing our 2141bis goal I see that there is consensus within this working group for making this transition. Peter Saint-Andre has also submitted a 3406bis document consistent with the same style as his 2141bis document. For consistency, this new document will be used as a basis for this working group's 3406bis goal going forward. It should be noted that these new documents are not the final output of this working group but are simply a new basis for the development of the milestones we must achieve, and they will be based on consensus within this working group and the IETF in accordance with IETF practices. With regards to the historical context and motivations described in the current set of documents, we will seek the addition of new milestones for Informational track RFCs in which to capture this information. -andy, URNBIS co-chair --f46d0420a695fcda4804cf8004d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

With respect to moving to a new, smaller document e= ncompassing our 2141bis goal I see that there is consensus within this work= ing group for making this transition.=A0Peter Saint-Andre has also submitted a 3406bis document = consistent with the same style as his 2141bis document. For consistency, th= is new document will be used as a basis for this working group's 3406bi= s goal going forward.

It should be no= ted that these new documents are not the final output of this working group= but are simply a new basis for the development of the milestones we must a= chieve, and they will be based on consensus within this working group and t= he IETF in accordance with IETF practices.

With regards to= the historical context and motivations described in the current set of doc= uments, we will seek the addition of new milestones for Informational track= RFCs in which to capture this information.

-andy, URNBIS c= o-chair
--f46d0420a695fcda4804cf8004d7-- From stpeter@stpeter.im Tue Nov 27 19:46:55 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 EC98021E8047 for ; Tue, 27 Nov 2012 19:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBl1I4gNMaB0 for ; Tue, 27 Nov 2012 19:46:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 21F5D21E8030 for ; Tue, 27 Nov 2012 19:46:55 -0800 (PST) Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D742640092; Tue, 27 Nov 2012 20:51:49 -0700 (MST) Message-ID: <50B5892E.1070301@stpeter.im> Date: Tue, 27 Nov 2012 20:46:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andrew Newton References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "urn@ietf.org" Subject: Re: [urn] Transition of 2141bis and 3406bis 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, 28 Nov 2012 03:46:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/12 1:37 PM, Andrew Newton wrote: > All, > > With respect to moving to a new, smaller document encompassing our > 2141bis goal I see that there is consensus within this working > group for making this transition. Peter Saint-Andre has also > submitted a 3406bis document consistent with the same style as his > 2141bis document. For consistency, this new document will be used > as a basis for this working group's 3406bis goal going forward. As requested, I have submitted the following documents, which will appear shortly in the I-D repository: - - draft-ietf-urnbis-rfc2141bis-urn-04 - - draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04 I have also checked the XML files into source control: https://svn.tools.ietf.org/svn/wg/urnbis/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC1iS4ACgkQNL8k5A2w/vxzCACffrWRknTWpmQqjF5b8qyE+K/m 5fUAoOIynHlnyqwDcf/aZmRKCwyCd04+ =FCQJ -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue Nov 27 19:47: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 5A80721E8048; Tue, 27 Nov 2012 19:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AN0PdYBQZDU; Tue, 27 Nov 2012 19:47:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDC821E804B; Tue, 27 Nov 2012 19:47:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121128034711.22173.11338.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 19:47:11 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-04.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: Wed, 28 Nov 2012 03:47:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Syntax Author(s) : Peter Saint-Andre Ryan Moats Filename : draft-ietf-urnbis-rfc2141bis-urn-04.txt Pages : 9 Date : 2012-11-27 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme. This document defines the canonical syntax for URNs, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc2141bis-urn-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 27 19:48:33 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 BBFE221E8030; Tue, 27 Nov 2012 19:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR9wEcGeNZO2; Tue, 27 Nov 2012 19:48:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2073F21E804C; Tue, 27 Nov 2012 19:48:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121128034833.21010.71343.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 19:48:33 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04.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: Wed, 28 Nov 2012 03:48:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Uniform Resource Names, Revised Working G= roup of the IETF. Title : Uniform Resource Name (URN) Namespace Definitions Author(s) : Peter Saint-Andre Leslie Daigle Renato Iannella Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04.txt Pages : 16 Date : 2012-11-27 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-urnbis-rfc3406bis-urn-ns-reg-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/