From nobody Mon Jun 1 03:46:53 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46771AC3FC for ; Mon, 1 Jun 2015 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaQTokr-_Q24 for ; Mon, 1 Jun 2015 03:46:49 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 784091AC3F4 for ; Mon, 1 Jun 2015 03:46:49 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 17E498B019; Mon, 1 Jun 2015 12:46:48 +0200 (CEST) X-AuditID: 0a453fe7-f79136d0000011d7-05-556c3817e622 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 3D.C2.04567.7183C655; Mon, 1 Jun 2015 12:46:47 +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.03.0181.006; Mon, 1 Jun 2015 12:46:47 +0200 From: "Svensson, Lars" To: John C Klensin , Peter Saint-Andre - &yet Thread-Topic: Resolution services (was: Re: [urn] suggested change for -12 of rfc2141bis section 7.3.6) Thread-Index: AQHQmguUiq2ErBmBukKz9NZyb23fD52XeVzw Date: Mon, 1 Jun 2015 10:46:46 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF711DC@dnbf-ex1.AD.DDB.DE> References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE> <5567B021.3060401@andyet.net> <08B0499456635B130B203DEE@JcK-HP8200.jck.com> In-Reply-To: <08B0499456635B130B203DEE@JcK-HP8200.jck.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.102] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TeUgUURzHezurO24+e63HvtasXILK0rIipKI72DIoyIUusrGd3NVRt5nd 0igoli6LbjtWczPUskzFQMoDZNnoxC4oiy4tijSwyK7tsHk7szb2328+v9/3+/v+eAxN6b5p DLQt18HyuQxnDNWqtQtnf0nUp3DmSXerp6fsfPArNOVWp49KKXJ9VM2hTG3PHmlM5eU/VKaH Vd3UMmqVdqaF5WybWH7irHVa6/5jXZT9+pT8353Vmu3g1LhCEEZjNBUfuXpDI9Ux+N6L2tBC oKV1yAfw5U89QPpoAPho+zXxQ0OHogTcYyXzUciMT/8qVJOaQvG4/uUxFakjkQ3f3HlJI81k 4ccldaInLdaT8eU7gwlWo9G4tqqdIjVEqfhSZ5m8tlGF/e7igGcYmo7bXa2A1ADF4bq6u5S0 S4/r334LkTIjXN4scYyi8fvXf2Qej1v2lqik+Um4p80ja8fjyrJuefFQfPPUG/UhEONW2LoV ErdC4lZIzgD1BRAh5GQmJzGWJIslI8nC1gPphd5dAQceLPACRANjOOwtyjbrQphNQkGOFyyl VcZomPZJRBEZeZYCKyNY03knxwrGKLhrGmfWwX6c4eSyjSNg1QabWafvp4JTsNvW2/KcQrqT 57wA05QotcQSqYUp2MLyeZKhF8TSaqMeHm7akaZDmYyDzWZZO8sHuyto2ojhYrJzKM9msvkb bJwj2BZ156aIHaTsBALFwyISyKBs/J9JRYd5wRI6XAxmDtwk2JkcwZYpe0fCYkLDgzTgGwdf EN+YIBzoeQssN+hhKpEhMmF15vZnNcRAviPLrBuiaBBLwyiY2CTyYQo+0LULLBKfKBJWBOKI /9m/jDpYSeBgGQYiDoedJGK0zP73WiK+bRTcjQIHOxiH8mA/EYYHqXzwF+lgGQ60M2wHJ00h lR1Wl7+3j6u7HuG+3Xrwe/Wb1TMGOS5mHepO9axdPbfPE+d7PW/z8cdfJ8J9r3qGTCh1qTd6 Vjbn1toTG6b+qXDeN8eWjslaOH9B2Yek56Y9t2vais7nH13zxD/iROk2Z01NS1n5enzWZ+1r 39o71hVSoBn52d/40zf56TtPV7RRLViZ5ASKF5i/t7WSAIoEAAA= Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Resolution services (was: Re: suggested change for -12 of rfc2141bis section 7.3.6) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 10:46:53 -0000 John, On Friday, May 29, 2015 2:33 PM, John C Klensin wrote: >=20 > It is possible that we are arguing about an already-solved > problem here. Or not... see below. >=20 > --On Thursday, May 28, 2015 18:17 -0600 Peter Saint-Andre - &yet > wrote: >=20 > >>> I seem to be in the rough about my desire to remove all > >>> discussion of resolution from the syntax and registration > >>> specification. Every time we talk about resolution, we seem > >>> to fall down a rat hole of unusual size. Since we're not > >>> replacing RFC 2276 in parallel with replacing RFC 2141 and > >>> RFC 3406, I feel like we're flying blind with respect to all > >>> resolution-related topics. > >> > >> If I understand you correctly, your suggestion is concentrate > >> on syntax (and as little semantics as possible) making > >> 2141bis fly as soon as possible. Once that is done, we go on > >> to revise 3406. WFM. That said, I don't think we can specify > >> registrations procedures without discussion resolution since > >> one important aspect of persistent naming is the ability to > >> find the named object through its name. And in most cases > >> this is done through some kind of lookup service and it is > >> indeed an important question who has the canonical registry. > >> I don't think we can offload that on to IANA... > > > > I'm suggesting that we concentrate on syntax (2141bis) and > > namespace registrations (3406bis) - those are easier to > > specify because we have more experience with them. We don't > > have experience with URN resolution or at least those folks > > haven't been involved here, so I suggest that we updated RFC > > 2276 separately and address the resolution-related topics then. >=20 > Let me try this a slightly different way, but reaching the same > conclusion. As Peter points out, we know, or are close to > knowing, how to update and replace 2141 and 3406. We also have > very specific problems that we are trying to solve. In the case > of 2141, allowing, for various reasons and in response to > various requirements, more syntax than 2141 permits: the things > we've been calling q-components and r-components; the > f-components / fragments that some of the opinions on RFC 3986 > claim that 2141 could not disallow if it wanted to; and either > the use of the "/" within the NSS or p-components. In the case > of 3406, it establishes a registration procedure for namespaces > that has been perceived as sufficiently onerous to discourage > namespaces from being registered, something I think we've > concluded is a bad idea. Indeed... > Now, if we start looking at resolution, we end up not only in > the territory of 2276 but also 3401ff. There are some > historical issues with 2277 related to how much consensus it > represented at the time and how informed that consensus was. It > is an Informational, rather than a Standards Track, document, > which may or may not mean much. More important today, 3401 > (and 3402-3405) claim to be a more or less consistent > implementation spec for the ideas in 2276, modifying those ideas > slightly in the process. With the exception of one, non-URN, > application, DDDS has not been broadly adopted or used. > Anything that was proposed today and based on any of those specs > would almost certainly have to include specific analysis of the > architecture and implementations and what had and had not > succeeded. To the best of my knowledge, no one has started that > work or even volunteered to do it. OK, I got that. I guess that my (and most people from outside of IETF) only= think of http-based resolution, e. g. http://nbn-resolving.org. >=20 > At the same time, most of the URNs we have seen in active use > either don't need resolution services or use resolution > mechanisms intrinsic in other standards or protocols. URNs used > in XMPP, ISBN and ISSN, and XML all come immediately to mind as > examples. The Finnish urn resolver does support Finnish ISBNs: http://urn.fi/URN:ISBN= :952-10-0093-7 but that is probably an exception to the rule.=20 >=20 > I think Keith's most recent comments > (http://www.ietf.org/mail-archive/web/urn/current/msg03076.html) > are largely consistent with the above although his perspective > is different. >=20 > Briefly addressing a more recent note: >=20 > --On Friday, May 29, 2015 07:35 +0000 "Svensson, Lars" > wrote: >=20 > > But can we really specify the registration procedure without > > asking the registrants to say anything about resolution > > services? >=20 > I think we have little choice, for the reasons outlined above > and in Keith's and Peter's notes. However, we provided some > time ago for comments about resolution when those are > appropriate and I haven't seen proposals to remove those > provisions. See in particular (in > draft-ietf-urnbis-rfc2141bis-urn-11): >=20 > Section 7.1, numbered item 6 and > Section 7.3.6 >=20 > I've expressed some concerns earlier about the second paragraph > of the latter because of the interaction and reference to 2276 > (for the reasons above), but don't recall anyone else expressing > interest in that issue. However, it seems to me that this text > provides mechanisms that allow a registration to say any of the > following in the registration specification: >=20 > (i) This namespace is indicator-only and unlikely to be > resolved (or resolution would be meaningless). > (ii) Resources associated with this namespace are > located and resolved according to the mechanism > specified in ... > (iii) While the identifier is universal and persistent, > registration is likely to be a local matter. > (iv) We know what these are, aren't ready to say > anything general about resolution yet, but will update > the registration when we figure that out. > (v0 ... and so on >=20 > It seems to me that provides a way to record whatever > information is known and which the registrants think is > appropriate to supply while avoiding unrealistic requirements > to specific things that neither we nor the registrant knows or > requiring that all URNs be resolvable or resolvable in one of an > enumerated set of ways. >=20 > What else do you think is both useful and feasible? Is the > current text ok or would you suggest improvements, particularly > to say either more or less? No, the current text sounds feasible. I guess the reviewers will look caref= ully at that section. Best, Lars=20 From nobody Mon Jun 1 04:34:28 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E271A0155 for ; Mon, 1 Jun 2015 04:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM-rWdODb8kE for ; Mon, 1 Jun 2015 04:34:14 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 369E71A0115 for ; Mon, 1 Jun 2015 04:34:14 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 92B768B019; Mon, 1 Jun 2015 13:34:13 +0200 (CEST) X-AuditID: 0a453fe7-f79136d0000011d7-55-556c43351f4b Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id A9.F2.04567.5334C655; Mon, 1 Jun 2015 13:34:13 +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.03.0181.006; Mon, 1 Jun 2015 13:34:12 +0200 From: "Svensson, Lars" To: "Leslie Daigle (ThinkingCat)" , John C Klensin Thread-Topic: [urn] Re-examining p-components (and "/", hierarchy, and relative references) Thread-Index: AQHQmCXPcfjDkZzFBEmq6mZ5R3u+kJ2QQCkAgABUmgCAAA90AIAAd6KAgAZmeKA= Date: Mon, 1 Jun 2015 11:34:11 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010CF7125D@dnbf-ex1.AD.DDB.DE> References: <666705E5201C2C1889DF193A@JcK-HP8200.jck.com> <55312E53.2010605@thinkingcat.com> <55652D6F.3050506@andyet.net> <6C54139B-45A0-4D15-A63F-32F03540A961@thinkingcat.com> <55668636.5030604@andyet.net> <8974ECB12DBFCD57CF72D435@JcK-HP8200.jck.com> <1730CA74-D57F-4D25-A3A0-0183EBB8D860@thinkingcat.com> In-Reply-To: <1730CA74-D57F-4D25-A3A0-0183EBB8D860@thinkingcat.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12TWUwTURSGczvTdqi9eC3QXquiLRqjCYuJSzUIKhowoJJIjRvBwQ5tpUAz 0xLwCYIrxh0wErcIuD4AatxQow2LEgEFoyYqEXCJimtsjIrEWVoovJ35zvn/85/cDEVoiig9 Zc91MWwu7TAqVKRqWbw3ck6CwxzTeGKyaXvngMJ0u6aWMLX2NhKm8pJvskVkUvvLp8qk6urf sqSu85+IpN4jZ+Wp5HpVrIVx2PMZNjpuk8rW0dNMOvu1Bfd6XiuLwCltKQiiMJqNB/f2EVKt xY+6axWlQEVpUCPAzy8fk0kfVwE+8+UJ31FSCjQTf7UJ86GIxlea2pRCTaCVuL+6TPQJQRvx 588/FNJMOv7b1gWkeiXe//CYyEk0FX862SJqIUrG9cUX5dKqWzJ88V6Z2AhCCdhbX08KNUCT cF1dByEt0+FL737JpdAIV9/q8B0Qhj/0Dfq4Ad/eLeSn+PkZuPZmtCQ14LI9Pb694/CDo2/I A0BbGeBaOayoDFBUBihOAfICCOZyrLOiaEuUxZIZZWEuAemp3l8H+zqXegCigFENf5ZnmzVy Op8rzPGAVZTMGAbTvvMoODPPUmijOVsG63YwnDEUZi92mDVwCGe6HdnGcHg+y27W6IYo5+ac 9s32PDeX4WYdHoApgpfKFgpSC124lWHzJEMPmECRRh082FCcpkFW2sVkM4yTYf3dtRRlxJAT do5jGStTkGV3uPxtXtcZz3dQYEcMZIDlQiB9YGN0JhkV5AEplJoP1iTexDnpHM5u9XmHwMkC Vfup6DsJdgu+Wj8c6dkKVut1MFOQIWHC5s4dyqrXQrZni1kzNqAhWOqnwMgGno8P4CNdP4Ll /BOFwGYxDv/DDWfUQOsSHo7xQTHiRNgrRAzzsdFeKfzbhsKdSDzYRbsCD/4jCNV+6jvYKx3s gyPt9EUA/EtdF1nc37d1iTquKmXetWelJctgePBAS8GdBNegZX5D4lPvjpqIaem6KuW59scx r/JfjC+9sX7BjbS68K7D214Hf4jzLogwJHMxG9n0XeiE9lDZ6QPJKRVvN6yYbqjaH5vw5/jc 7oiK+29ynF1318wpbk2ML9zXn2ga2K2Vr1O3FhhJzkbPmkmwHP0fwWOrQJMEAAA= Archived-At: Cc: "urn@ietf.org" , Peter Saint-Andre - &yet Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 11:34:19 -0000 T24gVGh1cnNkYXksIE1heSAyOCwgMjAxNSAxOjEwIFBNLCBMZXNsaWUgRGFpZ2xlIHdyb3RlOg0K PiANCj4gQXMgSSB1bmRlcnN0YW5kIGl0ICh3aGljaCBtYXkgYmUgd3JvbmcpLCB0aGUgcmVhbCBk ZXNpcmUgaW4gVVJOQklTIGhhcw0KPiBiZWVuIHRvIGJlIGFibGUgdG8gaGF2ZSDigJwv4oCcLCBu b3QgYSBiZWxpZWYgaW4gdGhlIG5lZWQgZm9yDQo+IOKAnHAtY29tcG9uZW50c+KAnSBvciByZWxh dGl2ZSBVUk5zICh3aGljaCBhcmUsIGFzIHlvdSBub3RlLCBkaWZmZXJlbnQpLg0KDQpUaGF0IGlz IGF0IGxlYXN0IG15IGRlc2lyZS4NCg0KPiBXaXRoIHRoYXQ6DQo+IA0KPiBPbiAyOCBNYXkgMjAx NSwgYXQgMDowMSwgSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+IA0KPiA+IC0tT24gV2VkbmVzZGF5 LCBNYXkgMjcsIDIwMTUgMjE6MDYgLTA2MDAgUGV0ZXIgU2FpbnQtQW5kcmUgLQ0KPiA+ICZ5ZXQg PHBldGVyQGFuZHlldC5uZXQ+IHdyb3RlOg0KPiA+DQo+ID4+IE9uIDUvMjcvMTUgNDowMyBQTSwg TGVzbGllIERhaWdsZSAoVGhpbmtpbmdDYXQpIHdyb3RlOg0KPiA+Pj4NCj4gPj4+IE15IHJlY29s bGVjdGlvbiBhbGlnbmVkIHdpdGggS2VpdGgncyDigJQgdGhhdCB3ZSBhZ3JlZWQgdG8NCj4gPj4+ IGRvIGF3YXkgd2l0aCBwLWNvbXBvbmVudHMuICAgRGlnZ2luZyBiYWNrLCBoYXZlIGEgbG9vayBh dCB0aGUNCj4gPj4+IHRocmVhZCB0aGF0IHN0YXJ0ZWQgd2l0aCBLZWl0aCdzIG1lc3NhZ2Ugd2l0 aCBzdWJqZWN0DQo+ID4+PiAic3VnZ2VzdGVkIHRleHQgY2hhbmdlcyBmb3IgLTEyIG9uIHAtY29t cG9uZW50cywgZi0gYW5kDQo+ID4+PiBxLWNvbXBvbmVudHMgaW4gVVJOIHJlc29sdXRpb24sIGFu ZCByZWxhdGl2ZSByZWZlcmVuY2VzIi4NCj4gPj4+DQo+ID4+PiBJdCBtYWRlIHNlbnNlIHRvIEtl aXRoLCBtZSwgSnVoYSBhbmQgU3ZlbiBhdCB0aGUgdGltZSwgaXQNCj4gPj4+IHNlZW1zLiAgKEFu ZCBpdCBzdGlsbCBtYWtlcyBzZW5zZSB0byBtZSwgRldJVyA6XikgKS4NCj4gPj4NCj4gPj4gQXMg SSByZWNhbGwsIHdlIGdvdCByaWQgb2YgcC1jb21wb25lbnRzIGJ1dCBkaWRuJ3QgZGlzYWxsb3cN Cj4gPj4gIi8iIGluIHRoZSBOU1MuIEEgcm9zZSBieSBhbnkgb3RoZXIgbmFtZS4uLg0KPiA+DQo+ ID4gU28sIHdlIGFsbG93ICIvIiwgd2UgZG9uJ3QgdHJlYXQgaXQgaW4gYW55IHdheSBhcyBhIHNw ZWNpYWwNCj4gPiBkZWxpbWl0ZXIgdGhhdCBzZXJ2ZXMgdGhlIGRlbGltaXRlciBmdW5jdGlvbiBk ZXNjcmliZWQgaW4NCj4gPiBTZWN0aW9uIDEuMi4zIG9mIFJGQyAzOTg2LCBicmVha3MgdGhlIG9w YWNpdHkgZGlzY3Vzc2VkIGluIHRoZQ0KPiA+IGxhc3QgcGFyYWdyYXBoIG9mIHRoYXQgc2VjdGlv biBhbmQgYnJlYWtzIHRoZSBwYXRoIGludG8gc2VnbWVudHMNCj4gPiByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgd2UgaW50ZXJwcmV0IHRob3NlIHNlcGFyYXRlbHkuDQo+IA0KPiBJIGRvbuKAmXQgYmVs aWV2ZSB0aGF0IGlzIHRoZSBjYXNlIGluIHdoYXQgd2UgZGlzY3Vzc2VkIG9uIHRoYXQgdGhyZWFk DQo+IOKAlCBiZWNhdXNlIHRoZSBiZWxpZWYgYW5kIGV4cGVjdGF0aW9uIGlzIHRoYXQg4oCcL+KA nCBhcHBlYXJzIGluIHNpbmdsZQ0KPiBpbnN0YW5jZXMgd2l0aGluIHRoZSBOU1MsIGFuZCB0aGUg d2hvbGUgc3RyaW5nIGlzIHRyZWF0ZWQgYXMNCj4g4oCccGF0aC1yb290bGVzc+KAnS4NCj4gDQo+ IEFzIEkgd3JvdGUgYXQgdGhlIHRpbWUg4oCUIEkgYW0gbm90IGEgVVJJIHBhcnNlciBhbmQgSSBz dGlsbCB3b3VsZG4ndA0KPiBvYmplY3QgdG8gaGVhcmluZyBjb25maXJtYXRpb24gZnJvbSBzb21l b25lIHdobyBkb2VzIGRlYWwgaW4gbm9uLVVSTiBVUkkNCj4gcGFyc2luZyBmb3IgYSBsaXZpbmcu DQoNCldlbGwsIHBhdGgtcm9vdGxlc3MgaXMgZGVmaW5lZCBhcw0KDQpwYXRoLXJvb3RsZXNzCT0g CXNlZ21lbnQtbnogICAqKCAiLyIgICBzZWdtZW50ICkNCg0Kc28gaXQgX2RvZXNfIHNwbGl0IGlu dG8gc2VnbWVudHMuIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhhdCBicmVha3MgdGhlIG9wYWNp dHkgb2YgcmZjIDM5ODYgwqcxLjIuMywgdGhvdWdoLiBDb3VsZCBzb21lb25lIHBsZWFzZSBleHBs YWluPw0KDQpUaGFua3MsDQoNCkxhcnMNCg== From nobody Mon Jun 1 22:16:12 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E49A1A0078 for ; Mon, 1 Jun 2015 22:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_yJ20tFvIul for ; Mon, 1 Jun 2015 22:16:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5041A003A for ; Mon, 1 Jun 2015 22:16:08 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YzeYW-0002Ra-8e; Tue, 02 Jun 2015 01:16:04 -0400 Date: Tue, 02 Jun 2015 01:15:59 -0400 From: John C Klensin To: "Svensson, Lars" , Peter Saint-Andre - &yet Message-ID: In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010CF711DC@dnbf-ex1.AD.DDB.DE> References: <55430DDE.5070104@network-heretics.com> <5564FD3F.9070302@andyet.net> <55668540.90804@andyet.net> <24637769D123E644A105A0AF0E1F92EF010CF6F040@dnbf-ex1.AD.DDB.DE> <5567B021.3060401@andyet.net> <08B0499456635B130B203DEE@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EF010CF711DC@dnbf-ex1.AD.DDB.DE> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Resolution services (was: Re: suggested change for -12 of rfc2141bis section 7.3.6) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 05:16:11 -0000 Lars, --On Monday, June 01, 2015 10:46 +0000 "Svensson, Lars" wrote: >... >> Now, if we start looking at resolution, we end up not only in >> the territory of 2276 but also 3401ff. There are some >> historical issues with 2277 related to how much consensus it >> represented at the time and how informed that consensus was. >> It is an Informational, rather than a Standards Track, >> document, which may or may not mean much. More important >> today, 3401 (and 3402-3405) claim to be a more or less >> consistent implementation spec for the ideas in 2276, >> modifying those ideas slightly in the process. With the >> exception of one, non-URN, application, DDDS has not been >> broadly adopted or used. Anything that was proposed today and >> based on any of those specs would almost certainly have to >> include specific analysis of the architecture and >> implementations and what had and had not succeeded. To the >> best of my knowledge, no one has started that work or even >> volunteered to do it. > > OK, I got that. I guess that my (and most people from outside > of IETF) only think of http-based resolution, e. g. > http://nbn-resolving.org. Ah. The piece of explanation I left out. If one is going to do "http-based resolution", one can ultimately do one of four classes of methods (or, as noted below, a combination of them). (I'm going to ignore namespaces that don't resolve in this note, which doesn't imply they aren't important or, indeed, that tricks can't be invented to accommodate them in any or all of the approaches that follow.) (i) Bind the resolution domain tightly to the namespace at resolution time and permanently so that the URN becomes little more than an abbreviation. In other words and doing a bit of handwaving, urn:example-namespace:foo-bar-baz would be registered as using, e.g., "namespace.example.net" as a resolver and would then be equivalent to something like: http://namespace.example.net/example-namespace?foo-bar-baz dealing with the additional syntax options we expect to have in 2141bis would require more conventions about syntax and more handwaving, but is not a difficult problem. I note that this sort of registration-time tight binding/ abbreviation model violates several people's assumptions about what persistence is all about. In particular, if the existence and utility of the "namespace.example.net" domain cannot be guaranteed for a very long time for the "example-namespace" NID and similarly for all other NIDs, the approach doesn't meet their criteria for persistent URHs. In addition, finding the binding itself either requires that it be included in the code of any system that intends to use/allow that namespace or that a real-time lookup be performed on the contents of an IANA registry that maps namespaces to resolvers. The former would eliminate the possibility of doing anything generic with URNs because a system would have to reject any URN containing an NID it didn't recognize. The latter would require, not only resolution-time access to an IANA registry (something IANA generally has not allowed for technical reasons) and, if the registry entries are allowed to be changed/updated, models for synchronization and timeouts so that caches of the registries work (that is one of those technical reasons). (ii) In a different, but potentially somewhat more persistent and useful, variation on "really just an abbreviation", adopt a model that has recently come up as the "useless prefix" theory, e.g., urn:example-namespace:foo-bar-baz would really be a different way to write example-namespace:foo-bar-baz or example-namespace://namespace.example.net/foo-bar-baz or some such thing. Those are obviously not "http resolution" unless they introduced another level of indirection. They are, however, the only options that introduce the level of opacity some of us have sometimes argued for without running afoul of restrictions in RFC 3986 in a major way (given some recent discussions, even this option wouldn't help with fragments and maybe some other things). (iii) Bind namespaces to a general-purpose namespace resolution mechanism that can supply information about where to find a resolver and the instructions to give it. DDDS is a member of this family. To all intents and purposes, the form of it that has been fully specified, implemented, and deployed operates by associating an NID, for instance "exampleNID", with a domain name in a subtree reserved for that use, for instance something like "exampleNID.urn.arpa". That domain name "owns" records that provide one or more substitution templates that define how to map the NSS (and, presumably, other information) associated with the NID (and maybe the NID string itself) into a URI or preferential list of URIs. At the time 2276, and especially 3401ff, were written, many people assumed that _all_ namespaces using the "urn:" scheme would behave this way, i.e., that this approach is very similar to the first one but loosens the binding between namespace and actual resolver by introducing an intermediate level resolver-finding and syntax-finding layer, thereby eliminating the most important of the persistence problems. When combined with the observation that not all URNs used today work that way, that view of things is one of the reasons I (and maybe others) periodically make comments that we should have left "URN" as an abstract term paralleling "URL" and used something like "ddds:" where we now use "urn:" and expect that treatment. In more practical form, it is a key reason why discussions about putting strong references to 2276 and/or 3401 into 2141bis cause me (at least) some anxiety. (iv) Something else, in which the binding between the URN and some HTTP URL, or for that matter, other URLs or actions is left to other specifications. This is where ISBN is one of a family of useful examples. Without affecting the integrity or persistence of the urns with an NID of "isbn", one can use and interpret such a URN as an abstract identifier suited mostly for identity tests but not resolved; as something that is resolved locally to an inventory number, accession number, shelf or bin, or other locator (more typically using a database lookup than anything necessarily involving HTTP or other URIs); or mapped (back?) into, e.g., a {publisher, title, edition, binding, medium}-tuple by an ISBN-specific resolution method reliant either on a centralized database or walking the country-publisher tree and then asking the publisher. The last of these lends itself nicely to http URIs but certainly does not require them (and I think your example of urn.fi below is an excellent example). At present and modulo a lot of handwaving, we seem to be at the fourth option even though some of us would like to see more generic approaches along the lines of (iii) for some or all URN namespaces and, while some of us understand the issues better then we did a few weeks ago, there is probably some lingering disagreement about how necessary, desirable, or feasible it is to limit flexibility in the namespace -> resolver -> object bindings. A different version of the latter is that, if you create a namespace and define it as associated with a certain resolution mechanism or type of resolution mechanism, is it appropriate for me to substitute a resolution mechanism of my own for either my or more general purposes. We also don't have strong agreement about how much information about resolution should be allowed or required in the IANA registration template. >> At the same time, most of the URNs we have seen in active use >> either don't need resolution services or use resolution >> mechanisms intrinsic in other standards or protocols. URNs >> used in XMPP, ISBN and ISSN, and XML all come immediately to >> mind as examples. > > The Finnish urn resolver does support Finnish ISBNs: > http://urn.fi/URN:ISBN:952-10-0093-7 but that is probably an > exception to the rule. Depends on which rule. Using the typology above, this is a mixture between method (i) (i.e., "the URN is just an abbreviation") and method (iv) (i.e., "the information is obtained externally", in this case what domain goes into the template URL). But that example also points out why (iv) is not, in practice, as bad an idea as it probably seemed when RFC 2276 was written. I don't want to get confused with what actually happens with ISBNs (and, in particular, the question of what the resolver at urn.fi does with non-Finnish ISBNs and namespaces it has never heard of), so suppose we had an International Non-Standard Example Number (INSEN), an INSEN management agency, and a URN namespace with NID "insen". Suppose that the management agency established a resolution convention such that resolvers for urn:insen:whatever-goes-in-the-NSS used the form http:///urn:insen:whatever-goes-in-the-NSS and also established conventions about how those resolvers worked, including conventions about what to do if the first 10 characters in the path were not "urn:insen:". Now, they might also have a registry of resolvers that were certified as following their rules, but you, as someone looking up one of these insen URNs, ultimately just have a trust issue: you would need to trust that whatever resolver you decided to use would return correct results, that any resolvers you used (perhaps as fallback or load-sharing) would return compatible or identical results, and you just wouldn't call on any resolvers you didn't trust. If you decided to delegate that trust problem to the management agency and its list... well, up to you. And none of that needs to be part of the URN spec. By the way, as a design issue for the long term, I think that using a little depth in the domain tree such that, e.g., for the resolvers for the URN namespace "penguin", it would be better to look for http://penguin.urn.aq/penguin-registration-number or http://penguin.urn.ar/penguin-registration-number etc. rather than http://urn.aq/urn:penquin:penguin-registration-number The deeper domain structure probably be a better idea, if only because the user would get a much faster and more clear indication if the appropriate resolver database were not present, as I expect it might not be for http://urn.fi/urn:penquin:penguin-registration-number or http://urn.aq/urn:tiger:tiger-registration-number >... >> What else do you think is both useful and feasible? Is the >> current text ok or would you suggest improvements, >> particularly to say either more or less? > > No, the current text sounds feasible. I guess the reviewers > will look carefully at that section. Thanks. best, john p.s. Perhaps it is just because I've been thinking about this too much, but I wonder if we've got enough confusion about these issues that it would be useful to have some of the above information organized and written down in more accessible form than this message and its predecessor. Especially with my co-editor hat momentarily on, I'd hate to clutter 2141bis up with it, but, if anyone feels strongly that it should be preserved, we could probably organize an informational document fairly quickly, much more so if someone else volunteered to at least collaborate on the work. From nobody Tue Jun 2 06:20:55 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24081A6FEE for ; Tue, 2 Jun 2015 06:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhbWf6frSGVz for ; Tue, 2 Jun 2015 06:20:54 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4B1A1BD2 for ; Tue, 2 Jun 2015 06:20:54 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 9A60F2005D921; Tue, 2 Jun 2015 06:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=y74wjbs6lgFJtr xpX8cw+3Asth4=; b=PK15QVcZFbR1cNEIWlalrkaVIEhHaUWi6jA3bFUpFV0aBz Ix8fw67B/R4MXKpUw1ZEyzzxWKBL9HULdSIbvgkP7yEpkxzZg7wpb7/T5M5PJKgV BEle4WuS1xANih5wBeAcE6N620/sWjB8FHoESqkiq26pVQmLTHBx6OgZixltI= Received: from [192.168.1.106] (stjhnbsu0nw-142167242073.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.242.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id A57AE2005D82C; Tue, 2 Jun 2015 06:20:52 -0700 (PDT) From: "Leslie Daigle (ThinkingCat)" To: "urn@ietf.org" Date: Tue, 02 Jun 2015 09:20:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed X-Mailer: MailMate (1.9.1r5084) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:20:55 -0000 Some of John=E2=80=99s comments through the last week have caused me to h= ave a=20 sense of deja vu and also to wonder what is a standard, anyway. I think John and I agree on facts but diverge in conclusion. [John Klensin wrote, on another thread:] > At the time 2276, and especially 3401ff, were written, many > people assumed that _all_ namespaces using the "urn:" scheme > would behave this way, i.e., that this approach is very similar > to the first one but loosens the binding between namespace and > actual resolver by introducing an intermediate level > resolver-finding and syntax-finding layer, thereby eliminating > the most important of the persistence problems. My perspective is that we didn=E2=80=99t only assume that, we believed th= at=20 the URN standard was the syntax plus the means of finding the resolution=20 system (DDDS). 20 years ago, we were at least as stuck on the questions of =E2=80=9Cwhat= =E2=80=99s=20 a name=E2=80=9D and =E2=80=9Chow do you achieve persistence=E2=80=9D as w= e are today in=20 this discussion. Can you achieve it with sub-second resolution=20 (Mitra-just-Mitra=E2=80=99s requirement); can you prove it will persist, = etc. It seems the IETF is not very good at finding answers to information=20 system questions. We only broke free of the log jam in the=20 then-Applications Area when we found a technical framework to specify. =20 Given the URN (syntax), what would be standard operations on it (DDDS). And, we (the IETF) called that the URN standard. > > When combined with the observation that not all URNs used today > work that way, that view of things is one of the reasons I (and > maybe others) periodically make comments that we should have > left "URN" as an abstract term paralleling "URL" and used > something like "ddds:" where we now use "urn:" and expect that > treatment. In more practical form, it is a key reason why > discussions about putting strong references to 2276 and/or 3401 > into 2141bis cause me (at least) some anxiety. Indeed, we probably should have done that. But, we didn=E2=80=99t. And,= here=20 we are. I believe that, if you want to deprecate DDDS in its role for URNs, that=20 takes an IETF standards action. If this group wants to solve the information systems problems of naming=20 in the Internet differently, then it probably needs to call them=20 something _else_ at this point. Leslie. --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- From nobody Tue Jun 2 07:45:37 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937981ACD34 for ; Tue, 2 Jun 2015 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyZMeTlPtzFr for ; Tue, 2 Jun 2015 07:45:34 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05801ACD33 for ; Tue, 2 Jun 2015 07:45:33 -0700 (PDT) Received: by igblz2 with SMTP id lz2so12288368igb.1 for ; Tue, 02 Jun 2015 07:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qnm+CqTcJz9BbRSTBFutG/Ui9DUpQB/n1miO9xpYDEc=; b=RJlMmdooN1jYw28eTazY5IhIdBk9UjHZSBdP0MsRszFh5DBE7yHmj1pAJCrXPDqtm4 Yv/cmwB3AmDwcsmw3JZ78YPNqtHKwxAC6qWrOS+G0FZjK0cHwFjfEmHTqZT67g6facoY uHGCtKXEMdYP0QutbS/sEOaaE4g81Gi1VkBLmP2eMcrxz0jvBCJafUsixqEMZaaP8dlL mAiHwj6iYQ2MNse+M0NQCYxYyKC+41VC3MdS3L0aZBEmzSxbmgNu+TQSi4O094bcPFKX O2I8bKKEJ9jmo0207/vZ6Bm947Rqhjl9OBlcXgO3wjri+rtUEeiKyPXi/3OZivJUqDw8 j6jQ== X-Gm-Message-State: ALoCoQnOrfGAmzXHrJSLhzIQO8fHdsUYks4rrB+pLJ5ZVCFZVD01pOcM3GR5AHI0WIUInni9nKX7 X-Received: by 10.107.17.161 with SMTP id 33mr34434129ior.48.1433256333456; Tue, 02 Jun 2015 07:45:33 -0700 (PDT) Received: from aither.local ([2601:1:8200:3a60:8919:e8ec:2b0:bc88]) by mx.google.com with ESMTPSA id qs10sm10093871igb.14.2015.06.02.07.45.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2015 07:45:32 -0700 (PDT) Message-ID: <556DC18B.4050804@andyet.net> Date: Tue, 02 Jun 2015 08:45:31 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Leslie Daigle (ThinkingCat)" , "urn@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:45:36 -0000 On 6/2/15 7:20 AM, Leslie Daigle (ThinkingCat) wrote: > > Some of John’s comments through the last week have caused me to have a > sense of deja vu and also to wonder what is a standard, anyway. > > I think John and I agree on facts but diverge in conclusion. > > [John Klensin wrote, on another thread:] >> At the time 2276, and especially 3401ff, were written, many >> people assumed that _all_ namespaces using the "urn:" scheme >> would behave this way, i.e., that this approach is very similar >> to the first one but loosens the binding between namespace and >> actual resolver by introducing an intermediate level >> resolver-finding and syntax-finding layer, thereby eliminating >> the most important of the persistence problems. > > My perspective is that we didn’t only assume that, we believed that the > URN standard was the syntax plus the means of finding the resolution > system (DDDS). > > 20 years ago, we were at least as stuck on the questions of “what’s a > name” and “how do you achieve persistence” as we are today in this > discussion. Can you achieve it with sub-second resolution > (Mitra-just-Mitra’s requirement); can you prove it will persist, etc. > > It seems the IETF is not very good at finding answers to information > system questions. We only broke free of the log jam in the > then-Applications Area when we found a technical framework to specify. > Given the URN (syntax), what would be standard operations on it (DDDS). > > And, we (the IETF) called that the URN standard. Clearly I need to re-read all of the relevant documents (I suppose that would be at least RFCs 2168, 2915, 2276, 3401-3406 - any others?), because I haven't know about that original intent until just now. >> When combined with the observation that not all URNs used today >> work that way, that view of things is one of the reasons I (and >> maybe others) periodically make comments that we should have >> left "URN" as an abstract term paralleling "URL" and used >> something like "ddds:" where we now use "urn:" and expect that >> treatment. In more practical form, it is a key reason why >> discussions about putting strong references to 2276 and/or 3401 >> into 2141bis cause me (at least) some anxiety. > > Indeed, we probably should have done that. But, we didn’t. And, here > we are. > > I believe that, if you want to deprecate DDDS in its role for URNs, that > takes an IETF standards action. Perchance. But does updating the URN syntax document require us to revisit the entire "system" as you have outlined it above? > If this group wants to solve the information systems problems of naming > in the Internet differently, then it probably needs to call them > something _else_ at this point. That's sounds like a larger effort than anyone has energy for. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Jun 2 10:42:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1BC1ACE34 for ; Tue, 2 Jun 2015 10:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5DhbZXMAc44 for ; Tue, 2 Jun 2015 10:42:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3B21ACE30 for ; Tue, 2 Jun 2015 10:42:14 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YzqCa-0003wY-IF; Tue, 02 Jun 2015 13:42:12 -0400 Date: Tue, 02 Jun 2015 13:42:07 -0400 From: John C Klensin To: "Leslie Daigle (ThinkingCat)" , urn@ietf.org Message-ID: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 17:42:17 -0000 --On Tuesday, June 02, 2015 09:20 -0400 "Leslie Daigle (ThinkingCat)" wrote: > Some of John's comments through the last week have caused me > to have a sense of deja vu and also to wonder what is a > standard, anyway. > > I think John and I agree on facts but diverge in conclusion. Or maybe not even completely about the facts and conclusions, because some of the actual text is inconsistent with your thinking at the time (as you report it and that I have no reason to question). > [John Klensin wrote, on another thread:] >> At the time 2276, and especially 3401ff, were written, many >> people assumed that _all_ namespaces using the "urn:" scheme >> would behave this way, i.e., that this approach is very >> similar to the first one but loosens the binding between >> namespace and actual resolver by introducing an intermediate >> level resolver-finding and syntax-finding layer, thereby >> eliminating the most important of the persistence problems. > > My perspective is that we didn't only assume that, we > believed that the URN standard was the syntax plus the means > of finding the resolution system (DDDS). Rather than quibble about "we", let's assume that for now (I question it further below). Then, from my perspective, "we" have an interesting problem or set of problems. The XML community has created URIs using the "urn:" scheme that ignore that standard/connection. The XMPP community has created URIs using the "urn:" scheme that ignore that standard/connection. So has the library community and a bunch of others. There are millions of URNs out there that do not use DDDS and therefore do not conform, almost certainly far more, and far more visible, than the URIs with scheme "urn:" that do conform to the DDDS linkage. So, what should we do? (1) One option is to freeze things as they are, reaffirm the linkage, tell everyone with those other uses that they are non-conforming, evil, and should, in the words of a recent draft, get off the URN lawn. (2) Another is to accept the breaking of that linkage as a fact on the ground, construct a 2141bis that makes clear that DDDS is one way to resolve URNs, that there are other ways, and that there are some UNRs that are really indicators, flags, or abstract designators that don't resolve. (3) A third is to become even more aggressive than the second, assume that, after more than a dozen years after 3401ff were published, the IETF has some obligations to the opposite of "[deployed and] running code". With this option, we recognize how little DDDS has been used for URNs in practice. We also note that no one to my knowledge has even discussed updates to 3401ff (including 3406) that would supply enough definitional material to pass the pieces of a URN parse tree that contained some or all of r-components, q-components, or f-components into an RFC 3402 regular expression, much less analyzed how pieces of r-components that specify resolver instructions or actions would mesh with the DDDS discovery model. The logical result there would be an Applicability Statement about the relationship between the "urn:" scheme and DDDS that is consistent with common practice as of 2015 and reasonably expected practices going forward. I don't know whether development of that A/S would require protocol work leading to DDDSbis or not; I do know that neither is on the WG's charter at present. FWIW, I note that the likely, almost certain, consequence of choice one would be that those other communities would say some rude words about us and/or the IETF and then proceed to do whatever seems sensible to them. > 20 years ago, we were at least as stuck on the questions of > "what's a name" and "how do you achieve persistence" > as we are today in this discussion. Can you achieve it with > sub-second resolution (Mitra-just-Mitra's requirement); can > you prove it will persist, etc. Yes, I have noticed that. > It seems the IETF is not very good at finding answers to > information system questions. But good at getting itself into places that require answers to those questions, even the subset of them that what we would now call the information science community (and, in some cases, parts of the philosophy community) concluded centuries ago were unsolvable and/or unanswerable. I'm told that a WG was even shut down over that set of problems. I've believed for years that decision enabled useful progress that was clearly not occurring with the original model. I'm beginning to have my doubts. > We only broke free of the log > jam in the then-Applications Area when we found a technical > framework to specify. Given the URN (syntax), what would be > standard operations on it (DDDS). > > And, we (the IETF) called that the URN standard. And yet we failed to update 2141 to say "it isn't a URN if it doesn't use DDDS". The Knoxville report (reference [7] in RFC 3404, http://www.dlib.org/dlib/february96/02arms.html) contains a forward pointer to the DDDS work and some handwaving, but stops far short of establishing or recommending that URNs be limited, even in the short term, to those resolved by DDDS. The DDDS specs tell how to get a record for a particular URN namespace into URN.ARPA and how it is set up (at least given 2141 URN syntax and restrictions), and says that URNs registered according to RFC 3406 are candidates for entries in URN.ARPA [RFC 3405, Section 3.2] but do not impose that registration as even a temporary requirement on something being a valid URNs. RFC 3406 seems quite clear whether what it says was the intended meaning or not: the last paragraph of Section 1 reads: "Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the DDDS system [RFC3401], is necessary. See [RFC3405] for information on obtaining registration in the DDDS global NID directory." That not only doesn't say "it isn't a URN unless it goes through DDDS or is otherwise bound to URN.ARPA", but I take it to mean both that some URNs don't resolve. While it does require that a global NID directory exist, it does not require that there be only one of them, DDDS is identified as an example, not a requirement, and the registration comment is about that particular NID directory only. One could have nailed that situation down further by requiring that all URN NIDs have entries in URN.ARPA for as long as the DNS lasted, established a form of NAPTR record (or some other record) that would have returned a clear "don't even think about resolving this" indication, provided for evolution to records other than NAPTR (something that has mostly been done without explicit binding to URNs), and established a transition procedure for representing the who database in some way alternative to the DNS (i.e., establishing an abstract database and is structures and properties, but making sure that the DNS representa6ation was only one such representation Aside: RFC 3401 and 3403 take some small steps in this direction -- I don't think they are sufficient, but YMMD and I don't think they would be very hard to fix/upgrade. RFC 3986 could also have imposed a requirement, most logically in the section where it says that not all URNs are part of the "urn:" scheme. But it didn't either. So we have had a _lot_ of chances to clearly establish the requirement of a binding between URNs (or resolvable URNs) and "the" IETF-designated NID database. We haven't done so. For the record, I believe that happened because folks were being super-careful to preserve persistence by not tying things to particular formats or mechanisms -- a goal that I support. But the bottom line is that, however much the bindings may have been intended and were considered part of the oral tradition associated with "the URN standard", it just doesn't seem to be in the Standard itself. In other words, while I understand your intent and understanding, nothing in the relevant text(s) seems to me to make DDDS or those linkages a requirement. >> When combined with the observation that not all URNs used >> today work that way, that view of things is one of the >> reasons I (and maybe others) periodically make comments that >> we should have left "URN" as an abstract term paralleling >> "URL" and used something like "ddds:" where we now use "urn:" >> and expect that treatment. In more practical form, it is a >> key reason why discussions about putting strong references to >> 2276 and/or 3401 into 2141bis cause me (at least) some >> anxiety. > > Indeed, we probably should have done that. But, we didn't. > And, here we are. Yes. See three options above. > I believe that, if you want to deprecate DDDS in its role for > URNs, that takes an IETF standards action. I agree. However, possible applicability statements aside (and they require IETF standards actions too), the above, and the present language in 2141bis (and 2141bis and 3406bis before I got involved with the writing) effectively amount to "URNs can use DDDS if they like, but it is not required and no strong recommendation --one way or the other-- is being made." Unless that changes, there may be arguments for either updating or deprecating DDDS (and some of those arguments are at least implicit above), there is no requirement to do so. As a token of good will --which I actually do feel although I fear it isn't clear from this note -- if we can get 2141bis and friends wrapped up and, after that, you decided it was worth revisiting DDDS, cleaning up or clarifying some language that I don't think has stood the course of time, adding bits as needed to accommodate 2141bis URNs rather than just 2141 ones, and making a strong applicability statement, I'd be happy to try to find time to collaborate. I've got a lot of notes from going through the documents in the last few months and can probably find those I made myself during the 1996-2002 period. So far, I think everything necessary could be done from an updating and clarifying document and that actual revision of 3401ff would not be needed -- the task is not monstrous. > If this group wants to solve the information systems problems > of naming in the Internet differently, then it probably needs > to call them something _else_ at this point. Well, sure. But see comments about (1) above including the prediction of likely consequences. I also continue to believe, as I believed when it caused me to take actions long ago that were perceived as precipitous, that we need to figure out how to pragmatically work around those information systems/ information science problems, especially those that represent centuries of experience about things that can be handled by conventions, but not "solved". That belief is based now, as it was then, on a conviction that getting actual solutions to those problems into the critical path will transport us into a rathole of unimaginable depth. best, john From nobody Wed Jun 3 14:35:54 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97DA1B3065 for ; Wed, 3 Jun 2015 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.844 X-Spam-Level: * X-Spam-Status: No, score=1.844 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQtaFZxZ25V2 for ; Wed, 3 Jun 2015 14:35:50 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE621A914D for ; Wed, 3 Jun 2015 14:35:50 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id A5535540A5; Wed, 3 Jun 2015 14:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=Q cLpfi35OOV+vD9RHqvIuFuRYbU=; b=sEfZxol4Xv/ZBy7ixPmWLFx+4QrcuxW4V RYWeLhH0+qETRR21MQ7dQWu3CzDtjVr0z1iitLVk2J+PYf5D34zprXjK1jWFzoR+ 06xpXoDWD53oPFTqq/SK2M0N1agRaO1/TCMPGZvurnUQvUngh6XQtN8i03ilsJ2a zfbH9d3Zes= Received: from [192.168.1.106] (stjhnbsu0nw-142167242073.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.242.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id CD1255409F; Wed, 3 Jun 2015 14:35:48 -0700 (PDT) From: "Leslie Daigle (ThinkingCat)" To: "John C Klensin" Date: Wed, 03 Jun 2015 17:35:46 -0400 Message-ID: <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> In-Reply-To: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed X-Mailer: MailMate (1.9.1r5084) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 21:35:53 -0000 Thanks for the thoughtful reply. As always, a lot to chew on. If I can summarize in tweet-length, I get: URN standard did not write down that they require DDDS Many urn: namespaces diverge from intention; none use DDDS URNs are a concept and a standard What do we do now to align concept, standard and =E2=80=9Curn:=E2=80=9D i= n the wild. As difficult as it is to align =E2=80=9Curn:=E2=80=9D and =E2=80=9Cstanda= rd=E2=80=9D, when we=20 start bringing in =E2=80=9Cconcept=E2=80=9D, we=E2=80=99re cycling, IMO. This is where I have extreme difficulties with Keith=E2=80=99s desire to = have=20 everybody resolving everything, with no one able to preferentially hold=20 metadata for an item: it=E2=80=99s =E2=80=9Cconcept=E2=80=9D. An intere= sting one, but=20 neither where URNs were standardized, nor part of the =E2=80=9Curn:=E2=80= =9D in the=20 wild part of the problem. Leslie. On 2 Jun 2015, at 13:42, John C Klensin wrote: > --On Tuesday, June 02, 2015 09:20 -0400 "Leslie Daigle > (ThinkingCat)" wrote: > >> Some of John's comments through the last week have caused me >> to have a sense of deja vu and also to wonder what is a >> standard, anyway. >> >> I think John and I agree on facts but diverge in conclusion. > > Or maybe not even completely about the facts and conclusions, > because some of the actual text is inconsistent with your > thinking at the time (as you report it and that I have no reason > to question). > >> [John Klensin wrote, on another thread:] >>> At the time 2276, and especially 3401ff, were written, many >>> people assumed that _all_ namespaces using the "urn:" scheme >>> would behave this way, i.e., that this approach is very >>> similar to the first one but loosens the binding between >>> namespace and actual resolver by introducing an intermediate >>> level resolver-finding and syntax-finding layer, thereby >>> eliminating the most important of the persistence problems. >> >> My perspective is that we didn't only assume that, we >> believed that the URN standard was the syntax plus the means >> of finding the resolution system (DDDS). > > Rather than quibble about "we", let's assume that for now (I > question it further below). Then, from my perspective, "we" > have an interesting problem or set of problems. The XML > community has created URIs using the "urn:" scheme that ignore > that standard/connection. The XMPP community has created URIs > using the "urn:" scheme that ignore that standard/connection. > So has the library community and a bunch of others. There are > millions of URNs out there that do not use DDDS and therefore do > not conform, almost certainly far more, and far more visible, > than the URIs with scheme "urn:" that do conform to the DDDS > linkage. > > So, what should we do? > > (1) One option is to freeze things as they are, reaffirm the > linkage, tell everyone with those other uses that they are > non-conforming, evil, and should, in the words of a recent > draft, get off the URN lawn. > > (2) Another is to accept the breaking of that linkage as a fact > on the ground, construct a 2141bis that makes clear that DDDS is > one way to resolve URNs, that there are other ways, and that > there are some UNRs that are really indicators, flags, or > abstract designators that don't resolve. > > (3) A third is to become even more aggressive than the second, > assume that, after more than a dozen years after 3401ff were > published, the IETF has some obligations to the opposite of > "[deployed and] running code". With this option, we recognize > how little DDDS has been used for URNs in practice. We also > note that no one to my knowledge has even discussed updates to > 3401ff (including 3406) that would supply enough definitional > material to pass the pieces of a URN parse tree that contained > some or all of r-components, q-components, or f-components into > an RFC 3402 regular expression, much less analyzed how pieces of > r-components that specify resolver instructions or actions would > mesh with the DDDS discovery model. The logical result there > would be an Applicability Statement about the relationship > between the "urn:" scheme and DDDS that is consistent with > common practice as of 2015 and reasonably expected practices > going forward. I don't know whether development of that A/S > would require protocol work leading to DDDSbis or not; I do know > that neither is on the WG's charter at present. > > FWIW, I note that the likely, almost certain, consequence of > choice one would be that those other communities would say some > rude words about us and/or the IETF and then proceed to do > whatever seems sensible to them. > >> 20 years ago, we were at least as stuck on the questions of >> "what's a name" and "how do you achieve persistence" >> as we are today in this discussion. Can you achieve it with >> sub-second resolution (Mitra-just-Mitra's requirement); can >> you prove it will persist, etc. > > Yes, I have noticed that. > >> It seems the IETF is not very good at finding answers to >> information system questions. > > But good at getting itself into places that require answers to > those questions, even the subset of them that what we would now > call the information science community (and, in some cases, > parts of the philosophy community) concluded centuries ago were > unsolvable and/or unanswerable. I'm told that a WG was even > shut down over that set of problems. I've believed for years > that decision enabled useful progress that was clearly not > occurring with the original model. I'm beginning to have my > doubts. > >> We only broke free of the log >> jam in the then-Applications Area when we found a technical >> framework to specify. Given the URN (syntax), what would be >> standard operations on it (DDDS). >> >> And, we (the IETF) called that the URN standard. > > And yet we failed to update 2141 to say "it isn't a URN if it > doesn't use DDDS". The Knoxville report (reference [7] in RFC > 3404, http://www.dlib.org/dlib/february96/02arms.html) contains > a forward pointer to the DDDS work and some handwaving, but > stops far short of establishing or recommending that URNs be > limited, even in the short term, to those resolved by DDDS. The > DDDS specs tell how to get a record for a particular URN > namespace into URN.ARPA and how it is set up (at least given > 2141 URN syntax and restrictions), and says that URNs registered > according to RFC 3406 are candidates for entries in URN.ARPA > [RFC 3405, Section 3.2] but do not impose that registration as > even a temporary requirement on something being a valid URNs. > RFC 3406 seems quite clear whether what it says was the intended > meaning or not: the last paragraph of Section 1 reads: > > "Note that this document restricts itself to the description > of processes for the creation of URN namespaces. If > "resolution" of any so-created URN identifiers is desired, a > separate process of registration in a global NID directory, > such as that provided by the DDDS system [RFC3401], is > necessary. See [RFC3405] for information on obtaining > registration in the DDDS global NID directory." > > That not only doesn't say "it isn't a URN unless it goes through > DDDS or is otherwise bound to URN.ARPA", but I take it to mean > both that some URNs don't resolve. While it does require that a > global NID directory exist, it does not require that there be > only one of them, DDDS is identified as an example, not a > requirement, and the registration comment is about that > particular NID directory only. One could have nailed that > situation down further by requiring that all URN NIDs have > entries in URN.ARPA for as long as the DNS lasted, established a > form of NAPTR record (or some other record) that would have > returned a clear "don't even think about resolving this" > indication, provided for evolution to records other than NAPTR > (something that has mostly been done without explicit binding to > URNs), and established a transition procedure for representing > the who database in some way alternative to the DNS (i.e., > establishing an abstract database and is structures and > properties, but making sure that the DNS representa6ation was > only one such representation > > Aside: RFC 3401 and 3403 take some small steps in this > direction -- I don't think they are sufficient, but YMMD > and I don't think they would be very hard to fix/upgrade. > > RFC 3986 could also have imposed a requirement, most logically > in the section where it says that not all URNs are part of the > "urn:" scheme. But it didn't either. So we have had a _lot_ of > chances to clearly establish the requirement of a binding > between URNs (or resolvable URNs) and "the" IETF-designated NID > database. We haven't done so. For the record, I believe that > happened because folks were being super-careful to preserve > persistence by not tying things to particular formats or > mechanisms -- a goal that I support. But the bottom line is > that, however much the bindings may have been intended and were > considered part of the oral tradition associated with "the URN > standard", it just doesn't seem to be in the Standard itself. > In other words, while I understand your intent and > understanding, nothing in the relevant text(s) seems to me to > make DDDS or those linkages a requirement. > >>> When combined with the observation that not all URNs used >>> today work that way, that view of things is one of the >>> reasons I (and maybe others) periodically make comments that >>> we should have left "URN" as an abstract term paralleling >>> "URL" and used something like "ddds:" where we now use "urn:" >>> and expect that treatment. In more practical form, it is a >>> key reason why discussions about putting strong references to >>> 2276 and/or 3401 into 2141bis cause me (at least) some >>> anxiety. >> >> Indeed, we probably should have done that. But, we didn't. >> And, here we are. > > Yes. See three options above. > >> I believe that, if you want to deprecate DDDS in its role for >> URNs, that takes an IETF standards action. > > I agree. However, possible applicability statements aside (and > they require IETF standards actions too), the above, and the > present language in 2141bis (and 2141bis and 3406bis before I > got involved with the writing) effectively amount to "URNs can > use DDDS if they like, but it is not required and no strong > recommendation --one way or the other-- is being made." Unless > that changes, there may be arguments for either updating or > deprecating DDDS (and some of those arguments are at least > implicit above), there is no requirement to do so. > > As a token of good will --which I actually do feel although I > fear it isn't clear from this note -- if we can get 2141bis and > friends wrapped up and, after that, you decided it was worth > revisiting DDDS, cleaning up or clarifying some language that I > don't think has stood the course of time, adding bits as needed > to accommodate 2141bis URNs rather than just 2141 ones, and > making a strong applicability statement, I'd be happy to try to > find time to collaborate. I've got a lot of notes from going > through the documents in the last few months and can probably > find those I made myself during the 1996-2002 period. So far, I > think everything necessary could be done from an updating and > clarifying document and that actual revision of 3401ff would not > be needed -- the task is not monstrous. > >> If this group wants to solve the information systems problems >> of naming in the Internet differently, then it probably needs >> to call them something _else_ at this point. > > Well, sure. But see comments about (1) above including the > prediction of likely consequences. I also continue to believe, > as I believed when it caused me to take actions long ago that > were perceived as precipitous, that we need to figure out how to > pragmatically work around those information systems/ information > science problems, especially those that represent centuries of > experience about things that can be handled by conventions, but > not "solved". That belief is based now, as it was then, on a > conviction that getting actual solutions to those problems into > the critical path will transport us into a rathole of > unimaginable depth. > > best, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- From nobody Wed Jun 3 15:50:30 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8511B3008 for ; Wed, 3 Jun 2015 15:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfagqkdNi_Ib for ; Wed, 3 Jun 2015 15:50:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851331B3011 for ; Wed, 3 Jun 2015 15:50:20 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z0HUJ-00087w-8g; Wed, 03 Jun 2015 18:50:19 -0400 Date: Wed, 03 Jun 2015 18:50:14 -0400 From: John C Klensin To: "Leslie Daigle (ThinkingCat)" Message-ID: <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> In-Reply-To: <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:50:28 -0000 --On Wednesday, June 03, 2015 17:35 -0400 "Leslie Daigle (ThinkingCat)" wrote: > > Thanks for the thoughtful reply. As always, a lot to chew on. > > If I can summarize in tweet-length, I get: > > URN standard did not write down that they require DDDS > Many urn: namespaces diverge from intention; none use DDDS I don't know enough to assert "none", but certainly not a lot of widely-used ones. > URNs are a concept and a standard See below. > What do we do now to align concept, standard and "urn:" in > the wild. Yes, it seems to me that is the challenge. To make it a little worse, as evidence by the comment to the effect that only some URNs are part of the 'urn:' scheme" in 3986, we have: * A very broad concept about persistent, location-independent, named identifiers. That concept comes with a bit more ambiguity about what "persistent" and "location-independent" mean. A problem we don't have right now, but might, is whether that concept is necessarily also bound to URIs. In particular, DOIs, which the RFC Editor and IAB have chosen to endorse and use, are certainly persistent, location-independent names and, while there is a URI (but not URN) embedding, they are not natively URIs. * A much narrower concept, involving URNs linked to a DDDS-based resolver directory. * The standard, now and future. > As difficult as it is to align "urn:" and "standard", > when we start bringing in "concept", we're cycling, IMO. Certainly it makes it harder to have a conversation that converges. > This is where I have extreme difficulties with Keith's > desire to have everybody resolving everything, with no one > able to preferentially hold metadata for an item: it's > "concept". An interesting one, but neither where URNs > were standardized, nor part of the "urn:" in the wild part > of the problem. Agreed. That is also why I'm very anxious to defer that set of issues and concentrate on what we can do now, without opening those issues. I would love to see someone do the work implied by Keith's broader concepts (and those of others), but don't want the potential for that work to block us from moving forward on "urn:" as a practical standard that reflects or enhances existing practice. john From nobody Thu Jun 4 04:58:57 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBFE1A1B66 for ; Thu, 4 Jun 2015 04:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1itLY3XrPCHN for ; Thu, 4 Jun 2015 04:58:53 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518CB1A1B62 for ; Thu, 4 Jun 2015 04:58:53 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B682120CB5 for ; Thu, 4 Jun 2015 07:58:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 04 Jun 2015 07:58:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=RG6fTD1Ye4O4lLT gdX6BpxymhdA=; b=hj0+ap60mWaUF6u8buHUrIla/nuu0y2O0yLf114BEOweMVv QQcAPkGRwrp3fUkSqIqdVfvbUJDTflsYu2QjiEqXoGS7rerhlt3QFxV/NGKh15tC cV7mmL8roOrMFunvK4opnNECHnyMnJ6FzDWA96iGIeDijAMBpDhICIqNSvys= X-Sasl-enc: Lh2XztifjydeVWq85Xsv0RxZQespvR+E5Kmat8Nn4E9i 1433419132 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 3ED84C00019; Thu, 4 Jun 2015 07:58:52 -0400 (EDT) Message-ID: <55703D79.1060305@network-heretics.com> Date: Thu, 04 Jun 2015 07:58:49 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: urn@ietf.org References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> In-Reply-To: <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 11:58:55 -0000 On 06/03/2015 05:35 PM, Leslie Daigle (ThinkingCat) wrote: > This is where I have extreme difficulties with Keith’s desire to have > everybody resolving everything, with no one able to preferentially > hold metadata for an item: it’s “concept”. An interesting one, but > neither where URNs were standardized, nor part of the “urn:” in the > wild part of the problem. I haven't had time to dig through my list archives yet, but the best of my recollection is that certainly at the time of the original URN WG, and actually even by 1995 or so, it was widely understood that there should be no single resolution service for any URN namespace - that while we fully expected that many URNs would be resolvable, and also that some resolution services would be associated with particular namespaces (presumably via a DDDS-like mechanism), resolution of URNs should not depend on their being a designated resolution service for any particular namespace. This was important both for long-term viability of URNs (old URNs should not be deemed useless just because a resolution service once-associated with that namespace had ceased operation) and for security reasons (the namespace should not inherently be in a position to control access to the resources to which it issued names, since the role of namespace is not one of managing access rights - to the extent that this is done, it should be done by the owner of the content). However, just to try to clarify, I don't have a desire for "everybody" to resolve "everything". Instead, I think that: - It should be possible for parties other than those authorized by a namespace to operate services that accept that namespace's URNsas input and return locations, resources, and/or metadata associated with those URNs; - These non-authorized services should be able to use the same resolution protocols that namespace-authorized services use; - Clients/users should be able to select among namespace-authorized and non-authorized services so that they do not need to rely entirely on authorized services to obtain information about resources named with URNs; and - Determination of authenticity/provenance of information associated with URNs should be accomplished using digital signatures/certificates rather than by virtue of having been obtained from a namespace-authorized service (so, for instance, that signed metadata can potentially be cached by and returned by non-authorized services, and that metadata once signed by the namespace cannot later be repudiated). I'm not sure what "preferentially hold metadata" means, but I don't have any objection to namespaces operating resolution services for the names that they coin, nor to clients being configured to prefer those services over non-authorized services. Keith From nobody Thu Jun 4 05:25:57 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20921B3258 for ; Thu, 4 Jun 2015 05:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLcgvvcm2Jy0 for ; Thu, 4 Jun 2015 05:25:52 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAED1B3264 for ; Thu, 4 Jun 2015 05:24:33 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EDF2B2113F for ; Thu, 4 Jun 2015 08:24:32 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 04 Jun 2015 08:24:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=2Dttm+++sDzUFPv Xl3/MDS9r8tE=; b=N4rHEb39F7TycS4POcH6PTz9lDO9jo5o3Sdl1FhWdHRNQDG lNWIO3A0dSWwbtX0mxxNusiDSWOJxE89ZMAeRlpG5fvmKcDuqHer/dqOo6qE0vA8 OnJ7la3duoWEYA+u9jNlCMGDKG9pnTZUWydEodMnRxDnMLiDn1U+IVdjmGdE= X-Sasl-enc: wMkV0sGnBhCrp+IsvM4uhyNi4AwqvetjyWowC6egHewX 1433420672 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C7B06800F0; Thu, 4 Jun 2015 08:24:32 -0400 (EDT) Message-ID: <5570437E.8080207@network-heretics.com> Date: Thu, 04 Jun 2015 08:24:30 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: urn@ietf.org References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> In-Reply-To: <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 12:25:54 -0000 On 06/03/2015 06:50 PM, John C Klensin wrote: > > --On Wednesday, June 03, 2015 17:35 -0400 "Leslie Daigle > (ThinkingCat)" wrote: > >> Thanks for the thoughtful reply. As always, a lot to chew on. >> >> If I can summarize in tweet-length, I get: >> >> URN standard did not write down that they require DDDS >> Many urn: namespaces diverge from intention; none use DDDS > I don't know enough to assert "none", but certainly not a lot of > widely-used ones. > >> URNs are a concept and a standard > See below. > >> What do we do now to align concept, standard and "urn:" in >> the wild. > Yes, it seems to me that is the challenge. To make it a little > worse, as evidence by the comment to the effect that only some > URNs are part of the 'urn:' scheme" in 3986, we have: > > * A very broad concept about persistent, > location-independent, named identifiers. That concept > comes with a bit more ambiguity about what "persistent" > and "location-independent" mean. A problem we don't > have right now, but might, is whether that concept is > necessarily also bound to URIs. In particular, DOIs, > which the RFC Editor and IAB have chosen to endorse and > use, are certainly persistent, location-independent > names and, while there is a URI (but not URN) embedding, > they are not natively URIs. IMO we should declare URIs (whether or not persistent) that don't begin with "urn:", or which do begin with "urn:" but don't use registered namespaces, as out-of-scope. If someone eventually wishes to register doi as a URN namespace, then they would be in-scope, but that is no different in principle than registering isbn or any other set of persistent identifiers that wasn't originally designed to be a URN namespace. The same rules and procedures apply. Why wouldn't they? > > * A much narrower concept, involving URNs linked to a > DDDS-based resolver directory. This is another thing that I need to check, but my recollection is that we never intended for DDDS to be "the" sole resolver directory - it was only an example of a way to find resolvers. More broadly, URNs are still valid even if they can't be resolved, and whether a particular URN can be resolved is something that can change (in either direction) over time. So I don't find the "DDDS-resolvable URN" concept to be terribly useful. > > * The standard, now and future. > >> As difficult as it is to align "urn:" and "standard", >> when we start bringing in "concept", we're cycling, IMO. > Certainly it makes it harder to have a conversation that > converges. The first step in an engineering exercise is supposed to be to define the problem. It seems to me that the problem definition for URNs was never really stated to a sufficient degree, and that some want to dismiss or change the part of the definition that was stated. Then when there's some disagreement about some aspect of what we're trying to do, we don't have any agreed-on problem definition to refer to in order to evaluate competing ideas. So some people want to refer to 1737, and others want to ignore it. Some people want to cite the spectrum of existing usage of URNs as the problem definition, even though those are not representative of the problem that we were trying to solve in the original URI/URN WGs. And some of us who were actively participating way back when want to rely on the shared concept that we believed many of us had arrived at (through years of hard work) even if some of that concept wasn't ever captured in a document. etc. >> This is where I have extreme difficulties with Keith's >> desire to have everybody resolving everything, with no one >> able to preferentially hold metadata for an item: it's >> "concept". An interesting one, but neither where URNs >> were standardized, nor part of the "urn:" in the wild part >> of the problem. > Agreed. That is also why I'm very anxious to defer that set of > issues and concentrate on what we can do now, without opening > those issues. I would love to see someone do the work implied > by Keith's broader concepts (and those of others), but don't > want the potential for that work to block us from moving forward > on "urn:" as a practical standard that reflects or enhances > existing practice. I'm fine with deferring that set of issues except when we start setting bad precedents or going in a direction that breaks something important. But again, it's hard to argue that a precedent is bad, or that something important is being broken, without a problem definition to refer to. Keith From nobody Thu Jun 4 06:14:57 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931DA1A8720 for ; Thu, 4 Jun 2015 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_X_eu2WOuom for ; Thu, 4 Jun 2015 06:14:53 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id A09DA1A8715 for ; Thu, 4 Jun 2015 06:14:53 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 077DA567FCA; Thu, 4 Jun 2015 08:14:51 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E166EA042B; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHV1ZNviUKta; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B5DDDA0448; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 95C4EA0445; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W3RmliF9UIr3; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) Received: from [10.0.0.2] (c-67-166-198-20.hsd1.ga.comcast.net [67.166.198.20]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 556E9A042B; Thu, 4 Jun 2015 08:14:50 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Mealling In-Reply-To: Date: Thu, 4 Jun 2015 09:13:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 13:14:55 -0000 DDDS author here.... DDDS is a general system that can resolve any syntactically regular = string. ENUM is a proper subset of DDDS. It was never my nor anyone = else's intention for DDDS to be the only resolution system for URNs. = Indeed there are several URN schemes that can't be resolved via DDDS = because the authority hierarchy is far to difficult to setup (UUIDs for = example). In other cases the entity that registered and manages the = scheme doesn't find public DDDS style resolution all that useful so they = would never setup their piece of the system. Also, remember that DDDS isn't a final resolution system so much as a = way of discovery AUTHORITATIVE services that CAN tell you things about a = URN (or any other identifier). There are shortcuts in the system to = optimize for common queries (find me one or more instances of this = Resource) but there's no reason you have to use that. I see no reason = why you couldn't use DDDS to quickly find a Z39.50 server to answer all = sorts of fun questions about that Resource). DDDS was designed to = respect the hierarchy of authority embedded in the urn:: system.=20= Has anyone come up with a set of requirements for what they want their = 'resolution' service to do?=20 Is the issue that DDDS requires knowledge of DNS as opposed to URL = encoding the URN and sticking it in a URL as many want to do? A service = that hides DDDS authority chains behind a HTTP 1.1 gateway seems easy = enough to write. -MM > On Jun 4, 2015, at 8:24 AM, Keith Moore = wrote: >=20 > On 06/03/2015 06:50 PM, John C Klensin wrote: >> =09 >> * A much narrower concept, involving URNs linked to a >> DDDS-based resolver directory. >=20 > This is another thing that I need to check, but my recollection is = that we never intended for DDDS to be "the" sole resolver directory - it = was only an example of a way to find resolvers. More broadly, URNs are = still valid even if they can't be resolved, and whether a particular URN = can be resolved is something that can change (in either direction) over = time. So I don't find the "DDDS-resolvable URN" concept to be terribly = useful. From nobody Thu Jun 4 13:46:37 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4692F1A92F3 for ; Thu, 4 Jun 2015 13:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMvDe0fUClGB for ; Thu, 4 Jun 2015 13:46:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CCE1A923E for ; Thu, 4 Jun 2015 13:46:35 -0700 (PDT) Received: by wiga1 with SMTP id a1so652047wig.0 for ; Thu, 04 Jun 2015 13:46:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=z1/vyWAHrA1dbWVDvzyQgmCPmJZNrGgIWCWAfC0lVFk=; b=KjGwl7OTiroJrWCI+fZzYpW/Tr+aB6IgwFZ9U6/VSDYh5yu4Ezeav6Q5IlB5XRFl1U auSD2jo5YtO+DyMFinIynKRcHFpjIynp82XKSdOP6EJVgFG3/xUMGx//AgJo9532bgst rJVi2bss2xp6NVOAfp0M6v1WQFvoSRktqJtTwdH4/c/7CDlMQXMZnZIBDqKzOVn/5CDi GynqcpDN57IFV9jEjxe3adum8NyYW4RfnEwBIUAOd1ma8ztPfU7wPes5PLy1kEJe/IEp ENCIVI1lbTY8qMkZHoXrnAdersq29V5vjE4oGuF5gJtUDn7I0AWWzI7b2iVfXxdOw1eG iuRw== X-Gm-Message-State: ALoCoQlGQ7IA6GbI1OBXnPfNCDEfLQ6gLFyVtHnBHcFcsXEnWvP/BzGB6mMEsTS6QSF6ntJ3BDgW MIME-Version: 1.0 X-Received: by 10.180.106.97 with SMTP id gt1mr10899898wib.37.1433450793687; Thu, 04 Jun 2015 13:46:33 -0700 (PDT) Received: by 10.194.249.99 with HTTP; Thu, 4 Jun 2015 13:46:33 -0700 (PDT) X-Originating-IP: [2001:500:4:15:cc19:3873:274b:5afd] Date: Thu, 4 Jun 2015 16:46:33 -0400 Message-ID: From: Andrew Newton To: "urn@ietf.org" Content-Type: multipart/alternative; boundary=f46d044280665c717a0517b7455e Archived-At: Subject: [urn] No session at IETF 93 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 20:46:36 -0000 --f46d044280665c717a0517b7455e Content-Type: text/plain; charset=UTF-8 All, At present we do not see a need to meet at IETF 93, and have informed our AD and the secretariat. -andy --f46d044280665c717a0517b7455e Content-Type: text/html; charset=UTF-8
All,

