From nobody Mon Oct 5 03:54: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 3F1BD1A913F for ; Mon, 5 Oct 2015 03:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L71aKmnGKx8F for ; Mon, 5 Oct 2015 03:53:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316271A9136 for ; Mon, 5 Oct 2015 03:53:53 -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.280.20; Mon, 5 Oct 2015 10:53:36 +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.0280.017; Mon, 5 Oct 2015 10:53:35 +0000 From: "Hakala, Juha E" To: Sean Leonard , "urn@ietf.org" Thread-Topic: [urn] resolver profiles: a generative POWER-UP for r-component Thread-Index: AQHQ95WFeOnu40hdB0Sgxi8vmxZOHJ5cvcVg Date: Mon, 5 Oct 2015 10:53:35 +0000 Message-ID: References: <56054AEF.7000800@seantek.com> In-Reply-To: <56054AEF.7000800@seantek.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [128.214.71.222] x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:epWpNyuGZ5MRBV6w0x3J1f8Xj+P6ldNd4AanuYvOdYrZ7n+T/ouNHZorv6uwXK6bvd47nyFW7jW4eiuLfWoEEKOaKAJyoAFdzphPjuoOuDmCj4TSec8e7o48QZxRubKVJZ9YH+r9T+RAosYvONt+QQ==; 24:Y4f4/3U7qmPxNftVuPhE1GytJKpaWfKpl4ItX3HDmxNWkGyuOcgXG/wy7X75483t6/Ezq9XMReJzFbjC2fu60vu0YdEh1NSiTXiHdz8t8x4=; 20:1jrHp4JCd4OeX+Yn4gx3yEYq/nerfyU0wi4IoQnZiFASRnFzp/9uq6tcQeKfp9dgvABtfrLjWF6qVXEz+hhBRw== 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)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 07200C0526 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(45074003)(199003)(189002)(5001770100001)(74482002)(5001960100002)(105586002)(106116001)(50986999)(54356999)(68736005)(106356001)(76576001)(46102003)(15975445007)(10400500002)(107886002)(77096005)(5002640100001)(77156002)(102836002)(62966003)(189998001)(2501003)(101416001)(2900100001)(81156007)(5001830100001)(5003600100002)(5001920100001)(76176999)(74316001)(15380165006)(97736004)(19580405001)(92566002)(40100003)(66066001)(561944003)(19580395003)(64706001)(2950100001)(86362001)(33656002)(87936001)(122556002)(5004730100002)(5007970100001)(5008740100001)(5001860100001)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2015 10:53:35.5295 (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: Subject: Re: [urn] resolver profiles: a generative POWER-UP for r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 10:54:02 -0000 SGVsbG8sDQoNCnNvbWUgY29tbWVudHMgYmVsb3cuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHVybiBbbWFpbHRvOnVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU2VhbiBMZW9uYXJkDQo+IFNlbnQ6IDI1LiBzeXlza3V1dGEgMjAxNSAxNToyNA0KPiBU bzogdXJuQGlldGYub3JnDQo+IFN1YmplY3Q6IFt1cm5dIHJlc29sdmVyIHByb2ZpbGVzOiBhIGdl bmVyYXRpdmUgUE9XRVItVVAgZm9yIHItY29tcG9uZW50DQo+IA0KPiBVUk5pZXM6DQo+IA0KPiBX aGF0IFVSTnMgcmVhbGx5IG5lZWQgaXMgYSB3YXkgdG8gZW5zdXJlIHRoYXQgdGhlIHJlc29sdXRp b24gcHJvY2Vzcw0KPiBkZWxpdmVycyBtb3JlIGNvbnNpc3RlbnQgYW5kIHByZWRpY3RhYmxlIHJl c3VsdHMuDQoNCkFsbCBQSURzIG11c3QgYmUgbWFkZSAic21hcnRlciIuIElmIHJlc29sdXRpb24g b25seSBsaW5rcyBpZGVudGlmaWVyIChuYW1lKSB0byAxLW4gbG9jYXRpb25zLCBpdCBpcyBwb3Nz aWJsZSB0byBhcmd1ZSB0aGF0IHRoaXMgaXMgYW4gZXh0cmEgc3RlcCB0aGF0IGNhbiAvIHNob3Vs ZCBiZSBhdm9pZGVkLiBCdXQgaWYgcmVzb2x1dGlvbiBjYW4gZmFjaWxpdGF0ZSBwZXJzaXN0ZW50 IGFjY2VzcyB0byBhbGwga2luZHMgb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGlkZW50aWZpZWQg cmVzb3VyY2UsIGl0IGlzIGhhcmQgdG8gYWNoaWV2ZSBzaW1pbGFyIHJlc3VsdHMgd2l0aCBlLmcu IEhUVFAgKHdoaWNoIGlzIGl0c2VsZiBub3QgcGVyc2lzdGVudCkuICANCg0KSXQgaGFzIG5vdCBi ZWVuIGVhc3kgdG8gaW1wcm92ZSBVUk4gc3ludGF4IHNvIHRoYXQgc21hcnQgcmVzb2x1dGlvbiBp cyBwb3NzaWJsZS4gT25lIHByb2JsZW0gaXMgVVJJIHN5bnRheCwgd2hpY2ggaGFzIGxlZnQgdXMg d2l0aCBhIGxpbWl0ZWQgdG9vbCBzZXQgKD8gZm9yIHF1ZXJ5IGFuZCAjIGZvciBmcmFnbWVudCku IFVzaW5nID8/IGZvciByLWNvbXBvbmVudCBpcyBpbiB0aGVzZSBjaXJjdW1zdGFuY2VzIHRoZSBi ZXN0IHRoaW5nIHdlIGNhbiBkby4gQWxhcywgb3RoZXIgUElEIHN5c3RlbXMgbWF5IG5vdCBiZSBh YmxlIHRvIGRvIGV2ZW4gdGhpcy4gICANCg0KPiBTaW5jZSB0aGUgaW50cm9kdWN0aW9uIG9mIHRo ZSByLWNvbXBvbmVudCwgVVJOcyBhcmUgbm93IGFibGUgdG8gYWRkcmVzcw0KPiAoc3BlYWsgdG8p IHRoZSByZXNvbHZlciBkaXJlY3RseSB0byBjb250cm9sIGFzcGVjdHMgb2YgdGhlIHJlc29sdXRp b24gcHJvY2Vzcy4NCj4gWWV0IHRoZSBzcGVjaWZpY3MgYXJlIHdvZWZ1bGx5IGFic2VudCBpbiBk cmFmdC1pZXRmLXVybmJpcy1yZmMyMTQxYmlzLXVybi0xMy4NCg0KVGhlIGludGVudGlvbiBpcyB0 byBwcm9jZWVkIGluIHR3byBzdGVwczogZmlyc3QgdG8gZXN0YWJsaXNoIHItY29tcG9uZW50LCBh bmQgdGhlbiB0byBlc3RhYmxpc2ggbWVjaGFuaXNtIHdpdGggd2hpY2ggdGhlIHItY29tcG9uZW50 IHN5bnRheCBhbmQgc2VtYW50aWNzIGFyZSBtYWludGFpbmVkLiAgU2luY2UgdGhlIHRlY2huaWNh bCBpbmZyYXN0cnVjdHVyZSB3aXRoaW4gd2hpY2ggcmVzb2x1dGlvbiBoYXBwZW5zIGNoYW5nZXMg YWxsIHRoZSB0aW1lLCBpdCBpcyBub3QgcG9zc2libGUgdG8gY3JlYXRlIGEgZml4ZWQgbGlzdCBv ZiByZXNvbHV0aW9uIHNlcnZpY2VzIGFuZCBzZXJ2aWNlIHBhcmFtZXRlcnMuIEJ1dCB3ZSBjYW4g aGF2ZSBmb3IgaW5zdGFuY2UgSUFOQSByZWdpc3RyeSBmb3Igc2hhcmVkIHNlcnZpY2VzIChhbmQg dGhlaXIgcGFyYW1ldGVycykgYW5kIHNvbWUgb3RoZXIgYXJyYW5nZW1lbnRzIGZvciBuYW1lc3Bh Y2Ugc3BlY2lmaWMgc2VydmljZXMgKGlmIGFueSkuIA0KDQo+IEkgcHJvcG9zZSB0aGF0IHRoZSBy LWNvbXBvbmVudCBiZWdpbiB3aXRoIGEgcmVzb2x2ZXIgcHJvZmlsZSAob3IgcmVzb2x1dGlvbg0K PiBwcm9maWxlLCBvciBkaXJlY3RpdmUpLCB3aGljaCBpcyBhbiBvcGFxdWUgc3RyaW5nIHRoYXQg aWRlbnRpZmllcyB0aGUgbmF0dXJlIG9mDQo+IHRoZSByZXNvbHV0aW9uIHNlcnZpY2VzIGJlaW5n IHJlcXVlc3RlZCBieSB0aGUgcGFydGljdWxhciB1cm46IFVSSS4gSXQncyBhDQo+IFBPV0VSLVVQ IPCfjYQgZm9yIHRoZSByLWNvbXBvbmVudCENCg0KVGhpcyBpcyBvbmUgb3B0aW9uIHRoYXQgd2Ug Y2FuIGNvbnNpZGVyLiANCg0KPiBDb25zaWRlciBvdXIgZmF2b3JpdGUgdXJuOmlzYm4uIEdpdmVu IGFuIElTQk4sIHdoYXQgY2FuIHdlIGRvIHdpdGggaXQ/DQo+IFdoYXQgZG8gd2Ugd2FudCB0byBn ZXQgZm9yIGl0PyBBbmQgaG93IGNhbiB3ZSBtYWtlIHRoZSBmLWNvbXBvbmVudA0KPiBtZWFuaW5n ZnVsLCBpZiB0aGUgdXJuOiBVUkkgc3RyaW5nIGlzIG5vdCBnb2luZyB0byBnaXZlIHVzIGJhY2sg c29tZSBraW5kIG9mDQo+IHByZWRpY3RhYmxlIG1lZGlhIHR5cGUvdHlwZSBvZiByZXNvdXJjZT8N Cg0KQW5kIGFsc286IHdoYXQgZG8gLyBjYW4gd2UgZG8gbm93LCBhbmQgd2hhdCBpcyBwb3NzaWJs ZSA1MCBvciAxMDAgeWVhcnMgZnJvbSBub3c/IFdlIGRvIG5vdCBoYXZlIGFueSBpZGVhIG9mIHdo YXQgbGlicmFyeSBzeXN0ZW1zIC8gZGlnaXRhbCBhcmNoaXZlcyB3aWxsIGJlIGNhcGFibGUgb2Yg aW4gdGhlIGRpc3RhbnQgZnV0dXJlLCBidXQgd2UgZG8gbm93IHRoYXQgYm9va3Mgd2lsbCBzdGls bCBoYXZlIHRoZSBzYW1lIElTQk5zIGJ5IHRoZW4uIE9mIGNvdXJzZSwgYWxsIG1hbmlmZXN0YXRp b25zIHZhbGlkIG5vdyB3aWxsIGJlIHJlbmRlcmVkIHVzZWxlc3MgZm9yIG1vc3QgdXNlcnMgaW4g MjExNTsgb25seSB0aG9zZSB3aXRoIHNwZWNpYWxpemVkIHRvb2xzIGNhbiBzdGlsbCByZW5kZXIg dGhlIG9yaWdpbmFsIGRvY3VtZW50cy4gQWxsIG90aGVycyB3aWxsIHVzZSBtaWdyYXRlZCBtb2Rl cm4gdmVyc2lvbnMgb2YgdGhlIHdvcmtzLiAgDQoNCj4gQW5zd2VyOiB0aGUgbmFtZXNwYWNlIHJl Z2lzdHJhdGlvbiBjYW4gaW5jbHVkZSBwcm9maWxlcywgYW5kIHRoZXNlIHByb2ZpbGVzDQo+IGJl dHRlciBzcGVjaWZ5IHdoYXQgaGFwcGVucyB3aGVuIHJlc29sdXRpb24gb2NjdXJzLiBJbiBvdXIg SVNCTiBjYXNlLA0KPiBwcm9maWxlcyBjYW4gaW5jbHVkZToNCj4gc2hvd2Jvb2sNCj4gbGlicmFy eWNhdGFsb2cNCj4gcHJpY2luZw0KPiBidXlib29rDQo+IGNvdmVyc2hvdA0KPiBiaWJsaW9ncmFw aGljaW5mbw0KPiByZWZlcmVuY2Vkd29ya3MNCj4gLi4uYW5kIGEgcG90ZW50aWFsbHkgaW5maW5p dGUgcmFuZ2Ugb2Ygb3RoZXIgcmVzb2x1dGlvbiB0aGluZ3MgdG8gZG8uDQoNCkluZGVlZDsgSSBj b3VsZCBlYXNpbHkgYWRkIGEgbG90IG9mIHN0dWZmIGludG8gdGhpcyBsaXN0IDstKS4gDQogDQo+ IFRoZSBhYnNlbmNlIG9mIGEgcHJvZmlsZSBzdHJpbmcgZG9lcyBub3QgaW1wbHkgYSAiZGVmYXVs dCIgYWN0aW9uLiBJZiB5b3UNCj4gc3BlY2lmeSB1cm46aXNibjowMzg1NTM3NjcwLCB5b3UgYXJl IGxlZnQgd2l0aCBqdXN0IHRoZSBpZGVudGlmaWVyLg0KPiBUaGUgaW1wbGVtZW50YXRpb24gKGNv bnRleHQpIGNhbiBmaWd1cmUgb3V0IHdoYXRldmVyIGl0IHdhbnRzIHRvIGRvLg0KDQpUaGlzIGlz IHRoZSBjdXJyZW50IHN0YXR1cyBhbmQgZGVmaW5pdGVseSBub3Qgb25lIHRoYXQgd2Ugc2hvdWxk IGJlIGhhcHB5IHdpdGguIEl0IGlzIGltcG9ydGFudCB0byBnaXZlIHRoZSB1c2VyIGEgY2hvaWNl IGJldHdlZW4gZGlmZmVyZW50IG9wdGlvbnMuIElNTyB0aGUgcm9sZSBvZiBtZXRhZGF0YSB3aWxs IGJlIGVzc2VudGlhbDogaG93IG11Y2ggd2lsbCB0aGlzIHJlc291cmNlIGNvc3Q/IGlzIHRoZXJl IGEgRmlubmlzaCB0cmFuc2xhdGlvbj8gd2hhdCBjYW4gSSBkbyB3aXRoIHRoaXMgcmVzb3VyY2Ug b25jZSBJIGhhdmUgZG93bmxvYWRlZCBpdD8gd2hhdCB0b29scyBzaGFsbCBJIG5lZWQgdG8gcmVu ZGVyIGl0PyB3aG8gb3ducyB0aGUgcmlnaHRzIGZvciB0aGlzIHdvcms/IEFuZCBzbyBvbi4gDQoN Cj4gVG8gdGhlIGV4dGVudCB0aGF0IHRoZSByZXNvbHZlciBwcm9maWxlIG5lZWRzIG9yIGFjY2Vw dHMgYWRkaXRpb25hbCBkYXRhLCB0aGlzDQo+IGRhdGEgY2FuIGZvbGxvdyB0aGUgcHJvZmlsZSBz dHJpbmcuDQo+IA0KPiBFeGFtcGxlcyBpbmNsdWRlOg0KPiANCj4gdXJuOmlzYm46MDM4NTUzNzY3 MD9wcm9kdWN0cGhvdG86ZHBpPTYwMA0KPiB1cm46aXNibjowMzg1NTM3NjcwP3ByaWNpbmc6YXU7 dXNlZA0KDQpBbHRob3VnaCB0aGVzZSBpbmZvcm1hdGlvbiBuZWVkcyBhcmUgZGVmaW5pdGVseSB2 YWxpZCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIG5haWwgdGhlIHN5bnRheCB5ZXQuIA0KDQo+IHVy bjpvaWQ6MS4zLjYuMS41LjU/aW5mbw0KPiB1cm46aWV0ZjpyZmM6Mzk4Nj9nZXRzcGVjOmN0PXRl eHQvaHRtbCNzZWN0aW9uLTIuMQ0KPiANCj4gVGhlIHN5bnRheCBpczoNCj4gDQo+IA0KPiAgICAg ICAgbmFtZXN0cmluZyAgICA9IGFzc2lnbmVkLW5hbWUNCj4gICAgICAgICAgICAgICAgICAgICAg ICBbICI/IiByLWNvbXBvbmVudCBdDQo+ICAgICAgICAgICAgICAgICAgICAgICAgWyAiIyIgZi1j b21wb25lbnQgXQ0KPiAgICAgICAgYXNzaWduZWQtbmFtZSA9ICJ1cm4iICI6IiBOSUQgIjoiIE5T Uw0KPiAgICAgICAgTklEICAgICAgICAgICA9IChhbHBoYW51bSkgMCozMChsZGgpIChhbHBoYW51 bSkNCj4gICAgICAgIGxkaCAgICAgICAgICAgPSBhbHBoYW51bSAvICItIg0KPiAgICAgICAgTlNT ICAgICAgICAgICA9IHdvcmQNCj4gICAgICAgIHItY29tcG9uZW50ICAgPSBwcm9maWxlIFsiOiIg cXVlcnldDQo+ICAgICAgICBwcm9maWxlICAgICAgID0gTklEDQo+ICAgICAgICA7IHF1ZXJ5IGlz IGZyb20gUkZDIDM5ODYNCj4gICAgICAgIHdvcmQgICAgICAgICAgPSBwY2hhciAqKHBjaGFyIC8g Ii8iKQ0KPiAgICAgICAgZi1jb21wb25lbnQgICA9IGZyYWdtZW50ICANCj4gDQo+IFVubGlrZSB0 aGUgTlNTLCB3aGljaCBuZWVkcyB0byBiZSB3ZWxsLWRlZmluZWQsIGR1cmFibGUsIGltbXV0YWJs ZSwgZXRjLiwNCj4gcHJvZmlsZXMgYXJlIGludGVuZGVkIHRvIGJlIHZlcnkgbGlnaHR3ZWlnaHQg YW5kIGNhcHJpY2lvdXMuIFRvIHRoZSBleHRlbnQNCj4gdGhhdCBhIG5hbWVzcGFjZSB1c2VzIHBy b2ZpbGVzIGF0IGFsbCwgcmVnaXN0cmF0aW9uIG9mIHByb2ZpbGVzIHdvdWxkIGJlIGVpdGhlcg0K PiBGaXJzdC1Db21lLCBGaXJzdC1TZXJ2ZWQsIG9yIFNwZWNpZmljYXRpb24gUmVxdWlyZWQuIFRo ZSBuYW1lc3BhY2UNCj4gcmVnaXN0cmF0aW9uIGNhbiBpbXBvc2UgcmVzdHJpY3Rpb25zIG9uIHBy b2ZpbGVzIChpbmNsdWRpbmcgZGlzYWxsb3dpbmcgcHJvZmlsZXMNCj4gYWx0b2dldGhlciksIGJ1 dCBhbnlvbmUgc2hvdWxkIGJlIHBlcm1pdHRlZCB0byBpbnZlbnQgYSBuZXcgcHJvZmlsZSwNCj4g ZG9jdW1lbnQgaXQsIGFuZCByZWdpc3RlciBpdC4gW1RoaXMgaXMgYSBnZW5lcmF0aXZlIHByb3Bv c2l0aW9uLS1zZWUgRGF2aWQgRy4NCj4gUG9zdCwgVGhlIFRoZW9yeSBvZiBHZW5lcmF0aXZpdHks DQo+IDxodHRwOi8vaXIubGF3bmV0LmZvcmRoYW0uZWR1L2Zsci92b2w3OC9pc3M2LzIvPi5dDQoN CldoYXRldmVyIHJ1bGUgYSBVUk4gbmFtZXNwYWNlIGFwcGxpZXMgZm9yIG5hbWluZywgb25seSBh cHBsaWVzIHRvIE5TUy4gVGhlIGNvbXBvbmVudHMgY2FuIGJlIGFkZGVkIGJ5IGFueWJvZHkgYW55 IHRpbWUuIEkgc3VwcG9zZSB0aGF0IHRoZXkgd2lsbCBvZnRlbiBiZSBtYWNoaW5lIGdlbmVyYXRl ZC4gQSBHVUkgd2hpY2ggZW5hYmxlcyB0aGUgdXNlciB0byByZXRyaWV2ZSBtZXRhZGF0YSBhYm91 dCB0aGUgcmVzb3VyY2Ugd2lsbCBtb2RpZnkgdGhlIGFjdHVhbCBjb21wb25lbnQgYWNjb3JkaW5n bHkgd2hlbiBwcm90b2NvbHMgYW5kIG1ldGFkYXRhIGZvcm1hdHMgY2hhbmdlLiBVc2VycyBkbyBu b3QgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0IHRoZXNlIGNoYW5nZXMuIEFuZCB3ZSBzdGFu ZGFyZCBtYWtlcnMgb25seSBuZWVkIHRvIHByb3ZpZGUgbmV3IHNlcnZpY2VzIGFuZCBwYXJhbWV0 ZXJzIHdoZW4gcmVxdWVzdGVkLiANCg0KQXMgcmVnYXJkcyB0aGUgc3ludGF4IG9mIHItY29tcG9u ZW50LCBJTU8gaXQgaXMgdXNlZnVsIHRvIHByb3ZpZGUgc29tZSBnZW5lcmljIHNlcnZpY2VzLiBC YWNrd2FyZHMgY29tcGF0aWJpbGl0eSB3aXRoIFJGQyAyNDgzIHJlcXVpcmVzIHRoYXQuIEJ1dCB3 ZSBhbHNvIGtub3cgdGhhdCBSRkMgMjQ4MyBoYWQgdG9vIHNpbXBsZSB2aWV3IG9uIHNlcnZpY2Vz OyBmb3IgaW5zdGFuY2UsIHRoZXJlIGNhbiBiZSBtYW55IGRpZmZlcmVudCBtZXRhZGF0YSBmb3Jt YXRzLCBhbmQgYXNraW5nIGVhY2ggb25lIG9mIHRoZW0gdmlhIGRpZmZlcmVudCBzZXJ2aWNlIHdv dWxkIG5vdCBtYWtlIHNlbnNlLiAgDQoNCj4gUmVzb2x2ZXIgcHJvZmlsZXMgYXJlIG5hbWVzcGFj ZS1zcGVjaWZpYywgc28gImluZm8iIGZvciB0aGUgb2lkOiBVUk4gd291bGQNCj4gaGF2ZSB0b3Rh bGx5IGRpZmZlcmVudCBzZW1hbnRpY3MgZnJvbSAiaW5mbyIgZm9yIHRoZSBuYXRvOiBVUk4gb3IN Cj4gc2VydmljZTogVVJOLg0KPiANCj4gVGhlIHByb2ZpbGUgZnVuY3Rpb25zIGFzIGEgY29udHJh Y3Qgb24gaG93IHNwZWNpZmljIHJlc29sdmVycyBzaG91bGQgYmVoYXZlLA0KPiBpbmNsdWRpbmcg aG93IHRoZSByZXNvbHZlciBzaG91bGQgaW50ZXJwcmV0IHRoZSBxdWVyeSBwYXJhbWV0ZXJzDQo+ IChzdHJpbmcpIGFuZCB0cmFuc2xhdGUgdGhlIGluZm9ybWF0aW9uIGludG8gcmVzb3VyY2VzIChv ciBpbnRvIFVSTHMgdGhhdCBjYW4gYmUNCj4gZGVyZWZlcmVuY2VkIGludG8gcmVzb3VyY2VzKS4N Cg0KSSBhbSBhZnJhaWQgdGhhdCBtYWtpbmcgcmVzb2x2ZXIgcHJvZmlsZXMgc29sZWx5IG5hbWVz cGFjZS1zcGVjaWZpYyBtaWdodCBjcmVhdGUgcHJvYmxlbXMuIEJ1dCBpdCBpcyBjZXJ0YWluIHRo YXQgZGlmZmVyZW50IG5hbWVzcGFjZXMgd2lsbCBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2aWNlcy4g Rm9yIGluc3RhbmNlLCBJU0JOIGFuZCBJU05JIChJbnRlcm5hdGlvbmFsIFN0YW5kYXJkIE5hbWUg SWRlbnRpZmllcikgd2lsbCBub3QgaGF2ZSBtdWNoIGNvbW1vbiBmcm9tIHNlcnZpY2UgcG9pbnQg b2Ygdmlldy4gQnV0IHNhbWUgcGVvcGxlIHdpbGwgYmUgdXNpbmcgYm90aCwgcHJvdmlkZWQgdGhh dCBJU05JIGFjcXVpcmVzIGEgVVJOIG5hbWVzcGFjZS4gDQoNCkJlc3QgcmVnYXJkcywgDQoNCkp1 aGENCg0KPiBXaXRoIHRoaXMgZGVmaW5pdGlvbiwgdGhlcmUgaXMgbm8gbG9uZ2VyIGEgcS1jb21w b25lbnQuIEV2ZXJ5dGhpbmcgaXMgb24gdGhlIHItDQo+IGNvbXBvbmVudC4gRWZmZWN0aXZlbHkg dGhlIHItY29tcG9uZW50IGlzIHRoZSBxdWVyeSwgYnV0IGl0J3MgYWRkcmVzc2VkIHRvDQo+IGFu ZCBpbnRlcnByZXRlZCBieSB0aGUgcmVzb2x2ZXIuDQo+IA0KPiBUaGF0J3MgdGhlIHByb3Bvc2Fs LiBDb21tZW50cyB3ZWxjb21lLg0KPiANCj4gU2Vhbg0KDQo= From nobody Tue Oct 6 02:27: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 D7D8C1B3EAD for ; Tue, 6 Oct 2015 02:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1noHGM1UzHUt for ; Tue, 6 Oct 2015 02:27:25 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540D31B3EAB for ; Tue, 6 Oct 2015 02:27:25 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6A320509C4; Tue, 6 Oct 2015 05:27:23 -0400 (EDT) To: "Hakala, Juha E" , "urn@ietf.org" References: <56054AEF.7000800@seantek.com> From: Sean Leonard Message-ID: <561393DB.6090001@seantek.com> Date: Tue, 6 Oct 2015 02:26:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020906030708040406010501" Archived-At: Subject: Re: [urn] resolver profiles: a generative POWER-UP for r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 09:27:28 -0000 This is a cryptographically signed message in MIME format. --------------ms020906030708040406010501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Thank you for this response. I think we are making progress. On 10/5/2015 3:53 AM, Hakala, Juha E wrote: > Hello, > > some comments below. > >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard >> Sent: 25. syyskuuta 2015 15:24 >> To: urn@ietf.org >> Subject: [urn] resolver profiles: a generative POWER-UP for r-componen= t >> >> URNies: >> >> What URNs really need is a way to ensure that the resolution process >> delivers more consistent and predictable results. > All PIDs must be made "smarter". If resolution only links identifier (n= ame) to 1-n locations, it is possible to argue that this is an extra step= that can / should be avoided. But if resolution can facilitate persisten= t access to all kinds of information about the identified resource, it is= hard to achieve similar results with e.g. HTTP (which is itself not pers= istent). > > It has not been easy to improve URN syntax so that smart resolution is = possible. One problem is URI syntax, which has left us with a limited too= l set (? for query and # for fragment). Using ?? for r-component is in th= ese circumstances the best thing we can do. Alas, other PID systems may n= ot be able to do even this. The invention of the r-component is (in my view) a major step forward.=20 Making the r-component mean something, i.e., enabling and channeling the = resolution process, is the next step forward. > >> Since the introduction of the r-component, URNs are now able to addres= s >> (speak to) the resolver directly to control aspects of the resolution = process. >> Yet the specifics are woefully absent in draft-ietf-urnbis-rfc2141bis-= urn-13. > The intention is to proceed in two steps: first to establish r-componen= t, and then to establish mechanism with which the r-component syntax and = semantics are maintained. Since the technical infrastructure within whic= h resolution happens changes all the time, it is not possible to create a= fixed list of resolution services and service parameters. But we can hav= e for instance IANA registry for shared services (and their parameters) a= nd some other arrangements for namespace specific services (if any). Yes, that is the idea. >> Consider our favorite urn:isbn. Given an ISBN, what can we do with it?= >> What do we want to get for it? And how can we make the f-component >> meaningful, if the urn: URI string is not going to give us back some k= ind of >> predictable media type/type of resource? > And also: what do / can we do now, and what is possible 50 or 100 years= from now? We do not have any idea of what library systems / digital arch= ives will be capable of in the distant future, but we do now that books w= ill still have the same ISBNs by then. Of course, all manifestations vali= d now will be rendered useless for most users in 2115; only those with sp= ecialized tools can still render the original documents. All others will = use migrated modern versions of the works. Yes we should design for the future as well. > >> Answer: the namespace registration can include profiles, and these pro= files >> better specify what happens when resolution occurs. In our ISBN case, >> profiles can include: >> showbook >> librarycatalog >> pricing >> buybook >> covershot >> bibliographicinfo >> referencedworks >> ...and a potentially infinite range of other resolution things to do. > Indeed; I could easily add a lot of stuff into this list ;-). > =20 >> The absence of a profile string does not imply a "default" action. If = you >> specify urn:isbn:0385537670, you are left with just the identifier. >> The implementation (context) can figure out whatever it wants to do. > This is the current status and definitely not one that we should be hap= py with. It is important to give the user a choice between different opti= ons. IMO the role of metadata will be essential: how much will this resou= rce cost? is there a Finnish translation? what can I do with this resourc= e once I have downloaded it? what tools shall I need to render it? who ow= ns the rights for this work? And so on. Yes. > >> To the extent that the resolver profile needs or accepts additional da= ta, this >> data can follow the profile string. >> >> Examples include: >> >> urn:isbn:0385537670?productphoto:dpi=3D600 >> urn:isbn:0385537670?pricing:au;used > Although these information needs are definitely valid it is not necessa= ry to nail the syntax yet. > >> urn:oid:1.3.6.1.5.5?info >> urn:ietf:rfc:3986?getspec:ct=3Dtext/html#section-2.1 >> >> The syntax is: >> >> >> namestring =3D assigned-name >> [ "?" r-component ] >> [ "#" f-component ] >> assigned-name =3D "urn" ":" NID ":" NSS >> NID =3D (alphanum) 0*30(ldh) (alphanum) >> ldh =3D alphanum / "-" >> NSS =3D word >> r-component =3D profile [":" query] >> profile =3D NID >> ; query is from RFC 3986 >> word =3D pchar *(pchar / "/") >> f-component =3D fragment >> >> Unlike the NSS, which needs to be well-defined, durable, immutable, et= c., >> profiles are intended to be very lightweight and capricious. To the ex= tent >> that a namespace uses profiles at all, registration of profiles would = be either >> First-Come, First-Served, or Specification Required. The namespace >> registration can impose restrictions on profiles (including disallowin= g profiles >> altogether), but anyone should be permitted to invent a new profile, >> document it, and register it. [This is a generative proposition--see D= avid G. >> Post, The Theory of Generativity, >> .] > Whatever rule a URN namespace applies for naming, only applies to NSS. Yes. > The components can be added by anybody any time. Yes, that is part of the "generative principle": we are designing=20 systems that will generate innovation by making the registration process = as free and open as possible to disruptive new technologies. > I suppose that they will often be machine generated. A GUI which enable= s the user to retrieve metadata about the resource will modify the actual= component accordingly when protocols and metadata formats change. Users = do not need to know anything about these changes. And we standard makers = only need to provide new services and parameters when requested. > > As regards the syntax of r-component, IMO it is useful to provide some = generic services. Backwards compatibility with RFC 2483 requires that. Bu= t we also know that RFC 2483 had too simple view on services; for instanc= e, there can be many different metadata formats, and asking each one of t= hem via different service would not make sense. I do not consider RFC 2483 backwards compatibility a design goal (for=20 one thing, it includes URCs, which don't really exist now), but it's=20 good to know. I have now been made aware of the text/uri-list media type.= > >> Resolver profiles are namespace-specific, so "info" for the oid: URN w= ould >> have totally different semantics from "info" for the nato: URN or >> service: URN. >> >> The profile functions as a contract on how specific resolvers should b= ehave, >> including how the resolver should interpret the query parameters >> (string) and translate the information into resources (or into URLs th= at can be >> dereferenced into resources). > I am afraid that making resolver profiles solely namespace-specific mig= ht create problems. But it is certain that different namespaces will supp= ort different services. For instance, ISBN and ISNI (International Standa= rd Name Identifier) will not have much common from service point of view.= But same people will be using both, provided that ISNI acquires a URN na= mespace. Yes, that is the tension between universal resolver profiles and ones=20 that are namespace-specific: identifiers (or, more specifically,=20 identified objects) may not have much in common with each other's=20 applicable services. Delineating by namespace is one way to group=20 services, but it is not the only way. I will follow-up with a dedicated=20 post on this topic. Best regards, Sean --------------ms020906030708040406010501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MDYwOTI2NTFaMC8GCSqGSIb3DQEJBDEiBCAxN9kbdkDhexI1Hs3ulFmkv9UYXkua1zvVwA7y Sk6qiTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQC37V/lggqdzjSRQcYe Ixkwd+oIvU+Tzr4/uw8sxkzKo+ojVgxWBpDWHhMpeEtMEWV/R7W1jGc4QELn4xLNbDyghlh3 5cV0ax9m8NEQ6Tkt/pBD2BvVRovRzXSFoP3t48rNjLqmhVBHpouO62k7CitQBoO+LT/ocqbm AMJlmZ/gqItoHOnXKZMkcS+11MCx4VI6HOSnZ4hf/E6+mcAU7TU/Mb0PIp+DjM2S5NZEJ/YJ FHiLp3AeQ1D68n08dfY7B7YRLX9MawJX8J7W9iYdEk6V89c4xkv0xRKZJY3fj+6mhvnhpcyR HNHe1JIJnntIsUr6JX04kwQYapAxE6J2+fMqAAAAAAAA --------------ms020906030708040406010501-- From nobody Tue Oct 6 03:27:22 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877A91A00A1 for ; Tue, 6 Oct 2015 03:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRjMMkXmhkpg for ; Tue, 6 Oct 2015 03:27:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9843A1A00AC for ; Tue, 6 Oct 2015 03:27:17 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F49B509C0; Tue, 6 Oct 2015 06:27:15 -0400 (EDT) To: "Hakala, Juha E" , "urn@ietf.org" References: <56054AEF.7000800@seantek.com> From: Sean Leonard Message-ID: <5613A1E3.2070206@seantek.com> Date: Tue, 6 Oct 2015 03:26:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070201090909090200050302" Archived-At: Subject: Re: [urn] resolver profiles: a generative POWER-UP for r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 10:27:20 -0000 This is a cryptographically signed message in MIME format. --------------ms070201090909090200050302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/5/2015 3:53 AM, Hakala, Juha E wrote: > As regards the syntax of r-component, IMO it is useful to provide some = > generic services. [...] >> Resolver profiles are namespace-specific, [...] >> >> The profile functions as a contract on how specific resolvers should b= ehave, >> including how the resolver should interpret the query parameters >> (string) and translate the information into resources (or into URLs th= at can be >> dereferenced into resources). > I am afraid that making resolver profiles solely namespace-specific mig= ht create problems. But it is certain that different namespaces will supp= ort different services. [...] Let us look at where we are now: urn:ietf:rfc:3986?getspec:ct=3Dtext/html#section-2.1 | \ / \ | \ / \ / NID NSS ? profile : params # fragment <-p-component-><-- r-component --> <-f-component-> The "profile" here could easily be called the "service" or "operation". It is a design goal to make the "profile" as open to new registrants as p= ossible. We also know that the NID only constrains the rest of the p-comp= onent. There is some tension about whether the NID (namespace) should als= o constrain or define the universe of resolution services that apply, and= whether services can be limited to one namespace. As we have said, urn:i= etf probably needs different services than urn:isbn. The counterpoint is = that urn:ietf:rfc:XXXX may share many service needs in common with urn:is= o:std:iso:9999:-1:ed-1:en (both being identifiers for standards documents= ). In contrast, urn:ietf:params:oauth:redirect_uri (see ) shares very few= service needs in common with urn:ietf:rfc:3986. Here is an additional proposal to the structure of "profile": profile =3D ( service [ "@" r-authority ] ) / ( r-token service ) service =3D NID / utf-8-pct-encoded r-authority =3D host r-token =3D "*" / "!" / "?" A resolver profile can identify a service, optionally AT (@) a specific, = named resolver: the r-authority. The r-authority can be a host name on th= e network, or can be a keyword of some kind that identifies a "service sp= ace" (by analogy to how the NID identifies the namespace--perhaps a Servi= ce Identifier or SID). Therefore: urn:isbn:0385537670?pricing@amazon.com:au;used means to get the resource(s) for the ISBN 0385537670 using the service "p= ricing" as resolved by amazon.com. In proposing this syntax, I am vaguely= invoking RFC 2168, with a vague premise that the DNS is supposed to be i= nvolved with the resolution process. This syntax only permits host names,= not IP address literals. If people object to embedding DNS names directly in the urn URI, consider= : 1) The r-component is not the URN, it's the r-component of the urn URI, s= o it doesn't affect equivalence. 2) We are supposed to keep the URN (p-component) part stable, but the r-c= omponent does not need to be so--resolution is supposed to happen with so= me network interactions, so the topology of the network is expected to ch= ange over time. 3) When embedding such a urn: URI in a resource like HTML, the HTML itsel= f is pretty dynamic and expected to change over time. Instead of a DNS name, the r-authority could simply name a generic "servi= ce space" (SID). How that service space gets defined (registration? First= -Come, First-Served? etc.) is up to this WG. I have provided an alternate syntax to segregate different kinds of servi= ces with the r-token, which could take on various meanings. For example, = "universal" service keywords could be identified with service and X-speci= fic (namespace-specific, domain-specific, etc.) services could be identif= ied with *service, or vice-versa. If the r-authority is the namespace (sp= ecifically, if the r-authority name is the same as the NID, i.e., is defi= ned by the same organization that issues the URNs), then !service could b= e a shorthand for service@NID, sparing the repetition. For example: urn:ietf:rfc:3986?!getDependentInternet-Drafts could be syntactic sugar for: urn:ietf:rfc:3986?getDependentInternet-Drafts@ietf assuming that the "service space" "ietf" is well-defined. (Obviously, @ie= tf.org has a different proposed meaning, per above.) The nice thing about= SIDs that are also NIDs like "ietf", "oasis", and "iso" is that although= the organizations have specific locations on the network today (ietf.org= , oasis-open.org, iso.org), the URN r-component formulation is not depend= ent on the network name, which could change, or could be subsumed by succ= essor organizations. In the production above, the service name could be any Unicode name, thus= greatly expanding the space or names. Sean --------------ms070201090909090200050302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MDYxMDI2NDNaMC8GCSqGSIb3DQEJBDEiBCCoQsUyvVN7zio1CLqfUbKneQFzafDWFY2ATi2n F61usjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQC7Yv8KNfWdaoItC4/v WZNE43luP3mLoFmvHv0bsn73+TIyi/m+wQPGdHj1gKB3NkbzxP7WM1X6rcWHUR1Gc7ecPsDo b74LLoq1H3cGZzIXauVIyPsRldoxlHIUAQ5OiYyxcKUTxdcYIjekR8SSj4gUNR9+C8qTnQif YS8Jq1rRk1xe10tkRHxY6K5Nzpop4TIGMEYLFgHtvceRkOp6SYDdtUpbuy41upcCJF9Fmlam n1m9Uiajkh42eQShO86sUvBvxkeuR2qn/cmb1RjHK3l5t2uTzMBozOY3AxcSRn6080BQXlMx itYrg1O8LWyzMNoRtWjQonUqYeQbwQPV/YVHAAAAAAAA --------------ms070201090909090200050302-- From nobody Thu Oct 8 05:38:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95A1B3335 for ; Thu, 8 Oct 2015 05:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 NahUN2oIonWS for ; Thu, 8 Oct 2015 05:38:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D11B1A1BDF for ; Thu, 8 Oct 2015 05:38:28 -0700 (PDT) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 8 Oct 2015 12:38:08 +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.0293.007; Thu, 8 Oct 2015 12:38:08 +0000 From: "Hakala, Juha E" To: Sean Leonard Thread-Topic: [urn] q-components, r-components, and resource transmission: Section 3.3 Thread-Index: AQHQ9p2oxzFKKoS3ckqC9QF0XoDGQp5LrK2AgAAEQXCAALQqAIAVM3Zw Date: Thu, 8 Oct 2015 12:38:08 +0000 Message-ID: References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <5603FA95.5080609@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: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [145.100.47.16] x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 5:T18hsrJe2rmDsWqOnqMAsGg72kOEvnC+P+fulmhas6PT6DJCP+pxlknOXt5gdHAXhc+oaO9mueQDRp8uJjwSTTICEmUefhDLfG75Dk6ciHVmUdAuengyFK+1vMxQ7SEOutXDfapCUoqc2t4Q4iivBw==; 24:cTdX2OpvNprpNBGSovMoB0ynYnpUxJZkvABRJPFUmRtpp9g8fAG+dhVAJITBXZI0PRirMsZxq2K36OWXllUudXI0e72Xs93qlOItz0QN0VI=; 20:rGpiv6YFBVpEa/hlPqf3vsIN6Onqh+z1BClwvyMIsgVJlRuUaH0D6QjJq7QtNC8ySPoIdOEn/iZdhvLdhf3e3Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 0723A02764 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(199003)(189002)(15975445007)(5007970100001)(93886004)(97736004)(81156007)(92566002)(106116001)(5008740100001)(5004730100002)(106356001)(86362001)(74482002)(105586002)(19580395003)(40100003)(46102003)(5003600100002)(19580405001)(102836002)(122556002)(50986999)(66066001)(77096005)(87936001)(5001960100002)(10400500002)(101416001)(64706001)(15395725005)(110136002)(189998001)(74316001)(76576001)(16601075003)(2950100001)(2900100001)(5002640100001)(54356999)(33656002)(19625305001)(11100500001)(76176999)(19626425003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2015 12:38:08.4926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 Archived-At: Cc: "urn@ietf.org" , Keith Moore Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 08 Oct 2015 12:38:33 -0000 Hello,=20 Some comments below.=20 > -----Original Message----- > From: Sean Leonard [mailto:dev+ietf@seantek.com] > Sent: 25. syyskuuta 2015 2:29 > To: Hakala, Juha E > Cc: Keith Moore ; urn@ietf.org > Subject: Re: [urn] q-components, r-components, and resource transmission: > Section 3.3 >=20 >=20 > On Sep 24, 2015, at 6:55 AM, Hakala, Juha E wro= te: >=20 > > I do not know where this naming authority comes from, how users are > supposed to be able to see it, and why some URIs may not have any if all = URIs > are a priori supposed to identify something. >=20 > I believe that the term "authority" in RFC 3986 refers to: > authority =3D [ userinfo "@" ] host [ ":" port ] >=20 > I.e., some server on the network. This is my problem. I understand the syntax, but I can't approve what it im= plies. Let us assume that URLs http://example.com http://example.com/ http://example.com:/ http://example.com:80/ belong to some "authority" which is the current custodian of domain example= .com.=20 The whole naming system is standing on clay feet if naming authorities are = assigned like this. Creating a URL does not, IMO, mean that a resource in t= hat location has received a persistent name / identifier. And most people w= ho create URLs probably agree, and do not even try tom keep them alive. =20 Domain names do change hands, and organization may decide to change its dom= ain name or acquire many domains. If domains are volatile, what is the pers= istence of naming system & authority built on top of them? =20 > In a broader sense, it can be any abstract or concrete naming authority, > including a reserved keyword such as "left-usb-hub". See Section 3.2 of R= FC > 3986. Representing some of the real naming authorities whose naming privileges ar= e based on e.g. ISO standards, I find it strange that "left-usb-hub" has, a= ccording to RFC 3986, naming privileges in the same way as for instance the= ISBN International Centre. I do understand that naming of web resources is= different from naming books, but IMO RFC 3986 has taken things too far. Ke= eping names (URNs) and locations (URLs) would have been OK, but merging the= se functions in URIs creates confusion (how do you know if URL was intended= to name something by the authority, whatever organization it is / was) and= will continue to do so. =20 Best regards, Juha > When there is no naming authority, the URI scheme itself serves as the > authority. For example, the data URI (RFC 3987) does not depend on the > network at all; the entirety of the data is crammed into the URI. >=20 > Sean From nobody Mon Oct 26 18:45:34 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBC91B32B2 for ; Mon, 26 Oct 2015 18:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_44=0.6, 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 pexgWxLeBFcS for ; Mon, 26 Oct 2015 18:45:32 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 9B3051B32AC for ; Mon, 26 Oct 2015 18:45:32 -0700 (PDT) Received: by obbza9 with SMTP id za9so41058049obb.1 for ; Mon, 26 Oct 2015 18:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=CicDlMcMZJuugxE3eJdd17jy6IQ0O+T5ewyqAms8BBI=; b=ORjKNpSprTOkCRgqJiUoA3/bcSUf5X/YQoh1p3xNTECeJTpQYQIYgBInAiZBD3hSQB eZ5U00TNfKCjatPQzraRgUM/CXZzReV4GMxKlT7rIU/g7CY1fT4XPLW+OsWi4bbIyJIr WwdyIklzwTOQTh8VZKvcCO5LLZ0JTtUB7zjeLSzNZpc/jbqpntGGMQIdwmhjJQhawC6S +o06OQIrX1UGpET0dKjZKTKmIQ4Kfc7LNy4baNohgWP8o0Y4kgCaVtZC2PriR4d+Lyu8 4JBxVwlNX0iDTTtkJFq3xhA0UF0G4YsRvC2tDieka+I9bYjANJmlhXYEG20qmIv/ez0g 0G+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=CicDlMcMZJuugxE3eJdd17jy6IQ0O+T5ewyqAms8BBI=; b=QLNHqHzTYrG5BzeWC6gucSwJ1AdIou+IYry+2HueBOQ/PeJPR4kM068wqSPSemkcg7 TqHFgvZsOdXTdMZqxUHSnBDdH9a/vAPWu8ZEABw12XNn1s2Rqs+3hdeCvw+tHBu2kP1G Eh5douYY7+K2WetAIZNoXDEb2YKtCNb+wTQ4IZI1WRPyrMRIdwYTr2zIssCTb82iuHto JsiFkPKpGRIBLS+hjlubR+/AD2KJl24exbXuq3o7Cc2my4Gw4fVVd5o358jb37Avspow Aqq5KPRcO9WXRXh7n2/I0sIb0SdTYI6KepdSjYMR7oZDk0pp7w/cbxnk0hORLzmRbRKq OFLA== X-Gm-Message-State: ALoCoQndokPveq87A7NUXGxndsrqxiTVUg/kp73UYlIGpUG9du9akQYtpYoE/G71EvyeGSru9MCK X-Received: by 10.60.155.145 with SMTP id vw17mr4659349oeb.73.1445910331972; Mon, 26 Oct 2015 18:45:31 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id wr6sm16314271obb.21.2015.10.26.18.45.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 18:45:30 -0700 (PDT) To: John C Klensin , urn@ietf.org References: <55F8352B.4090305@andyet.net> <343D92700F25A9E6609B5F39@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: <562ED738.2080503@andyet.net> Date: Mon, 26 Oct 2015 19:45:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <343D92700F25A9E6609B5F39@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] ABNF 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, 27 Oct 2015 01:45:33 -0000 On 9/15/15 9:44 AM, John C Klensin wrote: > > > --On Tuesday, September 15, 2015 09:11 -0600 Peter Saint-Andre - > &yet wrote: > >> As mentioned last night, I have been experimenting with the >> ABNF so that we can capture the fact that we don't want "??" >> in a q-component, only at the start of an r-component. >> >> Unfortunately my experiments were not complete when I >> submitted -13, so let's try to get this right in -14. >> >> I see two primary approaches: >> >> 1. Approximate things in the ABNF (as they were in -12) and >> supplement the ABNF with some additional text (e.g., "a >> q-component MUST NOT contain any sequences of two question >> mark characters, since that sequence is to be used only at the >> beginning of an r-component"). >> >> 2. Try to capture things in the ABNF. Here is where I ended up >> after publishing -13 last night (the only difference from -13 >> is that I changed the terms 'word' and 'phrase' to the less >> suggestive terms 'ustring' and 'uset'): >> >> namestring = assigned-name >> [ "?" q-component ] >> [ "??" r-component ] >> [ "#" f-component ] >> assigned-name = "urn" ":" NID ":" NSS >> NID = (alphanum) 0*30(ldh) (alphanum) >> ldh = alphanum / "-" >> NSS = ustring >> q-component = ustring *uset >> r-component = ustring *uset >> ustring = pchar *(pchar / "/") >> uset = "?" ustring >> f-component = fragment >> >> I am not an ABNF expert, so suggestions are welcome (including >> the suggestion that #2 is impossible and I should give up). > > Peter, > > I don't think it is impossible. I continue to prefer something > resembling your first approach. #2 illustrates why: It is > really hard to look at that and efficiently deduce that the > intent is to ban "??" except as the introducer for an > r-component. It is more likely to induce an "eyes glaze over" > effect. Because of that, if you were to use #2 (or a variation > that works if #2 does not), I'd ask that we include a comment > about that intent. For better or worse, that comment is more or > less equivalent to what you'd need for #1, so, especially > because I believe no one would study the ABNF if the comment > were there the main advantage of #2 over #1 would be to prove > that you/we could do it. Not a sufficient reason, IMHO. I suggest that we go back to the ABNF that we had in -12. > Trying to sort out the syntax does nave one good feature in > terms of forcing clarity of discussion. It is not clear to me > that we have discussed and decided whether > abcd?efgh > abcd??efgh > abcd?efgh?? > abcdefgh? > > are valid r-components or not. While I can't imagine anyone > really caring about these sorts of cases in practice, pushing > everything into ABNF forces us to decide, while a prose > statement (as in #1) would allow us to say something like > "question marks, especially consecutive ones, inside the > r-component string or a question mark at the end of either an > r-comonents or q-component, are bad ideas and likely to confuse > people and computers alike, but not prohibited." Some text along those lines seems helpful. Peter From nobody Mon Oct 26 18:58:14 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992ED1B32EC for ; Mon, 26 Oct 2015 18:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qHemoP6u_zQL for ; Mon, 26 Oct 2015 18:58:12 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 22C7C1B32EA for ; Mon, 26 Oct 2015 18:58:12 -0700 (PDT) Received: by oies66 with SMTP id s66so111752740oie.1 for ; Mon, 26 Oct 2015 18:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=9itM4HgvvjXaoWOR3tandccobcfnqYKb86UO5YAWFDU=; b=0J7WFmP/i35ZveP6S+uDLghzB7u1ViKqa2XP/J0zXj0G6Gh2ecRM8btQk/DAsR2T3t hWNbwu8lEwQNiCBgaszMF59QCPa8F9R39O4hrwKYA0K6vDTNDCGn+7U9kiWD89fGiP1b V6gGIswi9Oz+WrxOTwmLlT7QUab11O+qfQiKoxVxvev6+WL/trzqQx4tTIFo36OZlcqT 62bu0whg4CfoWgvMM2CW9juOgnAYvMDil+tU9NqBOcwH8iHl6eFDnrE8GdhM41FB7BUu ied+p4bS37CtSTeVqTleWtIYx1C08/Kjztgxr+fKm3oswbV264l0OnMg7hJoDY1lN0r3 lsYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9itM4HgvvjXaoWOR3tandccobcfnqYKb86UO5YAWFDU=; b=HphtP2ORftx/gd8AtEmrpoxk3gbTFGCPmh0pZsDjj54bZNPRSps6spfGQdux6vEW18 lzEyVkAom2w+RG3sYcQy869qUZd9WTrpPcTrULifFVqrOCEVJxCkG4Hl1zmlkkvj9P09 FqVz/p+/Mu8KVGeK4VqKdu3sxX1iVCziZqZxiCXb99FgbG3ItUDXOvtRBJ8/eq11WrSd B3Gl1J2TrxgNZFTSVkTzUlfclEokgbHhX36Eo0ixmy4ZlO7KMkPfLnDRrkEhAarCczdb DfZfnIk1rcqX9w1sjJ8qrqw9skpYI2xOU4fjQmpA6NEtcP8QbQEVk4EGSJEM8dC/MK0q RMiw== X-Gm-Message-State: ALoCoQk6x1hpQ3sQXsvUbJjCl0feu95IMt11Ir9oj1avdOwuqKH6iKOfytJ+6+kpNLmgnbZVAYC6 X-Received: by 10.202.46.207 with SMTP id u198mr23641565oiu.66.1445911091405; Mon, 26 Oct 2015 18:58:11 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id s5sm16360462oie.12.2015.10.26.18.58.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 18:58:10 -0700 (PDT) To: Sean Leonard , "urn@ietf.org" References: <56033432.3040506@seantek.com> From: Peter Saint-Andre Message-ID: <562EDA31.9080203@andyet.net> Date: Mon, 26 Oct 2015 19:58:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56033432.3040506@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Think about r-components and q-components differently 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, 27 Oct 2015 01:58:13 -0000 On 9/23/15 5:22 PM, Sean Leonard wrote: > URNies: > > The introduction of r-components and separating out directives to the > resolver, from directives to the resource*, is a welcome development. > > For my part I want to put a big +1 to putting the r-component before the > q-component. I.e.: > > urn:isbn:0385537670??service=showscanned?dpi=600#chapter2 I have gone back and forth on this. Conceptually I agree with you that it seems cleaner to have the r-component first. I think we need to have the chairs tell us how they want to proceed here (see also John Klensin's message from August 13, 2015). Peter From nobody Mon Oct 26 19:07: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 459A01B3309 for ; Mon, 26 Oct 2015 19:07: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 55YfXb5E21oL for ; Mon, 26 Oct 2015 19:07:13 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 1B9981B3308 for ; Mon, 26 Oct 2015 19:07:13 -0700 (PDT) Received: by pabla5 with SMTP id la5so12571398pab.0 for ; Mon, 26 Oct 2015 19:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=rzxJYc29SOulYn2hg3fr3C4QXz5F30TYp93nGr1/qHo=; b=JRJxJRrO/Wui00vaw55EeJ7eHdD5ts/sCuOfj3+5rscEV/QGG+UxKdyHgAHsG8MdA8 T1T72BsVBtttFQaExHB2CeaqAnpmboz/v2RNwYyDknfCKvYk+AHYvWvrze0X7QblBNDX szja4+Af76xCy6jJ8DMFXUYhLH60XodrbwXAzD1SIhKGIz4vbhCoEJ4SmSPVN1rrpd9H Ez4rvMMcp++4x1LNbpzhcOa7rHHLTTUNJasyNTnioIx6671cssloJaA420/8bwWvWxQD GQF8Vc9L/ep6wfQUzgIv/ET8mDEVkOG8tAIT0ogzgWEMotOQpXDTXRHHz6DDKQuRh0vy G4bA== X-Received: by 10.66.235.39 with SMTP id uj7mr25048536pac.34.1445911632790; Mon, 26 Oct 2015 19:07:12 -0700 (PDT) Received: from ?IPv6:2400:4040::23:380d:d0ce:5c3e:e788? ([2400:4040:0:23:380d:d0ce:5c3e:e788]) by smtp.gmail.com with ESMTPSA id yq2sm36270357pbb.39.2015.10.26.19.07.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 19:07:12 -0700 (PDT) To: Peter Saint-Andre , Sean Leonard , "urn@ietf.org" References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> From: Melinda Shore Message-ID: <562EDC4D.3010400@gmail.com> Date: Mon, 26 Oct 2015 18:07:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562EDA31.9080203@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Think about r-components and q-components differently 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, 27 Oct 2015 02:07:14 -0000 On 10/26/15 5:58 PM, Peter Saint-Andre wrote: > I think we need to have the chairs tell us how they want to proceed here > (see also John Klensin's message from August 13, 2015). I am generally extremely loathe to have chairs resolving technical questions in the absence of an emergency. That said, I think we have an emergency. I think we need to hear from John if he'd block going ahead with r-then-q. Melinda From nobody Mon Oct 26 19:10:35 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEE11B3310 for ; Mon, 26 Oct 2015 19:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fMLS4EgzM9eY for ; Mon, 26 Oct 2015 19:10:32 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 741841B330C for ; Mon, 26 Oct 2015 19:10:32 -0700 (PDT) Received: by oies66 with SMTP id s66so111880643oie.1 for ; Mon, 26 Oct 2015 19:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=nJousLcchdQIvEG91NOgiKeaizIK7Rn4jqfcnY353uI=; b=dWlxAzbGxvNMc/q3XDgo4H6qsWErY/eGWDBkAK20wD6VITcCJQ+Mtm6tlSaXDukpCu gubeDKTKcMY6A/QmouxjlgmbEzo6lhDacdIayJlUp50OgQ8UO5JTjh7KU9YAdDg4U7R6 HlOGF1JyskRWvQBkDuSbCsAKUmdZv8x/Va2L63msZt/KDKSJeiKYsst1R6si0aYsK1XQ KF2G+NfZ4YBXLzsx9pfoVWPNNQI/gbJUsx+YlqZZZO8kCaIP0x5j4xsfmnFdNSOue+ZE 3neiiDUAqylbjRES8h+bp2z/UD6WJAZ3HupyMQzfgHivyio47BmyCSdiWTq47BcCghiv YtfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nJousLcchdQIvEG91NOgiKeaizIK7Rn4jqfcnY353uI=; b=hF5F/ifjjiIt1YLOcgZfoTAYR/B0OAd4BM99pzZmX38/sMNDH9RZpF3yxZoNHEkcZl 8mE3HYpUmBwwg0DzXo9n1X2+klrleEVDSP1a6GgVJcfHw0J6Ytxq+i4VqK7HgbrFMA7K pxqhaT7kn2degPmCW2eMeSIjuM+MbCxUpHpx7s7grR8l/4IM+zSqJfzSql8j7HkjCpnI of+rU+Lg5KUnBcD5YqOL05DKCaTNxd1A1g8LSFsp4P89b/zuZGbADCloy2468DQ6fijs 83CiBujE2xd2mM8v3KSArL8m/Hxkt4SWBS4p/67hR8qnKlp0RS6fU6MJ8Pl7C5INAe8x 7Mgw== X-Gm-Message-State: ALoCoQnhj4ps9y3lnMFrZi+8HIDvQIPyRLOFyKO4n40MlhocFmQFV8+W98WLg94easQ5wqxPh2kN X-Received: by 10.202.86.214 with SMTP id k205mr25820301oib.115.1445911831850; Mon, 26 Oct 2015 19:10:31 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id p130sm10985261oia.20.2015.10.26.19.10.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 19:10:30 -0700 (PDT) To: Melinda Shore , Sean Leonard , "urn@ietf.org" References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> From: Peter Saint-Andre Message-ID: <562EDD15.50108@andyet.net> Date: Mon, 26 Oct 2015 20:10:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <562EDC4D.3010400@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Think about r-components and q-components differently 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, 27 Oct 2015 02:10:33 -0000 On 10/26/15 8:07 PM, Melinda Shore wrote: > On 10/26/15 5:58 PM, Peter Saint-Andre wrote: >> I think we need to have the chairs tell us how they want to proceed here >> (see also John Klensin's message from August 13, 2015). > > I am generally extremely loathe to have chairs resolving > technical questions in the absence of an emergency. That > said, I think we have an emergency. I think we need to hear > from John if he'd block going ahead with r-then-q. Sorry, I was not clear: it strikes me that we might need a consensus call. Peter From nobody Mon Oct 26 19:29: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 C60EF1B334D for ; Mon, 26 Oct 2015 19:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 dw0qbrpTQz77 for ; Mon, 26 Oct 2015 19:29:27 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 786A91B334C for ; Mon, 26 Oct 2015 19:29:27 -0700 (PDT) Received: by obbwb3 with SMTP id wb3so160016320obb.0 for ; Mon, 26 Oct 2015 19:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Vjy3gNbik565YgzkfUMalTNeekP0QXoadOmaenvgRBk=; b=aqkFdC3PEQXTSYux3SllSr6EmFCLPgve1K//rip511fI3uGoXIsVJG06rWlWVfetqT CEZCRz2v8ABwiks3Jy3y1gZAYzBKFPznoQccFA2OH5R2oNVLV2+G15fzZnUy3dPgmU/N CR7/Uy3Jx5DcrjXlAWx4blVL++EQOM27fqdo0N6gXZDV4S6urzuKzHEesgTb6PmZcPqu iRdOD/CUpb7D0dC3jbduh/98Sn94NotJIdVvmweitxCAqLI82gc0tqkum+K5tM7y/ocz LYb/HqCzhrJ2FneSFi4sVK2Rgid7MC3MfM93vvowiojbNZNXHok/dfyWEIXs0ijZn5Uc i9MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Vjy3gNbik565YgzkfUMalTNeekP0QXoadOmaenvgRBk=; b=RnR5bweIHUHGd1UW1RtP+Kyf289rUDTq/TrHdNx1v9igOShZUDtZpnbwSUxjFxrFhF VAAcSV5axmokT81Xb8CB02MQfu3LXsYb6CPIYk+W7aojleN4A6hrYs7SYoBG0F6My+rf s9CqUNHBhLPD1jM6hEbJJh7mc0dMCaJgB7Nzva9MyFgf+2BcC/PzF6CC3vIjMmz7oGCz fCmvTiqR+pbyYSTWMC94EXVUNMMA8+06xPHOLWyHCzdqpdaEwtYnz9nGIGO+OCmP6V30 o/YAnQse3ISJun2COONKyGou7WM9SRSSicVokVwv99xqUTWEKnkx9Gkkc6qcYlTfHzyT Bbig== X-Gm-Message-State: ALoCoQmxUACj05TygC4K0i+3XKyY5zPbeGUlvs4oWwA7Q9+W3OQpMbk9UkXTgg9SEm62Lc8UcXd+ X-Received: by 10.182.121.163 with SMTP id ll3mr26506819obb.27.1445912966764; Mon, 26 Oct 2015 19:29:26 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id e3sm16398550obv.12.2015.10.26.19.29.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Oct 2015 19:29:25 -0700 (PDT) To: Sean Leonard , "Hakala, Juha E" , "urn@ietf.org" References: <56054AEF.7000800@seantek.com> <561393DB.6090001@seantek.com> From: Peter Saint-Andre Message-ID: <562EE183.50703@andyet.net> Date: Mon, 26 Oct 2015 20:29:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561393DB.6090001@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] resolver profiles: a generative POWER-UP for r-component 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, 27 Oct 2015 02:29:28 -0000 On 10/6/15 3:26 AM, Sean Leonard wrote: > Hello, > > Thank you for this response. I think we are making progress. > > On 10/5/2015 3:53 AM, Hakala, Juha E wrote: >> Hello, >> >> some comments below. >> >>> -----Original Message----- >>> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard >>> Sent: 25. syyskuuta 2015 15:24 >>> To: urn@ietf.org >>> Subject: [urn] resolver profiles: a generative POWER-UP for r-component >>> >>> URNies: >>> >>> What URNs really need is a way to ensure that the resolution process >>> delivers more consistent and predictable results. >> All PIDs must be made "smarter". If resolution only links identifier >> (name) to 1-n locations, it is possible to argue that this is an extra >> step that can / should be avoided. But if resolution can facilitate >> persistent access to all kinds of information about the identified >> resource, it is hard to achieve similar results with e.g. HTTP (which >> is itself not persistent). >> >> It has not been easy to improve URN syntax so that smart resolution is >> possible. One problem is URI syntax, which has left us with a limited >> tool set (? for query and # for fragment). Using ?? for r-component is >> in these circumstances the best thing we can do. Alas, other PID >> systems may not be able to do even this. > > The invention of the r-component is (in my view) a major step forward. > Making the r-component mean something, i.e., enabling and channeling the > resolution process, is the next step forward. The major questions are: where and by whom will the next step be taken? In my opinion: 1. Where is not draft-ietf-urnbis-rfc2141bis-urn but it might be a document that updates or obsoletes RFC 2483. 2. By whom might be this working group but I think that energy to do this work might lie elsewhere (among those who are more actively implementing and deploying URN resolution services). Peter From nobody Mon Oct 26 19:42:52 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB711B3387 for ; Mon, 26 Oct 2015 19:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ROknMb8uIZaS for ; Mon, 26 Oct 2015 19:42:49 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 61BBD1B3386 for ; Mon, 26 Oct 2015 19:42:49 -0700 (PDT) Received: by oifu63 with SMTP id u63so69810329oif.2 for ; Mon, 26 Oct 2015 19:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=g8vXnavFLux2g1yNG39G+AyF3IPR2aOyWN5W0j4+Fx8=; b=Rx0nUFXJ9F4lByoRr7RiH8mU/WdzFDCBfURfr2OYjCUWU+3U6zmyqSnLKS3CEPCM/8 0dAiH8poWixWHUpOnxKf+MM8x1OtEWCjlRf6ajzfJNzL2+SkEICzuWO57dWVywY1UU+K DcOk8fKTEEZP/ooRzbcWNDE3xVSnUps2CudrfqWCTUeV9/m92L4Cw2ub3EKDsSMy7p2d QW6zTDK5LIyG9K/785LdhAwwLa/6NAFqBL3rIN/Uljn2D3MDIgEDpy0J9S4zMVkPKMWt FHIGaN4yDHPzM4XveskKPtnZs4Mzm3H05e9mT2Ppqrt305B2d8JXv5qWpGkqCWnro0cQ c/OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=g8vXnavFLux2g1yNG39G+AyF3IPR2aOyWN5W0j4+Fx8=; b=lvhLNFYq0POcLUqo5oJcPCSsz3H1DiR7PW0TLNkdkFDuLUNZoMVhZ2M1oQaKE6wEmk ZEM9NBbKviwnkBoqA9enAngBbbDsoWLXuKPXeZumkpankrTBxNKVHRFctUzPguNvwz6n g373qjLrAK6RQQlMl1hiu5B6sx9hUslglmiQ0t3UF2pWsbiT+IYCMtx8amMt+XBL/hyg h3IU7u/OZKVOQIN5owfSzgmBkNR9T62AsJ5tLGHbenqQK9BlxHEruYn6MgnkJgu/BmOT uaQuF2hSlxv5HG0ICNhnFfOr/KwE4Sh6ebEnev3illiCrP5jpmwZX/BfX4/qYpkSZnwt HF4Q== X-Gm-Message-State: ALoCoQkRBC9l2a3/7xZIl5279DZJXpkaCtTyYjhH1ZAHtAeLQCB4c6kl1MkOF3K1cgmH5HnYlCAB X-Received: by 10.202.52.5 with SMTP id b5mr9545898oia.120.1445913768678; Mon, 26 Oct 2015 19:42:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id s1sm11386928oem.14.2015.10.26.19.42.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 19:42:47 -0700 (PDT) To: Keith Moore , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> From: Peter Saint-Andre Message-ID: <562EE4A5.90204@andyet.net> Date: Mon, 26 Oct 2015 20:42:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56049DF0.6090508@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 02:42:50 -0000 On 9/24/15 7:05 PM, Keith Moore wrote: > On 09/24/2015 08:56 PM, Keith Moore wrote: >> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>> I believe we are in agreement that q-components are part of >>> resource identification. >> This is simply not the case. > > In the case of a URL query or a URN q-component, I think the confusion > results because there are actually two resources: > > 1) The resource that produces the response. > 2) If there are no errors resulting from the request to the resource, > the response is also a resource, separate from resource #1. > > The base URL or the assigned portion of the URN names resource #1. But > it's debatable whether either the entire URL nor the entire URN is a > "name" for resource #2, because resource #1 is really not constrained to > produce consistent output even when presented with the same > query/q-component. (Such a resource might however be expected to > generate correct HTTP response headers to defeat caching.) > > At least for URNs I don't think we want to treat the entire URN + > components as a "name" for resource #2, because even if it is properly > termed a "name" it doesn't have the persistence properties of URNs and > calling it a name seems likely to create confusion. Keith, you have stated before on this list that a URN is primarily or effectively resolved into one or more URLs. How does that model map into your resource #1 and resource #2? Concrete examples would be especially appreciated. :-) Peter From nobody Mon Oct 26 19:51: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 07EB11B339B for ; Mon, 26 Oct 2015 19:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbvqO382CHdl for ; Mon, 26 Oct 2015 19:51:43 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 D46DE1B3396 for ; Mon, 26 Oct 2015 19:51:42 -0700 (PDT) Received: by oifu63 with SMTP id u63so69895927oif.2 for ; Mon, 26 Oct 2015 19:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=VDx1oaPKwUCRbXy82CEdJtMYB07nzoSMnNxULX3OqIc=; b=DLS8vNbmk+Sh07YWFa5O4Vxliyni29dONedjEbn4OvHE5ZEDJAlurDKg9fDdCRRWUv 9V6CSahKioEaBfxUFa1SNmW4H95sisBtwqvJhTdEjWs5eUUlRe/yXBBdUhucFbqzu0eA PfqSUIHl02Mydm9LmG4s1Hdy/QEUTNEFZ5HDaotf7GEpMu9D7/C4vcVOy4sOFBui5iKg Oky403OBYVX7r7UjyOZ0r698s6Vlv9xZ41W0QrtXuTQYoiyzzakZUIluiQbfxN0aHrka 9d5jwPr04ysBZe8N51aWaWVyoGIAtBj2rmdb2mMM07LNsFaXzRuHys6D8ON7aZr76zsd Fl7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=VDx1oaPKwUCRbXy82CEdJtMYB07nzoSMnNxULX3OqIc=; b=ILIv33GE2NiKMoZPE+FbcWe39bxU/DI0wOrohRLGXXqM/PTM1bxYgiWbRTXVYpyidL qvJFzUeHm8C/FdhEL5BAh68BezPTiErCKFnoPWoUFGOcTTUh+Q8e9okDRr7uuN4YTHOr LCNMFTPtmgXbq1bUhfzloTB1bCRyIpZeuJlGT3nfHIAD2B0G0mknJuW87YIfN6HTT6g/ f+kHDUw+kxtdBWZiHkdaADqgGEbsuR5aixrszjXUHwRAPmUFO8EaNnbKmdQGJPJm4h0S N1YkJSQQqudEpPaWEopvgWMpSlfpDJE4+S21dT4xLZjJNrOHBXzo2ZvxyNQTOXKg+/+F jCtw== X-Gm-Message-State: ALoCoQnW8t/zUVMvlIOO30Ms2Q1WGtPX/UpBgMOEOcIgWG0QPVHG23uTg+XfJDIIYM6Y3kBNzNXj X-Received: by 10.202.71.9 with SMTP id u9mr20301497oia.118.1445914302114; Mon, 26 Oct 2015 19:51:42 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id w204sm16493674oie.13.2015.10.26.19.51.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Oct 2015 19:51:40 -0700 (PDT) To: John C Klensin , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , urn@ietf.org References: <65C29163B6F527DF836969A9@JcK-HP8200.jck.com> <55F7BC49.6090505@it.aoyama.ac.jp> <1ECD3A3077BAB0F3916E3D0A@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: <562EE6BA.7000502@andyet.net> Date: Mon, 26 Oct 2015 20:51:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1ECD3A3077BAB0F3916E3D0A@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Approval process for new URNs based on non-IETF standards 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, 27 Oct 2015 02:51:45 -0000 On 9/15/15 8:04 AM, John C Klensin wrote: > Hi. > > I'm responding to Martin's note as a convenience, but some > things below address Peter's comment and a brief offlist > conversation. > > --On Tuesday, September 15, 2015 15:35 +0900 "Martin J. Dürst" > wrote: > >> ... >>> 2. A specification is required that reflects of points >>> to the needed external standards or specifications. >>> Publication in the RFC Series or through an IETF process >>> (e.g., posting as an Internet Draft) is not expected and >>> would be appropriate only under very unusual >>> circumstances. >> >> Why not simply say "is not necessary". > > This is mostly a textual matter and I don't feel strongly about > it one way or the other. FWIW, what I was thinking when I wrote > the above was that, in general, when we are dealing with other > bodies that have their own approval and publication procedures, > we let them finish whatever they are doing and publish and we > then either reference their publication or work our permission > to republish in the RFC Series. The disadvantage of having an > I-D posted and considered in the IETF is that the risks of > inconsistent specifications resulting from two groups tuning > things in different directions and creating inconsistencies are > significant (especially if the IETF community starts making > modifications it may not understand to documents it doesn't > understand, which was exactly the case that the Media Types > mechanism and this proposal were intended to bypass). > > But, while that was my reasoning and the answer to "why not", I > again don't feel strongly about this so, if others prefer "not > necessary", go for it (although a sentence about understanding > the consequences or being clear about change control would seem > useful). > >>> 3. The reviews on the discussion list and by the >>> designated experts are, however, strictly advisory, with >>> the decisions about what advice to accept and the length >>> of time to allocate to the process strictly under the >>> control of the external body. >> >> I agree that this should be the case for the content aspect of >> the request (what stuff is given URNs,...), but I think we >> should make extremely clear that the overall syntactic >> restrictions that the spec makes are not up for negotiation or >> reinterpretation. > > While I agree, my usual concerns about the protocol police and > the advantages of having even bad stuff registered and known > kick in. So the WG has a choice that applies to both this fact > track case and the normal one: Assume some organization decides > that it is going to use something that looks like a URN (e.g., > something that looks like a URI starts with "urn:") but that > violates "overall syntactic restrictions", design assumptions, > or something else fundamental. If we cannot convince them to > not do that, is the Internet better off with a registration that > can identify the non-conforming use or not registering it at all > but hoping that no one will use or notice it (or that our > condemnation through silence will prevent its use). > > At the moment, my instinct says that we are better off with the > documentation, even if it means creating an extra section of the > registry or a registration category for non-conforming names and > namespaces just to reduce the odds or name conflicts and > identify the uses. I think the Internet is better off that way > than if we try to pretend the usage doesn't exist. > > None of that suggests that we should be willing to negotiate or > reinterpret. The question is only about what we do if, e.g., > someone has a namespace and syntax that uses "#" as an > introducer that has absolutely nothing to do with the 3986 > requirements for fragments. > > Noting that exactly the same question applies to non-conforming > URI schemes as to non-conforming URN namespaces, I don't feel > strongly about this or feel a need to spend a lot of time on it > because I think that the number of cases in which someone will > come forward and say "I have this namespace and URN syntax for > it that violates a bunch of your rules but want to register it > with you anyway" will be very few, maybe few enough to be safely > ignored. However, if we are going to make strong statements > about what people cannot do, I think we need to understand and > should consider the issue. > > > > --On Sunday, September 13, 2015 16:15 -0600 Peter Saint-Andre - > &yet wrote: > >>> (3) Add a new Section 7.3, titled "Registration Policy and >>> Process: Fast Track for Recognized Standards Development >>> Organizations and Scientific Societies" that reads: >> >> I have two concerns about "scientific societies": >> >> 1. The IETF has experience in judging when another >> organization is an SDO, but not in judging when it is a >> scientific society. > > I'm not in a good position to debate "experience", but note that > "scientific societies" were explicitly recognized a decade ago > in RFC 4288. FWIW, while we have never formalized a > relationship or, AFAIK, even seriously discussed doing so, but, > for those who don't know, there is a body known as the > International Council of Scientific Unions (ICSU) whose > membership (and the membership of its their subsidiaries and > ICSU formal affiliates) comes fairly close to an authoritative > list. In that sense, "scientific societies" may actually be > easier to make objective judgments about than SDOs where, for > example, the boundaries between "trade association", "industry > consortium", and "SDO" may get very subjective and difficult to > evaluate fairly. But see below. > >> 2. It seems to me that the realm of organizations that might >> deserve to be on the fast track is not limited to scientific >> ones. What about organizations whose purpose is cultural >> (e.g., the British Museum), scholarly (e.g., the London >> Philological Society), educational (e.g., TERENA - see RFC >> 6338), governmental (e.g., the United Nations), military >> (e.g., NATO), charitable (e.g., Creative Commons), >> professional (various industry consortia), and so on? > > What we did in RFC 4288 and the later 6838 was to leave > "recognized" completely in the hands of the IESG without even > trying to spell out criteria. In a way, that turns the > criterion into "are you, IESG, willing to trust this body > sufficiently to give up some authority to it". In the media > types case, I don't believe that there has ever been controversy > about the decisions the IESG has made. Neither the IESG nor the > community have felt the need for a formal application procedure > for someone to be recognized as a standards body (or whatever). > I take those as good signs and suggest that it would be wiser to > say, perhaps, "recognized SDOs, scientific societies, and > similar bodies" and then drop the subject in 2141bis, leaving it > to the IESG to figure out what to "recognize" and what > constitutes "similar". That sounds quite reasonable to me! Peter From nobody Mon Oct 26 20:19:04 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 E13B21B33F1 for ; Mon, 26 Oct 2015 20:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 ELpRJEp9TiXf for ; Mon, 26 Oct 2015 20:19:02 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 2BCC71B33D8 for ; Mon, 26 Oct 2015 20:12:58 -0700 (PDT) Received: by obbza9 with SMTP id za9so42311237obb.1 for ; Mon, 26 Oct 2015 20:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=KQtE4rIvqq45BORV++5lj6rqnQ3CwqKETFgAqGf3XJg=; b=N2/T4N2lnZaaTjOGV1Icv8Nv7ZOY9HfXvKYvfAHznDkGifGoefmzoTJXIFwrxMHEYx O4sVlVxbWfdvLaL3Mq8izax1isqqFvg+9X4XVnxNBTZR7K52q4hrt197poXCP8Zfku7T cUeCglhxm7RPv1w6oXVyLutev9ULZ/kUU5v5DrsQ2nHQo0Px1b+6pNY4+IOOYLVs64D/ NBKC7KEx2JD0nyQhri5lvCcMotAuTNLj3OICdyf6F2rRZ1rKNFS/ODChhBXBAyiuW0la 4YXgYDMb+OLWFU7CTn5HAAdCYQ5sS9lRA/ka30hFMUWWuKWdpQvIXUZr1SCIETf0mE2g aFdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=KQtE4rIvqq45BORV++5lj6rqnQ3CwqKETFgAqGf3XJg=; b=NoMf2Sq4ey1oYPuEVYXZwjqGprbF0gKXrxuyoxVJeCAwC0U8NGxPkbIA6KsMaixhOl qp+zPSlpERSRizYsH86UwwUvjo36AW3mhKZ1lRIb+9PKLp4w6YjvdpDPTw4sZS4A7pfl GTNX5KKE8U3Ai3PbFTO9HT/4FsUvJetahzo0vRxk4pG93vaE8aQ+4KPh8v+6fqpSLEde QIPNVKd0Z/AkhAy4wJkHdiTeRmPIXc8c/d08xMamLd9aEgDxjmjfL0+OeXBfd51FIpq4 JZmAUS/OLvjThoY6Gg2LriwuWDThEYme/t2uGfIsa86bK8VAJ7ue32J7mI+2xovTdQRi bHsg== X-Gm-Message-State: ALoCoQl7NvAwhWOjelehdoNiqICSr8qxerDZRrunpiAyNR5EItzbuVg57xcJfBm7BqF9jNgCTDZa X-Received: by 10.60.51.163 with SMTP id l3mr16515344oeo.10.1445915577422; Mon, 26 Oct 2015 20:12:57 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id v76sm16489265oie.18.2015.10.26.20.12.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 20:12:56 -0700 (PDT) To: "urn@ietf.org" From: Peter Saint-Andre Message-ID: <562EEBB6.8050201@andyet.net> Date: Mon, 26 Oct 2015 21:12:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] next steps 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, 27 Oct 2015 03:19:03 -0000 In my capacity as co-editor of draft-ietf-urnbis-rfc2141bis-urn, I have reviewed the list discussion since publication of version -13. I think we have have one major open issue: the relative order of q-components and r-components. And I have asked the chairs if they can issue a call for consensus in an effort to close that issue. Aside from that, I think we have agreement on the concepts we wish to convey and their representation in the text of the document. Therefore, I can submit -14 on November 1 (when the I-D submission window opens again). If we have not closed the major open issue by then, we can submit -15 once that issue is closed. Peter From nobody Mon Oct 26 20:30: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 144DC1B3415 for ; Mon, 26 Oct 2015 20:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ne00BeyeXf18 for ; Mon, 26 Oct 2015 20:30:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6AF01B3414 for ; Mon, 26 Oct 2015 20:30:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ED66320836 for ; Mon, 26 Oct 2015 23:30:36 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 26 Oct 2015 23:30:36 -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=GZZ4xYDaPDP4FoA6W8827ZVCxGI=; b=JpZm0 ZaXGMGpoUX0NTGZjiUaL81MrQbj23yInVV6jNNctUXBgcVURfZzJ8kzz2r4hMidK KioWT8N6/CpyiEXo9s2HldLoB9aL3L0/vSQwrPVNYQempOI0fyWkOkfIsmsgn2ej TzApQ1mmqhSEjkKjzpq3NDRHaJqlp1AzObB64o= X-Sasl-enc: hFUA9VKnMLll5/qCO8bZfKu3XLR2NJfRaI2yTZjxB6fb 1445916636 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A6F1C00012; Mon, 26 Oct 2015 23:30:36 -0400 (EDT) To: Peter Saint-Andre , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> From: Keith Moore Message-ID: <562EEFD5.3090402@network-heretics.com> Date: Mon, 26 Oct 2015 23:30:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562EE4A5.90204@andyet.net> Content-Type: multipart/alternative; boundary="------------060206010807080608070803" Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 03:30:42 -0000 This is a multi-part message in MIME format. --------------060206010807080608070803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/26/2015 10:42 PM, Peter Saint-Andre wrote: > On 9/24/15 7:05 PM, Keith Moore wrote: >> On 09/24/2015 08:56 PM, Keith Moore wrote: >>> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>>> I believe we are in agreement that q-components are part of >>>> resource identification. >>> This is simply not the case. >> >> In the case of a URL query or a URN q-component, I think the confusion >> results because there are actually two resources: >> >> 1) The resource that produces the response. >> 2) If there are no errors resulting from the request to the resource, >> the response is also a resource, separate from resource #1. >> >> The base URL or the assigned portion of the URN names resource #1. But >> it's debatable whether either the entire URL nor the entire URN is a >> "name" for resource #2, because resource #1 is really not constrained to >> produce consistent output even when presented with the same >> query/q-component. (Such a resource might however be expected to >> generate correct HTTP response headers to defeat caching.) >> >> At least for URNs I don't think we want to treat the entire URN + >> components as a "name" for resource #2, because even if it is properly >> termed a "name" it doesn't have the persistence properties of URNs and >> calling it a name seems likely to create confusion. > > Keith, you have stated before on this list that a URN is primarily or > effectively resolved into one or more URLs. How does that model map > into your resource #1 and resource #2? 1. Forget about URNs for the moment. Say you have a CGI program running on an HTTP server. That program is a resource. Call it resource #1. Now say you submit a query to that CGI program (aka resource #1) and it returns a result document. The result document is a separate resource from the CGI program. Call that result document resource #2. Say for the sake of example that the URL of resource #1 is "http://example.com/cgi-bin/foo.cgi" . Say also that the query submitted to resource #1 is "?bar=zot" One could then say that the URL of resource #2 is "http://example.com/cgi-bin/foo.cgi?bar=zot" . The point is that resource #1 and resource #2 are distinct things, and it makes sense to be able to refer to them separately. 2. Now back to URNs. Say that the URN for resource #1 were "urn:example:foo" . One could then combine that URN with a query "?bar=zot" and produce a string "urn:example:foo?bar=zot". Requesting the resource associated with that string would result in resource #2 (the result document) being returned. The URN for resource #1 has the persistence properties of URNs. The string used to access resource #2 *does not* have those properties, but it will probably still be called a URN because it begins with "urn:". (We could try to insist on a different name for such strings, but getting users to adopt whatever terminology we chose would be a tremendous feat of social engineering.) I don't even like calling the combination of a base URN and a q-component and/or r-component and/or f-component a "name". I prefer to think of it as a combination of a name and one or more modifiers. 3. Now as to your question. A query about a URN can be submitted to a resolution service. This service can return zero or more URLs. Depending on the query, such URLs might be (for instance): (a) identical locations of the resource named by the URN, such that any of those locations should produce the same result (b) locations of variants of the resource named by the URN that differ in some way (say, the same resource in different languages), (c) URLs of resources related to the URN about which the query to the resolution service was issued (say, earlier or later revisions of the resource). Other kinds of query results are also possible. Again, the result obtained should depend on the kind of query issued to the resolution service. A client shouldn't get back a list of resource variants, or a list of related resources, unless that's what it has asked for. Or at least the different kinds of results need to be distinguished in a way that the client doesn't get confused about what it's getting. In case (a), each of the URLs returned are for resource #1. But if a query is then submitted to one of those URLs, the resource it returns is resource #2. Since in this case all of the URLs for resource #1 are supposed to produce identical results, any of the result documents returned are for resource #2. In case (b), the URLs returned might still be for resource #1, because the concept of URN doesn't require that all instances of the named resource be identical. But to me it doesn't make sense to say that "resource #2" encompasses all of the possibilities that might get from transmitting "?bar=zot" to each of those URLs. Those results might be in different languages. Or sending "?bar=zot" might only make sense to Klingon-language versions of those resource instances, while the other resource instances might simply return errors or garbage. Similarly for case (c). But the resource#1/resource#2 example wasn't intended to apply to all possible ways that a URN resolution service might return URLs. It was only intended to make a clear distinction between the resource that generates a result document and the result document itself. Keith > > Concrete examples would be especially appreciated. :-) > > Peter > > --------------060206010807080608070803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/26/2015 10:42 PM, Peter Saint-Andre wrote:
On 9/24/15 7:05 PM, Keith Moore wrote:
On 09/24/2015 08:56 PM, Keith Moore wrote:
On 09/24/2015 08:24 PM, Sean Leonard wrote:
  I believe we are in agreement that q-components are part of
resource identification.
This is simply not the case.

In the case of a URL query or a URN q-component, I think the confusion
results because there are actually two resources:

1) The resource that produces the response.
2) If there are no errors resulting from the request to the resource,
the response is also a resource, separate from resource #1.

The base URL or the assigned portion of the URN names resource #1. But
it's debatable whether either the entire URL nor the entire URN is a
"name" for resource #2, because resource #1 is really not constrained to
produce consistent output even when presented with the same
query/q-component.   (Such a resource might however be expected to
generate correct HTTP response headers to defeat caching.)

At least for URNs I don't think we want to treat the entire URN +
components as a "name" for resource #2, because even if it is properly
termed a "name" it doesn't have the persistence properties of URNs and
calling it a name seems likely to create confusion.

Keith, you have stated before on this list that a URN is primarily or effectively resolved into one or more URLs. How does that model map into your resource #1 and resource #2?

1.  Forget about URNs for the moment.

Say you have a CGI program running on an HTTP server.   That program is a resource.  Call it resource #1.

Now say you submit a query to that CGI program (aka resource #1) and it returns a result document.   The result document is a separate resource from the CGI program.   Call that result document resource #2.

Say for the sake of example that the URL of resource #1 is "http://example.com/cgi-bin/foo.cgi" .
Say also that the query submitted to resource #1 is "?bar=zot"
One could then say that the URL of resource #2 is "http://example.com/cgi-bin/foo.cgi?bar=zot" .

The point is that resource #1 and resource #2 are distinct things, and it makes sense to be able to refer to them separately.

2.  Now back to URNs.  

Say that the URN for resource #1 were "urn:example:foo" .   One could then combine that URN with a query "?bar=zot" and produce a string "urn:example:foo?bar=zot".   Requesting the resource associated with that string would result in resource #2 (the result document) being returned.

The URN for resource #1 has the persistence properties of URNs.    The string used to access resource #2 does not have those properties, but it will probably still be called a URN because it begins with "urn:".   (We could try to insist on a different name for such strings, but getting users to adopt whatever terminology we chose would be a tremendous feat of social engineering.)  

I don't even like calling the combination of a base URN and a q-component and/or r-component and/or f-component a "name".   I prefer to think of it as a combination of a name and one or more modifiers.

3.  Now as to your question.

A query about a URN can be submitted to a resolution service.  This service can return zero or more URLs.   Depending on the query, such URLs might be (for instance):

(a) identical locations of the resource named by the URN, such that any of those locations should produce the same result
(b) locations of variants of the resource named by the URN that differ in some way (say, the same resource in different languages),
(c) URLs of resources related to the URN about which the query to the resolution service was issued (say, earlier or later revisions of the resource).  
Other kinds of query results are also possible. 

Again, the result obtained should depend on the kind of query issued to the resolution service.   A client shouldn't get back a list of resource variants, or a list of related resources, unless that's what it has asked for.   Or at least the different kinds of results need to be distinguished in a way that the client doesn't get confused about what it's getting.

In case (a), each of the URLs returned are for resource #1.   But if a query is then submitted to one of those URLs, the resource it returns is resource #2.   Since in this case all of the URLs for resource #1 are supposed to produce identical results, any of the result documents returned are for resource #2.

In case (b), the URLs returned might still be for resource #1, because the concept of URN doesn't require that all instances of the named resource be identical.   But to me it doesn't make sense to say that "resource #2" encompasses all of the possibilities that might get from transmitting "?bar=zot" to each of those URLs.   Those results might be in different languages.  Or sending "?bar=zot" might only make sense to Klingon-language versions of those resource instances, while the other resource instances might simply return errors or garbage.  
Similarly for case (c).  

But the resource#1/resource#2 example wasn't intended to apply to all possible ways that a URN resolution service might return URLs.  It was only intended to make a clear distinction between the resource that generates a result document and the result document itself.

Keith








Concrete examples would be especially appreciated. :-)

Peter



--------------060206010807080608070803-- From nobody Mon Oct 26 20:41: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 36FAB1A8ABF for ; Mon, 26 Oct 2015 20:41:30 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK6qDfXswujp for ; Mon, 26 Oct 2015 20:41:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BF51A8AA0 for ; Mon, 26 Oct 2015 20:41:28 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3958F509BD for ; Mon, 26 Oct 2015 23:41:26 -0400 (EDT) To: urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> From: Sean Leonard Message-ID: <562EF218.3040705@seantek.com> Date: Mon, 26 Oct 2015 20:40:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562EEFD5.3090402@network-heretics.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030107030902000204000401" Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 03:41:30 -0000 This is a cryptographically signed message in MIME format. --------------ms030107030902000204000401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/26/2015 8:30 PM, Keith Moore wrote: > > The URN for resource #1 has the persistence properties of URNs. The=20 > string used to access resource #2 *does not* have those properties,=20 > but it will probably still be called a URN because it begins with=20 > "urn:". (We could try to insist on a different name for such=20 > strings, but getting users to adopt whatever terminology we chose=20 > would be a tremendous feat of social engineering.) > > I don't even like calling the combination of a base URN and a=20 > q-component and/or r-component and/or f-component a "name". I prefer = > to think of it as a combination of a name and one or more modifiers. In posts around 1 - 1.5 years ago, I referred to these as: 1. URN, or Name vs. 2. urn: URI For #2, compare with "http: URI", "ldap: URI", "mid: URI", etc. Last is particularly instructive. A Message-ID value is supposed to be=20 globally unique. Assuming this exists in our fantasy land, it is clear=20 that the Message-ID production (or, if you will, MID production) is=20 different than the mid: URI. For one thing, a mid: URI can identify a=20 MIME content part by Content-ID (CID). As for a backronym, how about "Universally Resolvable Name", anyone?? ;-)= Sean --------------ms030107030902000204000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MjcwMzQwMDhaMC8GCSqGSIb3DQEJBDEiBCBgL67EmrzyC/2FtZYR8AKpU8VJ9Nq9agwhWXQC 39YJQzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAKtbpyUW9bR+acLSny tdYlYMhXWiKBm8hYyMs1AUpbEVD42GctOgmwL8xkQlprgjfp2EwR793dC7+obHmMl39M2Hny 7+1KifEwWzlcUbiFAaRS+tJsdoDCXJmN4xf2Ej4ygKRXF/FbM9cTW7XA9uAgFSCkGP4W4Lll HrmPkRpTORBld0/Nk2Xxah83EARU9LHkqIoX5ZirOpnn6E7VwsZ90miTkXvgfmYViKlKjVJc QSnnuVa/WuQStP+caiCGOX8nke1SakZJsjg+Qasj4oTATwm9mVOxAIxZncEEAjBDqRs79OYr C8dNOknQCQDVrvUuOja9ccnxYJO2AUmrQyqhAAAAAAAA --------------ms030107030902000204000401-- From nobody Mon Oct 26 21:01:29 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 17D641B3444 for ; Mon, 26 Oct 2015 21:01:29 -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 9OIqXex-3S4X for ; Mon, 26 Oct 2015 21:01:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0251B3443 for ; Mon, 26 Oct 2015 21:01:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 91DD32075F for ; Tue, 27 Oct 2015 00:01:26 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 27 Oct 2015 00:01:26 -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=7GbN35xcdr1AvQO uZjZRkZbhjWY=; b=K65YSvca8ZG+s8kieFSny1vQjJVAgJFK/uJ9UJgpl4W09X+ Pkejl2JSxnC7ZrK+eOKDn74VKWYAIkNYl+tVnBxM/9gNP14uueSvhuPBNdkLpmBe e9ISpy+JD74jk/Xqk5VcI3rh1H8uG3W8bHc/BwfHLMU91KHw5yWmvlwb+rUM= X-Sasl-enc: ndjgHF1ncdUn3o3kkERWsc0tqptQTbJdN9HCy0xGyOfz 1445918486 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ACA1C0001A; Tue, 27 Oct 2015 00:01:26 -0400 (EDT) To: urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562EF218.3040705@seantek.com> From: Keith Moore Message-ID: <562EF70E.2090601@network-heretics.com> Date: Tue, 27 Oct 2015 00:01:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562EF218.3040705@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 04:01:29 -0000 On 10/26/2015 11:40 PM, Sean Leonard wrote: > On 10/26/2015 8:30 PM, Keith Moore wrote: >> >> The URN for resource #1 has the persistence properties of URNs. The >> string used to access resource #2 *does not* have those properties, >> but it will probably still be called a URN because it begins with >> "urn:". (We could try to insist on a different name for such >> strings, but getting users to adopt whatever terminology we chose >> would be a tremendous feat of social engineering.) >> >> I don't even like calling the combination of a base URN and a >> q-component and/or r-component and/or f-component a "name". I >> prefer to think of it as a combination of a name and one or more >> modifiers. > > In posts around 1 - 1.5 years ago, I referred to these as: > 1. URN, or Name > vs. > 2. urn: URI Again, I think getting users to call the two of these different things would be a tremendous feat of social engineering. The distinction you want to make seems particularly subtle and likely to be missed by users. Though I'm sorely tempted to suggest the following proposal: 1. Define a new URI prefix for the combination of URN + one or more components. I don't care (much) what the prefix is, but for the sake of example I'll call it "augmented URN" with the prefix "aurn:" (or maybe "burn" for "broken URN", or "yarn" for "yet another resource name" or ...) 2. Leave URN syntax as it is in existing RFCs. (without declaring whether 2141 or 3986 is boss) 3. Define a grammar for "aurn" URIs as being AURN = "aurn:" urn-assigned-portion [ r-component ] [ q-component ] [ f-component ] along with definitions of the roles of each of those components. Then maybe we'd preserve a clear distinction between AURNs (or whatever we call them), which do not have persistence properties, and URNs (which do). And we might also be able to avoid fights over different ideas about what URNs mean, or how they're expected to be used, because we wouldn't be changing the meaning of URNs (from whatever people think it is now, even though they don't agree). And we might get to avoid rehashing old battles about whether URNs should exist, or whether they're URIs, or how they fit into the Grand Naming Architecture of the Web. And we wouldn't be sullying URNs with modifiers that make them non-persistent. We could also make it clear that not all URNs would be expected to be meaningful in AURNs without trying to make this property namespace-specific. Keith From nobody Tue Oct 27 04:20:51 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979201A8718 for ; Tue, 27 Oct 2015 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 ASD_pzKi6Lqf for ; Tue, 27 Oct 2015 04:20:46 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1382A1A8729 for ; Tue, 27 Oct 2015 04:20:44 -0700 (PDT) Received: from AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 11:20:20 +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.0306.003; Tue, 27 Oct 2015 11:20:20 +0000 From: "Hakala, Juha E" To: Peter Saint-Andre , Keith Moore , "urn@ietf.org" Thread-Topic: [urn] q-components, r-components, and resource transmission: Section 3.3 Thread-Index: AQHQ9p2oxzFKKoS3ckqC9QF0XoDGQp5MY9YAgDJxViOAAHFPQA== Date: Tue, 27 Oct 2015 11:20:20 +0000 Message-ID: References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> In-Reply-To: <562EE4A5.90204@andyet.net> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-originating-ip: [8.25.222.10] x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:k2vJGcN9lxcJ/frixMrQP3Tpei5AUUCx3HYfKeMdP3qkrv2Z2qx3g5KRp9hSrhNoMKdxpTluxL3ui4EPitkOAVeJSQ7n4fcb9DTM1t+Rxiact8zcy0/uAldq1w6VFv8IbxlLXMHDRGl0Lp8+5Pvalg==; 24:3jaJXsfS+Kl23NbazB3h5uq1BSEvM+W2KaZl2nZYre7iUvF6zVyJog2P+ZcINw99SHX0eMV83MVwJREfmCvO3MvMKIq2/plo8lOVACR/U2c=; 20:Tb1ac6rTNE/jGu4mp4S5AzfzuOj+i775M2WwUJfWv+U0Vi4knfhxgCQJ8nT7YVIOzuaoQIv0lxgpnL03QKk4Bw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(199003)(24454002)(479174004)(377454003)(189002)(13464003)(77096005)(102836002)(92566002)(19580405001)(15975445007)(19580395003)(66066001)(10400500002)(74316001)(122556002)(2950100001)(2900100001)(40100003)(74482002)(5007970100001)(5004730100002)(93886004)(2501003)(5008740100001)(81156007)(189998001)(5001770100001)(5002640100001)(5001960100002)(106116001)(11100500001)(50986999)(105586002)(76176999)(54356999)(106356001)(101416001)(86362001)(19625305001)(5003600100002)(76576001)(87936001)(97736004)(33656002)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB454.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 11:20:20.3449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 11:20:50 -0000 Hello, Usually it will be enough to have just r- or q-component in the URN string.= That is, normally resolution related parameters are passed either to the U= RN resolver or to the target system, but not to both of them at the same ti= me. If a user wants for instance metadata about the identified resource, th= e request can be made either with an r-component or with a q-component. In = the former case the r-component specifies the requested resolution service,= and it is up to the resolver to turn that into a URI that will be accepted= by the target system. In the latter case, q-component must contain a strin= g the target will be able to deal with without conversion by the URN resolv= er. So for a hypothetical ISTC (International Standard Text Code) A02-2009-= 000004BE-A there could be URN (provided that namespace ISTC has been regist= ered): URN:ISTC:A02-2009-000004BE-A We can then add an r-component indicating that the user wants Dublin Core m= etadata about this work=20 URN:ISTC:A02-2009-000004BE-A??s=3DI2C&p=3DDC A URN resolver might map this URN into e.g. =20 http://lx2.loc.gov:210/lcdb?version=3D1.1&operation=3DsearchRetrieve&query= =3DA02-2009-000004BE-A&recordSchema=3Ddc which is an SRU (http://www.loc.gov/standards/sru/index.html ) search to be= sent to the SRU server in the Library of Congress (the search does not wor= k since ISTC in the example is not real). Whenever protocol version or the = address of the target system changes, the URN resolver URN to SRU mapping m= ust be updated accordingly. But r-component will remain the same, and is th= erefore more persistent than the q-component.=20 If the target system does not support a standard search protocol, proprieta= ry search can be "hard-coded" into a q-component. But a simple use case suc= h as "find metadata about the identified resource" should not require use o= f both components in the same time, no matter how the target system behaves= .=20 However, a user who knows the work identifier may want to retrieve a specif= ic manifestation of the work - for instance, a PDF version - without knowin= g its identifier (in the worst case, the book may not have an identifier at= all). Getting from works to manifestations may require slightly more compl= ex communication between the URN resolver and the target system, and the us= e of both r and q components may be necessary. =20 The URN to start the process could be something like=20 URN:ISTC:A02-2009-000004BE-A??s=3DI2CS?s=3DI2R&p=3DPDF That is, the first step is to retrieve all metadata about the work and its = manifestations. Then, if there is a PDF version, its metadata should enable= the target system to locate the document and deliver it (copyright allowin= g) to the user. Only the first part of the process (metadata retrieval) can= be encoded as an SRU search and represented as an r-component. Although th= e user does not want the metadata it is important to retrieve it, not least= because if the PDF version does not exist, the user needs to know what his= options are. But if there is a PDF version, the role of the q-component is= to finish the process. It provides the target system guidelines on how to = deal with the metadata from the first step of the process. =20 In these examples and also generally, neither r- nor q-component have a rol= e in identification (which is what we have agreed on ages ago). It would be= very confusing to say that the ISTC identifies anything else than the work= itself. And although q- and r-components could be presented in any order, = IMO it is more logical to express the r-component first. Some actions by th= e URN resolver (based on the r-component) may be required before the target= system can carry on using the guidelines provided in the q-component.=20 Best regards, Juha > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 27. lokakuuta 2015 4:43 > To: Keith Moore ; urn@ietf.org > Subject: Re: [urn] q-components, r-components, and resource transmission: > Section 3.3 >=20 > On 9/24/15 7:05 PM, Keith Moore wrote: > > On 09/24/2015 08:56 PM, Keith Moore wrote: > >> On 09/24/2015 08:24 PM, Sean Leonard wrote: > >>> I believe we are in agreement that q-components are part of > >>> resource identification. > >> This is simply not the case. > > > > In the case of a URL query or a URN q-component, I think the confusion > > results because there are actually two resources: > > > > 1) The resource that produces the response. > > 2) If there are no errors resulting from the request to the resource, > > the response is also a resource, separate from resource #1. > > > > The base URL or the assigned portion of the URN names resource #1. But > > it's debatable whether either the entire URL nor the entire URN is a > > "name" for resource #2, because resource #1 is really not constrained > > to produce consistent output even when presented with the same > > query/q-component. (Such a resource might however be expected to > > generate correct HTTP response headers to defeat caching.) > > > > At least for URNs I don't think we want to treat the entire URN + > > components as a "name" for resource #2, because even if it is properly > > termed a "name" it doesn't have the persistence properties of URNs and > > calling it a name seems likely to create confusion. >=20 > Keith, you have stated before on this list that a URN is primarily or eff= ectively > resolved into one or more URLs. How does that model map into your resourc= e > #1 and resource #2? >=20 > Concrete examples would be especially appreciated. :-) >=20 > Peter >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Tue Oct 27 06:27:43 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFC1A891D for ; Tue, 27 Oct 2015 06:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 BAnFZru7TXbf for ; Tue, 27 Oct 2015 06:27:31 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 4A0861A8927 for ; Tue, 27 Oct 2015 06:27:31 -0700 (PDT) Received: by obbwb3 with SMTP id wb3so170746295obb.0 for ; Tue, 27 Oct 2015 06:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=+MGKAKki/vJYxzU1CcM+hoVLn/uLT0xCNT+WrIGN77s=; b=l1nhbDWnNE28wjDodIcUdwmQHo1jMkL+90O8XmQzpJYO6MBK2uVAqr2AverEV2Em52 Ma1kqcgcfqvFHCJj4fAkDgGj96JKDSNYhBdiKlNqi9YbVRt6iw6kBKvXko7iN2b6m1wo SMaGWcsFfYYEhJP5wAVwGSlS1keosy2OOE6dHVWOGUshb8mTDkcMjta0I9UmzguOAtUv IpvReIU/rYurb9hRb6m7torn+t+h/0r0osCd88X6QDNAyspoKqfEJ/fdG7epl5OifzvR t4xUT+X1F0sTCZ3KxozCy+CO9bxClfCPJkDjpoIzvcWcMeJn0iYXlofcVhXnZnWc+iQQ nfgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+MGKAKki/vJYxzU1CcM+hoVLn/uLT0xCNT+WrIGN77s=; b=ZjyzG2rx8TncpB7msTh6rc2qwNJioT+v1YvYHDXU6gZBkDf36JJWuZh4rfK3SPolfL 7Y00WNum14cvZlkL3LZx4JSMcCR0InKoYRqpWcBS38zW62rgRNz43qw8hkL7bMaD2r58 mK4F+o19Yz2HJ1H0iitk2h0opf9x5hGRx5BLF8utNqNHkbJtmbuZwNS4DB3TSwPpbHf0 CDmYPjNH3WyxMES+HLewvVBpxQOGDHO9OiGedLhfoBJnakZ15N4rExe7fgsCmA5To8yL ikiQqLxW+p2/DFw2m7yPACKMycwfIxVQy1sAtwdgTOWJwQUqLAY5mdxNBhAi6xgK7rkf yHPw== X-Gm-Message-State: ALoCoQmQBc86ohXxrjZ9Fj2ucUkm1DxTYdP2CqCZTryIGJPqELLSLvSyeSc9oh31bJ6sZZfaFme0 X-Received: by 10.60.33.202 with SMTP id t10mr28050373oei.66.1445952450479; Tue, 27 Oct 2015 06:27:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id s127sm17369134oia.21.2015.10.27.06.27.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2015 06:27:28 -0700 (PDT) To: Keith Moore , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> From: Peter Saint-Andre Message-ID: <562F7BC0.1090404@andyet.net> Date: Tue, 27 Oct 2015 07:27:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <562EEFD5.3090402@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 13:27:33 -0000 On 10/26/15 9:30 PM, Keith Moore wrote: > On 10/26/2015 10:42 PM, Peter Saint-Andre wrote: >> On 9/24/15 7:05 PM, Keith Moore wrote: >>> On 09/24/2015 08:56 PM, Keith Moore wrote: >>>> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>>>> I believe we are in agreement that q-components are part of >>>>> resource identification. >>>> This is simply not the case. >>> >>> In the case of a URL query or a URN q-component, I think the confusion >>> results because there are actually two resources: >>> >>> 1) The resource that produces the response. >>> 2) If there are no errors resulting from the request to the resource, >>> the response is also a resource, separate from resource #1. >>> >>> The base URL or the assigned portion of the URN names resource #1. But >>> it's debatable whether either the entire URL nor the entire URN is a >>> "name" for resource #2, because resource #1 is really not constrained to >>> produce consistent output even when presented with the same >>> query/q-component. (Such a resource might however be expected to >>> generate correct HTTP response headers to defeat caching.) >>> >>> At least for URNs I don't think we want to treat the entire URN + >>> components as a "name" for resource #2, because even if it is properly >>> termed a "name" it doesn't have the persistence properties of URNs and >>> calling it a name seems likely to create confusion. >> >> Keith, you have stated before on this list that a URN is primarily or >> effectively resolved into one or more URLs. How does that model map >> into your resource #1 and resource #2? > > 1. Forget about URNs for the moment. > > Say you have a CGI program running on an HTTP server. That program is > a resource. Call it resource #1. > > Now say you submit a query to that CGI program (aka resource #1) and it > returns a result document. The result document is a separate resource > from the CGI program. Call that result document resource #2. Yes, that's the distinction I thought was in your mind. :-) I wouldn't call a CGI program a resource - I think of it as a service. But in any case, although it's interesting to have this discussion, I don't yet see that it has any impact on the text of 2141bis. If I'm missing a connection there, please enlighten me. Peter From nobody Tue Oct 27 07:16:19 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C191A8A29 for ; Tue, 27 Oct 2015 07:16: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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs9o8FUNIoNE for ; Tue, 27 Oct 2015 07:16:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410031A8A25 for ; Tue, 27 Oct 2015 07:16:16 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0EB5B509C2 for ; Tue, 27 Oct 2015 10:16:14 -0400 (EDT) To: urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562F7BC0.1090404@andyet.net> From: Sean Leonard Message-ID: <562F86E0.2050206@seantek.com> Date: Tue, 27 Oct 2015 07:14:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562F7BC0.1090404@andyet.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090704030507050009090705" Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 14:16:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090704030507050009090705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/27/2015 6:27 AM, Peter Saint-Andre wrote: > On 10/26/15 9:30 PM, Keith Moore wrote: >> On 10/26/2015 10:42 PM, Peter Saint-Andre wrote: >>> On 9/24/15 7:05 PM, Keith Moore wrote: >>>> On 09/24/2015 08:56 PM, Keith Moore wrote: >>>>> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>>>>> I believe we are in agreement that q-components are part of >>>>>> resource identification. >>>>> This is simply not the case. >>>> >>>> In the case of a URL query or a URN q-component, I think the confusi= on >>>> results because there are actually two resources: >>>> >>>> 1) The resource that produces the response. >>>> 2) If there are no errors resulting from the request to the resource= , >>>> the response is also a resource, separate from resource #1. >>>> >>>> The base URL or the assigned portion of the URN names resource #1. B= ut >>>> it's debatable whether either the entire URL nor the entire URN is a= >>>> "name" for resource #2, because resource #1 is really not=20 >>>> constrained to >>>> produce consistent output even when presented with the same >>>> query/q-component. (Such a resource might however be expected to >>>> generate correct HTTP response headers to defeat caching.) >>>> >>>> At least for URNs I don't think we want to treat the entire URN + >>>> components as a "name" for resource #2, because even if it is proper= ly >>>> termed a "name" it doesn't have the persistence properties of URNs a= nd >>>> calling it a name seems likely to create confusion. >>> >>> Keith, you have stated before on this list that a URN is primarily or= >>> effectively resolved into one or more URLs. How does that model map >>> into your resource #1 and resource #2? >> >> 1. Forget about URNs for the moment. >> >> Say you have a CGI program running on an HTTP server. That program i= s >> a resource. Call it resource #1. >> >> Now say you submit a query to that CGI program (aka resource #1) and i= t >> returns a result document. The result document is a separate resourc= e >> from the CGI program. Call that result document resource #2. > > Yes, that's the distinction I thought was in your mind. :-) > > I wouldn't call a CGI program a resource - I think of it as a service. We are participating in a standardization activity...at (most) levels,=20 it is not important what things are called, as long as we have rough=20 consensus that we all call it the same thing. Please. With this said, I understand that "resource" in the sense promulgated by = URI refers to the "thing" that the absolute-URI of RFC 3986 refers to,=20 i.e., *including the q-component*, but *not the f-component*. Can we just agree that when we say resource, we really are referring=20 just to that part? And while we are in an agreeing mood, also agree that the=20 urn:NID:(p-component) is the persistent and durable thing, and the thing = worth comparing for URN equality purposes, (and can return possibly a=20 lot of different kinds of resources, depending on how it gets resolved), = while urn:NID:(p-component)?(q / r-components) is the full absolute-URI=20 syntax, and we agree that it's supposed to narrow down the kinds of=20 resources being requested, possibly narrowing it down to one resource.=20 (That way, the #(f-component) on the client actually stands a chance at=20 being meaningful, i.e., as an identifier for a sub-resource associated=20 with the media type of the dereferenced content.) Sean --------------ms090704030507050009090705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEw MjcxNDE0NTZaMC8GCSqGSIb3DQEJBDEiBCAkienV4LKCz8NgedSGrkBZGzgLz787W9X3aQMc gy5PdTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAsllJ/BZQRBVnsNOGq 7mGIwSsiDrU1zZVkPSmpbMN5jDhxGpgKu3fuooB9vg6OerP+T0iKBCRjleNKebdISsWHffcq yZY5Atv9Z6QMQNkgb49H/MnD/C5m4wBcNzsf8xuh0NPc7h+8mDXgo0KWFp8GsrS92AXnAOym KRmQZRJZgvyKSuOd/4wyvlQhVWqrvhRJ7HEUFIbiwGVHrASd/KWkppyCMNhIMMnzvQyT3kNb WaqGTOjHkwm4+Z+og+ARvs7ZiKekcyUIOVblOIdSdeVYFh+VGmvcoosHevXdIUYvPwPn3uP/ Ia+KsW7PSWFQzAu+L3gF4VT0KOsq99jg7yV4AAAAAAAA --------------ms090704030507050009090705-- From nobody Tue Oct 27 07:28:23 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 B4BE51A8A78 for ; Tue, 27 Oct 2015 07:28:22 -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 aarUsEWW7Hg3 for ; Tue, 27 Oct 2015 07:28:21 -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 C4C001A8A68 for ; Tue, 27 Oct 2015 07:28:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2C1742040D for ; Tue, 27 Oct 2015 10:28:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 27 Oct 2015 10:28:21 -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=cnU185dVR0+fEh1 4LQypHzCiF7U=; b=j06z+4v/Ir7rUCDPrQVg7yIsNFayjyTP2IUC05e2fdpYvdS s5NkU2ZfPv0dquqN7tOv50ZOtsWHRNF63OXO1lf4i11pF6pUqk310/uaHbXdaEov yA5vM0uZYf3x+IlVTSJncbdCDrigT7/GB6Kx6+1Ubsmd2EEsn+mIeliEJM30= X-Sasl-enc: /e0euBszcUqGY6inGw9BQ9Zdf6bDtbHA2XLQOQ5Pwqbd 1445956100 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A64A3C00021; Tue, 27 Oct 2015 10:28:20 -0400 (EDT) To: Peter Saint-Andre , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562F7BC0.1090404@andyet.net> From: Keith Moore Message-ID: <562F89FB.1090708@network-heretics.com> Date: Tue, 27 Oct 2015 10:28:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562F7BC0.1090404@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 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, 27 Oct 2015 14:28:22 -0000 On 10/27/2015 09:27 AM, Peter Saint-Andre wrote: > I wouldn't call a CGI program a resource - I think of it as a service. A service is a kind of resource. It's reasonable to give a service a resource name. Keith From nobody Tue Oct 27 12:24: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 0B2B71ACE6E for ; Tue, 27 Oct 2015 12:24:17 -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 9q_mII3s29ue for ; Tue, 27 Oct 2015 12:24:15 -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 9C7C71ACE6C for ; Tue, 27 Oct 2015 12:24:15 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zr9qt-0000Ip-3K; Tue, 27 Oct 2015 15:24:11 -0400 Date: Tue, 27 Oct 2015 15:24:06 -0400 From: John C Klensin To: Melinda Shore , Peter Saint-Andre , Sean Leonard , urn@ietf.org Message-ID: <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> In-Reply-To: <562EDC4D.3010400@gmail.com> References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.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.10 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] Think about r-components and q-components differently 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, 27 Oct 2015 19:24:17 -0000 --On Monday, October 26, 2015 18:07 -0800 Melinda Shore wrote: > On 10/26/15 5:58 PM, Peter Saint-Andre wrote: >> I think we need to have the chairs tell us how they want to >> proceed here (see also John Klensin's message from August 13, >> 2015). > > I am generally extremely loathe to have chairs resolving > technical questions in the absence of an emergency. That > said, I think we have an emergency. I think we need to hear > from John if he'd block going ahead with r-then-q. Melinda, I hope to catch up in the recent flurry of messages within the next day or three but, unfortunately, tried to reserve time to review a complete -14 posted some time ago and then immediately before the deadline and therefore have not had time to parse these messages. However, with the understanding that there could be something in the message threads that would cause a revelation and result in a change of mind... I continue to think that r-then-q is a bad idea. I won't repeat the reasons, which I have explained at length. I also believe that any argument that hinges on whether something is more likely to be done by left to right or top-down parsing or regular expression matching is probably a sign that we've got the basic design idea wrong and should be looking for other alternatives. However, I agree with others that the cases in which the choice is likely to lead to a big issue are going to be very rare and probably represent bad judgment by whomever is designing the namespace or whatever the URN points to. I therefore do not consider one resolution or the other of this issue to be a showstopper or "known defect" and think it is more important to get this work finished than to spend significantly more time and energy trying to find strong consensus on an optimal solutions. So I'm not going to try to block either choice. That said, I do have one requirement and one suggestion: (1) Whichever ordering is chosen, the ABNF must be correct, unambiguous, or conform to RFC 5234. As long as they are unambiguous, a closed set of productions would be fine, a more open set of productions plus prose restrictions would be fine, but some "pick the production that most nearly resembles the string" handwaving (akin to part of 3986) is not. (2) I won't try to insist but I think it would be wise to include a strong warning in the text about embedded "?" characters inside the r-component and q-component strings and about decoding implications of embedded %3F if the intention is to embed a substring of the URN to some other processor (e.g., in a URL) and whether such a escape should be decoded before embedding. If r-component comes first, that also implies a warning about the use of embedded "??". The syntax must be clear enough that any such construction has one and only one interpretation, but it would be reasonable to also suggest that such constructions should be avoided if possible because sloppy implementations seem inevitable and almost certain to trap the unwary and those whose constructions depend on exact and accurate interpretation of this spec and the relevant rules from 3986. I'd be happy to try to construct text once I see -14. john From nobody Wed Oct 28 02:27:50 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A567B1B373A for ; Wed, 28 Oct 2015 02:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 mghyFsayY9-P for ; Wed, 28 Oct 2015 02:27:47 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.dnb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC01B3739 for ; Wed, 28 Oct 2015 02:27:47 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id D28878AE9B; Wed, 28 Oct 2015 10:27:45 +0100 (CET) X-AuditID: 0a453fe7-f79136d0000011d7-c9-56309511aa4a 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 E6.47.04567.11590365; Wed, 28 Oct 2015 10:27:45 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 28 Oct 2015 10:27:45 +0100 From: "Svensson, Lars" To: Barry Leiba , "STARK, BARBARA H" Thread-Topic: [urn] questions on new namespace registrations Thread-Index: AQHQ+usQhSovFAdEwkShKdspQjNj+J6Az8bg Date: Wed, 28 Oct 2015 09:27:44 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D0F3149@dnbf-ex1.AD.DDB.DE> References: <2D09D61DDFA73D4C884805CC7865E6113A9EBA38@GAALPA1MSGUSRBF.ITServices.sbc.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.200.69.226] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHObt7XOdOXu90nlZW3izIUldJCIlF9DCSHmSjFLJru22r+eDe zTIhjKRokdqLTBKXWaBI2tSUHlSrjEIy1CKC7GFlFmEPKo2K7tnd7Np/v/v5/r7f8z0cLknQ Ixojac9zcnwe62DUWqV22aJv8eEnTGbT94/xyb6zParko79HQfKJfZ8Ui4m0ofLTIK204TCR Vlc3qlhLZGpTLJzDXsjxialbtLaDVzygoF6/66m3S1ECboe5QQiJqCTU3vFOJc0G9LC/Se0G WpKmbgF0p9Sjkj7aAbr47TNwAw2ppuLQsA3vR1Cr0c2hXjWeCSoGeZ8fV+BZTy1EtefaFdJO CvLuf6WS5nmo7+sh/76SmoGGWo76OaRWoZt1lRrpKA9ALQOVfnMItQ41tZUo8QyoaNTc3E1I h0Uh79sfgdIUqrsqcURFoqGBPwEeg8qangbKmdDwg5qAdzY6f+YDIR0cju6deq2sAIYqWWyV zFIls1TJLB6gbAAThFzr3ATWkmCx5CRYOC+QnmiwA5T1LPUBigSMDrYWJ5hpFVsoFOX6wBpS wURC80qTmZ6Qk28psrGCLZt3OTiBiYDTK0QMx3COy7GDmQKTUKKZjhqjgksosG+157uEbBfv 8AFEEqL1eym2Wtii3RyfLwX6wCRSyUTBI1f2ZtCUlXVyOziugOOD6kaSZBCceVw0hvOcldu1 ze5wBmXRZyoXFUqu+AvFwC5cyCgX/u+kIEN8IJ3UicUqjuFiQgGbK9itgWw9rCgTqS5I/bnR sBfnGoJwfOZ9sN4YBQlclsIbNlfeWFejASa5RCFMJuBI4zRofBRvpifK+PjU92Cl+ER6OIhL 6sQf7V9HGnIYhgagv+Jk+AFXjAyw/7PSxbeNgCv64vGFnaxTfuE5mOqCNHDhWAwNQTg+zlgC QlunZqydcvjSUv3OVId61qbaXxu+mBVtj2LLtFMPfdyyx7bEPf8GQ9RXT8y9SzRmnEsdXnzw 9HJDSGN5dcM8X2MxPax+cfWa5udg//WXWfWc27r5wJvSuE7ToobmSm33hZcn0Yvoyds7V4Rm hvXRvSM1jy8/iRQ8Xv5ZYd6rrIEFGkYp2Ni5cQQvsH8B/Zz/Y4sEAAA= Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] questions on new namespace registrations X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 09:27:49 -0000 Barry, Barbara, I'll keep it short: "Yes, what Barry said". Best, Lars *** Lesen. H=F6ren. Wissen. Deutsche Nationalbibliothek ***=20 --=20 Dr. Lars G. Svensson Deutsche Nationalbibliothek Informationsinfrastruktur Adickesallee 1 D-60322 Frankfurt am Main Telefon: +49-69-1525-1752 Telefax: +49-69-1525-1799 mailto:l.svensson@dnb.de=20 http://www.dnb.de > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday, September 30, 2015 4:14 AM > To: STARK, BARBARA H > Cc: urn@ietf.org > Subject: Re: [urn] questions on new namespace registrations >=20 > Hi, Barbara. I'm sorry you haven't gotten a response to this yet, so > in the hope of getting either a "Yes, what Barry said," or a "Oh, my, > Barry's totally full of potatoes, and here's what you should do > instead of listening to him," I'll give an answer. >=20 > > I have a "friend" [...] I think my friend needs advice. >=20 > Wink-wink. >=20 > > The 2 squatted namespace NIDs are derived from the current and former > > domain names. Hypothetically, I'll call these "dslforum-org" and > > "broadband-forum-org". > > > > Would it make sense to register both of these once the new > > registration process is in place? > > > > My friend has expressed some sensitivity that these look nothing like > > currently registered formal URNs (none of which have hyphens, and > > which are all shorter). Would it make sense to register a new formal > > NID (for example, "bbf") that looks more like the other formally > > registered URNs? Or, if the squatted ones were to be registered, would > > those be just fine, and my friend should feel no shame in the lengthy > > and hyphenated nature of those NIDs? >=20 > If the two in the first paragraph are already in use, I see no reason > to change them, and I'd suggest registering them as is. If they're > theoretical, or if the current use is limited and easy to change, and > if they belong to the same organization (hypothetically, BBF), then > it'd be nicer (but not really because of the hyphens) to group them > together under the same NID, and just make them two "branches" that > are defined there (and then BBF could hypothetically define more > branches now or later if it needs them). >=20 > Barry >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Wed Oct 28 13:26: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 AA0A51ACEBE for ; Wed, 28 Oct 2015 13:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 f0URqn-H7B1o for ; Wed, 28 Oct 2015 13:26:50 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 265191ACEBD for ; Wed, 28 Oct 2015 13:26:49 -0700 (PDT) Received: by obcqt19 with SMTP id qt19so16680088obc.3 for ; Wed, 28 Oct 2015 13:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Aj5ZndkRv+MhDJeHTWn2wWHyD0zBvpQacSFKG/w9uYg=; b=lDXbu9ABMDwhN2K1DL+6p9dHfsGfGJfjWdiZWTs6MIO7Lt75GEC4XMDwBOYPU4264+ wXji6dZJSWGy4g0aX9RbQEgvXdsN3o+S6wsTa40VmGSWs14HKLao4AiIufAfDqr9HrDW +Xhvf6KyqE15cpeNWHYUWuNfIlh5u9YXoMv81WbhEQcqy1wiPgbEWxysfop0d22dxflM 8ScnwSgLWjBjCeBZ6Akl2xYtl2sLIAFdhx95UrwXyqXw6nd95hrLHYCkJhXdYYBxgrpi sinax+WhpMrK3hcpbW24MWWaYXrxc9f4SFNd8zQRTl7AzkIJOFJLnuVrpVQa4rVr16tc 8C+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Aj5ZndkRv+MhDJeHTWn2wWHyD0zBvpQacSFKG/w9uYg=; b=PEQueDir2G6JmblF1NJXBzWjx7lio3nA1288yPrzqRa4rZLSJNsrVO/P7fx8EmR7xl naU89kMsibSxRxncHTMw/pa6QagUqwGFZBRkCOGvdVxlVEG0YEgE/aZ/oa2qCtRWx0ef /B8CNNI3Gl5JHNb3oeNAeQZ1d9M1HirHhJv/hHJEyN6qZrlddF24qtjqedsqvqOIhXZf ZwrxLEm2ZgSBIMSAm5s4DUjB8B1gtp5Pc6sTgjO21andiv4SP0aROYMu1flGdxZMLIY9 67MgdOdWV6Fs21ulNL+uFQHNEy4Yrn9n0FRmtO9lXZeEe5sThesjF2aeqigQqOHF50Px L9Eg== X-Gm-Message-State: ALoCoQm+agKMMmJ9Ms1ncw5Fw0qqEAG9bHS0qzVf6FAdok4Gko0tAEpjPIXyekVVd8xMempifqvc X-Received: by 10.60.150.138 with SMTP id ui10mr10756917oeb.8.1446064008443; Wed, 28 Oct 2015 13:26:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id m10sm20472542oex.12.2015.10.28.13.26.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 13:26:47 -0700 (PDT) To: Sean Leonard , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562F7BC0.1090404@andyet.net> <562F86E0.2050206@seantek.com> From: Peter Saint-Andre Message-ID: <56312F86.7030300@andyet.net> Date: Wed, 28 Oct 2015 14:26:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <562F86E0.2050206@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 20:26:51 -0000 On 10/27/15 8:14 AM, Sean Leonard wrote: > On 10/27/2015 6:27 AM, Peter Saint-Andre wrote: >> On 10/26/15 9:30 PM, Keith Moore wrote: >>> On 10/26/2015 10:42 PM, Peter Saint-Andre wrote: >>>> On 9/24/15 7:05 PM, Keith Moore wrote: >>>>> On 09/24/2015 08:56 PM, Keith Moore wrote: >>>>>> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>>>>>> I believe we are in agreement that q-components are part of >>>>>>> resource identification. >>>>>> This is simply not the case. >>>>> >>>>> In the case of a URL query or a URN q-component, I think the confusion >>>>> results because there are actually two resources: >>>>> >>>>> 1) The resource that produces the response. >>>>> 2) If there are no errors resulting from the request to the resource, >>>>> the response is also a resource, separate from resource #1. >>>>> >>>>> The base URL or the assigned portion of the URN names resource #1. But >>>>> it's debatable whether either the entire URL nor the entire URN is a >>>>> "name" for resource #2, because resource #1 is really not >>>>> constrained to >>>>> produce consistent output even when presented with the same >>>>> query/q-component. (Such a resource might however be expected to >>>>> generate correct HTTP response headers to defeat caching.) >>>>> >>>>> At least for URNs I don't think we want to treat the entire URN + >>>>> components as a "name" for resource #2, because even if it is properly >>>>> termed a "name" it doesn't have the persistence properties of URNs and >>>>> calling it a name seems likely to create confusion. >>>> >>>> Keith, you have stated before on this list that a URN is primarily or >>>> effectively resolved into one or more URLs. How does that model map >>>> into your resource #1 and resource #2? >>> >>> 1. Forget about URNs for the moment. >>> >>> Say you have a CGI program running on an HTTP server. That program is >>> a resource. Call it resource #1. >>> >>> Now say you submit a query to that CGI program (aka resource #1) and it >>> returns a result document. The result document is a separate resource >>> from the CGI program. Call that result document resource #2. >> >> Yes, that's the distinction I thought was in your mind. :-) >> >> I wouldn't call a CGI program a resource - I think of it as a service. > > We are participating in a standardization activity...at (most) levels, > it is not important what things are called, as long as we have rough > consensus that we all call it the same thing. Please. > > With this said, I understand that "resource" in the sense promulgated by > URI refers to the "thing" that the absolute-URI of RFC 3986 refers to, > i.e., *including the q-component*, but *not the f-component*. > > Can we just agree that when we say resource, we really are referring > just to that part? > > And while we are in an agreeing mood, also agree that the > urn:NID:(p-component) is the persistent and durable thing, and the thing > worth comparing for URN equality purposes, The spec already says that. :-) > (and can return possibly a > lot of different kinds of resources, depending on how it gets resolved), Ditto. > while urn:NID:(p-component)?(q / r-components) is the full absolute-URI > syntax, and we agree that it's supposed to narrow down the kinds of > resources being requested, possibly narrowing it down to one resource. > (That way, the #(f-component) on the client actually stands a chance at > being meaningful, i.e., as an identifier for a sub-resource associated > with the media type of the dereferenced content.) Is there text that needs to be added to the spec here? Peter From nobody Wed Oct 28 13:27:48 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 2895C1ACEC0 for ; Wed, 28 Oct 2015 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 a386MzVy8eUm for ; Wed, 28 Oct 2015 13:27:46 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 18F2C1ACEBE for ; Wed, 28 Oct 2015 13:27:46 -0700 (PDT) Received: by obcqt19 with SMTP id qt19so16700723obc.3 for ; Wed, 28 Oct 2015 13:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=MYbKdYlw9QD9cIJ5DqkhJ/ztW/yZ5nNkrH4D1pQ6sYc=; b=YwbLR9wkzSV0Dc+IJ9MVRzVWIXajHycSOUz9qmuC7WYXqSFTUA9CqmEC9p33q6lujW vhkUHwieC8jWR0fxuObjDLbUJshHMfvr6zT0HAxFZroNcPagSq06KmO9j5pu20hrvuMs OpFMgjzMvAnVaUuFdP091XlnFayNV8dqTeY/WrU9luY06EmH+aArXHxaoZyfpF6lD/34 3YUJ8xsO8Jj4XGmpfUkDOOdVy0OCbmB0SVSE1x7cInVWEMgG0SEDcKyd+QJvSLqven6c +UeHChY1Da5RFEL451RPv/zb8euVRTtnleh2VOLo75wtuSMy5pLS/dZp7ulpIwPleFst 6edg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=MYbKdYlw9QD9cIJ5DqkhJ/ztW/yZ5nNkrH4D1pQ6sYc=; b=AmTzF9Pt6l9mcuOub+wa7O3bu0q45hK14yz56hh5UTt6cqOG6GSfsK8NgSIoHt61VK MtugRTDvEd2dD2oVd3i++1ComzkA5Qi8ilIfUcLK9/VkrPBzTiT/Syi3xRoBTbHjlVKR tsh3VwrGEIiuLWKgs1bNu39EE+EIvf96odr8sftGSI1IsaqLGk8CLPBr8S7D8lOgTlNX fQpX2wL/w4TTwWZTI/kss6AtN6YJqa1LET7gIQDyVCV+DzlFuvyWwez/3QN/AK1yJuKP tKdRNYTt/9UaN1osy6YTE8MgHcGUi/99Q1qPm0JmdatrrS7Em16tgSFmOa7nxN0LaFrz otlw== X-Gm-Message-State: ALoCoQnzNpn3mBMNmouQ2zdb17ZMJ2YcvqvRa0rwHs//FGQHadZChDffMfcxu6ocIXsir4omN0p7 X-Received: by 10.182.81.136 with SMTP id a8mr30952964oby.76.1446064065526; Wed, 28 Oct 2015 13:27:45 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id q2sm20660653obf.22.2015.10.28.13.27.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 13:27:44 -0700 (PDT) To: Keith Moore , urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562F7BC0.1090404@andyet.net> <562F89FB.1090708@network-heretics.com> From: Peter Saint-Andre Message-ID: <56312FBF.9010506@andyet.net> Date: Wed, 28 Oct 2015 14:27:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <562F89FB.1090708@network-heretics.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 20:27:47 -0000 On 10/27/15 8:28 AM, Keith Moore wrote: > On 10/27/2015 09:27 AM, Peter Saint-Andre wrote: >> I wouldn't call a CGI program a resource - I think of it as a service. > > A service is a kind of resource. It's reasonable to give a service a > resource name. Everything is a kind of resource, I suppose. I'm trying to figure out if text needs to change based on this thread. So far I don't think so, but I might have missed something. Peter From nobody Wed Oct 28 13:39:05 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627B61AD067 for ; Wed, 28 Oct 2015 13:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 J8tOm31BPPS3 for ; Wed, 28 Oct 2015 13:39:02 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 4DFBA1B5DA6 for ; Wed, 28 Oct 2015 13:39:01 -0700 (PDT) Received: by obbwb3 with SMTP id wb3so17137487obb.0 for ; Wed, 28 Oct 2015 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ISw3YxlLmUfdz9RaFUqD23g5PimfvwbPEjWcsZo4G1o=; b=jjS6BZEPxJ2tfUoBER1Khdxak6LmFgM/UXO+bEOib6A3Xfg80VhEeyV13uJcooEq3a Ee+iI2K71iVJVmXwsMflkwA7JsvpAnCq30J4/S+p7mMfSLY3H/9q6eB3ZQQs4c8zii26 M+82Yumr+6jkP/ft4mkCaXif9cnwVqAaoNcwRhtxh90OpH3FWjDTIPOBh/+EzHi9gPrl EzJXwX8+u3yvRXxd/oWDq6rCbYcQkIJvK7ceM2HByAWpAeL1AJH9RZO220Q5zsBKY9wz Cijrd0GkEmzbgk7jvM3Guxw06NRhPF1uV5DlLAuQqF7GRsEfOQ0otetU6WgtvEaqoZe2 wqSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ISw3YxlLmUfdz9RaFUqD23g5PimfvwbPEjWcsZo4G1o=; b=PogWgT5CzHxVGOLY3DFGsSsM2KzFSLB2tQIDg5t24xTZa2u8daWIz6K9XQeQN+wSGG xHWPH6v0/NzLF6UtemErgZiaSH13jmnOcxPknabdz/mNxWv9L3g7VozXtphgq3Tr27mO WO5266RgwBujd1EG4hvTtCM/wsj3eUrwvuz4KwCb4QMwbH2/KNRdP0pD8W9rNG2g7uWk 7AlZnk30/X18LuT4cFRFwzyQj0MTh0EO8Qd1kLseT7lQ2+6u7IfTwvXto5R4VdsF8yWH cNK1wLj9POGK+c3qYTZMny5eNAG+9glHbdgWekA4aF8TIH1QzsfmcfkHvdH95OjyQr0Q uPxQ== X-Gm-Message-State: ALoCoQnSkK1VzFXzWqUERMs7auEiBcSg/9lcEqyHwEIgpPrHI1Fge0/NJ5ypNv1NiDJmmbIjerSv X-Received: by 10.182.131.228 with SMTP id op4mr33347011obb.3.1446064740630; Wed, 28 Oct 2015 13:39:00 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id ny9sm20688968obc.23.2015.10.28.13.38.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 13:38:59 -0700 (PDT) To: John C Klensin , Melinda Shore , Sean Leonard , urn@ietf.org References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> From: Peter Saint-Andre Message-ID: <56313261.9070804@andyet.net> Date: Wed, 28 Oct 2015 14:38:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Think about r-components and q-components differently X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 20:39:04 -0000 On 10/27/15 1:24 PM, John C Klensin wrote: > > > --On Monday, October 26, 2015 18:07 -0800 Melinda Shore > wrote: > >> On 10/26/15 5:58 PM, Peter Saint-Andre wrote: >>> I think we need to have the chairs tell us how they want to >>> proceed here (see also John Klensin's message from August 13, >>> 2015). >> >> I am generally extremely loathe to have chairs resolving >> technical questions in the absence of an emergency. That >> said, I think we have an emergency. I think we need to hear >> from John if he'd block going ahead with r-then-q. > > Melinda, > > I hope to catch up in the recent flurry of messages Sorry about that - I seem to be processing IETF work in batch mode. > within the > next day or three but, unfortunately, tried to reserve time to > review a complete -14 posted some time ago and then immediately > before the deadline and therefore have not had time to parse > these messages. However, with the understanding that there > could be something in the message threads that would cause a > revelation and result in a change of mind... > > I continue to think that r-then-q is a bad idea. I won't repeat > the reasons, which I have explained at length. For other folks here, the primary message seems to be: http://www.ietf.org/mail-archive/web/urn/current/msg03025.html And, secondarily: http://www.ietf.org/mail-archive/web/urn/current/msg03120.html > I also believe > that any argument that hinges on whether something is more > likely to be done by left to right or top-down parsing or > regular expression matching is probably a sign that we've got > the basic design idea wrong and should be looking for other > alternatives. > > However, I agree with others that the cases in which the choice > is likely to lead to a big issue are going to be very rare and > probably represent bad judgment by whomever is designing the > namespace or whatever the URN points to. I therefore do not > consider one resolution or the other of this issue to be a > showstopper or "known defect" and think it is more important to > get this work finished than to spend significantly more time and > energy trying to find strong consensus on an optimal solutions. > So I'm not going to try to block either choice. > > That said, I do have one requirement and one suggestion: > > (1) Whichever ordering is chosen, the ABNF must be correct, > unambiguous, or conform to RFC 5234. As long as they are > unambiguous, a closed set of productions would be fine, a more > open set of productions plus prose restrictions would be fine, > but some "pick the production that most nearly resembles the > string" handwaving (akin to part of 3986) is not. > > (2) I won't try to insist but I think it would be wise to > include a strong warning in the text about embedded "?" > characters inside the r-component and q-component strings and > about decoding implications of embedded %3F if the intention is > to embed a substring of the URN to some other processor (e.g., > in a URL) and whether such a escape should be decoded before > embedding. If r-component comes first, that also implies a > warning about the use of embedded "??". The syntax must be > clear enough that any such construction has one and only one > interpretation, but it would be reasonable to also suggest that > such constructions should be avoided if possible because sloppy > implementations seem inevitable and almost certain to trap the > unwary and those whose constructions depend on exact and > accurate interpretation of this spec and the relevant rules from > 3986. I'd be happy to try to construct text once I see -14. Thsoe are good points that we need to take into account before we're done. Peter From nobody Wed Oct 28 16:11: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 B250A1B5EDD for ; Wed, 28 Oct 2015 16:11:16 -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 tPnsc_AxzSO6 for ; Wed, 28 Oct 2015 16:11: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 165201B5EDA for ; Wed, 28 Oct 2015 16:11:15 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7C7EE203B3 for ; Wed, 28 Oct 2015 19:11:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 28 Oct 2015 19:11: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=zi8x8Ey1oESSS99 x0PMIalNho0I=; b=Wp+sHxlHxRc7yAi4pAlD/acO4PHUvx85s4EIkk5D0dMAuAb PuaVQFmRETHSrR/5qYydZpzx617570jwDx0l0Cz/7Ocwdebs7jqdzpJXNR/1J7UF M1GlyVNK5hgOQb8dNS4IL+Yp8OXAN6eEFPEjrW0YKpgN+W5dodCxR2mcsYqg= X-Sasl-enc: rcUoWXIDfat6LlFeA+Gjx1WMOmqNDeqx99BXaZjAqBQN 1446073873 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FFD568013D; Wed, 28 Oct 2015 19:11:13 -0400 (EDT) To: urn@ietf.org References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562F7BC0.1090404@andyet.net> <562F86E0.2050206@seantek.com> <56312F86.7030300@andyet.net> From: Keith Moore Message-ID: <56315604.2060203@network-heretics.com> Date: Wed, 28 Oct 2015 19:11:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56312F86.7030300@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 23:11:16 -0000 On 10/28/2015 04:26 PM, Peter Saint-Andre wrote: > On 10/27/15 8:14 AM, Sean Leonard wrote: >> On 10/27/2015 6:27 AM, Peter Saint-Andre wrote: >>> On 10/26/15 9:30 PM, Keith Moore wrote: >>>> On 10/26/2015 10:42 PM, Peter Saint-Andre wrote: >>>>> On 9/24/15 7:05 PM, Keith Moore wrote: >>>>>> On 09/24/2015 08:56 PM, Keith Moore wrote: >>>>>>> On 09/24/2015 08:24 PM, Sean Leonard wrote: >>>>>>>> I believe we are in agreement that q-components are part of >>>>>>>> resource identification. >>>>>>> This is simply not the case. >>>>>> >>>>>> In the case of a URL query or a URN q-component, I think the >>>>>> confusion >>>>>> results because there are actually two resources: >>>>>> >>>>>> 1) The resource that produces the response. >>>>>> 2) If there are no errors resulting from the request to the >>>>>> resource, >>>>>> the response is also a resource, separate from resource #1. >>>>>> >>>>>> The base URL or the assigned portion of the URN names resource >>>>>> #1. But >>>>>> it's debatable whether either the entire URL nor the entire URN is a >>>>>> "name" for resource #2, because resource #1 is really not >>>>>> constrained to >>>>>> produce consistent output even when presented with the same >>>>>> query/q-component. (Such a resource might however be expected to >>>>>> generate correct HTTP response headers to defeat caching.) >>>>>> >>>>>> At least for URNs I don't think we want to treat the entire URN + >>>>>> components as a "name" for resource #2, because even if it is >>>>>> properly >>>>>> termed a "name" it doesn't have the persistence properties of >>>>>> URNs and >>>>>> calling it a name seems likely to create confusion. >>>>> >>>>> Keith, you have stated before on this list that a URN is primarily or >>>>> effectively resolved into one or more URLs. How does that model map >>>>> into your resource #1 and resource #2? >>>> >>>> 1. Forget about URNs for the moment. >>>> >>>> Say you have a CGI program running on an HTTP server. That >>>> program is >>>> a resource. Call it resource #1. >>>> >>>> Now say you submit a query to that CGI program (aka resource #1) >>>> and it >>>> returns a result document. The result document is a separate >>>> resource >>>> from the CGI program. Call that result document resource #2. >>> >>> Yes, that's the distinction I thought was in your mind. :-) >>> >>> I wouldn't call a CGI program a resource - I think of it as a service. >> >> We are participating in a standardization activity...at (most) levels, >> it is not important what things are called, as long as we have rough >> consensus that we all call it the same thing. Please. >> >> With this said, I understand that "resource" in the sense promulgated by >> URI refers to the "thing" that the absolute-URI of RFC 3986 refers to, >> i.e., *including the q-component*, but *not the f-component*. >> >> Can we just agree that when we say resource, we really are referring >> just to that part? Absolutely not. The named resource DOES NOT include the q-component. Part of the problem is that the binding between the URN + q-component and whatever is named by the combination of the URN and the q-component is not persistent. The binding between the URN and the resource *is* persistent. So it is vitally important to keep that distinction clear. Keith p.s. I still haven't had time to review the latest version of the spec, but will do so early next week. From nobody Wed Oct 28 20:11:26 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645941B637C for ; Wed, 28 Oct 2015 20:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 4b7VeOouhqV6 for ; Wed, 28 Oct 2015 20:11:15 -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 E344F1B6378 for ; Wed, 28 Oct 2015 20:11:14 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZrdcH-00063a-GG; Wed, 28 Oct 2015 23:11:05 -0400 Date: Wed, 28 Oct 2015 23:11:00 -0400 From: John C Klensin To: "Hakala, Juha E" , Peter Saint-Andre , Keith Moore , urn@ietf.org Message-ID: In-Reply-To: References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 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] q-components, r-components, and resource transmission: Section 3.3 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, 29 Oct 2015 03:11:23 -0000 Juha, For the record, I agree with all of what you have written below, but (the first part of this applies to everyone, not just Juha)... (1) Like Peter, I don't see it leading to text that needs to be changed in the document. If changes are needed, please try to identify what and where and, if at all possible, supply draft text. (2) Your ISTC example is, at least to me, clearly within the range of things I think URNs have historically been about. It is still identifying an object, even though that object is a somewhat abstracted one that can be (in your terminology) manifested in different ways and/or exist and be delivered in different formats. However, I can look at the relationships you describe in terms of r-component and q-component and devise almost equally reasonable ways of organizing that information. That suggests to me that those relationships had best be per-namespace and that we should be very careful about what advice 2141bis gives about them. If we try to move beyond that (and much beyond the language of -13), I think we are going to need a comprehensive model of the relationships among elements of the namespace, resolver location, resolver instructions, and query elements... and that would predict to our not being able to finished this work within finite time. (3) I have much the same reaction to trying to expand resource-object into active code (or "services") that returns resource-objects that are, in turn, dereferenced into locators that point to the objects themselves. If some special case of that sequence works well as a URN namespace, so be it. But, if we have to go down the path of working out the nested relationships and what information gets passed to what level (and is opaque to all the other levels), that is the traditional case for recursion and/or nesting of information. Whatever else it is good for, the URI design accommodates recursion and nesting very poorly and I suggest that our trying to "fix" that as part of URN work will just lead to a great deal of frustration and little likelihood of a consensus result that will also satisfy URI constraints (I can think of at least one way to do it, but the WG has already rejected the framework that would make it possible). best, john --On Tuesday, October 27, 2015 11:20 +0000 "Hakala, Juha E" wrote: > Hello, > > Usually it will be enough to have just r- or q-component in > the URN string. That is, normally resolution related > parameters are passed either to the URN resolver or to the > target system, but not to both of them at the same time. If a > user wants for instance metadata about the identified > resource, the request can be made either with an r-component > or with a q-component. In the former case the r-component > specifies the requested resolution service, and it is up to > the resolver to turn that into a URI that will be accepted by > the target system. In the latter case, q-component must > contain a string the target will be able to deal with without > conversion by the URN resolver. So for a hypothetical ISTC > (International Standard Text Code) A02-2009-000004BE-A there > could be URN (provided that namespace ISTC has been > registered): > > URN:ISTC:A02-2009-000004BE-A > > We can then add an r-component indicating that the user wants > Dublin Core metadata about this work > > URN:ISTC:A02-2009-000004BE-A??s=I2C&p=DC > > A URN resolver might map this URN into e.g. > > http://lx2.loc.gov:210/lcdb?version=1.1&operation=searchRetrie > ve&query=A02-2009-000004BE-A&recordSchema=dc > > which is an SRU (http://www.loc.gov/standards/sru/index.html ) > search to be sent to the SRU server in the Library of Congress > (the search does not work since ISTC in the example is not > real). Whenever protocol version or the address of the target > system changes, the URN resolver URN to SRU mapping must be > updated accordingly. But r-component will remain the same, and > is therefore more persistent than the q-component. > > If the target system does not support a standard search > protocol, proprietary search can be "hard-coded" into a > q-component. But a simple use case such as "find metadata > about the identified resource" should not require use of both > components in the same time, no matter how the target system > behaves. > > However, a user who knows the work identifier may want to > retrieve a specific manifestation of the work - for instance, > a PDF version - without knowing its identifier (in the worst > case, the book may not have an identifier at all). Getting > from works to manifestations may require slightly more complex > communication between the URN resolver and the target system, > and the use of both r and q components may be necessary. > > The URN to start the process could be something like > > URN:ISTC:A02-2009-000004BE-A??s=I2CS?s=I2R&p=PDF > > That is, the first step is to retrieve all metadata about the > work and its manifestations. Then, if there is a PDF version, > its metadata should enable the target system to locate the > document and deliver it (copyright allowing) to the user. Only > the first part of the process (metadata retrieval) can be > encoded as an SRU search and represented as an r-component. > Although the user does not want the metadata it is important > to retrieve it, not least because if the PDF version does not > exist, the user needs to know what his options are. But if > there is a PDF version, the role of the q-component is to > finish the process. It provides the target system guidelines > on how to deal with the metadata from the first step of the > process. > > In these examples and also generally, neither r- nor > q-component have a role in identification (which is what we > have agreed on ages ago). It would be very confusing to say > that the ISTC identifies anything else than the work itself. > And although q- and r-components could be presented in any > order, IMO it is more logical to express the r-component > first. Some actions by the URN resolver (based on the > r-component) may be required before the target system can > carry on using the guidelines provided in the q-component. From nobody Wed Oct 28 20:28:49 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8752F1B63EF for ; Wed, 28 Oct 2015 20:28:48 -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 fXbTIv2DWiOk for ; Wed, 28 Oct 2015 20:28:47 -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 EAA811B63EE for ; Wed, 28 Oct 2015 20:28:46 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZrdtM-00064w-HW; Wed, 28 Oct 2015 23:28:44 -0400 Date: Wed, 28 Oct 2015 23:28:39 -0400 From: John C Klensin To: Keith Moore , urn@ietf.org Message-ID: In-Reply-To: <562EF70E.2090601@network-heretics.com> References: <5603348F.9020307@seantek.com> <5603AB1D.6010703@it.aoyama.ac.jp> <56049BC2.2050109@network-heretics.com> <56049DF0.6090508@network-heretics.com> <562EE4A5.90204@andyet.net> <562EEFD5.3090402@network-heretics.com> <562EF218.3040705@seantek.com> <562EF70E.2090601@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.10 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: [urn] [A]URNs (was: Re: q-components, r-components, and resource transmission: Section 3.3) 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, 29 Oct 2015 03:28:48 -0000 --On Tuesday, October 27, 2015 00:01 -0400 Keith Moore wrote: >... >>> I don't even like calling the combination of a base URN and >>> a q-component and/or r-component and/or f-component a >>> "name". I prefer to think of it as a combination of a >>> name and one or more modifiers. >> >> In posts around 1 - 1.5 years ago, I referred to these as: >> 1. URN, or Name >> vs. >> 2. urn: URI > > Again, I think getting users to call the two of these > different things would be a tremendous feat of social > engineering. The distinction you want to make seems > particularly subtle and likely to be missed by users. Yep. > Though I'm sorely tempted to suggest the following proposal: > > 1. Define a new URI prefix for the combination of URN + one or > more components. I don't care (much) what the prefix is, but > for the sake of example I'll call it "augmented URN" with the > prefix "aurn:" (or maybe "burn" for "broken URN", or "yarn" > for "yet another resource name" or ...) > > 2. Leave URN syntax as it is in existing RFCs. (without > declaring whether 2141 or 3986 is boss) > > 3. Define a grammar for "aurn" URIs as being >... > Then maybe we'd preserve a clear distinction between AURNs (or > whatever we call them), which do not have persistence > properties, and URNs (which do). And we might also be able > to avoid fights over different ideas about what URNs mean, or > how they're expected to be used, because we wouldn't be > changing the meaning of URNs (from whatever people think it is > now, even though they don't agree). And we might get to > avoid rehashing old battles about whether URNs should exist, > or whether they're URIs, or how they fit into the Grand Naming > Architecture of the Web. And we wouldn't be sullying URNs > with modifiers that make them non-persistent. We could also > make it clear that not all URNs would be expected to be > meaningful in AURNs without trying to make this property > namespace-specific. I think it is likely far too late for at least two reasons. First, unless we actually deprecate the "URN" scheme and figure out how to enforce a "no more of them" rule, many (perhaps most) namespace-definers who are not persuaded that there is a difference and those looking to apply the new features to existing namespaces will simply continue to use the "URN" scheme name and expect it to behave... well, however they expect it to behave. The result would be that we would have three things: (i) AURNs, which would presumably conform to some new specification. (ii) URNs which conform to 2141 and/or 3986. (iii) URNs which look like the current 2141bis and/or the AURN spec, and/or some other notion of what should be going on. Assume we maintained backward-compatibility, it would basically be impossible to distinguish between (ii) and an instance of (i) in which optional components were not present. Maybe that would make no difference, but, depending on the semantics defined for (i), maybe it would. More important, it would be impossible to figure out what (iii) meant and, if no components were present, whether the URN could safely be treated as equivalent to (ii). . Second, this WG is not chartered to start inventing new schemes and, given how rapidly and efficiently we have made progress and the large number of people who have been actively and consistently engaged, the IESG would probably have to be insane to recharter it, or charter a new WG, to do that work, especially since doing so would recreate the controversy about the "...any other URI with the properties of a name" remark at the end of the first paragraph of Section 1.1.3 of RFC 3986 and all of the arguments about whether URNs are even needed or useless. So, interesting idea and one that has been proposed in one form or another several times, but I think it is too late and probably out of order (and a distraction from getting work done) in the present discussion. john From nobody Wed Oct 28 20:39:51 2015 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7CC1B6415 for ; Wed, 28 Oct 2015 20:39:49 -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 7GyO_zjEKT37 for ; Wed, 28 Oct 2015 20:39:48 -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 0D7841B6413 for ; Wed, 28 Oct 2015 20:39:48 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Zre3y-00067G-CG; Wed, 28 Oct 2015 23:39:42 -0400 Date: Wed, 28 Oct 2015 23:39:37 -0400 From: John C Klensin To: Peter Saint-Andre , Melinda Shore , Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <56313261.9070804@andyet.net> References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 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] Think about r-components and q-components differently 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, 29 Oct 2015 03:39:50 -0000 --On Wednesday, October 28, 2015 14:38 -0600 Peter Saint-Andre wrote: >... > On 10/27/15 1:24 PM, John C Klensin wrote: >> I also believe >> that any argument that hinges on whether something is more >> likely to be done by left to right or top-down parsing or >> regular expression matching is probably a sign that we've got >> the basic design idea wrong and should be looking for other >> alternatives. FWIW and with apologies for this being so late, I've been (again, since the prior note) trying to think through the reasons we are continuing to have an "r-component or q-component first" debate, one that has been going on for months with no obvious reason for strongly favoring one option over the other and doing so in the light of the "basic design idea wrong" hypothesis above. So, stepping back some distance... The problem we are having ultimately stems from trying to use "?" (derived from the 3986 production as an introducer to ) for the q-component and "??", a two-character URI invention, as an introducer for r-component, rather than treating both q-component and r-component as subsidiary to what 3986 calls "query". That doubled question mark causes many problems with either ordering although the problems differ. In particular, it makes the ABNF hard to write and it creates edge cases that are likely to confuse implementations and/or users. If the problem really lies with that doubled question mark, then suppose we do something different. In particular, we find two special characters that are now allowed within (that is just about anything other than "#"). We could then define the relevant syntax as follows (definitions for , and copied from the designated sections of 3986 for convenience): URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] ; section 3 intro query = *( pchar / "/" / "?" ) ; section 3.4 pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ; section 3.3 Now, since the handling of in 3986 is opaque as long as the syntax above is satisfied, we define or . Or one could get fancy and prohibit "?" and inside the q-component and "?" and inside the r-component. I don't personally recommend fancy -- if the special characters are chosen reasonably, the number of cases where their use following "?" within a string are going to be sufficiently few (and bizarre) that forcing escaping is reasonable and probably even a good idea (more on this below). The above permits q-component or r-component without the other and without creating edge cases. It also permits them to appear in either order if both appear. It (deliberately) has one interesting and useful side-effect: the first "?" in a URN must be followed immediately by either specialChar1 or specialChar2 or it is invalid (independent of namespace). That gets rid of a number of edge cases that have plagued the "?" and "??" model. specialChar1 and specialChar2 should be chosen to minimize the likelihood of collisions with URL queries. I'd guess that most of the characters other than left parentheses, left brackets, and single-quote listed for in 3986 would be reasonable candidates. To the extent to which queries ordinarily take the form ? [SP] phrase ... or ? [SP} keyword = value ... forms like ? are just not going to be an issue. Now, this does mean that 2141bis is going to need to be explicit about how a URN processor whose target is a URL extracts and converts a q-component into the query part of that URL. That rule is essentially that the q-component _is_ the query, but the "?" has to be re-supplied (a requirement if we are going to use the current 2141bis syntax anyway because the question mark is not part of the q-component itself. So nothing really changes. I think that 2141bis will need a paragraph or two to that effect anyway, just to get the level of clarity I think we need. That paragraph would need to specify that, if "?" inside a q-component is followed by the %-encoded form of specialCharX, it needs to decode it in the process of building the query. I'd prefer to do that by requiring that "?" be encoded for that case too, but I don't feel strongly about it. Again, some version of that language would still need to be present for ?%3F and %3F%3F inside q-components for the syntax now used in 2141bis, so this is not an extra problem. In practice, this would give us something that would look like (with one largely arbitrary choice of spacialChar1 and specialChar2): URN:NID:NSS?)q-component?]r-component#f-component Again, with q-component and r-component in whatever order amuses the user until the WG decides to make that choice, which, in this approach, is arbitrary and aesthetic, not technical. For the hypothetical generic URI processor, that string decomposes into scheme = "URN" hier-part = "NID:NSS" query = ")q-component?]r-component" fragment = "f-component" all of which is perfectly valid and straightforward. john From nobody Fri Oct 30 23:16: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 228491B34B2 for ; Fri, 30 Oct 2015 23:16:05 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR6ABfrDQ00B for ; Fri, 30 Oct 2015 23:16:03 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2344C1B34B1 for ; Fri, 30 Oct 2015 23:16:03 -0700 (PDT) Received: from [10.9.40.206] (unknown [104.156.62.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4B26022E200; Sat, 31 Oct 2015 02:15:48 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <56313261.9070804@andyet.net> Date: Sat, 31 Oct 2015 15:15:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: urn@ietf.org Subject: Re: [urn] Think about r-components and q-components differently X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 06:16:05 -0000 Hello: On Oct 29, 2015, at 5:38 AM, Peter Saint-Andre wrote: > On 10/27/15 1:24 PM, John C Klensin wrote: >>=20 >>=20 >> --On Monday, October 26, 2015 18:07 -0800 Melinda Shore >> wrote: >>=20 >>> [=85] I think we have an emergency. [=85] block going ahead with = r-then-q. >>=20 >> Melinda, >>=20 >> I hope to catch up in the recent flurry of messages >=20 > Sorry about that - I seem to be processing IETF work in batch mode. >=20 >> within the >> next day or three but, unfortunately, tried to reserve time to >> review a complete -14 posted some time ago and then immediately >> before the deadline and therefore have not had time to parse >> these messages. However, with the understanding that there >> could be something in the message threads that would cause a >> revelation and result in a change of mind... >>=20 >> I continue to think that r-then-q is a bad idea. I won't repeat >> the reasons, which I have explained at length. >=20 > For other folks here, the primary message seems to be: >=20 > http://www.ietf.org/mail-archive/web/urn/current/msg03025.html >=20 > And, secondarily: >=20 > http://www.ietf.org/mail-archive/web/urn/current/msg03120.html >=20 >> I also believe >> that any argument that hinges on whether something is more >> likely to be done by left to right or top-down parsing or >> regular expression matching is probably a sign that we've got >> the basic design idea wrong and should be looking for other >> alternatives. >> [=85] >> (2) I won't try to insist but I think it would be wise to >> include a strong warning in the text about embedded "?" >> characters inside the r-component and q-component strings and >> about decoding implications of embedded %3F if the intention is >> to embed a substring of the URN to some other processor (e.g., >> in a URL) and whether such a escape should be decoded before >> embedding. If r-component comes first, that also implies a >> warning about the use of embedded "??=94. The syntax must be >> clear enough that any such construction has one and only one >> interpretation, [=85] A very simple proposal: Remove the q-component. Seriously. At this point, URNBIS draft punts on what the q-component = means=85it basically just says that the q-component should be passed = along and tacked on to the resolved URLs (URI) as-is. How is that going to work if the resolver returns data: URLs (yes, they = are =93URLs=94, see RFC 2397)? How about if the resolver returns mid: = URIs? What about ldap: URIs? What about magnet: URIs? a mixture of all = of those? The syntax and semantics of q-components in these different = URIs are markedly different. The r-component makes a lot of sense. Have the resolver translate the = URN to other URIs (URLs, whatever). Note that the resolver can always = return a data: URL (URI) so this whole worry about returning resources = or resources to resources or pointers to resources to resources or what = have you seems to be moot. Trying to =93force=94 the resolver to = interpret the semantics of the r-component, but pass the q-component = along, does not strike me as workable. Thanks, Sean PS LDAP URIs can contain ?? or more in succession--that has a specific = meaning. Something to think about. [RFC4516]= From nobody Sat Oct 31 09:01:29 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 17D331A6FF8 for ; Sat, 31 Oct 2015 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] 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 Bxkati5hicoX for ; Sat, 31 Oct 2015 09:01:25 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740731A6FF5 for ; Sat, 31 Oct 2015 09:01:25 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZsYan-000IGF-WD; Sat, 31 Oct 2015 12:01:22 -0400 Date: Sat, 31 Oct 2015 12:01:25 -0400 From: John C Klensin To: Sean Leonard , Peter Saint-Andre Message-ID: In-Reply-To: References: <56033432.3040506@seantek.com> <562EDA31.9080203@andyet.net> <562EDC4D.3010400@gmail.com> <7197FB05E8A76DDCC76E200D@JcK-HP8200.jck.com> <56313261.9070804@andyet.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Cc: urn@ietf.org Subject: [urn] discard q-component (was: Re: Think about r-components and q-components differently) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 16:01:27 -0000 Sean, I think we are at risk of going around in circles... again. I'll leave it in the co-chair's hands what, if anything, to do about that, but suggest that, each time it happens, various people get demoralized and, even if they later come back, work grinds to a halt for an extended period. Specifics below. --On Saturday, October 31, 2015 3:15 PM +0900 Sean Leonard wrote: >... > A very simple proposal: >=20 > Remove the q-component. > Seriously. At this point, URNBIS draft punts on what the > q-component means=E2=80=A6it basically just says that the > q-component should be passed along and tacked on to the > resolved URLs (URI) as-is. I don't think "as-is" completely and unambiguously works (see prior note), but it feels to me as if we have had endless discussions about why something like a q-component is important and necessary for some significant applications (some of which do not involve mapping from URN to URL). If 2141bis is not clear enough about that, suggest text or at least what should be fixed and where (see below) > How is that going to work if the resolver returns data: URLs > (yes, they are "URLs", see RFC 2397)? How about if the > resolver returns mid: URIs? What about ldap: URIs? What about > magnet: URIs? a mixture of all of those? The syntax and > semantics of q-components in these different URIs are markedly > different. We have got all kinds of situations in which "resolving" a URN means different things (or nothing or nonsense) depending on the namespace. Mapping to some other flavor of URI is just one of the cases [1]. And certainly we've reached the conclusion several times that, no matter what the original intent (with or without a well-developed URC infrastructure), it is not, today, a requirement of the "urn:" scheme that all such URNs resolve to URLs (or even URCs). The generic answer to your questions about is "If anyone defines a namespace whose URN resolves to one of those schemes, it will get nonsense. An implementation of those schemes had better be as ready to defend against that as it would defend against any other nonsense". > The r-component makes a lot of sense. Have the resolver > translate the URN to other URIs (URLs, whatever). Note that > the resolver can always return a data: URL (URI) so this whole > worry about returning resources or resources to resources or > pointers to resources to resources or what have you seems to > be moot. Trying to "force" the resolver to interpret the > semantics of the r-component, but pass the q-component along, > does not strike me as workable. That is more or less where we started. My impression is that the WG concluded, rather strongly, that it was important to distinguish between instructions/requests to the resolver and instructions/requests about the object if there was one and to do so with syntax that applied to all URNs (although whether the syntax was useful/usable or not would be per-namespace). Like you, I'm not sure that, in some hypothetical general case, the distinction is always that clear. But, fwiw, I'm not convinced that going over that question again would be of any benefit. > PS LDAP URIs can contain ?? or more in succession--that has a > specific meaning. Something to think about. [RFC4516] My guess is that, if we look at the whole space of URI schemes that are documented and/or in use, we will find almost every syntax trick imaginable. I do think that a known specialized use of "??" strengthens the case for ? where both q- and r-components have those delimiters and neither is "?" or for nesting q- and r-component within what 3986 thinks of a . We also need to do a further clarity check on 2141bis in this area and probably change "as-in" to an explicit mapping, especially given the potential for interactions of IRIs [2]. >From my perspective, the problem goes back to 3986 and, in some cases, its predecessors: a lot of characters are given special interpretations, others are given special interpretations only in specific syntactic contexts, and still other are or are not delimiters based on the scheme. In addition, a lot of the language and assumptions are based on URLs that map to locations or objects but not to other, non-embedded URIs. As I have said before, I now believe, in retrospect, that it was a mistake to create a "URI"-thing rather than creating URLs, generic (not just one scheme) URNs, and maybe URCs that are distinguishable by basic syntax, with separate grammars for each. But that horse left the barn before RFC 1737 was published and, if there was any possibility of retrieving it, that window closed years ago. =20 I think we are at a fork in the virtual road. On one path, we just figure out how to make separate q- and r-components work, making sure that 2141bis contains appropriate qualifying language. On the other, we take a more extreme version of Keith's "URNA" proposal, depreciate URNs as having gotten just much too confused and now representing a bad combination of incompatible concepts, and then start efforts to define a new set of typologies for generic name-type things that may or may not define or point to resources. Or we can stand in the road, looking at the fork, and either jumping from one foot to the other or running in small circles until some truck comes along and puts an end to the discussion. =20 As a specific example of a truck-instance, suppose the ART ADs, sometime between now and IETF 95, come to the WG Co-chairs and say "given the WG's record of setting schedules and missing them and the observation that you are having some of the same debates now that you were having three or four years ago (remember the WG was created in the last quarter of 2010), is there any plausible reason to expect that it will converge and produce consensus results any time soon, because, if not, we are going to shut you down". If you were one of the co-chairs, how would you answer? best, john [1] Given language in 2396 and 3986 that essentially says that some of what had been called URLs are now URIs, it is hard for me to make strong inferences about what something is or is not from the use of the term "URL" in various contexts. [2] IRIs may be another example of the overreaching to has gotten us into trouble... it is likely that they should be called "IRLs" and that the internationalized analogy to URNs ("IRN"s?), if there is one, should be subject to different rules, especially for the cases in which they are expected to map into URLs.