At present we do not see a need to meet at IETF 93, and have informed our AD and the secretariat.

-andy
--f46d044280665c717a0517b7455e-- From nobody Fri Jun 5 11:26:27 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB01A1B30 for ; Fri, 5 Jun 2015 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkXRc9Rp1FtJ for ; Fri, 5 Jun 2015 11:26:25 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F0E1A1B2C for ; Fri, 5 Jun 2015 11:26:24 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z0wJw-000JrV-5B; Fri, 05 Jun 2015 14:26:20 -0400 Date: Fri, 05 Jun 2015 14:26:15 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: <12061A3747734BEB1A3FD4DF@JcK-HP8200.jck.com> In-Reply-To: <5570437E.8080207@network-heretics.com> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 18:26:27 -0000 --On Thursday, June 04, 2015 08:24 -0400 Keith Moore wrote: > IMO we should declare URIs (whether or not persistent) that > don't begin with "urn:", or which do begin with "urn:" but > don't use registered namespaces, as out-of-scope. I think we have done the latter. Indeed, I think we've don't something more strongly by declaring them invalid. That assertion is part of note about experimental namespaces in Section 6, but could be moved to a more prominent place and strengthened if someone thought it necessary and suggested text and a place to put it. With regard to other URIs, I don't think there is anything in any of our documents that suggests they are within scope. If you are aware of exceptions, please point them out. On the other hand, as far as our discussions are concerned, the WG's declining to adopt the "URNs are not URIs" approach makes a certain amount of discussion of the relationship inevitable much as I'd like to minimize it. >... >> * A much narrower concept, involving URNs linked to a >> DDDS-based resolver directory. > > This is another thing that I need to check, but my > recollection is that we never intended for DDDS to be "the" > sole resolver directory - it was only an example of a way to > find resolvers. More broadly, URNs are still valid even if > they can't be resolved, and whether a particular URN can be > resolved is something that can change (in either direction) > over time. So I don't find the "DDDS-resolvable URN" concept > to be terribly useful. I certainly agree and Michael's note certainly reinforces that view. However, I continue to see a logical problem in that either the same resolution mechanism or resolver-finding mechanism is applicable to all URNs (which we agree is not the case and should not be) or resolver-finding is per-namespace. I think you have strongly objected to the latter, so I'm not sure where you think we should go or what words should go into 2141bis. >... > The first step in an engineering exercise is supposed to be to > define the problem. It seems to me that the problem > definition for URNs was never really stated to a sufficient > degree, and that some want to dismiss or change the part of > the definition that was stated. Then when there's some > disagreement about some aspect of what we're trying to do, we > don't have any agreed-on problem definition to refer to in > order to evaluate competing ideas. So some people want to > refer to 1737, and others want to ignore it. Some people want > to cite the spectrum of existing usage of URNs as the problem > definition, even though those are not representative of the > problem that we were trying to solve in the original URI/URN > WGs. And some of us who were actively participating way back > when want to rely on the shared concept that we believed many > of us had arrived at (through years of hard work) even if some > of that concept wasn't ever captured in a document. etc. Suppose I agree with that as a statement of the meta-problem if not the problem (personally, I'm coming to a much more general conclusion, but it isn't helpful). How do you think we should proceed from it? Presumably, mourning our fate and the bad situation we are in is not particularly helpful in moving forward. > I'm fine with deferring that set of issues except when we > start setting bad precedents or going in a direction that > breaks something important. But again, it's hard to argue > that a precedent is bad, or that something important is being > broken, without a problem definition to refer to. Agreed. But, if you don't believe we have an adequate problem definition on which to proceed, we either have to face the question about the meta-problem above, or we are at dead stop until we fire up and complete a problem definition process. I don't see any energy for that. Even if I did, I think it would be no more likely to completely converge and reach consensus than we were nearly 20 years ago. I really hate being in a situation in which the best way we can characterize a collection that is (or is not) suitable for a URN namespace is on the basis of "I know one when I see one" or, perhaps better, "Keith, Leslie, and/or Michael know one when they see one". However, if that is where history has left us and the notion of starting over with new definitions of the problem (and of "persistence", etc.) is as implausible and impractical as I think it is, then shouldn't we be concentrating on how to move forward and, in particular what text should be added to or changed in 2141bis? john From nobody Fri Jun 5 11:37:06 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77851A1B81 for ; Fri, 5 Jun 2015 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvq2RzDea6qV for ; Fri, 5 Jun 2015 11:37:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90801A1B74 for ; Fri, 5 Jun 2015 11:37:03 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z0wUH-000JtR-8e; Fri, 05 Jun 2015 14:37:01 -0400 Date: Fri, 05 Jun 2015 14:36:56 -0400 From: John C Klensin To: Michael Mealling , Keith Moore Message-ID: In-Reply-To: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 18:37:05 -0000 --On Thursday, June 04, 2015 09:13 -0400 Michael Mealling wrote: > DDDS author here.... > > DDDS is a general system that can resolve any syntactically > regular string. ENUM is a proper subset of DDDS. It was never > my nor anyone else's intention for DDDS to be the only > resolution system for URNs. Indeed there are several URN > schemes that can't be resolved via DDDS because the authority > hierarchy is far to difficult to setup (UUIDs for example). In > other cases the entity that registered and manages the scheme > doesn't find public DDDS style resolution all that useful so > they would never setup their piece of the system. >... Michael, I found this note/discussion extremely helpful, so many thanks. Question: Are the resolver/ DDDS questions confusing enough people that we (presumably the WG) should be thinking about a document that summarizes the situation as of 2015? Presumably much of such a document could be built from Michael's note and a few other recent notes on the list. If the answer is "yes", does anyone have the time and inclination to do the work? john From nobody Fri Jun 5 11:42:09 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E241A1BA9 for ; Fri, 5 Jun 2015 11:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vpcHlhclTco for ; Fri, 5 Jun 2015 11:41:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BB01A1BD7 for ; Fri, 5 Jun 2015 11:41:56 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z0wZ1-000Jts-Hk; Fri, 05 Jun 2015 14:41:55 -0400 Date: Fri, 05 Jun 2015 14:41:50 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 18:42:00 -0000 Sorry... sent from wrong address. --On Thursday, June 04, 2015 08:24 -0400 Keith Moore wrote: > IMO we should declare URIs (whether or not persistent) that > don't begin with "urn:", or which do begin with "urn:" but > don't use registered namespaces, as out-of-scope. I think we have done the latter. Indeed, I think we've don't something more strongly by declaring them invalid. That assertion is part of note about experimental namespaces in Section 6, but could be moved to a more prominent place and strengthened if someone thought it necessary and suggested text and a place to put it. With regard to other URIs, I don't think there is anything in any of our documents that suggests they are within scope. If you are aware of exceptions, please point them out. On the other hand, as far as our discussions are concerned, the WG's declining to adopt the "URNs are not URIs" approach makes a certain amount of discussion of the relationship inevitable much as I'd like to minimize it. >... >> * A much narrower concept, involving URNs linked to a >> DDDS-based resolver directory. > > This is another thing that I need to check, but my > recollection is that we never intended for DDDS to be "the" > sole resolver directory - it was only an example of a way to > find resolvers. More broadly, URNs are still valid even if > they can't be resolved, and whether a particular URN can be > resolved is something that can change (in either direction) > over time. So I don't find the "DDDS-resolvable URN" concept > to be terribly useful. I certainly agree and Michael's note certainly reinforces that view. However, I continue to see a logical problem in that either the same resolution mechanism or resolver-finding mechanism is applicable to all URNs (which we agree is not the case and should not be) or resolver-finding is per-namespace. I think you have strongly objected to the latter, so I'm not sure where you think we should go or what words should go into 2141bis. >... > The first step in an engineering exercise is supposed to be to > define the problem. It seems to me that the problem > definition for URNs was never really stated to a sufficient > degree, and that some want to dismiss or change the part of > the definition that was stated. Then when there's some > disagreement about some aspect of what we're trying to do, we > don't have any agreed-on problem definition to refer to in > order to evaluate competing ideas. So some people want to > refer to 1737, and others want to ignore it. Some people want > to cite the spectrum of existing usage of URNs as the problem > definition, even though those are not representative of the > problem that we were trying to solve in the original URI/URN > WGs. And some of us who were actively participating way back > when want to rely on the shared concept that we believed many > of us had arrived at (through years of hard work) even if some > of that concept wasn't ever captured in a document. etc. Suppose I agree with that as a statement of the meta-problem if not the problem (personally, I'm coming to a much more general conclusion, but it isn't helpful). How do you think we should proceed from it? Presumably, mourning our fate and the bad situation we are in is not particularly helpful in moving forward. > I'm fine with deferring that set of issues except when we > start setting bad precedents or going in a direction that > breaks something important. But again, it's hard to argue > that a precedent is bad, or that something important is being > broken, without a problem definition to refer to. Agreed. But, if you don't believe we have an adequate problem definition on which to proceed, we either have to face the question about the meta-problem above, or we are at dead stop until we fire up and complete a problem definition process. I don't see any energy for that. Even if I did, I think it would be no more likely to completely converge and reach consensus than we were nearly 20 years ago. I really hate being in a situation in which the best way we can characterize a collection that is (or is not) suitable for a URN namespace is on the basis of "I know one when I see one" or, perhaps better, "Keith, Leslie, and/or Michael know one when they see one". However, if that is where history has left us and the notion of starting over with new definitions of the problem (and of "persistence", etc.) is as implausible and impractical as I think it is, then shouldn't we be concentrating on how to move forward and, in particular what text should be added to or changed in 2141bis? john From nobody Fri Jun 5 21:34:20 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5121ACE22 for ; Fri, 5 Jun 2015 21:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mh5cnAYf3Qh for ; Fri, 5 Jun 2015 21:34:15 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4341ACE23 for ; Fri, 5 Jun 2015 21:34:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id F3A5120767 for ; Sat, 6 Jun 2015 00:34:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 06 Jun 2015 00:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=pktf2lORmxzhW29 LYjZRLe+soOk=; b=CQbCH1lngQCUPz8WZoLH8SRVvQRFO7DbGGlEWLGRyt3vtlR PhCxtmNHXbV233XH9mKJzlo8Wv44RrVtaN2XBYl3MaRJYSJ1QX8BUC2tK40ABFwt OMhe13HR8FsO+qzqk5VLT52WLtP0MdP6TqVIkeC8gjn1/cH6VHMf6CeU+6RQ= X-Sasl-enc: UyZapkmOXf+XqTke0eeHReXwfsJzXFvhJcdoBe13b/Cf 1433565253 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A67268009B; Sat, 6 Jun 2015 00:34:13 -0400 (EDT) Message-ID: <5572783F.9080007@network-heretics.com> Date: Sat, 06 Jun 2015 00:34:07 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: urn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 04:34:19 -0000 On 06/05/2015 02:41 PM, John C Klensin wrote: > Sorry... sent from wrong address. > > --On Thursday, June 04, 2015 08:24 -0400 Keith Moore > wrote: > >> IMO we should declare URIs (whether or not persistent) that >> don't begin with "urn:", or which do begin with "urn:" but >> don't use registered namespaces, as out-of-scope. > I think we have done the latter. Indeed, I think we've don't > something more strongly by declaring them invalid. That > assertion is part of note about experimental namespaces in > Section 6, but could be moved to a more prominent place and > strengthened if someone thought it necessary and suggested text > and a place to put it. > > With regard to other URIs, I don't think there is anything in > any of our documents that suggests they are within scope. Ok, good. That was my impression also, but something you said made me wonder if maybe we weren't on the same page about that. > On the > other hand, as far as our discussions are concerned, the WG's > declining to adopt the "URNs are not URIs" approach makes a > certain amount of discussion of the relationship inevitable much > as I'd like to minimize it. I guess that depends on whether one believes that we have to somehow reconcile RFC 3986's idea that there are URNs that don't begin with "urn:", with common sense. But as of the last time I read 2141bis in its entirety (which I need to do again), the language in that document regarding what was in scope seemed ok to me. >> This is another thing that I need to check, but my >> recollection is that we never intended for DDDS to be "the" >> sole resolver directory - it was only an example of a way to >> find resolvers. More broadly, URNs are still valid even if >> they can't be resolved, and whether a particular URN can be >> resolved is something that can change (in either direction) >> over time. So I don't find the "DDDS-resolvable URN" concept >> to be terribly useful. > I certainly agree and Michael's note certainly reinforces that > view. However, I continue to see a logical problem in that > either the same resolution mechanism or resolver-finding > mechanism is applicable to all URNs (which we agree is not the > case and should not be) or resolver-finding is per-namespace. > I think you have strongly objected to the latter, so I'm not > sure where you think we should go or what words should go into > 2141bis. Slightly different wordings can mean very different things. If a client is looking for a namespace-authorized resolution service via a DDDS-like service, yes, that's inherently a per-namespace lookup. However, clients should also be able to consult non-authorized resolution services. Such services won't be inherently federated by URN namespace. (Note that a "resolution service" is really nothing but a database that can be queried using one of a hopefully-small number of known resolution protocols. To me, saying that all resolution services have to be namespace-authorized and federated by namespace seems tantamount to saying that nobody besides a namespace can operate a service that permits queries by URN. And this seems to be assigning a much greater role to the namespace than was anticipated in any of the existing URN RFCs.) >> ... >> The first step in an engineering exercise is supposed to be to >> define the problem. It seems to me that the problem >> definition for URNs was never really stated to a sufficient >> degree, and that some want to dismiss or change the part of >> the definition that was stated. Then when there's some >> disagreement about some aspect of what we're trying to do, we >> don't have any agreed-on problem definition to refer to in >> order to evaluate competing ideas. So some people want to >> refer to 1737, and others want to ignore it. Some people want >> to cite the spectrum of existing usage of URNs as the problem >> definition, even though those are not representative of the >> problem that we were trying to solve in the original URI/URN >> WGs. And some of us who were actively participating way back >> when want to rely on the shared concept that we believed many >> of us had arrived at (through years of hard work) even if some >> of that concept wasn't ever captured in a document. etc. > Suppose I agree with that as a statement of the meta-problem if > not the problem (personally, I'm coming to a much more general > conclusion, but it isn't helpful). How do you think we should > proceed from it? Presumably, mourning our fate and the bad > situation we are in is not particularly helpful in moving > forward. I agree that mourning is pointless, at least within the context of this WG's discussion. (Learning from this WG's experience might be useful, but probably not in this context.) One way forward would be to try to agree on a problem definition. I don't really recommend that, because a lot of people are already tired of trying to present their view of the problem. Another way forward would be to rely on RFC 1737, imperfect though it is. Even if we were comfortable with that approach, I suspect it would still leave some loose ends. Regardless of what one thinks about RFC 1737, the original URN WG was directed by its charter to comply with it, and presumably did so. https://datatracker.ietf.org/wg/urn/charter/ So I think it's fair to cite 1737 as at least part of a problem definition of URNs. And even if one has reservations about RFC 1737, it is nowhere nearly as bad as RFC 3986 is, and we seem to have found a way forward in spite of the latter. Another way is to do what IETF normally does: Skip trying to define the problem and just try to get consensus on a solution to a problem even though people might not actually have consensus on what the problem is (*). This might be the most expedient thing to do. However, it comes with a risk, which is that if anyone tries to raise an objection on technical grounds, IESG and higher-ups don't really have much in the way of criteria to evaluate the objection. And even if this WG has complete agreement, I suspect there's a better-than-even chance of someone objecting at Last Call, just because of the amount of religion around URNs that's out there. But if we can get consensus on 2141bis without trying to sort out the URN problem definition again, that's probably the most expedient thing to do for now. It just needs to be a strong consensus within the WG. (*) it's tempting to try to explain why this ever works for IETF at all, but it would probably be a distraction. > >> I'm fine with deferring that set of issues except when we >> start setting bad precedents or going in a direction that >> breaks something important. But again, it's hard to argue >> that a precedent is bad, or that something important is being >> broken, without a problem definition to refer to. > Agreed. But, if you don't believe we have an adequate problem > definition on which to proceed, we either have to face the > question about the meta-problem above, or we are at dead stop > until we fire up and complete a problem definition process. I > don't see any energy for that. Even if I did, I think it would > be no more likely to completely converge and reach consensus > than we were nearly 20 years ago. > > I really hate being in a situation in which the best way we can > characterize a collection that is (or is not) suitable for a URN > namespace is on the basis of "I know one when I see one" or, > perhaps better, "Keith, Leslie, and/or Michael know one when > they see one". I don't like it either, but even recent discussions within this WG, as well as with its chairs and ADs, convince me that it's an accurate assessment of the situation. I think it should be fixed, but I'd like to try to finish 2141bis before we try to fix it. (Though it would surely be odd if the ADs were to recharter this WG to define the URN problem as its last work item.) > However, if that is where history has left us > and the notion of starting over with new definitions of the > problem (and of "persistence", etc.) is as implausible and > impractical as I think it is, then shouldn't we be concentrating > on how to move forward and, in particular what text should be > added to or changed in 2141bis? I really don't think we should revisit the definition of "persistence" because as far as I can tell, the text in 1737 is highly unlikely to be improved upon, at least within an IETF WG discussion. (If we were to have a problem definition discussion, we might do well to rule certain questions already-settled and therefore out-of-scope.) Keith From nobody Fri Jun 5 21:47:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE531A88C8 for ; Fri, 5 Jun 2015 21:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxPjuK5DpW6r for ; Fri, 5 Jun 2015 21:47:29 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F347C1A88BC for ; Fri, 5 Jun 2015 21:47:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6969520D94 for ; Sat, 6 Jun 2015 00:47:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 06 Jun 2015 00:47:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=5eo0GwgRsRU/2RSqIykD0i3mUFc=; b=g0uT9 4rzsNkv4of4LmZpw8Wo33R76rpbBLOtce05SKS12bxgYpNc+IdAY3vIF9Ve+50g+ V8u+rTZVae22fIenEo/kObQFUkLL1evHP8LnwkufiT7ChFGo0kD0HDDenE2cHHRt fHaf27spupEL/4r6VEeOFnt/pN2JQBFQDhXbjs= X-Sasl-enc: f5axeascTDzuockjSaYArMxqKBx1/TPhGpjuGp1nON0H 1433566048 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id EDFFD68009B; Sat, 6 Jun 2015 00:47:27 -0400 (EDT) Message-ID: <55727B59.4020700@network-heretics.com> Date: Sat, 06 Jun 2015 00:47:21 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: urn@ietf.org References: <5572783F.9080007@network-heretics.com> In-Reply-To: <5572783F.9080007@network-heretics.com> Content-Type: multipart/alternative; boundary="------------010609000205090003070001" Archived-At: Subject: [urn] clarification (was: Re: URN standard) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 04:47:30 -0000 This is a multi-part message in MIME format. --------------010609000205090003070001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 06/06/2015 12:34 AM, Keith Moore wrote: >> >> I really hate being in a situation in which the best way we can >> characterize a collection that is (or is not) suitable for a URN >> namespace is on the basis of "I know one when I see one" or, >> perhaps better, "Keith, Leslie, and/or Michael know one when >> they see one". > > I don't like it either, but even recent discussions within this WG, as > well as with its chairs and ADs, convince me that it's an accurate > assessment of the situation. I realized after hitting "Send" that I misspoke (miswrote?) above. My assessment of the situation is /not/ that "Keith, Leslie, and/or Michael know one when they see one". It's that we lack an agreed-on problem definition, and that the lack of an agreed-on problem definition is one of the primary reasons why we so often dig ratholes and/or alienate participants. (now I hope to make another review pass over 2141bis before needing to reply again.) Keith --------------010609000205090003070001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 06/06/2015 12:34 AM, Keith Moore wrote:

I really hate being in a situation in which the best way we can
characterize a collection that is (or is not) suitable for a URN
namespace is on the basis of "I know one when I see one" or,
perhaps better, "Keith, Leslie, and/or Michael know one when
they see one".

I don't like it either, but even recent discussions within this WG, as well as with its chairs and ADs, convince me that it's an accurate assessment of the situation.

I realized after hitting "Send" that I misspoke (miswrote?) above.

My assessment of the situation is not that "Keith, Leslie, and/or Michael know one when they see one". It's that we lack an agreed-on problem definition, and that the lack of an agreed-on problem definition is one of the primary reasons why we so often dig ratholes and/or alienate participants.

(now I hope to make another review pass over 2141bis before needing to reply again.)

Keith

--------------010609000205090003070001-- From nobody Mon Jun 8 07:27:42 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD61A8928 for ; Mon, 8 Jun 2015 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5SQo534O1Ri for ; Mon, 8 Jun 2015 07:27:38 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 020501A8913 for ; Mon, 8 Jun 2015 07:27:37 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 93CF3563F8B; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 88C04601FA; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw3DkNmABHrz; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 671B3601B3; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 55F5F601FA; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YobDI6ov2gR1; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) Received: from [38.110.23.163] (unknown [38.110.23.163]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 2A77C601B3; Mon, 8 Jun 2015 09:27:32 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Mealling In-Reply-To: Date: Mon, 8 Jun 2015 10:27:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <938BB70C-1ADF-45B3-9584-5A3ADBB91934@refactored-networks.com> References: <5572783F.9080007@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 14:27:41 -0000 This is my characterization that I thought had made it into some of the = discussions but apparently never made it into a document as axiomatic.=20= Its not that a URN is suitable if "Keith, Leslie, or Michael say so when = they see it", its that someone asserts that they are following the rules = as specified in the registration documents. If someone asserts in the = NID registration that they are following the rules of non-reassignment, = syntax, etc then everyone can assume those rules are being followed. If = they come across a situation in which they aren't they get to then = assume that the namespace maintainer made an error, not that that the = consumer made an error.=20 So anything can be a URN IFF you agree to the limited set of = requirements in 2141 and the registration documents. If you then break = your agreement everyone knows you are the source of the problem. This = solves the problem of not knowing if http://example.com/weather/today.html is the same thing today as it is tomorrow. An HTTP URI doesn't tell me = anything about that. I could retrieve today's weather from that URI and = make some guesses based on some assertions about caching in the HTTP = headers but if I retrieve it the next day and get back a news story = about Siberian coal mining I have no idea whether the owner of = example.com intends for those two things to be the same or not. But, if they register the 'example' URN NID then they are making an = explicit statement that I can rely on that "urn:example:weather:today" = is always the same Resource no matter when I resolve it. If I resolve = that URN authoritatively and get back todays weather today and a = Siberian coal mining story the next day I can reliably assume that this = URN is saying those two things are the same Resource. I may not think so = but at least I can safely rely on the NID registration process assuring = me that THEY think it is.=20 In the HTTP URI example, making assumptions is an error on my part. In the URN example, breaking my assumptions is an error on their part.=20= IMHO, reliable assumptions about what things are today vs tomorrow is = what URNs were all about and the basis of building temporarily reliable = systems. -MM > On Jun 6, 2015, at 12:34 AM, Keith Moore = wrote: > On 06/05/2015 02:41 PM, John C Klensin wrote: >>=20 >>=20 >> I really hate being in a situation in which the best way we can >> characterize a collection that is (or is not) suitable for a URN >> namespace is on the basis of "I know one when I see one" or, >> perhaps better, "Keith, Leslie, and/or Michael know one when >> they see one". >=20 > I don't like it either, but even recent discussions within this WG, as = well as with its chairs and ADs, convince me that it's an accurate = assessment of the situation. >=20 > I think it should be fixed, but I'd like to try to finish 2141bis = before we try to fix it. (Though it would surely be odd if the ADs = were to recharter this WG to define the URN problem as its last work = item.) From nobody Wed Jun 10 03:47:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9E1ACE98 for ; Wed, 10 Jun 2015 03:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfY7768VNywQ for ; Wed, 10 Jun 2015 03:47:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5C11ACEAA for ; Wed, 10 Jun 2015 03:46:47 -0700 (PDT) Received: from DB4PR07MB460.eurprd07.prod.outlook.com (10.141.238.146) by DB4PR07MB457.eurprd07.prod.outlook.com (10.141.238.141) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 10:46:26 +0000 Received: from DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) by DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 10:46:27 +0000 From: "Hakala, Juha E" To: Michael Mealling , Keith Moore Thread-Topic: [urn] URN standard Thread-Index: AQHQn79ImT8rIkpDGEWdnusSzcmB+52e5I6AgAPKkl+AAt49gA== Date: Wed, 10 Jun 2015 10:46:26 +0000 Message-ID: References: <5572783F.9080007@network-heretics.com> <938BB70C-1ADF-45B3-9584-5A3ADBB91934@refactored-networks.com> In-Reply-To: <938BB70C-1ADF-45B3-9584-5A3ADBB91934@refactored-networks.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: refactored-networks.com; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DB4PR07MB457; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB457; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(51704005)(102836002)(106116001)(92566002)(76576001)(122556002)(19300405004)(40100003)(19273905006)(15975445007)(2656002)(77096005)(15395725005)(46102003)(19580395003)(74482002)(74316001)(19580405001)(87936001)(93886004)(5002640100001)(2950100001)(2900100001)(77156002)(62966003)(54356999)(76176999)(189998001)(5001960100002)(33656002)(5001770100001)(86362001)(50986999)(66066001)(5003600100001)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB457; H:DB4PR07MB460.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 10:46:26.7203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB457 Archived-At: Cc: "urn@ietf.org" , "stella@isbn-international.org" Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 10:47:14 -0000 Hello,=20 Comments below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Michael Mealling > Sent: 8. kes=E4kuuta 2015 17:28 > To: Keith Moore > Cc: urn@ietf.org > Subject: Re: [urn] URN standard >=20 > Its not that a URN is suitable if "Keith, Leslie, or Michael say so when = they see > it", its that someone asserts that they are following the rules as specif= ied in > the registration documents. If someone asserts in the NID registration th= at > they are following the rules of non-reassignment, syntax, etc then everyo= ne > can assume those rules are being followed. If they come across a situatio= n in > which they aren't they get to then assume that the namespace maintainer > made an error, not that that the consumer made an error. Almost every URN namespace says something about the syntax of NSS. But well= defined URN namespaces should also have rules concerning semantics (scope)= of the identifier. NID registration may provide only a summary of this. Fo= r instance, URN:ISBN namespace registration is not as exhaustive as the ISB= N Users' Manual. IMO namespace registration should provide a link (prefera= bly a persistent one) to this kind of external information. This way the sc= ope description does not need to be repeated in the NID registration.=20 Any identifier which has a generic scope such as Handle, DOI or URN:NBN (an= d of course URN:UUID) is difficult to manage well and does not function pro= perly unless the people who assign these identifiers know what they are doi= ng. Well managed namespaces like URN:ISBN are less demanding in this respe= ct because there are usually written rules which to follow. =20 > So anything can be a URN IFF you agree to the limited set of requirements= in > 2141 and the registration documents. If you then break your agreement > everyone knows you are the source of the problem. This solves the problem > of not knowing if >=20 > http://example.com/weather/today.html >=20 > is the same thing today as it is tomorrow. An HTTP URI doesn't tell me an= ything > about that. I could retrieve today's weather from that URI and make some > guesses based on some assertions about caching in the HTTP headers but if= I > retrieve it the next day and get back a news story about Siberian coal mi= ning I > have no idea whether the owner of example.com intends for those two thing= s > to be the same or not. For URLs it is safe to assume that the content of the page may not the same= anymore, just like it is safe to assume that after e.g. 5 years a book in = a library may not be found from the same shelf location. The difference is = that in the library a user can tell that the book has changed; in the Web t= hat may not be obvious.=20 =20 > But, if they register the 'example' URN NID then they are making an expli= cit > statement that I can rely on that "urn:example:weather:today" is always t= he > same Resource no matter when I resolve it. If I resolve that URN > authoritatively and get back todays weather today and a Siberian coal min= ing > story the next day I can reliably assume that this URN is saying those tw= o things > are the same Resource. I may not think so but at least I can safely rely = on the > NID registration process assuring me that THEY think it is. Yes, I can imagine a namespace where those documents are just two aspects o= f a single identified work, shown one after another.=20 > In the HTTP URI example, making assumptions is an error on my part. ... but you could put a blame on those who've told you that URIs are cool ;= -).=20 =20 > In the URN example, breaking my assumptions is an error on their part. ... provided that you have formed your expectations correctly on the basis = of the NID registration and additional information available (if any).=20 Of course, in the very long run (centuries, even) only those URNs and other= PIDs which are well managed will remain resolvable. Stable organizations s= uch as national libraries and national archives have the best chances of su= cceeding in this task. Of course it is going to be a major challenge, but i= t has to be done. We must not allow for instance links to electronic resour= ces in scientific articles to "die". =20 Juha > IMHO, reliable assumptions about what things are today vs tomorrow is wha= t > URNs were all about and the basis of building temporarily reliable system= s. >=20 > -MM >=20 >=20 > > On Jun 6, 2015, at 12:34 AM, Keith Moore heretics.com> wrote: > > On 06/05/2015 02:41 PM, John C Klensin wrote: > >> > >> > >> I really hate being in a situation in which the best way we can > >> characterize a collection that is (or is not) suitable for a URN > >> namespace is on the basis of "I know one when I see one" or, perhaps > >> better, "Keith, Leslie, and/or Michael know one when they see one". > > > > I don't like it either, but even recent discussions within this WG, as = well as > with its chairs and ADs, convince me that it's an accurate assessment of = the > situation. > > > > I think it should be fixed, but I'd like to try to finish 2141bis befor= e we try to > fix it. (Though it would surely be odd if the ADs were to recharter t= his WG > to define the URN problem as its last work item.) >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 10 05:32:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61A1AD370 for ; Wed, 10 Jun 2015 05:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9fPkgXdYTqa for ; Wed, 10 Jun 2015 05:32:10 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77271AD372 for ; Wed, 10 Jun 2015 05:32:09 -0700 (PDT) Received: from DB4PR07MB460.eurprd07.prod.outlook.com (10.141.238.146) by DB4PR07MB458.eurprd07.prod.outlook.com (10.141.238.142) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 12:31:52 +0000 Received: from DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) by DB4PR07MB460.eurprd07.prod.outlook.com ([10.141.238.146]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 12:31:52 +0000 From: "Hakala, Juha E" To: Michael Mealling , Keith Moore Thread-Topic: [urn] URN standard Thread-Index: AQHQnTb8mT8rIkpDGEWdnusSzcmB+52ZfHWAgAHTnQCAABTOAIAA44EAgAAOKjuACU8MAA== Date: Wed, 10 Jun 2015 12:31:51 +0000 Message-ID: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: refactored-networks.com; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DB4PR07MB458; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB458; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(479174004)(24454002)(46102003)(15188155005)(2900100001)(86362001)(5002640100001)(76576001)(54356999)(66066001)(74482002)(76176999)(189998001)(16799955002)(106116001)(2950100001)(5001770100001)(87936001)(77156002)(5001920100001)(62966003)(5001960100002)(50986999)(74316001)(102836002)(92566002)(15975445007)(33656002)(77096005)(19580405001)(40100003)(93886004)(2656002)(5003600100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB458; H:DB4PR07MB460.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 12:31:51.9577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB458 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 12:32:15 -0000 Hello,=20 Comments below.=20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Michael Mealling > Sent: 4. kes=E4kuuta 2015 16:14 > To: Keith Moore > Cc: urn@ietf.org > Subject: Re: [urn] URN standard >=20 > DDDS author here.... >=20 > DDDS is a general system that can resolve any syntactically regular strin= g. > ENUM is a proper subset of DDDS. It was never my nor anyone else's intent= ion > for DDDS to be the only resolution system for URNs. Indeed there are seve= ral > URN schemes that can't be resolved via DDDS because the authority hierarc= hy > is far to difficult to setup (UUIDs for example). In other cases the enti= ty that > registered and manages the scheme doesn't find public DDDS style resoluti= on > all that useful so they would never setup their piece of the system. Library community has regarded DDDS as one option to set up resolver discov= ery service, but not as the only one.=20 So far, the ambition level has been fairly modest; resolvers in the same na= mespace (like URN:NBN and URN:ISBN) may be aware of each other and harvest = each others' URN - URL linking tables.=20 > Also, remember that DDDS isn't a final resolution system so much as a way= of > discovery AUTHORITATIVE services that CAN tell you things about a URN (or > any other identifier). There are shortcuts in the system to optimize for > common queries (find me one or more instances of this Resource) but there= 's > no reason you have to use that. I see no reason why you couldn't use DDDS= to > quickly find a Z39.50 server to answer all sorts of fun questions about t= hat > Resource). DDDS was designed to respect the hierarchy of authority > embedded in the urn:: system. First the user should find out which questions the Z39.50 server can answer= . These servers are complex, and can tell a lot about themselves and databa= ses accessible via them. And this metadata should be machine understandable= , in order to allow Z39.50 clients to adapt themselves to the searching fac= ilities and (bibliographic) databases available.=20 A few years ago, ANSI/NISO (National Information Standards Organization) la= unched Metasearch Initiative to support sharing of information about inform= ation retrieval services. The project was not completed, but draft standard= Z39.92-200X is still available at=20 http://www.niso.org/apps/group_public/project/details.php?project_id=3D56 Usage of DDDS was never discussed in this context, but we could have done t= hat.=20 > Has anyone come up with a set of requirements for what they want their > 'resolution' service to do? Interesting question!=20 RFC 2483 never intended to provide a full set of services. From a librarian= 's point of view, RFC 2483 is a good start, but a lot of important things a= re missing, and the number of missing things has grown all the time.=20 The first problem is the data model: RFC 2483 assumes that there are resour= ces and metadata (in URC format) about them, and 0-n copies of these resour= ces. This model may be OK for some URN users, but it is far too simple for = e.g. libraries.=20 The model libraries are using / implementing starts from immaterial works l= ike James Joyce's Ulysses. Libraries have metadata (including identifiers) = about these immaterial things. And (metadata about) work may be linked to (= metadata about) other works; for Ulysses it is necessary to establish a con= nection to (for instance) Homer's Odyssey and Portrait of the Artist as a Y= oung Man.=20 There are a lot of adapted versions of Ulysses, and also translations to ot= her languages. In library vernacular, these are called expressions of Ulyss= es. We have metadata (and identifiers) about them as well, and routinely li= nk metadata about expressions to metadata about works. Each work and expression may have 0-n physical embodiments (manifestations)= such as hardback or PDF versions of Ulysses. All these have their own iden= tifiers. And of course manifestation metadata is linked to upper level meta= data records. =20 In this context there are a lot of potential requirements for resolution se= rvices. Just to give some examples, user may want to find metadata about a = particular work, expression or manifestation; identifiers of all works rela= ted to a work; metadata about all expressions related to a work; metadata a= bout all expressions related to one another (for instance, Finnish translat= ions of Ulysses; there are two), manifestations related to a work or expres= sion, or all locations of a manifestation. All these requests can be answer= ed if there are stable links between works, expressions, manifestations and= items.=20 This kind of interlinking is essential for persistence. For instance, 100 y= ears from now a user may find a reference from a scientific article pointin= g to an article in PDF published in 2013. He may not have SW with which to = open a PDF document, but he may find out that this work is also available i= n a more modern file format which is still readable with the HW/SW tools av= ailable to him.=20 Another issue with RFC 2483 is that it assumes that metadata (Uniform Resou= rce Characteristics) is a single "blob" available in a single format (alas,= URC never got past an idea; Dublin Core was established instead). Since ap= plications are now much more sophisticated than they were almost two decade= s ago, this is no longer the case. A user may need descriptive metadata in = a particular metadata format used for the resource in question (for instanc= e, DCAT for research data, ONIX for commercial publications or EAD for gove= rnmental documents). Or, she may need just technical metadata (what HW / SW= do I need to render this file), rights metadata (what can I do with this d= ocument after I have copied it on my computer) or preservation metadata (ho= w is this new version of the document different from the original one with = respect to look & feel and intellectual content). =20 =20 Other user communities are likely to have requirements which are beyond wha= t the libraries need.=20 Because resolution services will change over time due to changes in data mo= dels, technology etc. it is necessary to create a system where new resoluti= on services and service parameters can be easily added. We also need a mech= anism via which resolvers can share information about resolution services t= hey support. Then applications such as library systems will know what resol= ution requests any given URN resolver can deal with. In Z39.50 context robo= ts have been built in order to find out via trial and error what queries a = Z39.50 server & database it connects to support. This can be done in URN co= ntext as well, but it would be better to share this information.=20 > Is the issue that DDDS requires knowledge of DNS as opposed to URL encodi= ng > the URN and sticking it in a URL as many want to do? A service that hides= DDDS > authority chains behind a HTTP 1.1 gateway seems easy enough to write. It is a pity that so far nobody has done it. But let's hope the situation w= ill change.=20 Juha >=20 > -MM >=20 > > On Jun 4, 2015, at 8:24 AM, Keith Moore > wrote: > > > > On 06/03/2015 06:50 PM, John C Klensin wrote: > >> > >> * A much narrower concept, involving URNs linked to a > >> DDDS-based resolver directory. > > > > This is another thing that I need to check, but my recollection is that= we > never intended for DDDS to be "the" sole resolver directory - it was only= an > example of a way to find resolvers. More broadly, URNs are still valid = even if > they can't be resolved, and whether a particular URN can be resolved is > something that can change (in either direction) over time. So I don't f= ind the > "DDDS-resolvable URN" concept to be terribly useful. >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 10 08:42:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD921B2BE1 for ; Wed, 10 Jun 2015 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsHmsL5DlP5z for ; Wed, 10 Jun 2015 08:42:14 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 08D061B2BDB for ; Wed, 10 Jun 2015 08:42:14 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 8CF2B564156; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7FC7D60264; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMurUzwZ2dyH; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5B8786025D; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4370F60264; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a6l8KvpdFHye; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) Received: from [38.110.18.84] (unknown [38.110.18.84]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 07AB76025D; Wed, 10 Jun 2015 10:42:13 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Mealling In-Reply-To: Date: Wed, 10 Jun 2015 11:42:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2C3590-E878-4855-9046-89006D4B90B1@refactored-networks.com> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> To: "Hakala, Juha E" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 15:42:17 -0000 > On Jun 10, 2015, at 8:31 AM, Hakala, Juha E = wrote: >=20 >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Michael Mealling >>=20 >> DDDS is a general system that can resolve any syntactically regular = string. >> ENUM is a proper subset of DDDS. It was never my nor anyone else's = intention >> for DDDS to be the only resolution system for URNs. Indeed there are = several >> URN schemes that can't be resolved via DDDS because the authority = hierarchy >> is far to difficult to setup (UUIDs for example). In other cases the = entity that >> registered and manages the scheme doesn't find public DDDS style = resolution >> all that useful so they would never setup their piece of the system. >=20 > Library community has regarded DDDS as one option to set up resolver = discovery service, but not as the only one.=20 Good. > So far, the ambition level has been fairly modest; resolvers in the = same namespace (like URN:NBN and URN:ISBN) may be aware of each other = and harvest each others' URN - URL linking tables.=20 I would like to be careful about terminology with respect to the word = 'resolver'. A resolver is authoritative since it is either run by or = delegated its authority by the registrant of the NID. Without that = authority its just another database spouting its own opinion.=20 >> Also, remember that DDDS isn't a final resolution system so much as a = way of >> discovery AUTHORITATIVE services that CAN tell you things about a URN = (or >> any other identifier). There are shortcuts in the system to optimize = for >> common queries (find me one or more instances of this Resource) but = there's >> no reason you have to use that. I see no reason why you couldn't use = DDDS to >> quickly find a Z39.50 server to answer all sorts of fun questions = about that >> Resource). DDDS was designed to respect the hierarchy of authority >> embedded in the urn:: system. >=20 > First the user should find out which questions the Z39.50 server can = answer. These servers are complex, and can tell a lot about themselves = and databases accessible via them. And this metadata should be machine = understandable, in order to allow Z39.50 clients to adapt themselves to = the searching facilities and (bibliographic) databases available.=20 That sounds like a great requirement for a Z39.50 server. I can see = someone writing a 'profile' of Z39.50 for answering questions about = URIs. But I'm not really sure that's germane to this discussion.=20 > A few years ago, ANSI/NISO (National Information Standards = Organization) launched Metasearch Initiative to support sharing of = information about information retrieval services. The project was not = completed, but draft standard Z39.92-200X is still available at=20 >=20 > = http://www.niso.org/apps/group_public/project/details.php?project_id=3D56 > Usage of DDDS was never discussed in this context, but we could have = done that.=20 I wouldn't have. Its like discussing DNS while you're designing an = Oracle API: You know DNS exists but you really don't need to spend much = time talking about it. >> Has anyone come up with a set of requirements for what they want = their >> 'resolution' service to do? >=20 > Interesting question!=20 >=20 > RFC 2483 never intended to provide a full set of services. =46rom a = librarian's point of view, RFC 2483 is a good start, but a lot of = important things are missing, and the number of missing things has grown = all the time.=20 Heh... It wasn't intended to be much beyond getting a few interesting = services off the ground and start the ball rolling.=20 > The first problem is the data model: RFC 2483 assumes that there are = resources and metadata (in URC format) about them, and 0-n copies of = these resources. This model may be OK for some URN users, but it is far = too simple for e.g. libraries.=20 No where in RFC 2483 does it say that the services listed are the only = ones or that the data model (if you can even attach that much formality = to it) is the only one. Just because it doesn't talk about other ways to = ask questions doesn't mean those other methods are wrong or illegal. So = lets start with what you need. > < general summary of Cataloging > > In this context there are a lot of potential requirements for = resolution services. Just to give some examples, user may want to find = metadata about a particular work, expression or manifestation; = identifiers of all works related to a work; metadata about all = expressions related to a work; metadata about all expressions related to = one another (for instance, Finnish translations of Ulysses; there are = two), manifestations related to a work or expression, or all locations = of a manifestation. All these requests can be answered if there are = stable links between works, expressions, manifestations and items.=20 >=20 > This kind of interlinking is essential for persistence. For instance, = 100 years from now a user may find a reference from a scientific article = pointing to an article in PDF published in 2013. He may not have SW with = which to open a PDF document, but he may find out that this work is also = available in a more modern file format which is still readable with the = HW/SW tools available to him.=20 OK. Here is where we have a slight breakdown in terminology that goes = back a LONG way and even gets to Larry Masinter's use of 'persistence'. = In your use case and in Larry's view (sometimes) persistence of the = thing you want to retrieve is far more important. If you can't retrieve = the thing you are talking about then having a persistant identifier has = greatly reduced, if any, utility. My view and the view of many of us = those 20 years ago is that persistence of the thing the identifier = identifies is 'someone else's problem'. That's where the Archiving = department comes in. The Catalog can still contain the record and all = that metadata comfortable in the knowledge that someone isn't going to = reassign the URN to something else. Whether or not the actual resource = it identifies still exists is a separate problem. > Another issue with RFC 2483 is that it assumes that metadata (Uniform = Resource Characteristics) is a single "blob" available in a single = format (alas, URC never got past an idea; Dublin Core was established = instead). Since applications are now much more sophisticated than they = were almost two decades ago, this is no longer the case. A user may need = descriptive metadata in a particular metadata format used for the = resource in question (for instance, DCAT for research data, ONIX for = commercial publications or EAD for governmental documents). Or, she may = need just technical metadata (what HW / SW do I need to render this = file), rights metadata (what can I do with this document after I have = copied it on my computer) or preservation metadata (how is this new = version of the document different from the original one with respect to = look & feel and intellectual content). =20 Might I recommend redacting any mention of RFC 2483 beyond using it as a = list of possible classes of services meant for optimizing certain well = known use cases? I don't think anyone anywhere is suggesting that 2483 = limit any of those use cases. Is there a candidate system (protocol and = data model) that does some of those things now? > Other user communities are likely to have requirements which are = beyond what the libraries need.=20 Definitely... that was always our assumption. > Because resolution services will change over time due to changes in = data models, technology etc. it is necessary to create a system where = new resolution services and service parameters can be easily added. We = also need a mechanism via which resolvers can share information about = resolution services they support. Then applications such as library = systems will know what resolution requests any given URN resolver can = deal with. In Z39.50 context robots have been built in order to find out = via trial and error what queries a Z39.50 server & database it connects = to support. This can be done in URN context as well, but it would be = better to share this information.=20 And DDDS, as a system of discovering authoritative resolvers, supports = adding new services and endpoint identifiers. But its not meant to = encompass ALL of those things. DDDS isn't the resolver itself, its = simply meant to find the authoritative one. E.g. you use DNS to find the = web server to ask for the document, it doesn't give you the document = itself nor does it give you the equivalent of an 301 redirect to tell = you where to get it. It simply says "that server knows how to answer = complex questions about the thing you are after using a complex and = robust protocol". >> Is the issue that DDDS requires knowledge of DNS as opposed to URL = encoding >> the URN and sticking it in a URL as many want to do? A service that = hides DDDS >> authority chains behind a HTTP 1.1 gateway seems easy enough to = write. >=20 > It is a pity that so far nobody has done it. But let's hope the = situation will change.=20 I'll play around with setting one up this weekend.=20 -MM From nobody Wed Jun 10 08:48:28 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756C51B2E7C for ; Wed, 10 Jun 2015 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8cujOFdB0P0 for ; Wed, 10 Jun 2015 08:48:22 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 248931B2E38 for ; Wed, 10 Jun 2015 08:48:22 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id CAD8B564485; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 659D56025F; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0chM5MqKozV; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 421076025D; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 205F46025F; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mVmv6THjqdss; Wed, 10 Jun 2015 10:48:21 -0500 (CDT) Received: from [38.110.18.84] (unknown [38.110.18.84]) by smtp-out-2.01.com (Postfix) with ESMTPSA id E22F26025D; Wed, 10 Jun 2015 10:48:20 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Mealling In-Reply-To: Date: Wed, 10 Jun 2015 11:48:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> To: John C Klensin X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 15:48:27 -0000 I can help someone write this if necessary but I was hoping my RFC = writing days were over. ;-) I think an 'update' would be useful since I'm seeing definite confusion = about the 'standards' aspects of some of these documents. One = observation is that, if you remember back when these documents were = being written, new protocols and markup formats were flying around thick = as flies. Many of these documents were written assuming that better = metadata search and lookup protocols would be coming to the rescue. = Everyone had this hope that someone would write a version of Z39.50 that = mere mortals could understand and that Dublin Core would save us all = from attribute naming hell. Sadly no such knight on a white horse came = to save us... -MM > On Jun 5, 2015, at 2:36 PM, John C Klensin wrote: > --On Thursday, June 04, 2015 09:13 -0400 Michael Mealling > wrote: >=20 >> DDDS author here.... >>=20 >> DDDS is a general system that can resolve any syntactically >> regular string. ENUM is a proper subset of DDDS. It was never >> my nor anyone else's intention for DDDS to be the only >> resolution system for URNs. Indeed there are several URN >> schemes that can't be resolved via DDDS because the authority >> hierarchy is far to difficult to setup (UUIDs for example). In >> other cases the entity that registered and manages the scheme >> doesn't find public DDDS style resolution all that useful so >> they would never setup their piece of the system. >> ... >=20 > Michael, I found this note/discussion extremely helpful, so many > thanks. >=20 > Question: Are the resolver/ DDDS questions confusing enough > people that we (presumably the WG) should be thinking about a > document that summarizes the situation as of 2015? Presumably > much of such a document could be built from Michael's note and a > few other recent notes on the list. If the answer is "yes", > does anyone have the time and inclination to do the work? From nobody Thu Jun 11 00:30:20 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168A1A92B4 for ; Thu, 11 Jun 2015 00:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVP_GO1acS8r for ; Thu, 11 Jun 2015 00:30:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4FA1A92AD for ; Thu, 11 Jun 2015 00:30:15 -0700 (PDT) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 07:12:30 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0184.014; Thu, 11 Jun 2015 07:12:30 +0000 From: "Hakala, Juha E" To: Michael Mealling , John C Klensin Thread-Topic: [urn] URN standard Thread-Index: AQHQnTb8mT8rIkpDGEWdnusSzcmB+52ZfHWAgAHTnQCAABTOAIAA44EAgAAOKjuAAew5AIAHrKuwgAD+5bA= Date: Thu, 11 Jun 2015 07:12:29 +0000 Message-ID: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> In-Reply-To: <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: refactored-networks.com; dkim=none (message not signed) header.d=none; x-originating-ip: [128.214.71.222] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(51704005)(74316001)(54356999)(122556002)(92566002)(19580405001)(62966003)(77156002)(46102003)(74482002)(86362001)(50986999)(76176999)(93886004)(106116001)(2656002)(19580395003)(87936001)(33656002)(76576001)(2900100001)(77096005)(5001770100001)(66066001)(2950100001)(5001960100002)(189998001)(5002640100001)(15975445007)(102836002)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 07:12:29.7368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:30:19 -0000 Hello, There is no simple & efficient solution to the attribute naming problem. Th= ings are actually getting worse: richer and richer metadata is needed to ma= nage digital resources and rights related to them. There is a modernized version of Z39.50. SRU has been an OASIS standard sin= ce 2014. Replacing ASN.1/BER with XML does make the document more palatable= for some readers, but there are still all those search attributes rich lib= rary metadata supports. Dublin Core does simplify semantics a lot and it ha= s been kept stable since 2007, but most people outside libraries may think = that 70+ terms to describe resources is too much (libraries have several hu= ndreds of them).=20 I am afraid that the knight on the white horse is galloping away ;-), but t= here are no problems we librarians wouldn't be able to solve without his he= lp. But we do need some support from IETF to make the identifiers do the tr= icks required. =20 Juha =20 > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Michael Mealling > Sent: 10. kes=E4kuuta 2015 18:49 > To: John C Klensin > Cc: urn@ietf.org; Keith Moore > Subject: Re: [urn] URN standard >=20 > I can help someone write this if necessary but I was hoping my RFC writin= g > days were over. ;-) >=20 > I think an 'update' would be useful since I'm seeing definite confusion a= bout > the 'standards' aspects of some of these documents. One observation is th= at, > if you remember back when these documents were being written, new > protocols and markup formats were flying around thick as flies. Many of t= hese > documents were written assuming that better metadata search and lookup > protocols would be coming to the rescue. Everyone had this hope that > someone would write a version of Z39.50 that mere mortals could understan= d > and that Dublin Core would save us all from attribute naming hell. Sadly = no > such knight on a white horse came to save us... >=20 > -MM >=20 >=20 > > On Jun 5, 2015, at 2:36 PM, John C Klensin wrote: > > --On Thursday, June 04, 2015 09:13 -0400 Michael Mealling > > wrote: > > > >> DDDS author here.... > >> > >> DDDS is a general system that can resolve any syntactically regular > >> string. ENUM is a proper subset of DDDS. It was never my nor anyone > >> else's intention for DDDS to be the only resolution system for URNs. > >> Indeed there are several URN schemes that can't be resolved via DDDS > >> because the authority hierarchy is far to difficult to setup (UUIDs > >> for example). In other cases the entity that registered and manages > >> the scheme doesn't find public DDDS style resolution all that useful > >> so they would never setup their piece of the system. > >> ... > > > > Michael, I found this note/discussion extremely helpful, so many > > thanks. > > > > Question: Are the resolver/ DDDS questions confusing enough people > > that we (presumably the WG) should be thinking about a document that > > summarizes the situation as of 2015? Presumably much of such a > > document could be built from Michael's note and a few other recent > > notes on the list. If the answer is "yes", does anyone have the time > > and inclination to do the work? >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Jun 12 14:08:20 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2261A8907 for ; Fri, 12 Jun 2015 14:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLeNrAwejAjR for ; Fri, 12 Jun 2015 14:08:17 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288461B2AC8 for ; Fri, 12 Jun 2015 14:08:17 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so19952818igb.1 for ; Fri, 12 Jun 2015 14:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dhcOtR375oMYnkkjEAnrrpA2wDIua2o1/l0Hw6kS9Jw=; b=lrweHb8hFcGp+WwmHobqnJW2+K70xWY19Xvq5YubGWT+mKB5fJ9JAMMwZaRBkMpU3S wZLZVl3hO5itcrB6MsaCMMUDGso4cuCKxI97VehHijtaFshuHyZ1Q+dVRQr0T37Hsxt5 w3xeEerWbHbLkdiofYKsdSimQCF0ScGnn6xonuPhIDyo7TAxV/u8/WUvIzCFB+OKXG9W B4uKrk5b3sap3O0Wm08ZJgwXPHFqHX+Hqiov1n5HgcyiAXYwykkmtRj570xaBLuUUecN fafcqSz3OD7Kf2c2fknrrGAPO49bDvfvR4zlRRbWVhOu+XcPYpKocQzQScQ37ezOROXR qX+g== X-Gm-Message-State: ALoCoQnywsvCmoct89tq6CnE6G55REcjfKGUzkXr68e2W1St2rlLxOKErfhU/OC+gKhJBHIkJ0Dm X-Received: by 10.107.136.197 with SMTP id s66mr21147698ioi.65.1434143296600; Fri, 12 Jun 2015 14:08:16 -0700 (PDT) Received: from aither.local ([2601:1:8200:3a60:e5c4:b7b:9016:83fd]) by mx.google.com with ESMTPSA id m193sm3234031iom.19.2015.06.12.14.08.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2015 14:08:15 -0700 (PDT) Message-ID: <557B4A3D.4080607@andyet.net> Date: Fri, 12 Jun 2015 15:08:13 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "urn@ietf.org" References: <55418A5B.9000600@andyet.net> In-Reply-To: <55418A5B.9000600@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] schedule for -12 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:08:19 -0000 My apologies for not meeting the schedule that we outlined at the end of April. Much list discussion ensued on important topics, and John and I felt that we needed to address the issues that were raised in -12. We're close to having the next version ready and should be able to post it next week. Thanks for your patience and involvement! Peter On 4/29/15 7:50 PM, Peter Saint-Andre - &yet wrote: > Given the many significant discussions that have emerged on the list > since the interim meeting (many thanks to Keith, Leslie, and everyone > else!), I think it is best to reach some agreement on proposed text > before John and I publish version -12 of the syntax spec. We had planned > to do that a few days ago at the latest, but it will take us more time > to absorb the points raised and address them in the spec. > > Peter > From nobody Mon Jun 15 16:25:31 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB5C1B303F; Mon, 15 Jun 2015 16:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGPW-4ee_2iz; Mon, 15 Jun 2015 16:25:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E411B303B; Mon, 15 Jun 2015 16:25:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150615232526.32715.90754.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 16:25:26 -0700 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 23:25:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt Pages : 30 Date : 2015-06-15 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. 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: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 16 03:01:01 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3E1ACE65 for ; Tue, 16 Jun 2015 03:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2rELCCBBmzJ for ; Tue, 16 Jun 2015 03:00:58 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D6E1ACE59 for ; Tue, 16 Jun 2015 03:00:58 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Z4nfg-000JX5-M6; Tue, 16 Jun 2015 06:00:44 -0400 Date: Tue, 16 Jun 2015 06:00:39 -0400 From: John C Klensin To: "Hakala, Juha E" , Michael Mealling Message-ID: In-Reply-To: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 10:01:00 -0000 --On Thursday, June 11, 2015 07:12 +0000 "Hakala, Juha E" wrote: >... > I am afraid that the knight on the white horse is galloping > away ;-), but there are no problems we librarians wouldn't be > able to solve without his help. But we do need some support > from IETF to make the identifiers do the tricks required. Hi. (personal opinion only) I've found this discussion very useful in terms of understanding both the context of the issues and the issues themselves. However, I --and I hope all of us-- have a very specific and narrow problem, which is to establish a syntax and registration model in 2141bis that is sufficient to support whatever problems or requirements are out there or that might be developed in the reasonably near future. To that end and noting that 2141bis-12 has been posted... * If what it specifies does not provide the "support from IETF to make the identifiers do the tricks required", it would be good (actually, it is probably vital) to know, really soon now, what is missing or wrong and, in very specific terms, how it might reasonably be corrected. * Part of that support question is whether the current version of the registration templates and descriptions allow the necessary information to be supplied, require what should be required, provide enough hints and justification about what information is needed that we are likely to get that information, and, where appropriate, are clear about what needs to be supplied in-line and what can be provided by reference. If anything is not clear or complete enough, this is the time to say so. * There are some examples in 2141bis to illustrate applicability of r-components and q-components. I think they may be wrong and that they really need checking (and other ones specified/provided as appropriate) by people who have a clear idea of what they are intended to mean. The text about where those queries go is also not as clear as I would like it to be and that may be part of the problem, but it is about as good as Peter and have been able to do so far. Text would be appreciated. * The text about persistence has been removed from 2141bis. The recent threads of conversations have convinced me (at least), that an updated and up-to-date "theory of URNs" document would be very useful, but that (i) it isn't in the WG's charter, (ii) getting it into the WG's critical path would probably kill this effort, (iii) putting arbitrary small bits of it into 2141bis is likely to add to, rather than reducing, confusion, and (iii) we should almost certainly postpone work on that document (or even figuring how to organize that work until after 2141bis is finished). * I discovered in a very helpful conversation last week (with someone who still considers herself a librarian, by the way), that there is a great deal of research going on about identifiers in the Internet era, work that still pays attention to non-electronic "resources" and that probes at what terms like, e.g., "resource" are coming to mean. The conversation also convinced me even more of the wisdom of confining 2141bis as much as possible to syntax and then moving the other discussions to forums where the level of carefully-researched knowledge is much higher than it is in the IETF. Details (including references and pointers) after I get my notes together, but probably not until after 2141bis is locked down. If anyone needs them for ongoing work that won't get in the way to 2141bis, write me offlist. I want to stress that I'm not speaking for the WG, the Co-chairs, or even for Peter, but my assumption at the moment is the penultimate version of 2141bis before WG and IETF Last Call. In other words, we get the input asked for above, do one more revision, and then should be ready to wind this effort up. That schedule is also consistent with my/our not running out of energy to keep waiting for the comments needed to make revisions. I look forward to hearing from everyone who is involved and interested. best, john From nobody Tue Jun 16 07:24:11 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD72E1B3A0A for ; Tue, 16 Jun 2015 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2u1GlxCMR6X for ; Tue, 16 Jun 2015 07:24:06 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247521B3A09 for ; Tue, 16 Jun 2015 07:24:05 -0700 (PDT) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 16 Jun 2015 14:23:48 +0000 Received: from AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) by AMSPR07MB454.eurprd07.prod.outlook.com ([10.242.106.145]) with mapi id 15.01.0184.014; Tue, 16 Jun 2015 14:23:48 +0000 From: "Hakala, Juha E" To: John C Klensin , Michael Mealling Thread-Topic: [urn] URN standard Thread-Index: AQHQnTb8mT8rIkpDGEWdnusSzcmB+52ZfHWAgAHTnQCAABTOAIAA44EAgAAOKjuAAew5AIAHrKuwgAD+5bCACA3WgIAAQjly Date: Tue, 16 Jun 2015 14:23:48 +0000 Message-ID: References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> , In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [88.112.221.61] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51414003)(252514010)(86362001)(5001960100002)(106116001)(93886004)(50986999)(76576001)(5003600100002)(74316001)(2656002)(122556002)(5002640100001)(76176999)(87936001)(92566002)(40100003)(189998001)(77156002)(62966003)(2900100001)(229853001)(33656002)(66066001)(54356999)(46102003)(102836002)(77096005)(19580405001)(5001770100001)(2950100001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 14:23:48.6035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 14:24:10 -0000 Hello John; all, (also a personal opinion only) Considering just the URN syntax, the only library related requirements I am= aware of involved URI fragment and query. We wanted to use the former to i= ndicate locations within identified documents, and the latter to pass resol= ution related parameters to URN resolvers. Since our needs were relatively = modest, URNBIS has already met our requirements and then went on to specify= additional features. And IMO there is nothing wrong with what 2141bis say= s (but I need to check the latest draft, just in case).=20 I am not aware of any immediate need for newly minted URN features such as = r-components, but library community may find uses for it later when our res= olvers become smarter. As John says below, traditional identifiers are not = and cannot be carved in stone. Digital publishing has changed and is still = changing the ways in which ISBN, ISSN etc are used. Several systems are cur= rently under revision, and in some cases changes may be substantial. Many i= dentifier systems will specify how they can be made actionable as DOIs, URN= s etc. New ISBN standard is one of the first examples of this. =20 There are also new challenges, such as increasing need within publishing co= mmunity and libraries to develop a standard-based solution for identificati= on of logical fragments (assuming that URN + fragment can deal with physica= l ones, we still have a lot of cases when namespaces must develop their own= solutions to identify logical parts of documents which lack proper physica= l encoding).=20 Once the syntax revision is complete, we (I hope) need to take a closer loo= k on mechanism for registering resolution services and parameters, and then= specify to they are encoded as queries. How resolvers then deal with reque= sts is a different matter; often it will be sufficient to know, which serve= r(s) will be able to process the request and which protocol(s) they support= .=20 =20 Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Gsm: +358 50 3827678 email: juha.hakala@helsinki.fi ________________________________________ L=E4hett=E4j=E4: John C Klensin L=E4hetetty: 16. kes=E4kuuta 2015 13:00 Vastaanottaja: Hakala, Juha E; Michael Mealling Kopio: urn@ietf.org; Keith Moore Aihe: RE: [urn] URN standard --On Thursday, June 11, 2015 07:12 +0000 "Hakala, Juha E" wrote: >... > I am afraid that the knight on the white horse is galloping > away ;-), but there are no problems we librarians wouldn't be > able to solve without his help. But we do need some support > from IETF to make the identifiers do the tricks required. Hi. (personal opinion only) I've found this discussion very useful in terms of understanding both the context of the issues and the issues themselves. However, I --and I hope all of us-- have a very specific and narrow problem, which is to establish a syntax and registration model in 2141bis that is sufficient to support whatever problems or requirements are out there or that might be developed in the reasonably near future. To that end and noting that 2141bis-12 has been posted... * If what it specifies does not provide the "support from IETF to make the identifiers do the tricks required", it would be good (actually, it is probably vital) to know, really soon now, what is missing or wrong and, in very specific terms, how it might reasonably be corrected. * Part of that support question is whether the current version of the registration templates and descriptions allow the necessary information to be supplied, require what should be required, provide enough hints and justification about what information is needed that we are likely to get that information, and, where appropriate, are clear about what needs to be supplied in-line and what can be provided by reference. If anything is not clear or complete enough, this is the time to say so. * There are some examples in 2141bis to illustrate applicability of r-components and q-components. I think they may be wrong and that they really need checking (and other ones specified/provided as appropriate) by people who have a clear idea of what they are intended to mean. The text about where those queries go is also not as clear as I would like it to be and that may be part of the problem, but it is about as good as Peter and have been able to do so far. Text would be appreciated. * The text about persistence has been removed from 2141bis. The recent threads of conversations have convinced me (at least), that an updated and up-to-date "theory of URNs" document would be very useful, but that (i) it isn't in the WG's charter, (ii) getting it into the WG's critical path would probably kill this effort, (iii) putting arbitrary small bits of it into 2141bis is likely to add to, rather than reducing, confusion, and (iii) we should almost certainly postpone work on that document (or even figuring how to organize that work until after 2141bis is finished). * I discovered in a very helpful conversation last week (with someone who still considers herself a librarian, by the way), that there is a great deal of research going on about identifiers in the Internet era, work that still pays attention to non-electronic "resources" and that probes at what terms like, e.g., "resource" are coming to mean. The conversation also convinced me even more of the wisdom of confining 2141bis as much as possible to syntax and then moving the other discussions to forums where the level of carefully-researched knowledge is much higher than it is in the IETF. Details (including references and pointers) after I get my notes together, but probably not until after 2141bis is locked down. If anyone needs them for ongoing work that won't get in the way to 2141bis, write me offlist. I want to stress that I'm not speaking for the WG, the Co-chairs, or even for Peter, but my assumption at the moment is the penultimate version of 2141bis before WG and IETF Last Call. In other words, we get the input asked for above, do one more revision, and then should be ready to wind this effort up. That schedule is also consistent with my/our not running out of energy to keep waiting for the comments needed to make revisions. I look forward to hearing from everyone who is involved and interested. best, john From nobody Tue Jun 16 08:02:13 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24F51B3A8A for ; Tue, 16 Jun 2015 08:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYMwDNekBaM for ; Tue, 16 Jun 2015 08:02:10 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B481B3A85 for ; Tue, 16 Jun 2015 08:01:55 -0700 (PDT) Received: by igblz2 with SMTP id lz2so15934059igb.1 for ; Tue, 16 Jun 2015 08:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OgMYsr6s0H8OhdHkyPuotvhM5/spN2g2cd60iNvAt1w=; b=HxAe1+zl7BVrsPxJe3CdSnbkUekfY6m2JSLSZQOZ3I3IW9+38OOkb9rYZxfGKZk8uq AttoJvyoY+YTXPnPcAZOS1dcBGmGGvQa8A6X/hmXgYux4PkMHraazF8N8bYiBrRdNH0A 8n+mfHLXqBZvMte55gP914C+Yyd6iIePXf2pwDJX1sjIfd6P89Yfgzorfxo5nujUFypp Nc0VtaFUs44OmPvCBeiK+WWKtXQDg48FVPxzpdisv2Q/b0vUQo9VHqxJBJreruIDeFyh HOli+sl6BRnvYrTdm0br6jbY7pXvrVPWxn8z2DPOlxSGcw1PZGxsEjdNkdWPleg1P1R5 IBFw== X-Gm-Message-State: ALoCoQmK4Rl1xA5Y+i6efn370Dl2mYouZqIF+Pk1PIRT9Urpn3AlIXWHQpzn2/nWYthx7Fe6qWt2 X-Received: by 10.107.27.7 with SMTP id b7mr1113294iob.64.1434466914782; Tue, 16 Jun 2015 08:01:54 -0700 (PDT) Received: from aither.local ([2601:1:8200:3a60:7cb7:3b33:5446:d27d]) by mx.google.com with ESMTPSA id j5sm686505ioo.8.2015.06.16.08.01.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 08:01:53 -0700 (PDT) Message-ID: <55803A5F.6060608@andyet.net> Date: Tue, 16 Jun 2015 09:01:51 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Hakala, Juha E" , John C Klensin , Michael Mealling References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:02:12 -0000 Hi Juha, On 6/16/15 8:23 AM, Hakala, Juha E wrote: > Hello John; all, > > (also a personal opinion only) > > Considering just the URN syntax, the only library related > requirements I am aware of involved URI fragment and query. We wanted > to use the former to indicate locations within identified documents, > and the latter to pass resolution related parameters to URN > resolvers. Since our needs were relatively modest, URNBIS has already > met our requirements That's good to know. > and then went on to specify additional features. > And IMO there is nothing wrong with what 2141bis says (but I need to > check the latest draft, just in case). Your careful review at this stage would be very much appreciated! :-) Peter From nobody Tue Jun 16 08:28:16 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7F1B2E34 for ; Tue, 16 Jun 2015 08:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49YBWJSfFJhF for ; Tue, 16 Jun 2015 08:28:12 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861201B2E26 for ; Tue, 16 Jun 2015 08:28:11 -0700 (PDT) Received: by padev16 with SMTP id ev16so14890568pad.0 for ; Tue, 16 Jun 2015 08:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JBDJMh5ZiIWWm+tn/0rHQXNqOHA5kx85EOB0X8+PdYQ=; b=TVEKlcKkRD8YZa6xakcIXgXEjYRcUxpBoWahNc2m6dRaWFpHRtsRSyHu0IBOmkFxXC D8ZbmWxfaQ7gE3VuxbwpQ6xssDmSzluTrs/oSYpqkPopT3wOhoEw34S3dacfqkqrpB0b 7OEq+Erddc2j/celJQLNixgLDq1lxHMuQ3peO2UZzE2OXb7od4zc5Yj1qWOpodDn/pgA VbMOX5yzBJY3TI9wVXxWd5MERfuu++zqTKbvhAgFBBVJ3xYUcGK9HDm6SXhBmIlvz5U0 NCYuj64hYHXYK+qi74ghmUDqxQ6OFsTgV9/jbHI77M5OAX5c2Ri78hDVuTHXrTNKWVjY e+yQ== X-Received: by 10.68.94.37 with SMTP id cz5mr1705382pbb.70.1434468491196; Tue, 16 Jun 2015 08:28:11 -0700 (PDT) Received: from spandex.local (216-67-4-2-rb2.nwc.dsl.dynamic.acsalaska.net. [216.67.4.2]) by mx.google.com with ESMTPSA id je4sm1754595pbb.17.2015.06.16.08.28.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 08:28:09 -0700 (PDT) Message-ID: <55804085.5000105@gmail.com> Date: Tue, 16 Jun 2015 07:28:05 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "urn@ietf.org" References: <20150615232526.32715.90754.idtracker@ietfa.amsl.com> In-Reply-To: <20150615232526.32715.90754.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150615232526.32715.90754.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:28:14 -0000 As you've probably seen, the -12 version of the 2141bis draft was uploaded yesterday. We're planning on taking the -13 version to working group last call, and we really need some careful review to make sure that problems with the document have been identified and addressed. This morning John sent out a list of issues that he's identified and that need sign-off from the working group. Some of his questions are somewhat open-ended and we need to avoid rat-holing, so please be very specific and provide concrete examples where possible. The immediate questions are: . Are the current versions of the registration templates and descriptions complete and clear? . Are the r-component and q-component examples correct? . Can someone provide clarifying text about where r-component and q-component queries go? He also raised some broader questions which need discussion but which perhaps can wait until we've got some level of agreement on what needs to be done for wglc. (John's email is here: https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) Thanks, Melinda -------- Forwarded Message -------- Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt Date: Mon, 15 Jun 2015 16:25:26 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: urn@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt Pages : 30 Date : 2015-06-15 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. 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: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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 From nobody Fri Jun 19 19:16:46 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C51B2CA1 for ; Fri, 19 Jun 2015 19:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lyVXRK5gEQq for ; Fri, 19 Jun 2015 19:16:42 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5001B2C9F for ; Fri, 19 Jun 2015 19:16:42 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so101740776pdb.1 for ; Fri, 19 Jun 2015 19:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=V7mTGvWhLJ+F2OtDNmZdeZ37EAUzCLFHAaeEprSBC/U=; b=F7cdxbCYhxOU1xS2I+xwhDNlxGO4i4aVXsCkFhACvMI7kaGlR4BaqWMc0Qr+QKRrTI O2XNfRfARtejH8XnBOiXkZUfsTkRKHQ68ES31mXLKgbOkcbV3vTIaqes3e7H4BZQXfkf JJVcJHsyd5/ZKd1FLaP3sLWL7GJC8dWViaPoE8Hn+xHRH6nGlZePbOhQ/CMTJZWdHd4Y KEGivOLzRWpZqsNfciXKzOROb93lzTsPpcdaJ39C7IbFAKDHTmHEKFzvHGGSeuxAQwB1 +FJRAQD8ettU2ve396Htp2HGsc/BsDIIqyv2Qqk5Ik7vciuLxYfD7r+TbGVP0gIfFikT bl8g== X-Received: by 10.67.30.102 with SMTP id kd6mr37193072pad.132.1434766602210; Fri, 19 Jun 2015 19:16:42 -0700 (PDT) Received: from spandex.local (216-67-4-2-rb2.nwc.dsl.dynamic.acsalaska.net. [216.67.4.2]) by mx.google.com with ESMTPSA id af1sm12589460pad.34.2015.06.19.19.16.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 19:16:41 -0700 (PDT) Message-ID: <5584CD07.4050906@gmail.com> Date: Fri, 19 Jun 2015 18:16:39 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "urn@ietf.org" References: <55804085.5000105@gmail.com> In-Reply-To: <55804085.5000105@gmail.com> X-Forwarded-Message-Id: <55804085.5000105@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 02:16:44 -0000 This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-12 with an eye towards what, if anything, needs to be resolved before going to working group last call. Many thanks, and have an excellent weekend. Melinda -------- Forwarded Message -------- Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt Date: Tue, 16 Jun 2015 07:28:05 -0800 From: Melinda Shore To: urn@ietf.org As you've probably seen, the -12 version of the 2141bis draft was uploaded yesterday. We're planning on taking the -13 version to working group last call, and we really need some careful review to make sure that problems with the document have been identified and addressed. This morning John sent out a list of issues that he's identified and that need sign-off from the working group. Some of his questions are somewhat open-ended and we need to avoid rat-holing, so please be very specific and provide concrete examples where possible. The immediate questions are: . Are the current versions of the registration templates and descriptions complete and clear? . Are the r-component and q-component examples correct? . Can someone provide clarifying text about where r-component and q-component queries go? He also raised some broader questions which need discussion but which perhaps can wait until we've got some level of agreement on what needs to be done for wglc. (John's email is here: https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) Thanks, Melinda -------- Forwarded Message -------- Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt Date: Mon, 15 Jun 2015 16:25:26 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: urn@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt Pages : 30 Date : 2015-06-15 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. 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: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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 From nobody Thu Jun 25 05:19:08 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF121A0113 for ; Thu, 25 Jun 2015 05:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIFtTwsvwP1h for ; Thu, 25 Jun 2015 05:19:05 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 393A11A00EE for ; Thu, 25 Jun 2015 05:19:04 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id DDB558B111; Thu, 25 Jun 2015 14:19:03 +0200 (CEST) X-AuditID: 0a453fe7-f79136d0000011d7-00-558bf1b7df23 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 82.82.04567.7B1FB855; Thu, 25 Jun 2015 14:19: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.03.0224.002; Thu, 25 Jun 2015 14:19:03 +0200 From: "Svensson, Lars" To: "Hakala, Juha E" , John C Klensin , Michael Mealling Thread-Topic: [urn] URN standard Thread-Index: AQHQo5TrmT8rIkpDGEWdnusSzcmB+52u74xDgAAn4QCADiIxkA== Date: Thu, 25 Jun 2015 12:19:03 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D095A46@dnbf-ex1.AD.DDB.DE> References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.145] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHObt7XKenrnPO03rZoiAls+iPRVYaFassi5pEYXr13rbV1HHv FhkUvSydtcoelAYunKIWpUYYFBTL6EGaWlhGZFT2sHIl2YuI7tnd7Np/v/P5ne/39/1xOCSh cZN60lbgZLkC2m5QquXqxQuGprd8KTMne+pmGYu7fiuNewYPqIwtX3tVxvKhdqXxxN7PslSF 6XD9dZXJ5/spMz2s/0CYyu9kmj56+8EqxXp1CsPabVtZbsb8HLW11PsNOPzqbdWDL4ld4DLp BhEkomajPT3dSrHWoY7nF4VaTWqoVoCOe2/LxEMLQA29v4SDilRSCShgxVhLlQA0WNIux2KC Wo7+7K4H+EoMNRE1MZhqqXjUXX6fEOuFqNPvUeBaTk1Br1teqHANBaWv51Fo0g8l6qzpBLgR QW1A3WVHggJAjUeNjQ8IcVQcan7zXSFmppDvmsgRFYvev/oT4vFoINCoFO8no0B7VUibiGrP fiDEwdHo7unX8iNAVyGxrZBIKiSSConEC+QNYBSfb5mZRDNJDJObxLDNQHy0t1eAp2uRH1Ak METB36llZo2C3soX5ftBBikzxMKObgGNyi1kiqw0b83mXHaWN2jh/oCA4TDOddm3GCbAHydL zZq4Ycq7eIctz1bo4rNdnN0PEEkI0rrPWMrQRdtZrlA09IOxpNwQB49e3b1WQ1loJ7uFZR0s F+6uI0kDgiuxMJpjLey2TTa7M9wWdJm4Q0k7wUCT4JhKIZBe2vg/k4yM8IN0MkoItiIYjHfQ +bzNEvKOgSV406gwDfqOh3dOCL66MBzpeQ+s0cfBhGAkfMPqKhjOqtdBt9dt1oyWNLClPh4O ZQt8jISPdO0HS4UnioGl2DdK+Hr/MmrgLQwjQzAYcRx8jiPGhtj/XunC22rhJzwS8k7aKV34 ZI4bLxyioYWPYqgLw5F2+l1gdVvkjprej+4lG1+cW7qw2bxyc9rA0zPH7HM3BexNgYlcMdU8 lObZNzUlprSWaDvjIPt8WZ5nbQWV3zWpmxeszeqafaiqZk6fZV6rrCnz3SN33qVlN8HBad7J F24wp0xpUzfML7xX86xuoH9sRmKx/PHocRMStdVPzke+Obczp8+yOMUg5630zASC4+m/pIDh j50EAAA= Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 12:19:07 -0000 Juha, all, > (also a personal opinion only) Another personal opinion: > Considering just the URN syntax, the only library related requirements I = am > aware of involved URI fragment and query. We wanted to use the former to > indicate locations within identified documents, and the latter to pass re= solution > related parameters to URN resolvers. Since our needs were relatively mode= st, > URNBIS has already met our requirements and then went on to specify > additional features. And IMO there is nothing wrong with what 2141bis sa= ys > (but I need to check the latest draft, just in case). >=20 > I am not aware of any immediate need for newly minted URN features such a= s > r-components, but library community may find uses for it later when our > resolvers become smarter. While I agree with what Juha that the requirements of libraries are satisfi= ed by 2141bis, I have a slightly different view on query and r-component. J= uha says that "we wanted to use [...] the latter [e.g. queries] to pass res= olution related parameters to URN resolvers" and that he is "not aware of a= ny immediate need for newly minted URN features such as r-components". Aren= 't r-components exactly for passing resolution-related parameters to the re= solvers? /Lars (who is now moving on to read 2141bis-12)=20 From nobody Thu Jun 25 05:36:38 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EC21A0430 for ; Thu, 25 Jun 2015 05:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toPxsNe_R3c7 for ; Thu, 25 Jun 2015 05:36:35 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD121A01FA for ; Thu, 25 Jun 2015 05:36:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CE6D821AAE for ; Thu, 25 Jun 2015 08:36:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 25 Jun 2015 08:36:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=zj+4VgXgy8PdLMr ga61rNVNX/Ms=; b=ex4+BQOxMl9f/3VywGsknWVGWXS26Cdwdxdnl3A67+AbEjo oFse65cvu7a4C1TlPnN+pxb/jUvp1OCoVUUvjj54MqiwJzFeMz3UqGef1h/ZTKzi F7RffGK1KzK1i9ljJltcSn5ybL7P1+s2Njizb4T/wTaifS8VCJ/GhAjd5Hrg= X-Sasl-enc: dhqRiNGzQAaafch0BVMBjvopV+yAVbyYrlByAYytetiy 1435235794 Received: from [192.168.1.66] (unknown [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 273AA6800ED; Thu, 25 Jun 2015 08:36:34 -0400 (EDT) Message-ID: <558BF5C7.8060807@network-heretics.com> Date: Thu, 25 Jun 2015 08:36:23 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Svensson, Lars" , "Hakala, Juha E" , John C Klensin , Michael Mealling References: <43C8419CE576712C3FCBB16E@JcK-HP8200.jck.com> <6186B5A5-7356-4836-A41E-7C4D6CC50527@thinkingcat.com> <945BD50C1D2BE7CF4D440207@JcK-HP8200.jck.com> <5570437E.8080207@network-heretics.com> <2F1FC776-A7AD-43C2-A836-71310D2BC182@refactored-networks.com> , <24637769D123E644A105A0AF0E1F92EF010D095A46@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D095A46@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URN standard X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 12:36:37 -0000 On 06/25/2015 08:19 AM, Svensson, Lars wrote: > >> Considering just the URN syntax, the only library related requirements I am >> aware of involved URI fragment and query. We wanted to use the former to >> indicate locations within identified documents, and the latter to pass resolution >> related parameters to URN resolvers. Since our needs were relatively modest, >> URNBIS has already met our requirements and then went on to specify >> additional features. And IMO there is nothing wrong with what 2141bis says >> (but I need to check the latest draft, just in case). >> >> I am not aware of any immediate need for newly minted URN features such as >> r-components, but library community may find uses for it later when our >> resolvers become smarter. > While I agree with what Juha that the requirements of libraries are satisfied by 2141bis, I have a slightly different view on query and r-component. Juha says that "we wanted to use [...] the latter [e.g. queries] to pass resolution related parameters to URN resolvers" and that he is "not aware of any immediate need for newly minted URN features such as r-components". Aren't r-components exactly for passing resolution-related parameters to the resolvers? Yes. The purpose of r-components is to pass parameters to resolvers, so that q-components can be used exclusively to pass parameters to resources, and there's no ambiguity about where a parameter is to be used. Keith From nobody Tue Jun 30 08:28:18 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83671ACCEE for ; Tue, 30 Jun 2015 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a39vik1lgzJj for ; Tue, 30 Jun 2015 08:28:14 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DA41ACCFE for ; Tue, 30 Jun 2015 08:28:09 -0700 (PDT) Received: by igrv9 with SMTP id v9so14915673igr.1 for ; Tue, 30 Jun 2015 08:28:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U+DlZVA8XPyZ31+iGrV8rSzOiC0RYa9TZHdVSF6Dg7s=; b=NDm0mJDvq9uL7vfSf61S8puvjDTkWLYcgB7ZRaNOfK4oBw/YGhjhUYvDiriggI9K1v XyseY8zTFQaoJyeUupq6utgtBoKbfG3IZ94DvsuAa20wiA8buUkvheIuU8PmDDOGQueE uCNXgS+pJy+yveb123l2u2p3ruBQOAl6PzK9clchdvloDIT3AnRXLCkKnTieI6kWBt6f RGO7F8Y3r3L/5lj7LWwQVFzLNWhw8ozlEgeyiF+p82nIoVs/oa8rybQl2QZceN43txro Xin3MTxmCH66aWVmrZXjSpL31Bdu0GWZFulCOQvsSO74iYTqF9x73R+T5uYSvV7t86jf DA9g== X-Gm-Message-State: ALoCoQkqk0+F8A9ISdZ3qvAYosiB/Bt5YHRNDT/3vGaGXQfidNgMv7+T1pN9iJihTOltGXDCQgg8 X-Received: by 10.50.225.40 with SMTP id rh8mr20911080igc.39.1435678088648; Tue, 30 Jun 2015 08:28:08 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:45e0:d9ae:8491:b560]) by mx.google.com with ESMTPSA id i7sm7944578igt.18.2015.06.30.08.28.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 08:28:07 -0700 (PDT) Message-ID: <5592B585.7070302@andyet.net> Date: Tue, 30 Jun 2015 09:28:05 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Melinda Shore , "urn@ietf.org" References: <55804085.5000105@gmail.com> <5584CD07.4050906@gmail.com> In-Reply-To: <5584CD07.4050906@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Fwd: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 15:28:16 -0000 Thanks for the reminder, Melinda. I know that at least one active WG participant was on vacation recently, so he wasn't able to provide a review yet. If this WG were meeting at IETF 93, we would have a forcing function to complete reviews. Perhaps we can find a substitute somehow (a deadline or a conference call?). Thanks! Peter On 6/19/15 8:16 PM, Melinda Shore wrote: > This is a reminder to take a look at draft-ietf-urnbis-rfc2141bis-urn-12 > with an eye towards what, if anything, needs to be resolved before going > to working group last call. > > Many thanks, and have an excellent weekend. > > Melinda > > > -------- Forwarded Message -------- > Subject: Fwd: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > Date: Tue, 16 Jun 2015 07:28:05 -0800 > From: Melinda Shore > To: urn@ietf.org > > As you've probably seen, the -12 version of the 2141bis > draft was uploaded yesterday. We're planning on taking > the -13 version to working group last call, and we really > need some careful review to make sure that problems > with the document have been identified and addressed. > > This morning John sent out a list of issues that he's > identified and that need sign-off from the working group. > Some of his questions are somewhat open-ended and we > need to avoid rat-holing, so please be very specific > and provide concrete examples where possible. > > The immediate questions are: > > . Are the current versions of the registration templates > and descriptions complete and clear? > . Are the r-component and q-component examples correct? > . Can someone provide clarifying text about where r-component > and q-component queries go? > > He also raised some broader questions which need discussion > but which perhaps can wait until we've got some level of > agreement on what needs to be done for wglc. > > (John's email is here: > https://mailarchive.ietf.org/arch/msg/urn/H2lkeRkYhPhbqF_zMs555ARCp6g) > > Thanks, > > Melinda > > -------- Forwarded Message -------- > Subject: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-12.txt > Date: Mon, 15 Jun 2015 16:25:26 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: urn@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Uniform Resource Names, Revised > Working Group of the IETF. > > Title : Uniform Resource Names (URNs) > Authors : Peter Saint-Andre > John C Klensin > Filename : draft-ietf-urnbis-rfc2141bis-urn-12.txt > Pages : 30 > Date : 2015-06-15 > > Abstract: > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is assigned under the "urn" scheme and a particular URN > namespace, with the intent that the URN will be either a persistent, > location-independent resource identifier or in some cases an abstract > designator that is persistent but that does not identify a resource. > With regard to URN syntax, this document defines the canonical syntax > for URNs (in a way that is consistent with URI syntax), specifies > methods for determining URN equivalence, and discusses URI > conformance. With regard to URN namespaces, this document specifies > a method for defining a URN namespace and associating it with a > namespace identifier, and describes procedures for registering > namespace identifiers with the Internet Assigned Numbers Authority > (IANA). This document obsoletes both RFC 2141 and RFC 3406. > > > 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: > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >