From lisa.dusseault@gmail.com Mon Nov 2 12:17:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AA928C12C for ; Mon, 2 Nov 2009 12:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii1rohvW64Hy for ; Mon, 2 Nov 2009 12:17:56 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 8EBC828C122 for ; Mon, 2 Nov 2009 12:17:56 -0800 (PST) Received: by vws31 with SMTP id 31so1536523vws.29 for ; Mon, 02 Nov 2009 12:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hDjgNQ8trhri0Yh2g2ct4OXOtFkZKMoBx+FaL/QMO4s=; b=gMr+MKAmtUGxW6z/bwjrLgN2dAK4Qj49pVyWdhqJSrhCWWqIoyJGJc8yS2IFvnwg2u KDsrA9ru+4o6w+jtaaZ2jsjXBLOA75MuzQgfOfqinl/kQIF3sF5FhgSv/QXGyCzMCP1A ikUeqS7lwxN79Bu+YDKVTYDENjIOmC/CnGOVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UMlLCwty7gMdDcdpNZgWV16PBai0key19nQ5MFKGgQaF6fMT84D3h0tubG4RHBddKg wM8Jqzji0iniP+s57bt+YfvVpBYvkzQqLccUvgo+1ek96eqWMB4nbZTD8A5ghHWiXhk3 svRdljl3CzhASmjARz7Yon8zc/QEGYVajT++Y= MIME-Version: 1.0 Received: by 10.220.125.5 with SMTP id w5mr5655965vcr.30.1257193096523; Mon, 02 Nov 2009 12:18:16 -0800 (PST) Date: Mon, 2 Nov 2009 12:18:16 -0800 Message-ID: Subject: Lisa's Apps Area Activity Report for Oct 2009 From: Lisa Dusseault To: "Lisa Dusseault's Chairs" , Apps Discuss Content-Type: multipart/alternative; boundary=001636d34df3eeafb70477691343 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:17:57 -0000 --001636d34df3eeafb70477691343 Content-Type: text/plain; charset=ISO-8859-1 *News, Updates* APPAREA (monday morning) agenda still in progress Overall IETF agenda; https://datatracker.ietf.org/meeting/76/agenda.html *Document Status and Progress* *Active documents, my action:* - draft-ietf-idnabis-bidi (PS): Handling Last Call feedback - draft-ietf-idnabis-protocol (PS): Handling Last Call feedback - draft-ietf-idnabis-defs (PS): Handling Last Call feedback - draft-ietf-idnabis-tables (PS): Handling Last Call feedback - draft-ietf-idnabis-rationale (Info): Handling Last Call feedback - draft-ietf-idnabis-mappings (Info): Handling Last Call feedback - draft-freed-sieve-in-xml (PS): Trying to clear last DISCUSS - draft-larmouth-oid-uri (PS): Need to do AD Review - draft-giralt-schac-ns (Info): Need to get expert review from namespace experts *Active documents, waiting on other:* - draft-morg-status-in-list (PS): In Lat Call - draft-melnikov-imap-keywords (PS): In Last Call - draft-hammer-oauth (Info): In Last Call - draft-nottingham-site-meta (PS): In Last Call - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-nottingham-http-link-header (PS): Waiting for revision from authors Finished processing -- new in RFC Ed queue and new RFCs - draft-ietf-sieve-mime-loop (PS) - draft-ietf-calsify-2446bis (PS): - draft-wilde-sms-uri (PS): Just approved -- should go into RFC Ed queue shortly - RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement - RFC5703: Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure *WG Status* ALTO: Some light discussions in the last month. CALSIFY: Not much discussion while RFC2446 completes publication. HTTPBIS: New drafts out and closing issues. IDNABIS: IETF Last Call completed with significant feedback. OAUTH: Light discussion. SIEVE: Light discussion of mostly completed docs. --001636d34df3eeafb70477691343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
APPAREA (monday morning) agenda still in progressOverall IETF agenda; https://datatracker.ietf.org/meeting/76/agend= a.html

Document Status and Progress
Active documents, my action:<= br>- draft-ietf-idnabis-bidi (PS): Handling Last Call feedback
- draft-i= etf-idnabis-protocol (PS): Handling Last Call feedback
- draft-ietf-idna= bis-defs (PS): Handling Last Call feedback
- draft-ietf-idnabis-tables (PS): Handling Last Call feedback
- draft-ie= tf-idnabis-rationale (Info): Handling Last Call feedback
- draft-ietf-id= nabis-mappings (Info): Handling Last Call feedback
- draft-freed-sieve-i= n-xml (PS): Trying to clear last DISCUSS
- draft-larmouth-oid-uri (PS): Need to do AD Review
- draft-giralt-schac= -ns (Info): Need to get expert review from namespace experts


= Active documents, waiting on other:
- draft-morg-status-in-list (PS)= : In Lat Call
- draft-melnikov-imap-keywords (PS): In Last Call
- draft-hammer-oauth (= Info): In Last Call
- draft-nottingham-site-meta (PS): In Last Call
-= draft-montemurro-gsma-imei-urn (Exp): New version of draft expected
- draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and= writeup
- draft-nottingham-http-link-header (PS): Waiting for revision = from authors

Finished processing -- new in RFC Ed queue and new RFCs=
- draft-ietf-sieve-mime-loop (PS)
- draft-ietf-calsify-2446bis (PS): - draft-wilde-sms-uri (PS): Just approved -- should go into RFC Ed queue s= hortly
=A0- RFC5693: Application-Layer Traffic Optimization (ALTO) Probl= em Statement
=A0- RFC5703: Sieve Email Filtering: MIME Part Tests, Iteration, Extraction= ,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Replacement, and E= nclosure


WG Status

ALTO: Some light discussions in the last month.=
CALSIFY: Not much discussion while RFC2446 completes publication.
HT= TPBIS: New drafts out and closing issues.
IDNABIS: =A0IETF Last Call completed with significant feedback.
OAUTH: L= ight discussion.
SIEVE:=A0 Light discussion of mostly completed docs.

--001636d34df3eeafb70477691343-- From eran@hueniverse.com Fri Nov 6 13:43:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BEA73A67B0 for ; Fri, 6 Nov 2009 13:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK0-AGPJfNHI for ; Fri, 6 Nov 2009 13:43:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 961DE3A67AF for ; Fri, 6 Nov 2009 13:43:56 -0800 (PST) Received: (qmail 32304 invoked from network); 6 Nov 2009 21:44:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 21:44:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 6 Nov 2009 14:44:19 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Fri, 6 Nov 2009 14:44:17 -0700 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMAADvFXsAIIDq7w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 21:43:57 -0000 VGhpcyBzdWJqZWN0IHdhcyBkaXNjdXNzZWQgYXQgbGVuZ3RoIHRoaXMgd2VlayBhdCBJSVcuIFRo ZSBzdHJvbmcgY29uc2Vuc3VzIHdhcyB0aGF0IHNpbmNlIHRoZSBjdXJyZW50bHkgcHJvcG9zZWQg dGVtcGxhdGUgdm9jYWJ1bGFyeSBpc24ndCBleHByZXNzaXZlIGVub3VnaCwgaXQgc2hvdWxkIGJl IG1hZGUgZXZlbiBsZXNzIGV4cHJlc3NpdmUgKG9ubHkgZGVmaW5lICd1cmknKSBhbmQgbm90IG1v cmUgZXhwcmVzc2l2ZSAoc2VlIG9uZSBwcm9wb3NhbCBiZWxvdykuIFRoZSBtYWluIGFyZ3VtZW50 IHdlcmU6DQoNCi0gQSBmdXR1cmUgKHJpY2hlcikgdGVtcGxhdGUgc3ludGF4IHdpbGwgYWRkcmVz cyBlbXB0eSB2YXJpYWJsZXMgYW5kIHRoZSBwcm9wZXIgYXNzZW1ibGluZyBvZiBVUkkgY29tcG9u ZW50cyB0b2dldGhlci4gV2hlbiBpdCBiZWNvbWVzIGF2YWlsYWJsZSwgaG9zdC1tZXRhIGNvdWxk IGJlIHVwZGF0ZWQgdG8gZGVmaW5lIHRoZSBmdWxsIHNldCBvZiB2YXJpYWJsZXMgdG8gc3VwcG9y dCBzdWNoIGNvbW1vbiB0cmFuc2Zvcm1hdGlvbnMuDQoNCi0gQW55IHZvY2FidWxhcnkgYnJlYWtp bmcgdGhlIGNvbnRleHQgVVJJIGludG8gcGFydHMgd2lsbCBuZWVkIGEgY29tcGxpbWVudGFyeSBt ZXRob2QgZm9yIGFwcGx5aW5nIGxpbmtzIHRvIHJlc291cmNlIHN1YnNldHMgKGF0IGxlYXN0IGJh c2VkIG9uIHRoZSBVUkkgc2NoZW1lKS4gRm9yIGV4YW1wbGUsIGl0IGlzIG5vdCBsaWtlbHkgdGhh dCBhIHNpbmdsZSB0ZW1wbGF0ZSAodXNpbmcgdmFyaWFibGVzIG90aGVyIHRoYW4gJ3VyaScpIHdp bGwgYmUgYWJsZSB0byBwcm9wZXJseSBhZGRyZXNzIGJvdGggJ2h0dHAnIGFuZCAneG1wcCcgVVJJ IHRyYW5zZm9ybWF0aW9uLg0KDQpUaGUgc2Vjb25kIHBvaW50IGlzIHRoZSBtb3N0IGltcG9ydGFu dCBpbiBteSB2aWV3IHNpbmNlIGl0IHJlcXVpcmVzIGV4dGVuZGluZyB0aGUgcHJvcG9zZWQgZG9j dW1lbnQgZm9ybWF0IHRvIGRpcmVjdGx5IHN1cHBvcnQgZGVzY3JpYmluZyBzdWJzZXRzIG9mIHJl c291cmNlcy4gSSBhbSBtb3JlIGluY2xpbmVkIHRvIHJlZHVjZSB0aGUgdm9jYWJ1bGFyeSB0byBh IHNpbmdsZSAndXJpJyB2YXJpYWJsZSB0aGFuIGV4dGVuZCBib3RoIHRoZSB2b2NhYnVsYXJ5IGFu ZCBzY2hlbWEgdG8gc3VwcG9ydCByaWNoZXIgc2NoZW1lIG9yIHBhdHRlcm4gc3BlY2lmaWMgdHJh bnNmb3JtYXRpb24uDQoNClNpbmNlIGhvc3QtbWV0YSBhbGxvd3MgcHJvdG9jb2xzIHRvIGRlZmlu ZSB0aGVpciBvd24gJ3JlbCctc3BlY2lmaWMgdGVtcGxhdGUgc3ludGF4IGFuZCB2b2NhYnVsYXJ5 LCBpbmRpdmlkdWFsIHByb3RvY29scyB3aXRoIHN1Y2ggbmVlZHMgd2lsbCBzdGlsbCBiZSBhYmxl IHRvIG1ha2UgdXNlIG9mIHRoZSBmcmFtZXdvcmsuIEluIGFkZGl0aW9uLCBzZXJ2ZXJzIGNhbiBh bHdheXMgdXNlIGEgc2ltcGxlIHJlZGlyZWN0aW9uIHNjcmlwdCB0byByZWRpcmVjdCBhIGNsaWVu dCB0byBhIG1vcmUgY29tcGxleCBsb2NhdGlvbiB0aGFuIHByb3ZpZGVkIGJ5IGEgc2luZ2xlICd1 cmknIHZhcmlhYmxlLg0KDQpDb21tZW50cz8NCg0KRUhMDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmFwcHMtZGlzY3Vzcy0NCj4gYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwg SmFtZXMgSA0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI3LCAyMDA5IDM6NTIgUE0NCj4gVG86 IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogaG9zdC1tZXRhOiB0ZW1wbGF0 ZSBzeW50YXggaGFzc2xlcw0KPiANCj4gT25lIHNvbHV0aW9uIChmb3Igc2ltcGxlLCBidXQgY29y cmVjdCwgVVJJIHRlbXBsYXRlcyBmb3IgY29tbW9uDQo+IHNpdHVhdGlvbnMgaW4gaG9zdC1tZXRh KSBpcyB0byBkZWZpbmUgbW9yZSB2YXJpYWJsZXMuDQo+IA0KPiBGb3IgaW5zdGFuY2UsIGluIGFk ZGl0aW9uIHRvICdzY2hlbWUnLCAnYXV0aG9yaXR5JywgJ3BhdGgnLCAncXVlcnknLi4uDQo+IG9m ZmVyIHRoZSBmb2xsb3dpbmcgdmFyaWFibGVzOg0KPg0KPiAndG9EaXInIOKAlCB0aGUgVVJJIHVw IHRvLCBidXQgZXhjbHVkaW5nLCB0aGUgbGFzdCAnLycgaW4gdGhlIHBhdGgNCj4gJ2FmdGVyRGly JyDigJQgdGhlIFVSSSBmcm9tIHRoZSBsYXN0IHNlZ21lbnQgb2YgdGhlIHBhdGggdG8gdGhlIGVu ZCwgZXhjbHVkaW5nIHRoZSBmcmFnbWVudA0KPiAndG9FeHQnIOKAlCB0aGUgVVJJIHVwIHRvLCBi dXQgZXhjbHVkaW5nLCB0aGUgbGFzdCAnLicgaW4gdGhlIGxhc3Qgc2VnbWVudCBvZiB0aGUgcGF0 aCAob3IgdG8gdGhlIGVuZCBvZiB0aGUgcGF0aCBpZiB0aGVyZSBpcyBubyBzdWNoIGRvdCkNCj4g J3RvUGF0aCcg4oCUIHRoZSBVUkkgdXAgdG8gdGhlIGVuZCBvZiB0aGUgcGF0aA0KPiAnYWZ0ZXJQ YXRoJyDigJQgdGhlIFVSSSBmcm9tIGFmdGVyIHRoZSBwYXRoIHRvIHRoZSBlbmQsIGV4Y2x1ZGlu ZyB0aGUgZnJhZ21lbnQNCj4gJ3RvUXVlcnlQbHVzJyDigJQgdGhlIFVSSSBleGNsdWRpbmcgYW55 IGZyYWdtZW50LCBmb2xsb3dlZCBieSAnJicgaWYgdGhlcmUgaXMgYSBxdWVyeSBzdHJpbmcgb3Ig Jz8nIG90aGVyd2lzZSAoaWUgcmVhZHkgZm9yIGEgbmV3IHF1ZXJ5IHBhcmFtZXRlciB0byBiZSBh cHBlbmRlZCkNCj4gJ2JlZm9yZUhvc3QnIOKAlCB0aGUgVVJJIHVwIHRvLCBidXQgZXhjbHVkaW5n LCB0aGUgaG9zdA0KPiAnZnJvbUhvc3QnIOKAlCB0aGUgVVJJIGZyb20gdGhlIGhvc3QgdG8gdGhl IGVuZCwgZXhjbHVkaW5nIHRoZSBmcmFnbWVudA0KPiANCj4gVGVtcGxhdGUgZXhhbXBsZXM6DQo+ IHsrdG9FeHR9LnhyZHsrYWZ0ZXJQYXRofSDigJQgcmVwbGFjZSwgc2F5LCAuaHRtbCBleHRlbnNp b24gd2l0aCAueHJkIHRvIGdldCBtZXRhZGF0YQ0KPiB7K3RvUXVlcnlQbHVzfV89bWV0YSDigJQg YWRkIGEgcXVlcnkgcGFyYW1ldGVyIG5hbWVkIOKAnF/igJ0gd2l0aCBhIHZhbHVlIOKAnG1ldGHi gJ0gdG8gZ2V0IG1ldGFkYXRhDQo+IHsrdG9EaXJ9Ly5tZXRhL3srYWZ0ZXJEaXJ9IOKAlCBtZXRh ZGF0YSBpcyBpbiBhIHNwZWNpYWwgLm1ldGEvIHN1YmRpcmVjdG9yeSBvZiBlYWNoIGRpcmVjdG9y eQ0KPiB7K3RvUGF0aH07bWV0YXsrYWZ0ZXJQYXRofSDigJQgYXBwZW5kIOKAnDttZXRh4oCdIHRv IHRoZSBwYXRoIHRvIGdldCB0aGUgbWV0YWRhdGENCj4geytiZWZvcmVIb3N0fW1ldGEueytmcm9t SG9zdH0g4oCUbWV0YWRhdGEgaXMgaG9zdGVkIG9uIGEgc3ViLWRvbWFpbg0KPiANCj4gVGhlIHRv L2FmdGVyIChhbmQgYmVmb3JlL2Zyb20pIHBhaXJzIGJhc2ljYWxseSBvZmZlciBlYXN5IGFjY2Vz cyB0bw0KPiBkaWZmZXJlbnQgcG9pbnRzIGluIHRoZSBVUkkgdG8gaW5zZXJ0IGEgbmV3IGVsZW1l bnQuIEkgdGhpbmsgdGhlc2UNCj4gZXhhbXBsZXMgYXJlIGZhaXJseSBzaW1wbGUgd2F5cyB0byBp bXBsZW1lbnQgY29tbW9uIFVSSSBtYW5pcHVsYXRpb25zDQo+IHNhZmVseS4NCj4gDQo+IEphbWVz IE1hbmdlcg0KPiBKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tDQo+IElkZW50aXR5IGFu ZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0K DQo= From bil@corry.biz Fri Nov 6 19:39:59 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCE53A6886 for ; Fri, 6 Nov 2009 19:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74BniE2igiRL for ; Fri, 6 Nov 2009 19:39:59 -0800 (PST) Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 1F1443A6835 for ; Fri, 6 Nov 2009 19:39:58 -0800 (PST) Received: from [127.0.0.1] (adsl-71-141-241-26.dsl.snfc21.pacbell.net [71.141.241.26]) by mail.mindio.com (Postfix) with ESMTP id 590AAFC4E7; Fri, 6 Nov 2009 21:40:20 -0600 (CST) Message-ID: <4AF4EC1D.8010601@corry.biz> Date: Fri, 06 Nov 2009 19:40:13 -0800 From: Bil Corry User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard References: <92D713CF-28C5-4CCB-8803-A03CDCDED61B@cs.cmu.edu> <90C41DD21FB7C64BB94121FBBC2E72343784ECE4CB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECE4CB@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 03:39:59 -0000 Eran Hammer-Lahav wrote on 10/13/2009 6:53 PM: > I think it would be premature to define this before we have a few > items in the registry and see how it is used. FWIW, I brought up /.well-known/ for Mozilla's 'autoconfig' feature that is currently being developed: http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/18be26ee250a53b5 If they decide to implement /.well-known/, that's one way in which it'll be used. - Bil From alexey.melnikov@isode.com Sat Nov 7 18:06:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052113A68F9 for ; Sat, 7 Nov 2009 18:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25IXSPeiTZXA for ; Sat, 7 Nov 2009 18:06:35 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 347943A6767 for ; Sat, 7 Nov 2009 18:06:35 -0800 (PST) Received: from [133.93.16.183] (host-16-183.meeting.ietf.org [133.93.16.183]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 8 Nov 2009 02:06:58 +0000 Message-ID: <4AF627C5.50300@isode.com> Date: Sun, 08 Nov 2009 02:07:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: "apps-discuss@ietf.org" Subject: Updated Apps Area agenda for tomorrow MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 02:06:36 -0000 Here is the current list of topics I have so far: 1) Dan Wing: short announcement of GROBJ BOF (10 mins) 2) Dan Wing : Building IPv6 Applications which Access IPv4 Servers (draft-wing-v6ops-v6app-v4server-01.txt) - 15 mins 3) Peter Saint-Andre : Apps Review Team - 5 mins 4) Peter Saint-Andre : TLS server identity checks in application protocols (draft-saintandre-tls-server-id-check) - 20 mins [with discussions] 5) Magnus Westerlund : IANA ports and service names registry - 20 mins [with discussions] 6) John C Klensin : FTP commands and extensions registry - 15 mins 7) Spencer Dawkins : Subscription/Notification for Lightweight Directory Access Protocol (LDAP) (draft-dawkins-ldapext-subnot-01.txt) - 20 mins 45 mins for the remaining of the session: 8) Short presentations about other Apps BOFs 9) Open mic From lear@cisco.com Sun Nov 8 05:07:42 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0813A6995 for ; Sun, 8 Nov 2009 05:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY8hA8Y0-+G3 for ; Sun, 8 Nov 2009 05:07:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 93F823A6973 for ; Sun, 8 Nov 2009 05:07:41 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtICALpR9kqQ/uCWgWdsb2JhbACEcZcDAQEWJKVjhxWPUYEygjhUBA X-IronPort-AV: E=Sophos;i="4.44,703,1249257600"; d="scan'208";a="53896381" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2009 13:08:05 +0000 Received: from ams3-vpn-dhcp3083.cisco.com (ams3-vpn-dhcp3083.cisco.com [10.61.76.11]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA8D85sd027566 for ; Sun, 8 Nov 2009 13:08:05 GMT Message-ID: <4AF6C2B5.3040301@cisco.com> Date: Sun, 08 Nov 2009 14:08:05 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091103 Shredder/3.0pre MIME-Version: 1.0 To: Apps Discuss Subject: quick update on calsify X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 13:07:42 -0000 Lisa, Alexey, all, Since I won't be in Hiroshima, I thought I would give you and this group a brief update on where things are with Calsify. Although it has taken us a bit longer than anticipated, we have gotten an update to RFC 2445 out the door. That is RFC-5545. We now anticipate smooth sailing for draft-ietf-calsify-2446bis, which Cyrus has completed. Next up is draft-ietf-calsify-rfc2447bis, which is just about ready for WGLC. What is holding it up right now is me, as I want to check all of the examples, and provide some additional Security Considerations text. In the meantime, I ask that people take a good look at the document and provide the author or the Calsify working group comments. After this document is published, the chair (I) will engage in a discussion first with the ADs and then with the broader community over what if anything should happen next in Calsify. Thanks to the authors, Bernard, Cyrus, and Alexey, for their work, and for the chairs' and community's patience in getting these updates done. Eliot From anthonybryan@gmail.com Sun Nov 8 08:57:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C513A69BC for ; Sun, 8 Nov 2009 08:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=-3.225, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWpO7GDQPZY8 for ; Sun, 8 Nov 2009 08:57:53 -0800 (PST) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 4C9643A68B4 for ; Sun, 8 Nov 2009 08:57:53 -0800 (PST) Received: by iwn32 with SMTP id 32so1906784iwn.23 for ; Sun, 08 Nov 2009 08:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lzyP4cu1cvLrlyCVMS2QuHL76uYP8LK5bjLXnewTnss=; b=odqxwInOvqT5LioacmlZ+KxoSqKjiYahWFdT3bWXvFGmK0ZgTNloY5/RKA7Ijo+G3F EHdFRCHZy7dS7rZNcaJ0aPBGEdftrZ9diQQZRUuSxIdXhrABA0w6dyRcIoIBZzHKpgp5 m+dZo2Px0y4iUNpSN94bD+v6aPyr63dW2R+ZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RCIetUfG4EXeNhYlJCe6keQEVnKxJsLEZmNub7Q07605K9/e/xDv7vEpGqTekJtQWL q9OHBkD/+0Jgqc9Cz2uATElf6F6qikSPIMTEtSsjzJLLMXwvA/KEDfeGkf37VEzkq+vh DUB48r2W7X44kZTnkFaof3aJMesj320ciLVd0= MIME-Version: 1.0 Received: by 10.231.20.230 with SMTP id g38mr5248403ibb.49.1257699496079; Sun, 08 Nov 2009 08:58:16 -0800 (PST) Date: Sun, 8 Nov 2009 11:58:16 -0500 Message-ID: Subject: quick update on metalink From: Anthony Bryan To: general discussion of application-layer protocols Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 16:57:54 -0000 Lisa, Alexey, and everyone else, None of the metalink authors will be in Hiroshima (although some of us are trying to make Anaheim in March). We think draft-bryan-metalink is ready for last call. We have another revision waiting to submit that incorporates suggestions from Mark Baker via apps-review & PSA. Currently, 4 apps support this with more on the way. draft-bryan-metalinkhttp is a work in progress, specification wise, but functionality wise appears relatively stable. Most reception has been positive, at least of the ideas inside. We have a revision with Micah Cowan's (wget) suggestions waiting to submit. This draft is complementary to metalink (XML), not seen as competition or replacement, and can be used in less situations. Only 2 apps support it and we have lots of testing ahead of us. draft-bryan-http-digest-algorithm-values-update, "Additional Hash Algorithms for HTTP Instance Digests" is the update to the Instance Digests registry. This draft is rather short and simple. I think it is basically done, but welcome all comments of course. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From lars.eggert@nokia.com Sun Nov 8 18:21:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CB03A68DB; Sun, 8 Nov 2009 18:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juCdXTy1l0t8; Sun, 8 Nov 2009 18:21:14 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id EBC4B3A6405; Sun, 8 Nov 2009 18:21:13 -0800 (PST) Received: from [IPv6:2001:dfb::24:225:ff:fe45:eccf] ([IPv6:2001:dfb:0:24:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA92LOiS007916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Nov 2009 04:21:28 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Content-Type: multipart/signed; boundary=Apple-Mail-105-253204176; protocol="application/pkcs7-signature"; micalg=sha1 Subject: service names - one registry vs. two registries Date: Mon, 9 Nov 2009 11:21:18 +0900 Message-Id: To: Apps Discuss , tsvwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 09 Nov 2009 04:21:30 +0200 (EET) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:21:15 -0000 --Apple-Mail-105-253204176 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, as just briefly discussed in the APP area meeting after Joe's presentation, we need to come to some community consensus on what to do with service name registrations. draft-ietf-tsvwg-iana-ports has been written with the intent to unify the three(*) current places where service names can be registered, making the ports and service names registry the one-stop shop for ports and service names. All service names (~10K?) registered in one of the current three places would be grandfathered in. draft-gudmundsson-dns-srv-iana-registry advocates a creating new standalone registry for service names that are to be used with DNS SRV RRs (exclusively, in my reading) and seed it with only those 40 service names that are specifically called out in published RFCs. There is no discussion on how the new registry relates to the three(*) existing places where service names have currently been registered. (Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you should read the two documents to form your own opinion on the different proposals.) So far, the discussion has mostly seen arguments from the proponents of both approaches. It would be useful to hear from the broader community on which general approach is preferable. Lars (*) http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/service-names http://www.dns-sd.org/ServiceTypes.html --Apple-Mail-105-253204176 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwOTAyMjExOFowIwYJKoZIhvcNAQkEMRYEFGKX+qHV+P0jgZeUNcb5998c7C6nMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDJUFCcO4Bxu6sdWMm3fjMXhBjZsUavsU1Wumyw86hvkrD+pHjEVs4VPY8+dcPIHA89H8lS WxHDu/OXfu1rU/eX0Ls4evCNqYDlmLKKS23Mp6k+oDz4bvDXzUnFYlDIADq0aAHBW5sRfDikNhM+ SbrozLz6IFoHLDCc1W3DRqw5Jl/7NnBsMtkrpecYVjYiGSyv/AXb95aT3PU7+3HDQjLThNtAN2is ofjH4/Deo7f4kjhTeZKfo9bWRFRtxnnI8mVvcF6ysceVd9iiaY9fNssmychuQoWd/QlMbWJqcOip /32GK63PxAY2AKyHVGoLcPyFbOp7gdweuzbATwVqlONhAAAAAAAA --Apple-Mail-105-253204176-- From James.H.Manger@team.telstra.com Sun Nov 8 18:26:47 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443CC3A6911 for ; Sun, 8 Nov 2009 18:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhTbJmYyexpS for ; Sun, 8 Nov 2009 18:26:46 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 3C2463A6405 for ; Sun, 8 Nov 2009 18:26:45 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 09 Nov 2009 13:27:11 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 0AA8EFF81; Mon, 9 Nov 2009 13:27:11 +1100 (EST) Received: from WSMSG3752.srv.dir.telstra.com (wsmsg3752.srv.dir.telstra.com [172.49.40.173]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 7E94D41DA2; Mon, 9 Nov 2009 13:26:51 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 9 Nov 2009 13:27:08 +1100 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Mon, 9 Nov 2009 13:27:06 +1100 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMAADvFXsAIIDq7wAGsvmZA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112488D2CB1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:26:47 -0000 PiB0aGUgY3VycmVudGx5IHByb3Bvc2VkIHRlbXBsYXRlIHZvY2FidWxhcnkuLg0KPiBzaG91bGQg YmUgbWFkZSBldmVuIGxlc3MgZXhwcmVzc2l2ZSAob25seSBkZWZpbmUgJ3VyaScpDQoNCkkgKHNv bWV3aGF0IHJlbHVjdGFudGx5KSBhZ3JlZSwgYXMgbG9uZyBhcyB0aGUgJysnIG9wZXJhdG9yIChk b24ndCAlLWVzY2FwZSByZXNlcnZlZCBjaGFycykgaXMgcmVtb3ZlZCBhcyB3ZWxsLg0KDQpBIGRl Y2VudCBhaW0gaXMgdG8gc3VwcG9ydCBqdXN0IHRoZSBzaW1wbGVzdCBjYXNlIG5vdyAoZWcgPFVS SVRlbXBsYXRlPmh0dHA6Ly9leGFtcGxlLmNvbS9tZXRhP3U9e3VyaX08L1VSSVRlbXBsYXRlPiks IGFuZCB0cnkgdG8gYmUgY29tcGF0aWJsZSB3aXRoIGEgZnV0dXJlIGZ1bGx5LWRldmVsb3BlZCBV UkkgdGVtcGxhdGUgc3BlYy4gVGhlIGJlaGF2aW91ciB3aXRoIHVucmVjb2duaXNlZCB2YXJpYWJs ZXMsIGFuZCB1bmV4cGVjdGVkIHN5bnRheCBpcyBtb3JlIGltcG9ydGFudCB0aGFuIHRoZSBsaXN0 IG9mIHZhcmlhYmxlcyBkZWZpbmVkLg0KDQpUaGUgJysnIG9wZXJhdG9yIHNob3VsZCBOT1QgYmUg ZGVmaW5lZCBpbiBob3N0bWV0YSAoaWYgdGhlIG9ubHkgdmFyaWFibGUgaXMgJ3VyaScpLiBJdCBp cyBub3QgbmVjZXNzYXJ5IGZvciB0aGUgc2ltcGxlc3QgY2FzZS4gSSBkb24ndCB0aGluayBpdCBj YW4gYmUgdXNlZCBzYWZlbHkgd2l0aCB0aGUgJ3VyaScgdmFyaWFibGUuIEEgdGVtcGxhdGUgbGlr ZSAieyt1cml9O2J5IiBhbG1vc3QgbG9va3Mgc2Vuc2libGUsIGJ1dCBpdCBpc24ndC4gVGhlICI7 YnkiIHN1ZmZpeCBtYXkgYmUgYXBwZW5kZWQgdG8gdGhlIHBhdGggKGlmIHRoZXJlIGFyZSBubyBx dWVyeSBwYXJhbXMpLCB0byB0aGUgbGFzdCBxdWVyeSBwYXJhbWV0ZXIgdmFsdWUsIHRvIHRoZSB0 b3AtbGV2ZWwgZG9tYWluIChpZiB0aGUgcGF0aCBpcyBlbXB0eSkgZXRjLg0KDQpob3N0bWV0YS0w MiBzYXlzIHRvIGlnbm9yZSA8TGluaz5zIGNvbnRhaW5pbmcgdGVtcGxhdGVzIHdpdGggdW5yZWNv Z25pc2VkIHZhcmlhYmxlcywgZWcge2JsdXJnfS4gQSBmdXR1cmUgdGVtcGxhdGUgc3BlYyBpcyBt b3JlIGxpa2VseSB0byBzYXkgdG8gc3Vic3RpdHV0ZSBhbiBlbXB0eSBzdHJpbmcgIiIgaW4gdGhp cyBzaXR1YXRpb24uDQpJZ25vcmluZyA8TGluaz5zIHdpdGggdW5yZWNvZ25pc2VkIHZhcmlhYmxl cyBpcyBvayBpbiBob3N0LW1ldGEsIHRob3VnaCBqdXN0IGdpdmluZyB0aGVtIGEgbG93ZXIgcHJp b3JpdHkgdGhhbiA8TGluaz5zIHdpdGgga25vd24gdmFyaWFibGVzIG1heSBiZSBiZXR0ZXIgKHN1 YnN0aXR1dGluZyBhbiBlbXB0eSBzdHJpbmcgZm9yIHRoZSB1bnJlY29nbmlzZWQgdmFyaWFibGVz KS4gUHJpb3JpdGllcyBhZGQgYSBiaXQgbW9yZSBjb21wbGV4aXR5LCBhbmQgeW91IGNhbiBoYXZl IGFueSBudW1iZXIgb2YgPExpbms+cyB3aXRoIGEgZ2l2ZW4gcmVsYXRpb24gaW4gaG9zdC1tZXRh LCBzbyBJIGlnbm9yaW5nIHRoZSB3aG9sZSA8TGluaz4gaXMgb2suDQoNCmhvc3RtZXRhLTAyIHNh eXMgdG8gaWdub3JlIDxMaW5rPnMgY29udGFpbmluZyB0ZW1wbGF0ZXMgd2l0aCBhbiB1bmV4cGVj dGVkIHN5bnRheCAoaWUgY29udGFpbmluZyBjaGFycyBub3QgYWxsb3dlZCBpbiBhIHZhcmlhYmxl IG5hbWUsIGVnIHsvYmx1cmd9KS4gSSBhZ3JlZSB3aXRoIHRoaXMgKGl0IGlzIHVuY2xlYXIgd2hh dCBhIGZ1dHVyZSB0ZW1wbGF0ZSBzcGVjIHdpbGwgc2F5IGluIHRoaXMgY2FzZSkuIFNpbmNlIEkg dGhpbmsgdGhlICcrJyBvcGVyYXRvciBkb2VzIG5vdCBuZWVkIHRvIGJlIGRlZmluZWQgYXQgdGhp cyBwb2ludCwgYW55IGxpbmsgd2l0aCB7K3VyaX0gd291bGQgYWxzbyBiZSBpZ25vcmVkLg0KDQoN CkphbWVzIE1hbmdlcg0K From ted.ietf@gmail.com Sun Nov 8 20:49:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA10A28C12B; Sun, 8 Nov 2009 20:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn4dP7HOaGL4; Sun, 8 Nov 2009 20:49:58 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id ECDB228C0DF; Sun, 8 Nov 2009 20:49:57 -0800 (PST) Received: by pzk42 with SMTP id 42so2221012pzk.31 for ; Sun, 08 Nov 2009 20:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ik/Baw9DdYBTrgHwvbxMnLSyymkMbHxITF/7W+y5zQ0=; b=x02jRxM1O//thLosJ8J+wbq6y163XCsxppAPBREKfPtnAvc4gILLOcWxG2UyhBzdKy +/tm2MVfzRIkX9uk99zUHrZujn3zigW3Wlg61s0bmVcco/ZBfoILXEALd/gOoqlShL0l desvCzjghD5sCgRljQM4LO1SHPhPy1Kj4MWX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XqyQQRu643ksn4+CR4PeEBBpImRZDRLqVdfr75qTHZpM8i2INaBTht/pcYyej+H2OD lVCRmNqz+vIV6YnD3YOj621434G24Gq5HrEgmaF0iNSLEzJXD5qCoGjiuNJlwAsHAxnt 6kvfV4gZd+aEQ4pENawc92uzgoMFjZvyRcSIs= MIME-Version: 1.0 Received: by 10.143.138.4 with SMTP id q4mr757520wfn.38.1257742221243; Sun, 08 Nov 2009 20:50:21 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Nov 2009 20:50:21 -0800 Message-ID: <6e04e83a0911082050n4b59adb2l39d75797aa14fe9a@mail.gmail.com> Subject: Re: service names - one registry vs. two registries From: Ted Hardie To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Cc: tsvwg@ietf.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:49:58 -0000 On Sun, Nov 8, 2009 at 6:21 PM, Lars Eggert wrote: > Hi, > > as just briefly discussed in the APP area meeting after Joe's presentation, > we need to come to some community consensus on what to do with service name > registrations. > > draft-ietf-tsvwg-iana-ports has been written with the intent to unify the > three(*) current places where service names can be registered, making the > ports and service names registry the one-stop shop for ports and service > names. All service names (~10K?) registered in one of the current three > places would be grandfathered in. > > draft-gudmundsson-dns-srv-iana-registry advocates a creating new standalone > registry for service names that are to be used with DNS SRV RRs > (exclusively, in my reading) and seed it with only those 40 service names > that are specifically called out in published RFCs. There is no discussion > on how the new registry relates to the three(*) existing places where > service names have currently been registered. > Well, it certainly seems valuable to me to distinguish between the cases where you can expect to use SRV and those you cannot (the same for NAPTR or UNAPTR or DDDS). Whether you distinguish that by a field in a single registry or by having multiple registries which don't have overlapped names kind of doesn't make that big a difference to my way of thinking. regards, Ted From marc.blanchet@viagenie.ca Sun Nov 8 22:22:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA3A3A6867; Sun, 8 Nov 2009 22:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hHMquWdNxRu; Sun, 8 Nov 2009 22:22:23 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 532B73A69BD; Sun, 8 Nov 2009 22:22:23 -0800 (PST) Received: from host-24-139.meeting.ietf.org (host-24-139.meeting.ietf.org [133.93.24.139]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2935D210FD; Mon, 9 Nov 2009 01:22:47 -0500 (EST) Message-ID: <4AF7B534.3070704@viagenie.ca> Date: Mon, 09 Nov 2009 15:22:44 +0900 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert Subject: Re: service names - one registry vs. two registries References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:22:24 -0000 my 2 cents: - roughly, it does not matter. - I have a slight bias towards one single registry so that all assignments related to "transport services" are in one place. simpler for implementors, for protocol designers, etc... so voting for one registry for easier to find info. Marc. Lars Eggert a écrit : > Hi, > > as just briefly discussed in the APP area meeting after Joe's > presentation, we need to come to some community consensus on what to do > with service name registrations. > > draft-ietf-tsvwg-iana-ports has been written with the intent to unify > the three(*) current places where service names can be registered, > making the ports and service names registry the one-stop shop for ports > and service names. All service names (~10K?) registered in one of the > current three places would be grandfathered in. > > draft-gudmundsson-dns-srv-iana-registry advocates a creating new > standalone registry for service names that are to be used with DNS SRV > RRs (exclusively, in my reading) and seed it with only those 40 service > names that are specifically called out in published RFCs. There is no > discussion on how the new registry relates to the three(*) existing > places where service names have currently been registered. > > (Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you should > read the two documents to form your own opinion on the different > proposals.) > > So far, the discussion has mostly seen arguments from the proponents of > both approaches. It would be useful to hear from the broader community > on which general approach is preferable. > > Lars > > (*) > http://www.iana.org/assignments/port-numbers > http://www.iana.org/assignments/service-names > http://www.dns-sd.org/ServiceTypes.html > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Sun Nov 8 23:21:54 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155D83A6AF7 for ; Sun, 8 Nov 2009 23:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOUW4QnVKkd9 for ; Sun, 8 Nov 2009 23:21:53 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 363263A6920 for ; Sun, 8 Nov 2009 23:21:53 -0800 (PST) Received: (qmail 21359 invoked from network); 9 Nov 2009 07:22:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Nov 2009 07:22:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 Nov 2009 00:20:28 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "apps-discuss@ietf.org" Date: Mon, 9 Nov 2009 00:20:30 -0700 Subject: RE: host-meta: template syntax hassles Thread-Topic: host-meta: template syntax hassles Thread-Index: AcpWwpMrO2fBkK/zTVK4PvsTZrNbFQAA8nsQAAEiIMAADvFXsAIIDq7wAGsvmZAADk1gUA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378507870E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112488D2CB1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112488D2CB1@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:21:54 -0000 I agree. I will remove the '+' operator in the next draft. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Manger, James H > Sent: Sunday, November 08, 2009 6:27 PM > To: apps-discuss@ietf.org > Cc: webfinger@googlegroups.com > Subject: RE: host-meta: template syntax hassles >=20 > > the currently proposed template vocabulary.. > > should be made even less expressive (only define 'uri') >=20 > I (somewhat reluctantly) agree, as long as the '+' operator (don't %- > escape reserved chars) is removed as well. >=20 > A decent aim is to support just the simplest case now (eg > http://example.com/meta?u=3D{uri}), and try to > be compatible with a future fully-developed URI template spec. The > behaviour with unrecognised variables, and unexpected syntax is more > important than the list of variables defined. >=20 > The '+' operator should NOT be defined in hostmeta (if the only > variable is 'uri'). It is not necessary for the simplest case. I don't > think it can be used safely with the 'uri' variable. A template like > "{+uri};by" almost looks sensible, but it isn't. The ";by" suffix may > be appended to the path (if there are no query params), to the last > query parameter value, to the top-level domain (if the path is empty) > etc. >=20 > hostmeta-02 says to ignore s containing templates with > unrecognised variables, eg {blurg}. A future template spec is more > likely to say to substitute an empty string "" in this situation. > Ignoring s with unrecognised variables is ok in host-meta, though > just giving them a lower priority than s with known variables may > be better (substituting an empty string for the unrecognised > variables). Priorities add a bit more complexity, and you can have any > number of s with a given relation in host-meta, so I ignoring the > whole is ok. >=20 > hostmeta-02 says to ignore s containing templates with an > unexpected syntax (ie containing chars not allowed in a variable name, > eg {/blurg}). I agree with this (it is unclear what a future template > spec will say in this case). Since I think the '+' operator does not > need to be defined at this point, any link with {+uri} would also be > ignored. >=20 >=20 > James Manger > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From patrik@frobbit.se Sun Nov 8 23:33:53 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2459228C1BA; Sun, 8 Nov 2009 23:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttjRNNgOrGIG; Sun, 8 Nov 2009 23:33:52 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id D372228C1B5; Sun, 8 Nov 2009 23:33:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D95488233951; Mon, 9 Nov 2009 08:34:15 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdGJj5T5v88I; Mon, 9 Nov 2009 08:34:15 +0100 (CET) Received: from host-78-64-99-160.homerun.telia.com (host-78-64-99-160.homerun.telia.com [78.64.99.160]) by srv01.frobbit.se (Postfix) with ESMTP id E98FF8233937; Mon, 9 Nov 2009 08:34:13 +0100 (CET) Subject: Re: service names - one registry vs. two registries Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4AF7B534.3070704@viagenie.ca> Date: Mon, 9 Nov 2009 08:34:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AF7B534.3070704@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1076) Cc: Apps Discuss , tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:33:53 -0000 Also, the various registries have had different goals. For example, =20 IANA registering port numbers so that they are unique, and then a =20 descriptive string. Not a string -> port mapping for SRV record usage. =20= Other registries have other design goals. But, yes, better if there only would be one, but... The merge/=20 description of the registry must be done in a careful way. Patrik On 9 nov 2009, at 07.22, Marc Blanchet wrote: > my 2 cents: > - roughly, it does not matter. > - I have a slight bias towards one single registry so that all =20 > assignments related to "transport services" are in one place. =20 > simpler for implementors, for protocol designers, etc... so voting =20 > for one registry for easier to find info. > > Marc. > > Lars Eggert a =E9crit : >> Hi, >> as just briefly discussed in the APP area meeting after Joe's =20 >> presentation, we need to come to some community consensus on what =20 >> to do with service name registrations. >> draft-ietf-tsvwg-iana-ports has been written with the intent to =20 >> unify the three(*) current places where service names can be =20 >> registered, making the ports and service names registry the one-=20 >> stop shop for ports and service names. All service names (~10K?) =20 >> registered in one of the current three places would be =20 >> grandfathered in. >> draft-gudmundsson-dns-srv-iana-registry advocates a creating new =20 >> standalone registry for service names that are to be used with DNS =20= >> SRV RRs (exclusively, in my reading) and seed it with only those 40 =20= >> service names that are specifically called out in published RFCs. =20 >> There is no discussion on how the new registry relates to the three=20= >> (*) existing places where service names have currently been =20 >> registered. >> (Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you =20 >> should read the two documents to form your own opinion on the =20 >> different proposals.) >> So far, the discussion has mostly seen arguments from the =20 >> proponents of both approaches. It would be useful to hear from the =20= >> broader community on which general approach is preferable. >> Lars >> (*) >> http://www.iana.org/assignments/port-numbers >> http://www.iana.org/assignments/service-names >> http://www.dns-sd.org/ServiceTypes.html >> = ------------------------------------------------------------------------ >> _______________________________________________ >> Apps-Discuss mailing list >> Apps-Discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From magnus.westerlund@ericsson.com Sun Nov 8 23:37:11 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EC028C18E; Sun, 8 Nov 2009 23:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJBo6Auzuywq; Sun, 8 Nov 2009 23:37:10 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2459828C193; Sun, 8 Nov 2009 23:37:09 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-2e-4af7c6be8cd9 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F5.EC.31706.EB6C7FA4; Mon, 9 Nov 2009 08:37:35 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:37:34 +0100 Received: from [153.88.47.107] ([153.88.47.107]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 08:37:33 +0100 Message-ID: <4AF7C6BA.501@ericsson.com> Date: Mon, 09 Nov 2009 16:37:30 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ted Hardie Subject: Re: service names - one registry vs. two registries References: <6e04e83a0911082050n4b59adb2l39d75797aa14fe9a@mail.gmail.com> In-Reply-To: <6e04e83a0911082050n4b59adb2l39d75797aa14fe9a@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Nov 2009 07:37:33.0911 (UTC) FILETIME=[80579E70:01CA610F] X-Brightmail-Tracker: AAAAAA== Cc: Apps Discuss , tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:37:11 -0000 Ted Hardie skrev: > On Sun, Nov 8, 2009 at 6:21 PM, Lars Eggert wrote: >> Hi, >> >> as just briefly discussed in the APP area meeting after Joe's presentation, >> we need to come to some community consensus on what to do with service name >> registrations. >> >> draft-ietf-tsvwg-iana-ports has been written with the intent to unify the >> three(*) current places where service names can be registered, making the >> ports and service names registry the one-stop shop for ports and service >> names. All service names (~10K?) registered in one of the current three >> places would be grandfathered in. >> >> draft-gudmundsson-dns-srv-iana-registry advocates a creating new standalone >> registry for service names that are to be used with DNS SRV RRs >> (exclusively, in my reading) and seed it with only those 40 service names >> that are specifically called out in published RFCs. There is no discussion >> on how the new registry relates to the three(*) existing places where >> service names have currently been registered. >> > > Well, it certainly seems valuable to me to distinguish between the > cases where you can expect to use SRV and those you cannot (the same > for NAPTR or UNAPTR or DDDS). Whether you distinguish that by a field > in a single registry or by having multiple registries which don't have > overlapped names kind of doesn't make that big a difference to my way > of thinking. > My personal view (as individual and co-author) on this that having separate registries and expect them to have the name be truly unique across multiple registries give a risk for failure in checking in registration. I don't see any issues with having additional information pointing out that a name has explicitly specification as being used for SRV or other usages and references to where that is specified. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lear@cisco.com Mon Nov 9 07:17:44 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413C33A6B4F; Mon, 9 Nov 2009 07:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfHPQ0dgP1MY; Mon, 9 Nov 2009 07:17:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A05AA3A6838; Mon, 9 Nov 2009 07:17:42 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AALLB90qQ/uCWe2dsb2JhbACEcpcIAQEWJAaqTIcVj0iBMoI4VAQ X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="53975549" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2009 15:18:07 +0000 Received: from ams3-vpn-dhcp4612.cisco.com (ams3-vpn-dhcp4612.cisco.com [10.61.82.3]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9FI7V6010473; Mon, 9 Nov 2009 15:18:07 GMT Message-ID: <4AF832AF.60504@cisco.com> Date: Mon, 09 Nov 2009 16:18:07 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091103 Shredder/3.0pre MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tsvwg] service names - one registry vs. two registries References: In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:17:44 -0000 Lars, I've looked at both documents a bit, and I prefer yours, quite frankly. I think it's better written, and doesn't meander into a wilderness of underscores. As currently envisioned and deployed, service name resolves to a port number. As such I do not see an advantage to a pair of disconnected registries, but rather a single registry that can be keyed either on protocol/service, service, or port number/service. A query to service returns human readable information only, whereas the others may serve programmatic functions. Seems simple enough. What am I missing? Eliot From Nicolas.Williams@sun.com Mon Nov 9 09:52:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A053A67B2; Mon, 9 Nov 2009 09:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeQORiGGsYFM; Mon, 9 Nov 2009 09:52:15 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id D75D83A6774; Mon, 9 Nov 2009 09:52:14 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9Hqf1n006770; Mon, 9 Nov 2009 17:52:41 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA9HqeAB012763; Mon, 9 Nov 2009 10:52:41 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9Hf9oD011723; Mon, 9 Nov 2009 11:41:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9Hf8e7011722; Mon, 9 Nov 2009 11:41:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 11:41:08 -0600 From: Nicolas Williams To: Lars Eggert Subject: Re: service names - one registry vs. two registries Message-ID: <20091109174108.GZ1105@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: tsvwg@ietf.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:52:15 -0000 I think a single registry is better than N similar ones, even though one could always impose rules on the alternative such that collisions are minimized. I would also add that there are other service name registries in the IANA that you should consider folding in here. The one I'm thinking of is the GSS-API service name registry. Ideally what I'd like to see is something like this: +------------+--------+-------+-------+-------+ |Service | SRV |Default|Aliases|is GSS?| | Name |label | Port | | | +------------+--------+-------+-------+-------+ | foo | _foo | 12345 | | No | +------------+--------+-------+-------+-------+ | bar | | 23456 |foobar | Yes | +------------+--------+-------+-------+-------+ | ... | ... | ... |... | ... | +------------+--------+-------+-------+-------+ Perhaps a SQL model would help: ? CREATE TABLE services (canon_name TEXT PRIMARY KEY UNIQUE, srv_label TEXT UNIQUE, def_port INTEGER UNIQUE CHECK(def_port < 32768), is_GSS BOOLEAN CHECK(is_gss = 'true' OR is_gss = 'false')); CREATE TABLE aliases (alias_name TEXT PRIMARY KEY UNIQUE, canon_name TEXT, FOREIGN KEY (canon_name) REFERENCES services (canon_name)); (I didn't include CHECKs for name and srv_label, but, you get the point. I'm using SQLite3 syntax here, specificially w.r.t. type names. I also didn't capture the need for aliases to be unique relative to service canonical names.) Nico -- From lars.eggert@nokia.com Mon Nov 9 15:34:11 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954A73A69DF; Mon, 9 Nov 2009 15:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZCWlKH6zVe0; Mon, 9 Nov 2009 15:34:10 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 275AE3A69DA; Mon, 9 Nov 2009 15:34:09 -0800 (PST) Received: from host-24-27.meeting.ietf.org (host-24-27.meeting.ietf.org [133.93.24.27]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA9NXtJO094092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2009 01:33:58 +0200 (EET) (envelope-from lars.eggert@nokia.com) Subject: Re: service names - one registry vs. two registries Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-2-329560224; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20091109174108.GZ1105@Sun.COM> Date: Tue, 10 Nov 2009 08:33:54 +0900 Message-Id: <941C2468-FF79-4ED7-99CE-6747E9112577@nokia.com> References: <20091109174108.GZ1105@Sun.COM> To: Nicolas Williams , Pasi Eronen , Michelle Cotton X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Tue, 10 Nov 2009 01:34:01 +0200 (EET) Cc: "tsvwg@ietf.org" , Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:34:11 -0000 --Apple-Mail-2-329560224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2009-11-10, at 2:41, Nicolas Williams wrote: > I think a single registry is better than N similar ones, even though = one > could always impose rules on the alternative such that collisions are > minimized. >=20 > I would also add that there are other service name registries in the > IANA that you should consider folding in here. The one I'm thinking = of > is the GSS-API service name registry. I'm CC'ing Pasi, because we have discussed the GSS-API registry = (http://www.iana.org/assignments/gssapi-service-names) in the past and = concluded that because the use case is much more constrained, a separate = registry for those few GSS-enabled services makes sense. > Ideally what I'd like to see is something like this: >=20 > +------------+--------+-------+-------+-------+ > |Service | SRV |Default|Aliases|is GSS?| > | Name |label | Port | | | > +------------+--------+-------+-------+-------+ > | foo | _foo | 12345 | | No | > +------------+--------+-------+-------+-------+ > | bar | | 23456 |foobar | Yes | > +------------+--------+-------+-------+-------+ > | ... | ... | ... |... | ... | > +------------+--------+-------+-------+-------+ We _could_ certainly to this merge. I'd be interested to hear if others = think if that makes sense. > Perhaps a SQL model would help: ? I think IANA has an XML format for the new table (Michelle?) Since that = is somewhat internal to IANA's operation and can change for operational = reasons without the procedures changing, we didn't include it in the = draft. We could, if folks think it'd be useful. Lars >=20 > CREATE TABLE services (canon_name TEXT PRIMARY KEY UNIQUE, > srv_label TEXT UNIQUE, > def_port INTEGER UNIQUE CHECK(def_port < = 32768), > is_GSS BOOLEAN > CHECK(is_gss =3D 'true' OR is_gss =3D = 'false')); >=20 > CREATE TABLE aliases (alias_name TEXT PRIMARY KEY UNIQUE, > canon_name TEXT, > FOREIGN KEY (canon_name) > REFERENCES services (canon_name)); >=20 > (I didn't include CHECKs for name and srv_label, but, you get the > point. I'm using SQLite3 syntax here, specificially w.r.t. type = names. > I also didn't capture the need for aliases to be unique relative to > service canonical names.) >=20 > Nico > --=20 --Apple-Mail-2-329560224 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwOTIzMzM1NFowIwYJKoZIhvcNAQkEMRYEFNodnCPux6Fa1SpH5nVbu4E3a2m1MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQA5qdr7tQUwKxiQ/xUS54WB+Np3acXAPBiJaYdMsEJ0y/ZIgLnTv4MWYWdw0C4Fvt2VXBWT I0zbJUGOGNnaAyok4Eon5oRYL7Ku1FZresrV/IKeO4vQko1DRZ/mz9Pt9gsqwgnTQSdb/AkKmhni rtsd09XXX5Wd6wWD/1UzBU/sqWMgO593VUGdw56XsWpVy50XoX1cd4nWfu/DDT4WrTrI/K4C+GbQ rcUn9fb6tIJNH2aN9gBA1KFpRDIDbU2doI9qj7JY1mXX2eev5ibyREknLv6HvhE2COrH8iBEZ1qc sFr9airDFN79DQSvitVo+3dv5xQqoB4cUr8d/i8I+oUiAAAAAAAA --Apple-Mail-2-329560224-- From Nicolas.Williams@sun.com Mon Nov 9 15:56:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA2A3A6855; Mon, 9 Nov 2009 15:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.715 X-Spam-Level: X-Spam-Status: No, score=-5.715 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgK+koAMzIjX; Mon, 9 Nov 2009 15:56:24 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id AA2C73A677E; Mon, 9 Nov 2009 15:56:23 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9Nun7n021650; Mon, 9 Nov 2009 23:56:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA9Nun1w059493; Mon, 9 Nov 2009 16:56:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9NbhEq011999; Mon, 9 Nov 2009 17:37:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9Nbhjn011998; Mon, 9 Nov 2009 17:37:43 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 17:37:43 -0600 From: Nicolas Williams To: Lars Eggert Subject: Re: service names - one registry vs. two registries Message-ID: <20091109233743.GL1105@Sun.COM> References: <20091109174108.GZ1105@Sun.COM> <941C2468-FF79-4ED7-99CE-6747E9112577@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <941C2468-FF79-4ED7-99CE-6747E9112577@nokia.com> User-Agent: Mutt/1.5.7i Cc: Michelle Cotton , Pasi Eronen , "tsvwg@ietf.org" , Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:56:25 -0000 On Tue, Nov 10, 2009 at 08:33:54AM +0900, Lars Eggert wrote: > On 2009-11-10, at 2:41, Nicolas Williams wrote: > > I think a single registry is better than N similar ones, even though one > > could always impose rules on the alternative such that collisions are > > minimized. > > > > I would also add that there are other service name registries in the > > IANA that you should consider folding in here. The one I'm thinking of > > is the GSS-API service name registry. > > I'm CC'ing Pasi, because we have discussed the GSS-API registry > (http://www.iana.org/assignments/gssapi-service-names) in the past and > concluded that because the use case is much more constrained, a > separate registry for those few GSS-enabled services makes sense. I remember discussing this with others before. The GSS service name registry is rarely updated, but people do use service names that don't appear there. > > Ideally what I'd like to see is something like this: > > We _could_ certainly to this merge. I'd be interested to hear if others think if that makes sense. Well, you're trying to merge at least two registries, no? I think it makes sense to merge the GSS-API service name registry in too. > > Perhaps a SQL model would help: ? > > I think IANA has an XML format for the new table (Michelle?) Since > that is somewhat internal to IANA's operation and can change for > operational reasons without the procedures changing, we didn't include > it in the draft. We could, if folks think it'd be useful. I think it'd be nice to have a way to write registration rules with some formalism. Right now we lack that. I don't care what the language is that we use for this. Nico -- From A.Hoenes@TR-Sys.de Tue Nov 10 12:02:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958143A6A29; Tue, 10 Nov 2009 12:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.256 X-Spam-Level: *** X-Spam-Status: No, score=3.256 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MANGLED_SEX=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciixgXTzUR0m; Tue, 10 Nov 2009 12:02:42 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 1340F3A6B05; Tue, 10 Nov 2009 12:02:29 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA112543320; Tue, 10 Nov 2009 21:02:00 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA06871; Tue, 10 Nov 2009 21:01:42 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911102001.VAA06871@TR-Sys.de> Subject: Re: service names - one registry vs. two registries To: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, apps-discuss@ietf.org, tsvwg@ietf.org Date: Tue, 10 Nov 2009 21:01:41 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: iesg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:02:43 -0000 The notes below are intended to emphasize major concerns with draft-ietf-tsvwg-iana-ports presumably of interest for both APPS-DISCUSS and TSVWG. This message shall serve as partial WGLC comments for draft-ietf-tsvwg-iana-ports-03 in TSVWG as well. I still have not received any response from the protagonists of the 'unified', say, "service identifier" registry indicating how their proposal could properly match the needs of DDDS/DNS based (or only DNS SRV RR based) service discovery. This method in the meantime is being used as well for services that are not based on specific IETF transport protocols, not carried over IP at all but directly over L2 protocols (with their own, port-like demultiplexing fields if needed), or over some 'middleware' protocols with predefined or internally negotiated transport. The allusion in draft-ietf-tsvwg-iana-ports of a service name alone identifying the service instance is misleading; the "Service Prefix" that needs to be registered is composed of a _combination_ of Service Label and Protocol Label; that's in general by no means orthogonal. The Protocol Labels in practice are not restricted to IETF transport protocols which admittedly fall into the scope of TSVWG; there are other Protocol identifiers to be accommodated -- we call them "Overlay" or "Substrate" protocols in our I-D, draft-gudmundsson-dns-srv-iana-registry-04, and these generally are out of scope for TSVWG. Some application designers and SDOs would prefer to use the same identifiers at different stages in the DDDS with DNS database, for both protocol and service identifiers. This requires an integrated, and much more flexible treatment of the Protocol component in NAPTR Service Parameters and SRV Service Prefixes than envisioned in tsvwg-iana-ports. One more instance of practical needs I recently have been pointed at: ETSI/3GPP/3GPP2 make significant use of RFC 3958, i.e. DDDS with a DNS database, using NAPTR and SRV resource records, and they want to use the same service and protocol identifiers in the NAPTR Service Parameter field and in the SRV Service Prefixes. Currently, 3GPP TS 23.003 (== ETSI TS 123 003) lists Service and Protocol names provisionally assigned in the experimental name spaces for NAPTR (per RFC 3958, Section 6.5) starting with "x-", but AFAICT they would like to arrive in the IANA registered branch, getting rid of the "x-" prefix, and use the shortened identifiers in SRV Service Prefixes. There, the following twenty *Protocol* names are listed (list sorted here for readability): x-gn x-gp x-s1-mme x-s1-u x-s2 x-s2a-mipv4 x-s2a-pmip x-s2b-pmip x-s2c-dsmip x-s3 x-s4 x-s5-gtp x-s5-pmip x-s6a x-s8-gtp x-s8-pmip x-s10 x-s11 x-s12 x-s16 For brevity, I omit listing the five Service names specified there and the non-orthogonal list of valid combinations to form NAPTR service parameters and SRV Service Prefixes as well. One example for such Service Prefix would be: - currently, experimental : _x-3gpp-sgw._x-s2a-pmip - desired, registered : _3gpp-sgw._s2a-pmip I could not find any hint in draft-ietf-tsvwg-iana-ports-03 of how the registration of SRV Service Prefixes in general, and the registration of such concrete examples could be pursued in the 'unified' registry you would like to establish. More nasty details: Section 8.1 of draft-ietf-tsvwg-iana-ports still is stuck with the restriction of "Service Names" to 15 US-ASCII characters. Even RFC 3958 admits 32 characters for the service and protocol components of the NAPTR Service Parameter, and draft-gudmundsson-dns-srv-iana-registry accommodates the 'natural' DNS limit of 63 characters at most (including the added underscore) The same section requires "A reference document describing the protocol or application using this port, ..." This is but one example of text in this draft that does not contain proper provisions for registrations of services without assigned port usage. Furthermore, draft-ietf-tsvwg-iana-ports aims at 'integrating' the DNS WKS registry, without even contacting working groups responsible for the DNS protocol and its operational aspects. Due to signicifant security concerns, there have not been any registrations for many years there until recently; it is assumed that DNS experts would rather prefer to close that registry in order to raise a 'stop sign' than re-opening that registry wide in absorbing it into the Port Number registry and thereby apparently sanctioning the use of any preexisting Service Names from the Port Numbers registry for use with WKS resource records. If at all used, WKS (standing for "Well Known Services") would perhaps need to be restricted to services with assigned Well-Known port numbers. It has been observed with surprise that apparently the IESG has caused IANA to perform registrations in the WKS registry for a draft that did not even request that; that draft talks about SRV usage, not WKS, and hence the matching registrations would have been suitable for the DNS SRV Service Prefix registry sought by draft-gudmundsson-dns-srv-iana-registry. (Note that WKS is useless for service discovery in a domain -- WKS only answers the question of which well-known services are offered publicly at a given host, not which hosts offer a given service. Hence WKS is grossly inappropriate for IEEE Mobility Services discovery.) These and other details seem to confirm suspicion that the hastily performed misappropriation of subject matter out-of-scope for TSVWG did not even carefully pay attention to the needs of these topics. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Tue Nov 10 12:48:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8053A6A06; Tue, 10 Nov 2009 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.111 X-Spam-Level: ** X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qedwODMgrIjR; Tue, 10 Nov 2009 12:48:48 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id F10B13A6900; Tue, 10 Nov 2009 12:48:46 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA112836083; Tue, 10 Nov 2009 21:48:03 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA06919; Tue, 10 Nov 2009 21:48:01 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911102048.VAA06919@TR-Sys.de> Subject: Re: [apps-discuss] service names - one registry vs. two registries To: apps-discuss@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG Date: Tue, 10 Nov 2009 21:48:01 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:48:49 -0000 At Mon, 9 Nov 2009 11:21:18 +0900, Lars Eggert wrote: > ... > > draft-gudmundsson-dns-srv-iana-registry advocates a creating new > standalone registry for service names that are to be used with DNS > SRV RRs (exclusively, in my reading) and seed it with only those > 40 service names that are specifically called out in published RFCs. Incorporation of non-RFC material has been excluded from our draft on advice from the IESG, in order to avoid IETF procedural and IPR concerns for a document intended to amend a Standards Track RFC (2782). It was planned to co-author a second I-D with the maintainers of the DNS-SD registry for bulk-registration of active entries in that registry, once the establishment of the registry has been approved. This way, garbage collection after an uncritical incorporation of the material would not be necessary, thus presumably saving a lot of work for many folks, including IANA. Any entry in the registry is to point to _current_ service discovery specs, and should hence be coordinated with the original registrants, if not for other reasons then for politeness. Lars, it sounds strange for you to blame us of following advice from inside the IESG. > There is no discussion on how the new registry relates to the > three(*) existing places where service names have currently been > registered. The registry for WKS RR entries is out of scope of our draft and should better be out of scope for draft-ietf-tsvwg-iana-ports as well, for various reasons. It has been hibernating since years and should better not be revived (or have been revived) at all. Would DNSOP have been more active in the past and have had no other tasks to perform, formally closing that registry would perhaps have been the preferable way to handle that legacy, but nobody made notice of it. Re-opening this registry by unification with another, life registry is IMHO ill-advised. The recent registration in that registry of services that will not be assigned a port number from the WKS range, and where the defining document does not even mention WKS RR usage, is surprising, at best. The relationship between the Service Label part of SRV Service Prefixes and the Service Names in the Port Number registry is covered exhaustively in our draft, including collision avoiding procedures for services that once have been assigned a fixed port number and later are amended with a specification of service discovery using the DDDS over DNS or 'standalone' SRV RRs. The converse case is much less likely but is mentioned as well, and parallel registration of Service Prefix(es) and application for IANA assignment of a port number is possible anyway. > > ... > > Lars > > ... Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From lars.eggert@nokia.com Tue Nov 10 20:02:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2F628C233; Tue, 10 Nov 2009 20:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z748B1drVJIF; Tue, 10 Nov 2009 20:02:39 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 469783A691C; Tue, 10 Nov 2009 20:02:39 -0800 (PST) Received: from [IPv6:2001:dfb::24:225:ff:fe45:eccf] ([IPv6:2001:dfb:0:24:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nAB42ltO015103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Nov 2009 06:02:51 +0200 (EET) (envelope-from lars.eggert@nokia.com) Subject: Re: [apps-discuss] service names - one registry vs. two registries Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-8-432087357; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <200911102048.VAA06919@TR-Sys.de> Date: Wed, 11 Nov 2009 13:02:41 +0900 Message-Id: <1FBE43C6-1EF4-4443-828F-6AAFAF83A781@nokia.com> References: <200911102048.VAA06919@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 11 Nov 2009 06:02:54 +0200 (EET) Cc: "draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG" , "tsvwg@ietf.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:02:41 -0000 --Apple-Mail-8-432087357 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I expect we will continue to be at opposites sides of this debate. But = I'd like to correct a few things that I think you're overstating. On 2009-11-11, at 5:48, ah@tr-sys.de wrote: > Incorporation of non-RFC material has been excluded from our draft > on advice from the IESG, in order to avoid IETF procedural and IPR > concerns for a document intended to amend a Standards Track RFC = (2782). ... > Lars, > it sounds strange for you to blame us of following advice from > inside the IESG. There has been no "advice from the IESG". You may have gotten advice = from an individual AD, which is not the same. When we speak as "the = IESG", we run a consensus call (such as when we approve documents). This = hasn't happened here. > The registry for WKS RR entries is out of scope of our draft and > should better be out of scope for draft-ietf-tsvwg-iana-ports as well, > for various reasons. > It has been hibernating since years and should better not be revived > (or have been revived) at all. I assume you're referring to = http://www.iana.org/assignments/service-names here. We are not attempting to "revive" it. We're referring to it as a source = of grandfathered service names, and our ID actually asks IANA to = determine if that registry can be retired after that has happened = (Section 10). The reason we do this is that some of these may actually still be in use = somewhere, and hence should not be available for new registrations. Continuing with your second email: On 2009-11-11, at 5:01, ah@tr-sys.de wrote: > I still have not received any response from the protagonists > of the 'unified', say, "service identifier" registry indicating > how their proposal could properly match the needs of DDDS/DNS > based (or only DNS SRV RR based) service discovery. Speaking for myself only (and not my co-authors) that is because I don't = understand what needs we aren't matching. We're having lunch with Olafur = tomorrow, and I hope he will educate me. > The allusion in draft-ietf-tsvwg-iana-ports of a service > name alone identifying the service instance is misleading; > the "Service Prefix" that needs to be registered is composed > of a _combination_ of Service Label and Protocol Label; > that's in general by no means orthogonal. I'm not sure I'd readily agree here. There are several services (DNS = itself, for example) that can be talked to over different transport = protocols. Other existing TCP-based services are starting to grow = support for being talked to over SCTP. In my mind, "service" is a = concept that is de-coupled from transport. > I could not find any hint in draft-ietf-tsvwg-iana-ports-03 of how > the registration of SRV Service Prefixes in general, and the > registration of such concrete examples could be pursued in the > 'unified' registry you would like to establish. That's because they are specific to the use of service names in DNS SRV = RRs, which is *one such use only*.=20 > Section 8.1 of draft-ietf-tsvwg-iana-ports still is stuck with > the restriction of "Service Names" to 15 US-ASCII characters. > Even RFC 3958 admits 32 characters for the service and protocol > components of the NAPTR Service Parameter, and > draft-gudmundsson-dns-srv-iana-registry accommodates the 'natural' > DNS limit of 63 characters at most (including the added underscore) Correct. This is again because service names have other uses than for = DNS SRV RRs, and some of those uses require a stricter syntax. > The same section requires "A reference document describing the > protocol or application using this port, ..." > This is but one example of text in this draft that does not contain > proper provisions for registrations of services without assigned > port usage. Please realize that you are reading a *draft*. We have tried hard to be = precise in when we talk about ports, when we talk about service names, = and when we talk about both. You've demonstrated that we haven't managed = to be precise yet in all cases, and any such cases will be fixed when = found. > Furthermore, draft-ietf-tsvwg-iana-ports aims at 'integrating' > the DNS WKS registry, without even contacting working groups > responsible for the DNS protocol and its operational aspects. > Due to signicifant security concerns, there have not been any > registrations for many years there until recently; it is assumed > that DNS experts would rather prefer to close that registry in > order to raise a 'stop sign' than re-opening that registry wide > in absorbing it into the Port Number registry and thereby > apparently sanctioning the use of any preexisting Service Names > from the Port Numbers registry for use with WKS resource records. > If at all used, WKS (standing for "Well Known Services") would > perhaps need to be restricted to services with assigned Well-Known > port numbers. See above. We are *not* integrating the registry or the procedures. = We're grandfathering in the few service names registered there, so they = remain unavailable for new registrations. (Once that has happened, the = WKS registry may be a candidate for retirement.) > It has been observed with surprise that apparently the IESG has > caused IANA to perform registrations in the WKS registry for a > draft that did not even request that; that draft talks about SRV > usage, not WKS, and hence the matching registrations would have > been suitable for the DNS SRV Service Prefix registry sought by > draft-gudmundsson-dns-srv-iana-registry. I'm guessing that you are referring to draft-ietf-behave-turn. I don't = know what information you base your allegation on, but it is incorrect; = "the IESG" has not "caused" any registration in the WKS registry in this = case. What happened is this: IANA (ticket #272953) wanted to confirm whether = their planned actions upon publication of the draft were correct, like = they always do. Their interpretation of the draft text was that a = registration in the WKS registry should happen. Magnus and me suggested = to *instead* add an alias to the ports registry on the ports registered = for STUN (since TURN is a STUN extension). One of the working group = chairs disagreed with this and preferred what IANA had suggested = (registration in the WKS registry). During the follow-on discussion, we = agreed that there was no harm to do both of those actions. > These and other details seem to confirm suspicion that the hastily > performed misappropriation of subject matter out-of-scope for TSVWG > did not even carefully pay attention to the needs of these topics. I'm not going to respond to this. Lars= --Apple-Mail-8-432087357 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTExMTA0MDI0MVowIwYJKoZIhvcNAQkEMRYEFJnNqZQnDZq3iF8jS2nywb4QhVUTMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBqVaN0Jbe4aK0dFYP47m54yIFOhXxyr1+HQC66FGV3AJt8vlRk7lwPUbLc8uGdzQbh/iAj 3KArJuR5v4nqX9hJD8ygYw3UyZfZpHWNPSmHc875zavkkLw6hUUbUVRdapaLHLsRBCv585dtYF0S 9fg1KBWSshGIPXVmpZVUV9jQ3TzmZs015HnvRhbSWesx05qCubv3LTc+WSWQFY0jQI2E5Ug9Vumk bSYGoE17QTByNBnvzsgi1EJUNn0+zZiUbqiNAiBv2vnvEGrM4ky/TR2aXvoUZQx1Nepjq88+/+3p 2rYFHQ+U10IdRTSKrK6akC6ajDYR3k1ZbDzL2J7yl6qBAAAAAAAA --Apple-Mail-8-432087357-- From magnus.westerlund@ericsson.com Tue Nov 10 21:12:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE23E3A6A39; Tue, 10 Nov 2009 21:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dcmn3DLd6j0; Tue, 10 Nov 2009 21:12:14 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9D1E33A6910; Tue, 10 Nov 2009 21:12:13 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-40-4afa47c7628b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 71.B5.31706.7C74AFA4; Wed, 11 Nov 2009 06:12:39 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 06:12:39 +0100 Received: from [153.88.53.6] ([153.88.53.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 06:12:38 +0100 Message-ID: <4AFA47C3.3030802@ericsson.com> Date: Wed, 11 Nov 2009 14:12:35 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [apps-discuss] service names - one registry vs. two registries References: <200911102048.VAA06919@TR-Sys.de> <1FBE43C6-1EF4-4443-828F-6AAFAF83A781@nokia.com> In-Reply-To: <1FBE43C6-1EF4-4443-828F-6AAFAF83A781@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Nov 2009 05:12:38.0813 (UTC) FILETIME=[967C74D0:01CA628D] X-Brightmail-Tracker: AAAAAA== Cc: "apps-discuss@ietf.org" , ah@tr-sys.de, "tsvwg@ietf.org" , draft-ietf-tsvwg-iana-ports@tools.IETF.ORG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:12:15 -0000 Lars Eggert skrev: > >> It has been observed with surprise that apparently the IESG has >> caused IANA to perform registrations in the WKS registry for a >> draft that did not even request that; that draft talks about SRV >> usage, not WKS, and hence the matching registrations would have >> been suitable for the DNS SRV Service Prefix registry sought by >> draft-gudmundsson-dns-srv-iana-registry. > > I'm guessing that you are referring to draft-ietf-behave-turn. I don't know what information you base your allegation on, but it is incorrect; "the IESG" has not "caused" any registration in the WKS registry in this case. > Actually I think this is in regard to the MIPSHOP document that resulted in the adding of the following entries. MIHCS - MIH Command Services [RFC-ietf-mipshop-mos-dns-discovery-07.txt] MIHES - MIH Event Services [RFC-ietf-mipshop-mos-dns-discovery-07.txt] MIHIS - MIH Information Services [RFC-ietf-mipshop-mos-dns-discovery-07.txt] This is the result of IESG discussion around this. The document requested getting service names. If you look at RFC 2782 it points to RFC 1700 in the following way: Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. The only registry that can be interpreted as being the service name in RFC 1700 is the registry that currently are in: http://www.iana.org/assignments/service-names Due to the very fuzzy reference and lack of clear registration rules has resulted in the registrations in other registries and the setup of an non IANA registry. So I don't think IESG was wrong to make the registration we did. However, service names clearly needs to be clarified and thus working towards approval and publication of a RFC that has IETF consensus is clearly need. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From A.Hoenes@TR-Sys.de Wed Nov 11 03:20:35 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77CF3A6851; Wed, 11 Nov 2009 03:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkHLbA-kev8Q; Wed, 11 Nov 2009 03:20:34 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 654F73A67ED; Wed, 11 Nov 2009 03:20:33 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA116588397; Wed, 11 Nov 2009 12:19:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA07623; Wed, 11 Nov 2009 12:19:51 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911111119.MAA07623@TR-Sys.de> Subject: Re: [apps-discuss] service names - one registry vs. two registries To: lars.eggert@nokia.com Date: Wed, 11 Nov 2009 12:19:51 +0100 (MEZ) In-Reply-To: <1FBE43C6-1EF4-4443-828F-6AAFAF83A781@nokia.com> from Lars Eggert at Nov "11, " 2009 "01:02:41" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:20:35 -0000 Lars, thanks for your response. A few clarifications in-line. I defer to Olafur for more information on specific details and requirements. Lars Eggert wrote: > I expect we will continue to be at opposites sides of this debate. > But I'd like to correct a few things that I think you're overstating. > > On 2009-11-11, at 5:48, ah@tr-sys.de wrote: >> Incorporation of non-RFC material has been excluded from our draft >> on advice from the IESG, in order to avoid IETF procedural and IPR >> concerns for a document intended to amend a Standards Track RFC (2782). > ... >> Lars, >> it sounds strange for you to blame us of following advice from >> inside the IESG. > > There has been no "advice from the IESG". You may have gotten advice > from an individual AD, which is not the same. When we speak as > "the IESG", we run a consensus call (such as when we approve > documents). This hasn't happened here. Indeed, I did not want to confuse the two different kind of statement, and actually had intended to type "from within the IESG" in the first sentenc you quote. However, this should have been disambiguated by the second quote, "advice from inside the IESG". >> The registry for WKS RR entries is out of scope of our draft and >> should better be out of scope for draft-ietf-tsvwg-iana-ports as well, >> for various reasons. >> It has been hibernating since years and should better not be revived >> (or have been revived) at all. > > I assume you're referring to > http://www.iana.org/assignments/service-names here. Right, the one you quote in the tsvwg-iana-ports draft and in your posting. These services are represented by the mnemonics in the registry in the presentation (zone/master file) format of WKS RRs and by a bit map in the WKS RR binary / on-the-wire format, and in practice, the translation is built in into DNS server implementations. > > We are not attempting to "revive" it. We're referring to it as a > source of grandfathered service names, and our ID actually asks IANA > to determine if that registry can be retired after that has happened > (Section 10). > > The reason we do this is that some of these may actually still be > in use somewhere, and hence should not be available for new > registrations. Acknowledged, if that is the intention; but that was not clear from the draft currently under WGLC in TSVWG. > > ... [snip] ... > > >> It has been observed with surprise that apparently the IESG has >> caused IANA to perform registrations in the WKS registry for a >> draft that did not even request that; that draft talks about SRV >> usage, not WKS, and hence the matching registrations would have >> been suitable for the DNS SRV Service Prefix registry sought by >> draft-gudmundsson-dns-srv-iana-registry. > > I'm guessing that you are referring to draft-ietf-behave-turn. > ... Magnus already has clarified the context here of MoS (RFC-to-be 5679). > ... > > Lars Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Nov 11 03:37:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355853A67A4; Wed, 11 Nov 2009 03:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.082 X-Spam-Level: ** X-Spam-Status: No, score=2.082 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRV-ZJR8ph0J; Wed, 11 Nov 2009 03:37:14 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 22C983A6848; Wed, 11 Nov 2009 03:37:11 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA116679404; Wed, 11 Nov 2009 12:36:44 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA07645; Wed, 11 Nov 2009 12:36:26 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911111136.MAA07645@TR-Sys.de> Subject: Re: [apps-discuss] service names - one registry vs. two registries To: magnus.westerlund@ericsson.com Date: Wed, 11 Nov 2009 12:36:25 +0100 (MEZ) In-Reply-To: <4AFA47C3.3030802@ericsson.com> from Magnus Westerlund at Nov "11, " 2009 "02:12:35" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:37:15 -0000 Magnus, thanks for your clarifications and contributions. > Lars Eggert skrev: >> >>> It has been observed with surprise that apparently the IESG has >>> caused IANA to perform registrations in the WKS registry for a >>> draft that did not even request that; that draft talks about SRV >>> usage, not WKS, and hence the matching registrations would have >>> been suitable for the DNS SRV Service Prefix registry sought by >>> draft-gudmundsson-dns-srv-iana-registry. >> >> I'm guessing that you are referring to draft-ietf-behave-turn. >> I don't know what information you base your allegation on, but >> it is incorrect; "the IESG" has not "caused" any registration >> in the WKS registry in this case. > > Actually I think this is in regard to the MIPSHOP document that resulted > in the adding of the following entries. Thanks for this clarification. I did not want to go too deep into the details for not blaming anybody publicly wrt RFC-to-be 5679. > > MIHCS - MIH Command Services > [RFC-ietf-mipshop-mos-dns-discovery-07.txt] > MIHES - MIH Event Services > [RFC-ietf-mipshop-mos-dns-discovery-07.txt] > MIHIS - MIH Information Services > [RFC-ietf-mipshop-mos-dns-discovery-07.txt] > > This is the result of IESG discussion around this. The document > requested getting service names. If you look at RFC 2782 ... We once had agreed with the authors of that document that the SRV Service Prefix registry would be the proper target for the registration, and had promised to include them in the initial contents of that registry if that draft would be published earlier than ours -- which now will happen. The entries for the above services already linger in our draft's XML, but are still commented out, because the agreement was to refer to RFCs and only a few already widespread services in the initial registry content. Therefore, the registration in the WKS registry came to our surprise. > ... it points to RFC 1700 in the following way: > > Service > The symbolic name of the desired service, as defined in Assigned > Numbers [STD 2] or locally. > > The only registry that can be interpreted as being the service name in > RFC 1700 is the registry that currently are in: > http://www.iana.org/assignments/service-names That reasoning has been 100% correct at the time of publication of RFC 1700, because it predates NAPTR and SRV by years. > Due to the very fuzzy reference and lack of clear registration rules has > resulted in the registrations in other registries and the setup of an > non IANA registry. That's been part of the motivation for Olafur to write up the srv-iana-registry draft last year. > > So I don't think IESG was wrong to make the registration we did. > However, service names clearly needs to be clarified and thus working > towards approval and publication of a RFC that has IETF consensus is > clearly need. It is not expected that DNS server software will adopt these registrations because it would blow up the bit map in WKS to unreasonable size, that was intended for "Well-Known" services (ports 0..255 at the time of RFC 1035). Therefore I question the utility of performing this registration. > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Fdrvgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From magnus.westerlund@ericsson.com Wed Nov 11 17:30:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6D03A6B7A; Wed, 11 Nov 2009 17:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gO4fnMf2cg9; Wed, 11 Nov 2009 17:30:26 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8C8CF28C17B; Wed, 11 Nov 2009 17:30:25 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-46-4afb654c4ef6 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 62.2E.04191.C456BFA4; Thu, 12 Nov 2009 02:30:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:30:52 +0100 Received: from [153.88.46.204] ([153.88.46.204]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:30:51 +0100 Message-ID: <4AFB6548.9050705@ericsson.com> Date: Thu, 12 Nov 2009 10:30:48 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [apps-discuss] service names - one registry vs. two registries References: <200911111119.MAA07623@TR-Sys.de> In-Reply-To: <200911111119.MAA07623@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 01:30:52.0254 (UTC) FILETIME=[C5926FE0:01CA6337] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:30:27 -0000 Alfred, Alfred ďż˝ skrev: >> There has been no "advice from the IESG". You may have gotten advice >> from an individual AD, which is not the same. When we speak as >> "the IESG", we run a consensus call (such as when we approve >> documents). This hasn't happened here. > > Indeed, I did not want to confuse the two different kind of statement, > and actually had intended to type "from within the IESG" in the first > sentenc you quote. However, this should have been disambiguated by > the second quote, "advice from inside the IESG". > > I think it would been clearer if you simple pointed at the source of the input, i.e. the AD. >>> The registry for WKS RR entries is out of scope of our draft and >>> should better be out of scope for draft-ietf-tsvwg-iana-ports as well, >>> for various reasons. >>> It has been hibernating since years and should better not be revived >>> (or have been revived) at all. >> I assume you're referring to >> http://www.iana.org/assignments/service-names here. > > Right, the one you quote in the tsvwg-iana-ports draft and in your > posting. > These services are represented by the mnemonics in the registry > in the presentation (zone/master file) format of WKS RRs and by a > bit map in the WKS RR binary / on-the-wire format, and in practice, > the translation is built in into DNS server implementations. > I would classify this as unintentional effects. However, if that is how DNS SRVs was setup in this way, I don't know what to do about that side-effect. >From my perspective I tried to avoid blocking the document from being published due to that the service name registry fix wasn't ready. Also I had come to realization that we do need to pull in the names in Protocol and Service registry. However, at the time of performing this action our draft did not yet reflect that. >> We are not attempting to "revive" it. We're referring to it as a >> source of grandfathered service names, and our ID actually asks IANA >> to determine if that registry can be retired after that has happened >> (Section 10). >> >> The reason we do this is that some of these may actually still be >> in use somewhere, and hence should not be available for new >> registrations. > > Acknowledged, if that is the intention; but that was not clear from > the draft currently under WGLC in TSVWG. > We are not yet in WG last call. We know that we need another round of changes to clarify additional things. Then I hope we will be ready for WG last call. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Nov 11 17:59:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD2D3A68FC; Wed, 11 Nov 2009 17:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1e0xHBcpYqR; Wed, 11 Nov 2009 17:59:26 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 178FC3A689F; Wed, 11 Nov 2009 17:59:25 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-12-4afb6c196b0b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A2.F6.24094.91C6BFA4; Thu, 12 Nov 2009 02:59:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:59:53 +0100 Received: from [153.88.46.204] ([153.88.46.204]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:59:52 +0100 Message-ID: <4AFB6C15.6030207@ericsson.com> Date: Thu, 12 Nov 2009 10:59:49 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [apps-discuss] service names - one registry vs. two registries References: <200911111136.MAA07645@TR-Sys.de> In-Reply-To: <200911111136.MAA07645@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 01:59:52.0754 (UTC) FILETIME=[D2FDA920:01CA633B] X-Brightmail-Tracker: AAAAAA== Cc: apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:59:27 -0000 Alfred, See inline. Alfred ďż˝ skrev: > > Thanks for this clarification. I did not want to go too deep into > the details for not blaming anybody publicly wrt RFC-to-be 5679. > >> MIHCS - MIH Command Services >> [RFC-ietf-mipshop-mos-dns-discovery-07.txt] >> MIHES - MIH Event Services >> [RFC-ietf-mipshop-mos-dns-discovery-07.txt] >> MIHIS - MIH Information Services >> [RFC-ietf-mipshop-mos-dns-discovery-07.txt] >> >> This is the result of IESG discussion around this. The document >> requested getting service names. If you look at RFC 2782 ... > > We once had agreed with the authors of that document that the > SRV Service Prefix registry would be the proper target for the > registration, and had promised to include them in the initial > contents of that registry if that draft would be published > earlier than ours -- which now will happen. The entries for the > above services already linger in our draft's XML, but are still > commented out, because the agreement was to refer to RFCs and only > a few already widespread services in the initial registry content. > Therefore, the registration in the WKS registry came to our surprise. I think there has been communication issues here. If anyone of the authors or doc shepherd had raised this when we proposed the fix to the error in the IANA section. We didn't allow the document to be published without a registration that actually would ensure that the three service names needed ended up in a registry. If the authors had made a normative reference to your registry document, we would have been aware of that. Which would have raised the overlap with our WG document. It would also have signaled the authors and WGs willingness to have the document hang until the registration would have finished. > > >> ... it points to RFC 1700 in the following way: >> >> Service >> The symbolic name of the desired service, as defined in Assigned >> Numbers [STD 2] or locally. >> >> The only registry that can be interpreted as being the service name in >> RFC 1700 is the registry that currently are in: >> http://www.iana.org/assignments/service-names > > That reasoning has been 100% correct at the time of publication > of RFC 1700, because it predates NAPTR and SRV by years. Well, I don't know how much we need to continue this discussion. We can only state that it is unfortunate that the SRV RFCs wasn't very clear on what the registry was to be used. So lets make progress on getting a new well defined service name in place and take care of the issues that we know about that. We definitely appreciate input and suggestions for improvements. > > >> Due to the very fuzzy reference and lack of clear registration rules has >> resulted in the registrations in other registries and the setup of an >> non IANA registry. > > That's been part of the motivation for Olafur to write up the > srv-iana-registry draft last year. Yes, and the author team had service name discussions in Irland, with Stuart Cheshire. Unfortunately we clearly failed to make the larger community aware of our efforts. > >> So I don't think IESG was wrong to make the registration we did. >> However, service names clearly needs to be clarified and thus working >> towards approval and publication of a RFC that has IETF consensus is >> clearly need. > > It is not expected that DNS server software will adopt these > registrations because it would blow up the bit map in WKS to > unreasonable size, that was intended for "Well-Known" services > (ports 0..255 at the time of RFC 1035). Therefore I question > the utility of performing this registration. > Ok, I will talk to Olafur about these issues. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From A.Hoenes@TR-Sys.de Wed Nov 11 19:27:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F3D3A6B3F; Wed, 11 Nov 2009 19:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.069 X-Spam-Level: ** X-Spam-Status: No, score=2.069 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72CGhGriumQb; Wed, 11 Nov 2009 19:27:45 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 25EBB3A6B6A; Wed, 11 Nov 2009 19:27:43 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA120676417; Thu, 12 Nov 2009 04:26:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id EAA09199; Thu, 12 Nov 2009 04:26:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911120326.EAA09199@TR-Sys.de> Subject: Re: [apps-discuss] service names - one registry vs. two registries To: magnus.westerlund@ericsson.com Date: Thu, 12 Nov 2009 04:26:55 +0100 (MEZ) In-Reply-To: <4AFB6548.9050705@ericsson.com> from Magnus Westerlund at Nov "12, " 2009 "10:30:48" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:27:46 -0000 At Thu, 12 Nov 2009 10:30:48 +0900, Magnus Westerlund wrote: > Alfred, > > > Alfred skrev: >>> There has been no "advice from the IESG". You may have gotten advice >>> from an individual AD, which is not the same. When we speak as >>> "the IESG", we run a consensus call (such as when we approve >>> documents). This hasn't happened here. >> >> Indeed, I did not want to confuse the two different kind of statement,= >> and actually had intended to type "from within the IESG" in the first >> sentence you quote. However, this should have been disambiguated by >> the second quote, "advice from inside the IESG". > > I think it would been clearer if you simple pointed at the source of th= e > input, i.e. the AD. I didn't talk to any AD personally in the early stages; when I joined Olafur's caravana before IETF 73, there was no contention, and when Olafur eventually was able to resume work on the draft, the responsibility in the IESG had changed. So I was not aware of the details, and saying "some AD" instead seemed a bit too stupid. >>>> The registry for WKS RR entries is out of scope of our draft and >>>> should better be out of scope for draft-ietf-tsvwg-iana-ports as wel= l, >>>> for various reasons. >>>> It has been hibernating since years and should better not be revived= >>>> (or have been revived) at all. >>> I assume you're referring to >>> http://www.iana.org/assignments/service-names here. >> >> Right, the one you quote in the tsvwg-iana-ports draft and in your >> posting. >> These services are represented by the mnemonics in the registry >> in the presentation (zone/master file) format of WKS RRs and by a >> bit map in the WKS RR binary / on-the-wire format, and in practice, >> the translation is built in into DNS server implementations. > > I would classify this as unintentional effects. However, if that is > how DNS SRVs was setup in this way, I don't know what to do about > that side-effect. Oh, please do not confuse the leagacy WKS RR with SRV, invented roughly a decade later! Both are as different as could be. SRV carries the Service to look for in the owner name, i.e. its location in the DNS database tree, and it returns the FQDN of the host offering that service for the whole domain (identified in the SRV owner name as well, after the Service Prefix), whereas WKS simply returns the bit map of Well-Known Services offered at a given host (its owner name) -- these were indeed the services in the 0..255 port number range dedicated to Well-Known Services in the age of RFC 1035 and 1122. > >From my perspective I tried to avoid blocking the document from being > published due to that the service name registry fix wasn't ready. Also = I > had come to realization that we do need to pull in the names in Protoco= l > and Service registry. However, at the time of performing this action ou= r > draft did not yet reflect that. I recognize the good will behind the action, but ... Since the IEEE MoS services do not have a fixed port number assigned by IANA (RFC-to-be 5679 didn't ask for), entering MIHIS, MIHES, and MIHCS into the registry for WKS does not make sense. The heading of http://www.IANA.ORG/assignments/service-names is rather explicit: "Note: These are the Official Protocol Names as they appear in the Domain Name System WKS records and the NIC Host Table. Their use is described in [RFC952]." WKS had been created in the effort to migrate the data from the ARPANET "NIC Host Table" into the DNS and thereby separating address info from Well-Known Service info. (BSD created the /etc/hosts file that did not contain the list of WKSes for all listed hosts any more, and /etc/services listing the service_name-to-port mappings for locally "interesting" services -- no more per-known-host offered WKS lists; that information was fed into the DNS via the WKS RR.) It looks like you also got caught in one of the temptive traps awaiting visitors of the IANA site, with so many registries having titles making it hard to guess correctly at first glance what they are good for. :-) The SRV Service Prefix now seems to find creative use, adding more labels to the left, e.g. in a recent I-D (already challenged) _nfsv4._domainroot._tcp.bigbank.example. and: _nfsv4._write._domainroot._tcp.bigbank.example. >>> We are not attempting to "revive" it. We're referring to it as a >>> source of grandfathered service names, and our ID actually asks IANA >>> to determine if that registry can be retired after that has happened >>> (Section 10). >>> >>> The reason we do this is that some of these may actually still be >>> in use somewhere, and hence should not be available for new >>> registrations. Exactly, a domain server conforming to RFC 1035 needs to be able to read zone (master) files containing WKS records in the presentation form and to translate the keywords (commonly uppercase-only) into bit positions. Whenever a secondary authoritative server transfers a zone copy from a prmary server, it needs to translate from on-the-wire format to presentation format to store the zone content into a local file that can be used to reload the zone after a server restert. Given the infrastructure nature of the DNS and the underspecified syntax of the IANA registry file making it rather unsuitable for automated lookup, online lookup of the registry whenever a DNS server starts up or updates a zone file does not make sense. That's why in many DNS server implementations the WKS table is hardcoded or loaded from a file shipped by the vendor and rarely updated in deployments. >> >> Acknowledged, if that is the intention; but that was not clear from >> the draft currently under WGLC in TSVWG. > > We are not yet in WG last call. We know that we need another round of > changes to clarify additional things. Then I hope we will be ready for > WG last call. Oh sorry, you are right. I must have confused some of the WGLCs called out recently. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=CCr=CEgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From magnus.westerlund@ericsson.com Wed Nov 11 20:27:27 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EED03A69D6; Wed, 11 Nov 2009 20:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hcIFchTp0MG; Wed, 11 Nov 2009 20:27:26 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 260B13A68CE; Wed, 11 Nov 2009 20:27:24 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-d9-4afb8ec8b213 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 0C.88.31706.8CE8BFA4; Thu, 12 Nov 2009 05:27:52 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 05:26:28 +0100 Received: from [153.88.46.204] ([153.88.46.204]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 05:26:28 +0100 Message-ID: <4AFB8E71.307@ericsson.com> Date: Thu, 12 Nov 2009 13:26:25 +0900 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [apps-discuss] service names - one registry vs. two registries References: <200911120326.EAA09199@TR-Sys.de> In-Reply-To: <200911120326.EAA09199@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Nov 2009 04:26:28.0470 (UTC) FILETIME=[4DA56960:01CA6350] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:27:27 -0000 Alfred, Alfred ďż˝ skrev: > At Thu, 12 Nov 2009 10:30:48 +0900, Magnus Westerlund wrote: >> Alfred, >> >> >> Alfred skrev: >>>> There has been no "advice from the IESG". You may have gotten advice >>>> from an individual AD, which is not the same. When we speak as >>>> "the IESG", we run a consensus call (such as when we approve >>>> documents). This hasn't happened here. >>> Indeed, I did not want to confuse the two different kind of statement, >>> and actually had intended to type "from within the IESG" in the first >>> sentence you quote. However, this should have been disambiguated by >>> the second quote, "advice from inside the IESG". >> I think it would been clearer if you simple pointed at the source of the >> input, i.e. the AD. > > I didn't talk to any AD personally in the early stages; > when I joined Olafur's caravana before IETF 73, there was no > contention, and when Olafur eventually was able to resume work > on the draft, the responsibility in the IESG had changed. > So I was not aware of the details, and saying "some AD" instead > seemed a bit too stupid. > Well, it would have been more correct as saying IESG implies some consensus from us as a group. > >>>>> The registry for WKS RR entries is out of scope of our draft and >>>>> should better be out of scope for draft-ietf-tsvwg-iana-ports as well, >>>>> for various reasons. >>>>> It has been hibernating since years and should better not be revived >>>>> (or have been revived) at all. >>>> I assume you're referring to >>>> http://www.iana.org/assignments/service-names here. >>> Right, the one you quote in the tsvwg-iana-ports draft and in your >>> posting. >>> These services are represented by the mnemonics in the registry >>> in the presentation (zone/master file) format of WKS RRs and by a >>> bit map in the WKS RR binary / on-the-wire format, and in practice, >>> the translation is built in into DNS server implementations. >> I would classify this as unintentional effects. However, if that is >> how DNS SRVs was setup in this way, I don't know what to do about >> that side-effect. > > Oh, please do not confuse the leagacy WKS RR with SRV, invented > roughly a decade later! Both are as different as could be. > > SRV carries the Service to look for in the owner name, i.e. its > location in the DNS database tree, and it returns the FQDN of the > host offering that service for the whole domain (identified in the SRV > owner name as well, after the Service Prefix), whereas WKS simply > returns the bit map of Well-Known Services offered at a given host > (its owner name) -- these were indeed the services in the 0..255 port > number range dedicated to Well-Known Services in the age of > RFC 1035 and 1122. Yes, I have been educated by Olafur. > >> >From my perspective I tried to avoid blocking the document from being >> published due to that the service name registry fix wasn't ready. Also I >> had come to realization that we do need to pull in the names in Protocol >> and Service registry. However, at the time of performing this action our >> draft did not yet reflect that. > > I recognize the good will behind the action, but ... > > Since the IEEE MoS services do not have a fixed port number > assigned by IANA (RFC-to-be 5679 didn't ask for), entering MIHIS, > MIHES, and MIHCS into the registry for WKS does not make sense. > > The heading of http://www.IANA.ORG/assignments/service-names > is rather explicit: > > "Note: > These are the Official Protocol Names as they appear in the Domain > Name System WKS records and the NIC Host Table. Their use is > described in [RFC952]." > > WKS had been created in the effort to migrate the data from the > ARPANET "NIC Host Table" into the DNS and thereby separating address > info from Well-Known Service info. > (BSD created the /etc/hosts file that did not contain the list of > WKSes for all listed hosts any more, and /etc/services listing the > service_name-to-port mappings for locally "interesting" services -- > no more per-known-host offered WKS lists; that information was fed > into the DNS via the WKS RR.) > > It looks like you also got caught in one of the temptive traps > awaiting visitors of the IANA site, with so many registries having > titles making it hard to guess correctly at first glance what they > are good for. > :-) > Well, I am not the only one that has made this interpretation of the RFC 2782 to point at the Protocol and Services list. However, but this will be clarified when we can make progress on the document. Creating the service registry and then have your and Olafurs document update RFC 2782 will solve things. > > The SRV Service Prefix now seems to find creative use, adding > more labels to the left, e.g. in a recent I-D (already challenged) > > _nfsv4._domainroot._tcp.bigbank.example. > and: _nfsv4._write._domainroot._tcp.bigbank.example. > Ok > >>>> We are not attempting to "revive" it. We're referring to it as a >>>> source of grandfathered service names, and our ID actually asks IANA >>>> to determine if that registry can be retired after that has happened >>>> (Section 10). >>>> >>>> The reason we do this is that some of these may actually still be >>>> in use somewhere, and hence should not be available for new >>>> registrations. > > Exactly, a domain server conforming to RFC 1035 needs to be able to > read zone (master) files containing WKS records in the presentation > form and to translate the keywords (commonly uppercase-only) into > bit positions. Whenever a secondary authoritative server transfers > a zone copy from a prmary server, it needs to translate from > on-the-wire format to presentation format to store the zone content > into a local file that can be used to reload the zone after a server > restert. > Given the infrastructure nature of the DNS and the underspecified > syntax of the IANA registry file making it rather unsuitable for > automated lookup, online lookup of the registry whenever a DNS > server starts up or updates a zone file does not make sense. > That's why in many DNS server implementations the WKS table is > hardcoded or loaded from a file shipped by the vendor and rarely > updated in deployments. > Olafur explained that it has been recommended against using WKS for over 20 years. We should grandfather that registry as soon as have created the service registry. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From alexey.melnikov@isode.com Wed Nov 11 21:13:40 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA05E3A68E6; Wed, 11 Nov 2009 21:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE073ZWRepaK; Wed, 11 Nov 2009 21:13:40 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 22A723A6875; Wed, 11 Nov 2009 21:13:39 -0800 (PST) Received: from [133.93.16.183] (host-16-183.meeting.ietf.org [133.93.16.183]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Nov 2009 05:14:06 +0000 Message-ID: <4AFB9998.3030206@isode.com> Date: Thu, 12 Nov 2009 14:14:00 +0900 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Magnus Westerlund Subject: Re: [apps-discuss] service names - one registry vs. two registries References: <200911111119.MAA07623@TR-Sys.de> <4AFB6548.9050705@ericsson.com> In-Reply-To: <4AFB6548.9050705@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:13:41 -0000 Magnus Westerlund wrote: > Alfred, > > Alfred =EF=BF=BD skrev: > =20 >>> There has been no "advice from the IESG". You may have gotten advice >>> from an individual AD, which is not the same. When we speak as >>> "the IESG", we run a consensus call (such as when we approve >>> documents). This hasn't happened here. >>> =20 >> Indeed, I did not want to confuse the two different kind of statement, >> and actually had intended to type "from within the IESG" in the first >> sentenc you quote. However, this should have been disambiguated by >> the second quote, "advice from inside the IESG". >> =20 > I think it would been clearer if you simple pointed at the source of the > input, i.e. the AD. > =20 I believe I gave the advice and I was talking as myself only (but maybe=20 it wasn't entirely clear). From joe@bitworking.org Wed Nov 11 22:18:17 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD2528C0DD for ; Wed, 11 Nov 2009 22:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7fRa4peBaEY for ; Wed, 11 Nov 2009 22:18:16 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9B03B3A681F for ; Wed, 11 Nov 2009 22:18:16 -0800 (PST) Received: by ywh13 with SMTP id 13so2203581ywh.29 for ; Wed, 11 Nov 2009 22:18:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.106.24 with SMTP id i24mr2228476anm.141.1258006719691; Wed, 11 Nov 2009 22:18:39 -0800 (PST) In-Reply-To: <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> Date: Thu, 12 Nov 2009 17:18:39 +1100 Message-ID: Subject: Re: Input on request for link relation From: Joe Gregorio To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Atom-Syntax Syntax , HTTP Working Group , Hadrien Gardeur , Ian Hickson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 06:18:17 -0000 On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham wrote: > > On 16/09/2009, at 7:46 PM, Sam Johnston wrote: >> Would it be possible then to support multiple references so that people >> can see at a glance that a given relation is implemented as described in >> multiple formats (rather than just the first format that happened to >> register it)? May well not be worth the maintenance effort. > > How about adding a new field for references to more information about how= a > relation is used in a particular context (scoped by context media type)? > > E.g., > > References regarding use in specific contexts: > =A0 =A0text/html: [HTML5] > =A0 =A0application/atom+xml: [RFC4287] > Yes, that sounds like a great idea. And vaguely familiar: http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0699.html Thanks, -joe From samj@samj.net Thu Nov 12 02:23:46 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D753A68B9 for ; Thu, 12 Nov 2009 02:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8SCVIVZVZXw for ; Thu, 12 Nov 2009 02:23:45 -0800 (PST) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by core3.amsl.com (Postfix) with SMTP id 0205D28C13E for ; Thu, 12 Nov 2009 02:23:42 -0800 (PST) Received: from source ([209.85.160.48]) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKSvviSyOxGFTWSKWwVYz5S+Ftp4QakeZd@postini.com; Thu, 12 Nov 2009 10:24:12 UTC Received: by pwj12 with SMTP id 12so1425398pwj.27 for ; Thu, 12 Nov 2009 02:24:10 -0800 (PST) References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> From: Sam Johnston In-Reply-To: Mime-Version: 1.0 (iPhone Mail 7D11) Date: Thu, 12 Nov 2009 11:24:11 +0100 Received: by 10.140.170.10 with SMTP id s10mr153470rve.72.1258021449463; Thu, 12 Nov 2009 02:24:09 -0800 (PST) Message-ID: <-2851311788142652426@unknownmsgid> Subject: Re: Input on request for link relation To: Joe Gregorio Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , Atom-Syntax Syntax , HTTP Working Group , Hadrien Gardeur , Ian Hickson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 10:23:46 -0000 Another requirement I've stumbled on is the ability to group links. For OCCI for example we want to give users the ability to create their own actions (eg start, stop, restart) which will be advertised in the HTTP headers and/or HTML HEAD. Currently each action has it's own (opaque URI-based) rel so I have proposed class="action" be added for grouping. Alternatively we could do rel="[http://purl.org/occi/] action" and refine the action with one or more custom attributes (type is not really appropriate here, nor when advertising protocol endpoints like SSH and RDP which is anoter problem we ran into). Pagination (eg first, last, next, previous) is another potentially interesting group. Though the semantics are mostly predefined one could envisage links like "next 100", "next 1000". Sam on iPhone On 12/11/2009, at 7:18, Joe Gregorio wrote: > On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham > wrote: >> >> On 16/09/2009, at 7:46 PM, Sam Johnston wrote: >>> Would it be possible then to support multiple references so that >>> people >>> can see at a glance that a given relation is implemented as >>> described in >>> multiple formats (rather than just the first format that happened to >>> register it)? May well not be worth the maintenance effort. >> >> How about adding a new field for references to more information >> about how a >> relation is used in a particular context (scoped by context media >> type)? >> >> E.g., >> >> References regarding use in specific contexts: >> text/html: [HTML5] >> application/atom+xml: [RFC4287] >> > > Yes, that sounds like a great idea. And vaguely familiar: > > http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/ > 0699.html > > Thanks, > -joe From lear@cisco.com Thu Nov 12 03:14:45 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6073A6833; Thu, 12 Nov 2009 03:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgd+0cnpXw26; Thu, 12 Nov 2009 03:14:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3AF983A6842; Thu, 12 Nov 2009 03:14:44 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAMd8+0qQ/uCWe2dsb2JhbACEcpcmAQEWJAanTYcOkHaBMII4VAQ X-IronPort-AV: E=Sophos;i="4.44,727,1249257600"; d="scan'208";a="54230490" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2009 11:15:12 +0000 Received: from ams3-vpn-dhcp6956.cisco.com (ams3-vpn-dhcp6956.cisco.com [10.61.91.43]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nACBFBh3023716; Thu, 12 Nov 2009 11:15:11 GMT Message-ID: <4AFBEE3F.9090701@cisco.com> Date: Thu, 12 Nov 2009 12:15:11 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091108 Shredder/3.0pre MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [tsvwg] [apps-discuss] service names - one registry vs. two registries References: <200911120326.EAA09199@TR-Sys.de> In-Reply-To: <200911120326.EAA09199@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 11:14:45 -0000 Before we get hung up so high in WKS, I have an alternate suggestion. Simply deprecate the registry. From samj@samj.net Thu Nov 12 16:28:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F423E28C16B for ; Thu, 12 Nov 2009 16:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-1.695, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+gGT6679GGh for ; Thu, 12 Nov 2009 16:28:23 -0800 (PST) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by core3.amsl.com (Postfix) with SMTP id 6D90C28C163 for ; Thu, 12 Nov 2009 16:28:22 -0800 (PST) Received: from source ([209.85.216.186]) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKSvyoQ9FUJcjin+EFj/nZ3NbllJMw05eb@postini.com; Fri, 13 Nov 2009 00:28:52 UTC Received: by pxi16 with SMTP id 16so2004087pxi.29 for ; Thu, 12 Nov 2009 16:28:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.125.15 with SMTP id x15mr6398rvc.0.1258072129824; Thu, 12 Nov 2009 16:28:49 -0800 (PST) In-Reply-To: <4AFC937E.8060500@dehora.net> References: <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> <-2851311788142652426@unknownmsgid> <4AFC937E.8060500@dehora.net> Date: Fri, 13 Nov 2009 01:28:49 +0100 Message-ID: <21606dcf0911121628o20229c2ao3f73648941381ef2@mail.gmail.com> Subject: Re: Input on request for link relation From: Sam Johnston To: Bill de hOra Content-Type: multipart/alternative; boundary=000e0cd290ba666775047835bebb Cc: "apps-discuss@ietf.org" , Atom-Syntax Syntax , HTTP Working Group , Hadrien Gardeur , Ian Hickson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:28:25 -0000 --000e0cd290ba666775047835bebb Content-Type: text/plain; charset=ISO-8859-1 Bill, On Fri, Nov 13, 2009 at 12:00 AM, Bill de hOra wrote: > > (opaque URI-based) rel so I have proposed class="action" be added for > > > where "occi" is registered as for use by occi. > > IOW allow the link registry to define rel scopes. The url or clash thing > sucks and I don't want someone rolling up with a curies/qnames or some other > XML macrocrap proposal for Atom. > Thanks for the feedback - this is an interesting idea, however it's not immediately clear to me how this helps us as one of our main motivations is that others can create their own actions without bothering us or having to be registered. Basically we'd be trading one opaque identifier that doesn't need to be registered for a shorter one that does and unless we were to accept petitions from the public it would still not be possible to identify which relations are "actions" anyway (consider "stop@occi" vs "quiesce@vendor"). The use case is the client saying "ok all these things are actions so even if I don't understand what "quiesce" means I can still show a button to the user in the right place". A reversed, dotted domain format ala "org.occi-wg.action.stop" was something else we considered but it too would not enjoy backwards compatibility with existing implementations. It would however provide a simple solution to the registry "problem" and could be easily differentiated from "short" relations by the presence of "." and URIs by ":" (or some other regexps). That is to say, it's compatible with what we have today, infinitely scalable, distributed, concise, basically everything you want in an identifier. Sam > Sam Johnston wrote: > >> Another requirement I've stumbled on is the ability to group links. >> For OCCI for example we want to give users the ability to create their >> own actions (eg start, stop, restart) which will be advertised in the >> HTTP headers and/or HTML HEAD. Currently each action has it's own >> (opaque URI-based) rel so I have proposed class="action" be added for >> grouping. Alternatively we could do rel="[http://purl.org/occi/] >> action" and refine the action with one or more custom attributes (type >> is not really appropriate here, nor when advertising protocol >> endpoints like SSH and RDP which is anoter problem we ran into). >> >> Pagination (eg first, last, next, previous) is another potentially >> interesting group. Though the semantics are mostly predefined one >> could envisage links like "next 100", "next 1000". >> >> Sam on iPhone >> >> On 12/11/2009, at 7:18, Joe Gregorio wrote: >> >> On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham >>> wrote: >>> >>>> On 16/09/2009, at 7:46 PM, Sam Johnston wrote: >>>> >>>>> Would it be possible then to support multiple references so that >>>>> people >>>>> can see at a glance that a given relation is implemented as >>>>> described in >>>>> multiple formats (rather than just the first format that happened to >>>>> register it)? May well not be worth the maintenance effort. >>>>> >>>> How about adding a new field for references to more information >>>> about how a >>>> relation is used in a particular context (scoped by context media >>>> type)? >>>> >>>> E.g., >>>> >>>> References regarding use in specific contexts: >>>> text/html: [HTML5] >>>> application/atom+xml: [RFC4287] >>>> >>>> Yes, that sounds like a great idea. And vaguely familiar: >>> >>> http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/ >>> 0699.html >>> >>> Thanks, >>> -joe >>> >> >> > --000e0cd290ba666775047835bebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bill,

On Fri, Nov 13, 2009 at 12:00 AM, Bill de hOra <bil= l@dehora.net> wrote:
> (opaque URI-based) rel so I have proposed class=3D"action&qu= ot; be added for

<link rel=3D"stop@occi"

where "occi" is registered as for use by occi.

IOW allow the link registry to define rel scopes. The url or clash thing su= cks and I don't want someone rolling up with a curies/qnames or some ot= her XML macrocrap proposal for Atom.

Thanks for the feedback - this is a= n interesting idea, however it's not immediately clear to me how this h= elps us as one of our main motivations is that others can create their own = actions without bothering us or having to be registered.

Basically we'd be trading one opaque identifier tha= t doesn't need to be registered for a shorter one that does and unless = we were to accept petitions from the public it would still not be possible = to identify which relations are "actions" anyway (consider "= stop@occi" vs "quiesce@vendor"). The use case is the client = saying "ok all these things are actions so even if I don't underst= and what "quiesce" means I can still show a button to the user in= the right place".

A reversed, dotted domain format ala "org.occi-wg.= action.stop" was something else we considered but it too would not enj= oy backwards compatibility with existing implementations. It would however = provide a simple solution to the registry "problem" and could be = easily differentiated from "short" relations by the presence of &= quot;." and URIs by ":" (or some other regexps). That is to = say, it's compatible with what we have today, infinitely scalable, dist= ributed, concise, basically everything you want in an identifier.

Sam
=A0
Sam Johnston wrote:
Another requirement I've stumbled on is the ability to group links.
For OCCI for example we want to give users the ability to create their
own actions (eg start, stop, restart) which will be advertised in the
HTTP headers and/or HTML HEAD. Currently each action has it's own
(opaque URI-based) rel so I have proposed class=3D"action" be add= ed for
grouping. Alternatively we could do rel=3D"[http://purl.org/occi/]
action" and refine the action with one or more custom attributes (type=
is not really appropriate here, nor when advertising protocol
endpoints like SSH and RDP which is anoter problem we ran into).

Pagination (eg first, last, next, previous) is another potentially
interesting group. Though the semantics are mostly predefined one
could envisage links like "next 100", "next 1000".

Sam on iPhone

On 12/11/2009, at 7:18, Joe Gregorio <joe@bitworking.org> wrote:

On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham <mnot@mnot.net>
wrote:
On 16/09/2009, at 7:46 PM, Sam Johnston wrote:
Would it be possible then to support multiple references so that
people
can see at a glance that a given relation is implemented as
described in
multiple formats (rather than just the first format that happened to
register it)? May well not be worth the maintenance effort.
How about adding a new field for references to more information
about how a
relation is used in a particular context (scoped by context media
type)?

E.g.,

References regarding use in specific contexts:
=A0 text/html: [HTML5]
=A0 application/atom+xml: [RFC4287]

Yes, that sounds like a great idea. And vaguely familiar:

=A0http://lists.w3.org/Archives/Public/ietf-http-wg/2009Ju= lSep/
0699.html

=A0Thanks,
=A0-joe



--000e0cd290ba666775047835bebb-- From jpanzer@google.com Fri Nov 6 14:03:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4DB3A677E for ; Fri, 6 Nov 2009 14:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6JcbPjfUkZG for ; Fri, 6 Nov 2009 14:03:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 5324A3A68D6 for ; Fri, 6 Nov 2009 14:03:54 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id nA6M4GML018812 for ; Fri, 6 Nov 2009 22:04:16 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257545057; bh=40OFnaFyX9EfHpVRDMFajAWYQ9k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Kq1Kp75+j1EsufmrpFaxfc3tPudhpn9VaB6ItGGRkzIs1S/XlbFgb+Te9Ha1ErPL3 g4mpJIKapDPmq2zKub2kA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=rV2OsDYt0yQZvLi+F1c5q+AyRuntTQssngA2CGvrF6eUc5lEeNBPogr9nLyJfel14 hQjGkTvrZ0A2nLjIi8W4Q== Received: from pxi4 (pxi4.prod.google.com [10.243.27.4]) by wpaz29.hot.corp.google.com with ESMTP id nA6M4Dck024568 for ; Fri, 6 Nov 2009 14:04:14 -0800 Received: by pxi4 with SMTP id 4so947077pxi.6 for ; Fri, 06 Nov 2009 14:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.81.21 with SMTP id i21mr7279286wal.125.1257545053282; Fri, 06 Nov 2009 14:04:13 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 6 Nov 2009 14:04:13 -0800 Message-ID: Subject: Re: host-meta: template syntax hassles From: John Panzer To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=0016e64de80e30a0e60477bb06cf X-System-Of-Record: true X-Mailman-Approved-At: Sun, 15 Nov 2009 14:22:55 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:03:56 -0000 --0016e64de80e30a0e60477bb06cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm +1 on simplifying to 'uri' alone, because there is a fully capable workaround (server side rewriting/redirecting) that is well understood and is guaranteed to solve any specific problem with a small roundtrip cost. There was very strong consensus from the discussion at IIW, which included = a large # of the people who would depend on this spec. On Fri, Nov 6, 2009 at 1:44 PM, Eran Hammer-Lahav wrot= e: > This subject was discussed at length this week at IIW. The strong consens= us > was that since the currently proposed template vocabulary isn't expressiv= e > enough, it should be made even less expressive (only define 'uri') and no= t > more expressive (see one proposal below). The main argument were: > > - A future (richer) template syntax will address empty variables and the > proper assembling of URI components together. When it becomes available, > host-meta could be updated to define the full set of variables to support > such common transformations. > > - Any vocabulary breaking the context URI into parts will need a > complimentary method for applying links to resource subsets (at least bas= ed > on the URI scheme). For example, it is not likely that a single template > (using variables other than 'uri') will be able to properly address both > 'http' and 'xmpp' URI transformation. > > The second point is the most important in my view since it requires > extending the proposed document format to directly support describing > subsets of resources. I am more inclined to reduce the vocabulary to a > single 'uri' variable than extend both the vocabulary and schema to suppo= rt > richer scheme or pattern specific transformation. > > Since host-meta allows protocols to define their own 'rel'-specific > template syntax and vocabulary, individual protocols with such needs will > still be able to make use of the framework. In addition, servers can alwa= ys > use a simple redirection script to redirect a client to a more complex > location than provided by a single 'uri' variable. > > Comments? > > EHL > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Manger, James H > > Sent: Tuesday, October 27, 2009 3:52 PM > > To: apps-discuss@ietf.org > > Subject: RE: host-meta: template syntax hassles > > > > One solution (for simple, but correct, URI templates for common > > situations in host-meta) is to define more variables. > > > > For instance, in addition to 'scheme', 'authority', 'path', 'query'... > > offer the following variables: > > > > 'toDir' =97 the URI up to, but excluding, the last '/' in the path > > 'afterDir' =97 the URI from the last segment of the path to the end, > excluding the fragment > > 'toExt' =97 the URI up to, but excluding, the last '.' in the last segm= ent > of the path (or to the end of the path if there is no such dot) > > 'toPath' =97 the URI up to the end of the path > > 'afterPath' =97 the URI from after the path to the end, excluding the > fragment > > 'toQueryPlus' =97 the URI excluding any fragment, followed by '&' if th= ere > is a query string or '?' otherwise (ie ready for a new query parameter to= be > appended) > > 'beforeHost' =97 the URI up to, but excluding, the host > > 'fromHost' =97 the URI from the host to the end, excluding the fragment > > > > Template examples: > > {+toExt}.xrd{+afterPath} =97 replace, say, .html extension with .xrd to= get > metadata > > {+toQueryPlus}_=3Dmeta =97 add a query parameter named =93_=94 with a v= alue > =93meta=94 to get metadata > > {+toDir}/.meta/{+afterDir} =97 metadata is in a special .meta/ subdirec= tory > of each directory > > {+toPath};meta{+afterPath} =97 append =93;meta=94 to the path to get th= e > metadata > > {+beforeHost}meta.{+fromHost} =97metadata is hosted on a sub-domain > > > > The to/after (and before/from) pairs basically offer easy access to > > different points in the URI to insert a new element. I think these > > examples are fairly simple ways to implement common URI manipulations > > safely. > > > > James Manger > > James.H.Manger@team.telstra.com > > Identity and security team =97 Chief Technology Office =97 Telstra > > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer --0016e64de80e30a0e60477bb06cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm +1 on simplifying to 'uri' alone, because there is a fully = capable workaround (server side rewriting/redirecting) that is well underst= ood and is guaranteed to solve any specific problem with a small roundtrip = cost.

There was very strong consensus from the discussion at IIW, = which included a large # of the people who would depend on this spec.

On Fri, Nov 6, 2009 at 1:44 PM, Eran= Hammer-Lahav <= eran@hueniverse.com> wrote:
This subject was discussed at length this w= eek at IIW. The strong consensus was that since the currently proposed temp= late vocabulary isn't expressive enough, it should be made even less ex= pressive (only define 'uri') and not more expressive (see one propo= sal below). The main argument were:

- A future (richer) template syntax will address empty variables and the pr= oper assembling of URI components together. When it becomes available, host= -meta could be updated to define the full set of variables to support such = common transformations.

- Any vocabulary breaking the context URI into parts will need a compliment= ary method for applying links to resource subsets (at least based on the UR= I scheme). For example, it is not likely that a single template (using vari= ables other than 'uri') will be able to properly address both '= http' and 'xmpp' URI transformation.

The second point is the most important in my view since it requires extendi= ng the proposed document format to directly support describing subsets of r= esources. I am more inclined to reduce the vocabulary to a single 'uri&= #39; variable than extend both the vocabulary and schema to support richer = scheme or pattern specific transformation.

Since host-meta allows protocols to define their own 'rel'-specific= template syntax and vocabulary, individual protocols with such needs will = still be able to make use of the framework. In addition, servers can always= use a simple redirection script to redirect a client to a more complex loc= ation than provided by a single 'uri' variable.

Comments?

EHL


> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= Manger, James H
> Sent: Tuesday, October 27, 2009 3:52 PM
> To: apps-discuss@ietf.org=
> Subject: RE: host-meta: template syntax hassles
>
> One solution (for simple, but correct, URI templates for common
> situations in host-meta) is to define more variables.
>
> For instance, in addition to 'scheme', 'authority', &#= 39;path', 'query'...
> offer the following variables:
>
> 'toDir' =97 the URI up to, but excluding, the last '/'= in the path
> 'afterDir' =97 the URI from the last segment of the path to th= e end, excluding the fragment
> 'toExt' =97 the URI up to, but excluding, the last '.'= in the last segment of the path (or to the end of the path if there is no = such dot)
> 'toPath' =97 the URI up to the end of the path
> 'afterPath' =97 the URI from after the path to the end, exclud= ing the fragment
> 'toQueryPlus' =97 the URI excluding any fragment, followed by = '&' if there is a query string or '?' otherwise (ie rea= dy for a new query parameter to be appended)
> 'beforeHost' =97 the URI up to, but excluding, the host
> 'fromHost' =97 the URI from the host to the end, excluding the= fragment
>
> Template examples:
> {+toExt}.xrd{+afterPath} =97 replace, say, .html extension with .xrd t= o get metadata
> {+toQueryPlus}_=3Dmeta =97 add a query parameter named =93_=94 with a = value =93meta=94 to get metadata
> {+toDir}/.meta/{+afterDir} =97 metadata is in a special .meta/ subdire= ctory of each directory
> {+toPath};meta{+afterPath} =97 append =93;meta=94 to the path to get t= he metadata
> {+beforeHost}meta.{+fromHost} =97metadata is hosted on a sub-domain >
> The to/after (and before/from) pairs basically offer easy access to > different points in the URI to insert a new element. I think these
> examples are fairly simple ways to implement common URI manipulations<= br> > safely.
>
> James Manger
> James.H.Manger@team= .telstra.com
> Identity and security team =97 Chief Technology Office =97 Telstra




--
--
John Panzer / Goo= gle
jpanzer@google.com / abstractioneer.org / @jpanzer

--0016e64de80e30a0e60477bb06cf-- From breno.demedeiros@gmail.com Sat Nov 7 21:06:00 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F92E3A69B4 for ; Sat, 7 Nov 2009 21:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5F9f67UlMjP for ; Sat, 7 Nov 2009 21:05:58 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 851273A698A for ; Sat, 7 Nov 2009 21:05:58 -0800 (PST) Received: by qyk41 with SMTP id 41so1021491qyk.29 for ; Sat, 07 Nov 2009 21:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BT8sz1N8vaa5y+aKNkK9GXMguUw8I3EqSzKuMbz4RoI=; b=gkADxbYvQfmMuLpjMo4ol+14NLc0nitz1kEKVHyaYabeARwn5nTOV6HDslrXw7UNcZ hjmp5mVv34Ea6g3wl7fpyod/Lge+OIm6lC2UsYriSr4gTO7Yc8+Dx6tUvacepPS2q3Uh xC9Lbt/1EKMTsLwkQ7JWKQKzzCl2fcv0MpXo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cm1yQ0ZjELydOtqzYmwKeqYSzFZqiqFySlBCAI+ez8IvL3gEVRT8eMSUjUYD2/ivP4 CauKa9Wla/JIn7vE25wwcdmvDhruZ/HLKNMrwnEhcXn+eYdvFCrjON/XBR6vanQl7juL QBXG6804B2XeKvbb+uI7mYI3JNVlPMSLRv1aw= MIME-Version: 1.0 Received: by 10.229.55.210 with SMTP id v18mr866282qcg.19.1257656780380; Sat, 07 Nov 2009 21:06:20 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E112485B4116@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784FE8D9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112485B46BA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785078618@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 7 Nov 2009 21:06:20 -0800 Message-ID: Subject: Re: host-meta: template syntax hassles From: Breno To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=0015175cd082a4db630477d509d9 X-Mailman-Approved-At: Sun, 15 Nov 2009 14:22:55 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 05:06:00 -0000 --0015175cd082a4db630477d509d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 The simpler syntax will allow us to get this done quicker and will not commit us to a complex syntax. Server-side re-writing can keep us going until we know exactly what syntax we want, with the hindsight of practical deployment experience. On Fri, Nov 6, 2009 at 2:04 PM, John Panzer wrote: > I'm +1 on simplifying to 'uri' alone, because there is a fully capable > workaround (server side rewriting/redirecting) that is well understood an= d > is guaranteed to solve any specific problem with a small roundtrip cost. > > There was very strong consensus from the discussion at IIW, which include= d > a large # of the people who would depend on this spec. > > On Fri, Nov 6, 2009 at 1:44 PM, Eran Hammer-Lahav wr= ote: > >> This subject was discussed at length this week at IIW. The strong >> consensus was that since the currently proposed template vocabulary isn'= t >> expressive enough, it should be made even less expressive (only define >> 'uri') and not more expressive (see one proposal below). The main argume= nt >> were: >> >> - A future (richer) template syntax will address empty variables and the >> proper assembling of URI components together. When it becomes available, >> host-meta could be updated to define the full set of variables to suppor= t >> such common transformations. >> >> - Any vocabulary breaking the context URI into parts will need a >> complimentary method for applying links to resource subsets (at least ba= sed >> on the URI scheme). For example, it is not likely that a single template >> (using variables other than 'uri') will be able to properly address both >> 'http' and 'xmpp' URI transformation. >> >> The second point is the most important in my view since it requires >> extending the proposed document format to directly support describing >> subsets of resources. I am more inclined to reduce the vocabulary to a >> single 'uri' variable than extend both the vocabulary and schema to supp= ort >> richer scheme or pattern specific transformation. >> >> Since host-meta allows protocols to define their own 'rel'-specific >> template syntax and vocabulary, individual protocols with such needs wil= l >> still be able to make use of the framework. In addition, servers can alw= ays >> use a simple redirection script to redirect a client to a more complex >> location than provided by a single 'uri' variable. >> >> Comments? >> >> EHL >> >> >> > -----Original Message----- >> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > bounces@ietf.org] On Behalf Of Manger, James H >> > Sent: Tuesday, October 27, 2009 3:52 PM >> > To: apps-discuss@ietf.org >> > Subject: RE: host-meta: template syntax hassles >> > >> > One solution (for simple, but correct, URI templates for common >> > situations in host-meta) is to define more variables. >> > >> > For instance, in addition to 'scheme', 'authority', 'path', 'query'... >> > offer the following variables: >> > >> > 'toDir' =97 the URI up to, but excluding, the last '/' in the path >> > 'afterDir' =97 the URI from the last segment of the path to the end, >> excluding the fragment >> > 'toExt' =97 the URI up to, but excluding, the last '.' in the last seg= ment >> of the path (or to the end of the path if there is no such dot) >> > 'toPath' =97 the URI up to the end of the path >> > 'afterPath' =97 the URI from after the path to the end, excluding the >> fragment >> > 'toQueryPlus' =97 the URI excluding any fragment, followed by '&' if t= here >> is a query string or '?' otherwise (ie ready for a new query parameter t= o be >> appended) >> > 'beforeHost' =97 the URI up to, but excluding, the host >> > 'fromHost' =97 the URI from the host to the end, excluding the fragmen= t >> > >> > Template examples: >> > {+toExt}.xrd{+afterPath} =97 replace, say, .html extension with .xrd t= o >> get metadata >> > {+toQueryPlus}_=3Dmeta =97 add a query parameter named =93_=94 with a = value >> =93meta=94 to get metadata >> > {+toDir}/.meta/{+afterDir} =97 metadata is in a special .meta/ >> subdirectory of each directory >> > {+toPath};meta{+afterPath} =97 append =93;meta=94 to the path to get t= he >> metadata >> > {+beforeHost}meta.{+fromHost} =97metadata is hosted on a sub-domain >> > >> > The to/after (and before/from) pairs basically offer easy access to >> > different points in the URI to insert a new element. I think these >> > examples are fairly simple ways to implement common URI manipulations >> > safely. >> > >> > James Manger >> > James.H.Manger@team.telstra.com >> > Identity and security team =97 Chief Technology Office =97 Telstra >> >> > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > --=20 Breno de Medeiros --0015175cd082a4db630477d509d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1

The simpler syntax will allow us to get this done qui= cker and will not commit us to a complex syntax. Server-side re-writing can= keep us going until we know exactly what syntax we want, with the hindsigh= t of practical deployment experience.

On Fri, Nov 6, 2009 at 2:04 PM, John Panzer = <jpanzer@google.= com> wrote:
I'm +1 on simplifying to 'uri' alone, because there is a fully = capable workaround (server side rewriting/redirecting) that is well underst= ood and is guaranteed to solve any specific problem with a small roundtrip = cost.

There was very strong consensus from the discussion at IIW, = which included a large # of the people who would depend on this spec.

On= Fri, Nov 6, 2009 at 1:44 PM, Eran Hammer-Lahav <eran@hueniverse.com= > wrote:
This subject was discussed at length this we= ek at IIW. The strong consensus was that since the currently proposed templ= ate vocabulary isn't expressive enough, it should be made even less exp= ressive (only define 'uri') and not more expressive (see one propos= al below). The main argument were:

- A future (richer) template syntax will address empty variables and the pr= oper assembling of URI components together. When it becomes available, host= -meta could be updated to define the full set of variables to support such = common transformations.

- Any vocabulary breaking the context URI into parts will need a compliment= ary method for applying links to resource subsets (at least based on the UR= I scheme). For example, it is not likely that a single template (using vari= ables other than 'uri') will be able to properly address both '= http' and 'xmpp' URI transformation.

The second point is the most important in my view since it requires extendi= ng the proposed document format to directly support describing subsets of r= esources. I am more inclined to reduce the vocabulary to a single 'uri&= #39; variable than extend both the vocabulary and schema to support richer = scheme or pattern specific transformation.

Since host-meta allows protocols to define their own 'rel'-specific= template syntax and vocabulary, individual protocols with such needs will = still be able to make use of the framework. In addition, servers can always= use a simple redirection script to redirect a client to a more complex loc= ation than provided by a single 'uri' variable.

Comments?

EHL


> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org= ] On Behalf Of Manger, James H
> Sent: Tuesday, October 27, 2009 3:52 PM
> To: apps-di= scuss@ietf.org
> Subject: RE: host-meta: template syntax hassles
>
> One solution (for simple, but correct, URI templates for common
> situations in host-meta) is to define more variables.
>
> For instance, in addition to 'scheme', 'authority', &#= 39;path', 'query'...
> offer the following variables:
>
> 'toDir' =97 the URI up to, but excluding, the last '/'= in the path
> 'afterDir' =97 the URI from the last segment of the path to th= e end, excluding the fragment
> 'toExt' =97 the URI up to, but excluding, the last '.'= in the last segment of the path (or to the end of the path if there is no = such dot)
> 'toPath' =97 the URI up to the end of the path
> 'afterPath' =97 the URI from after the path to the end, exclud= ing the fragment
> 'toQueryPlus' =97 the URI excluding any fragment, followed by = '&' if there is a query string or '?' otherwise (ie rea= dy for a new query parameter to be appended)
> 'beforeHost' =97 the URI up to, but excluding, the host
> 'fromHost' =97 the URI from the host to the end, excluding the= fragment
>
> Template examples:
> {+toExt}.xrd{+afterPath} =97 replace, say, .html extension with .xrd t= o get metadata
> {+toQueryPlus}_=3Dmeta =97 add a query parameter named =93_=94 with a = value =93meta=94 to get metadata
> {+toDir}/.meta/{+afterDir} =97 metadata is in a special .meta/ subdire= ctory of each directory
> {+toPath};meta{+afterPath} =97 append =93;meta=94 to the path to get t= he metadata
> {+beforeHost}meta.{+fromHost} =97metadata is hosted on a sub-domain >
> The to/after (and before/from) pairs basically offer easy access to > different points in the URI to insert a new element. I think these
> examples are fairly simple ways to implement common URI manipulations<= br> > safely.
>
> James Manger
> J= ames.H.Manger@team.telstra.com
> Identity and security team =97 Chief Technology Office =97 Telstra




--
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer




--
Breno de Medeiros
--0015175cd082a4db630477d509d9-- From bill@dehora.net Thu Nov 12 14:59:56 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAD13A698F for ; Thu, 12 Nov 2009 14:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuo0NVBjSpWX for ; Thu, 12 Nov 2009 14:59:55 -0800 (PST) Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id 7D1CE3A690C for ; Thu, 12 Nov 2009 14:59:55 -0800 (PST) Received: from [192.168.1.18] (unknown [89.100.251.254]) by chilco.textdrive.com (Postfix) with ESMTP id 31E11E3F4D; Thu, 12 Nov 2009 23:00:22 +0000 (UTC) Message-ID: <4AFC937E.8060500@dehora.net> Date: Thu, 12 Nov 2009 23:00:14 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Johnston Subject: Re: Input on request for link relation References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> <-2851311788142652426@unknownmsgid> In-Reply-To: <-2851311788142652426@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2009 14:22:55 -0800 Cc: "apps-discuss@ietf.org" , Atom-Syntax Syntax , HTTP Working Group , Hadrien Gardeur , Ian Hickson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:59:56 -0000 > (opaque URI-based) rel so I have proposed class="action" be added for Another requirement I've stumbled on is the ability to group links. > For OCCI for example we want to give users the ability to create their > own actions (eg start, stop, restart) which will be advertised in the > HTTP headers and/or HTML HEAD. Currently each action has it's own > (opaque URI-based) rel so I have proposed class="action" be added for > grouping. Alternatively we could do rel="[http://purl.org/occi/] > action" and refine the action with one or more custom attributes (type > is not really appropriate here, nor when advertising protocol > endpoints like SSH and RDP which is anoter problem we ran into). > > Pagination (eg first, last, next, previous) is another potentially > interesting group. Though the semantics are mostly predefined one > could envisage links like "next 100", "next 1000". > > Sam on iPhone > > On 12/11/2009, at 7:18, Joe Gregorio wrote: > >> On Thu, Sep 17, 2009 at 5:26 PM, Mark Nottingham >> wrote: >>> On 16/09/2009, at 7:46 PM, Sam Johnston wrote: >>>> Would it be possible then to support multiple references so that >>>> people >>>> can see at a glance that a given relation is implemented as >>>> described in >>>> multiple formats (rather than just the first format that happened to >>>> register it)? May well not be worth the maintenance effort. >>> How about adding a new field for references to more information >>> about how a >>> relation is used in a particular context (scoped by context media >>> type)? >>> >>> E.g., >>> >>> References regarding use in specific contexts: >>> text/html: [HTML5] >>> application/atom+xml: [RFC4287] >>> >> Yes, that sounds like a great idea. And vaguely familiar: >> >> http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/ >> 0699.html >> >> Thanks, >> -joe > From bill@dehora.net Thu Nov 12 17:49:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF34E3A6881 for ; Thu, 12 Nov 2009 17:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y23e0tfyjWs2 for ; Thu, 12 Nov 2009 17:49:58 -0800 (PST) Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id 382973A6358 for ; Thu, 12 Nov 2009 17:49:58 -0800 (PST) Received: from [192.168.1.18] (unknown [89.100.251.254]) by chilco.textdrive.com (Postfix) with ESMTP id CDD7DDEB8F; Fri, 13 Nov 2009 01:50:24 +0000 (UTC) Message-ID: <4AFCBB59.3030905@dehora.net> Date: Fri, 13 Nov 2009 01:50:17 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Salz Subject: Re: Input on request for link relation References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> <-2851311788142652426@unknownmsgid> <4AFC937E.8060500@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2009 14:22:55 -0800 Cc: owner-atom-syntax@mail.imc.org, "apps-discuss@ietf.org" , Atom-Syntax Syntax , HTTP Working Group , Hadrien Gardeur , Ian Hickson X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:49:59 -0000 Richard Salz wrote: >> IOW allow the link registry to define rel scopes. The url or clash thing > >> sucks and I don't want someone rolling up with a curies/qnames or some >> other XML macrocrap proposal for Atom. > > Yeah, it would be a huge mistake to use something that's pretty much > already guaranteed to be part of your Atom infrastructure. Far better to > create yet another distributed naming scheme. It would be. HTML5 would probably be done by now if it wasn't for RDFa curies. Thanks for the sarcasm though, it amused me no end, although it's often more effective if you leave out the "Not" bit. Bill From rlmorgan@washington.edu Mon Nov 16 13:35:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D553A6834 for ; Mon, 16 Nov 2009 13:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzkpRqACdw75 for ; Mon, 16 Nov 2009 13:35:38 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by core3.amsl.com (Postfix) with ESMTP id DE1BC3A67B2 for ; Mon, 16 Nov 2009 13:35:38 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.14.3+UW09.06/8.14.3+UW09.09) with ESMTP id nAGLZbLo029189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Nov 2009 13:35:37 -0800 X-Auth-Received: from D-140-142-21-14.dhcp4.washington.edu (D-140-142-21-14.dhcp4.washington.edu [140.142.21.14]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW09.06/8.14.3+UW09.05) with ESMTP id nAGLZbkl007579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Nov 2009 13:35:37 -0800 Date: Mon, 16 Nov 2009 13:35:37 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: IETF Apps Subject: Lisa D's HTTP architecture presentation? Message-ID: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.5.8.383112, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.16.212422 X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_200_299 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SMALL_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0' X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:35:39 -0000 I wanted to point some folks at Lisa Dusseault's fine HTTP architecture presentation from last week (my impression is that it evolved some between the Monday apparea showing and the Thursday SAAG showing). Is it online somewhere? Thanks, - RL "Bob" From michelle.cotton@icann.org Wed Nov 18 11:09:43 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C688B3A688C; Wed, 18 Nov 2009 11:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDZl+d9ZcAPg; Wed, 18 Nov 2009 11:09:43 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 159F33A6855; Wed, 18 Nov 2009 11:09:43 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 18 Nov 2009 11:09:41 -0800 From: Michelle Cotton To: "apps-discuss@ietf.org" , "dnsop@ietf.org" , "tsvwg@ietf.org" Date: Wed, 18 Nov 2009 11:12:20 -0800 Subject: Update regarding I-D draft-ietf-tsvwg-iana-ports Thread-Topic: Update regarding I-D draft-ietf-tsvwg-iana-ports Thread-Index: AcpogwznmJdfMWyncUq0+0loKkBnbg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C72987141D937michellecottonicannorg_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 19 Nov 2009 08:04:35 -0800 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:09:43 -0000 --_000_C72987141D937michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the IETF meeting in Hiroshima, the I-D draft-ietf-tsvwg-iana-ports-03.tx= t was presented to the DNSOPS WG and APPS Area. These groups were requested to send feedback on this document. After receiving feedback from various individuals/groups regarding this doc= ument, a revision is being made and we expect it to be posted in a few week= s. Please wait to read the new version of the document before submitting comme= nts as we believe some issues will have been addressed. We will notify these groups when the new version of the document is availab= le. Thank you, Michelle Cotton Co-Author --_000_C72987141D937michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Update regarding I-D draft-ietf-tsvwg-iana-ports At the IETF meeting in Hiroshima, the I-D draft-ietf-tsvwg-iana-ports= -03.txt was presented to the DNSOPS WG and APPS Area.
These groups were requested to send feedback on this document.
After receiving feedback from various individuals/groups regarding this doc= ument, a revision is being made and we expect it to be posted in a few week= s.
Please wait to read the new version of the document before submitting comme= nts as we believe some issues will have been addressed.
We will notify these groups when the new version of the document is availab= le.

Thank you,

Michelle Cotton
Co-Author --_000_C72987141D937michellecottonicannorg_-- From magnus.westerlund@ericsson.com Thu Nov 19 08:20:52 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCDF28C18C; Thu, 19 Nov 2009 08:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR7Y0Q+n67LG; Thu, 19 Nov 2009 08:20:51 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4B31F28C18E; Thu, 19 Nov 2009 08:18:23 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-52-4b056fcb14d5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 5F.E5.24094.BCF650B4; Thu, 19 Nov 2009 17:18:20 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 17:16:49 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 17:16:49 +0100 Message-ID: <4B056F70.9070901@ericsson.com> Date: Thu, 19 Nov 2009 17:16:48 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [tsvwg] [apps-discuss] service names - one registry vs. two registries References: <200911120326.EAA09199@TR-Sys.de> <4AFBEE3F.9090701@cisco.com> In-Reply-To: <4AFBEE3F.9090701@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Nov 2009 16:16:49.0012 (UTC) FILETIME=[B25C4340:01CA6933] X-Brightmail-Tracker: AAAAAA== Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:20:53 -0000 Eliot Lear skrev: > Before we get hung up so high in WKS, I have an alternate suggestion. > Simply deprecate the registry. > I don't have any opinion on such an action. But from what Olafur explained it seems an appropriate action for someone to do that. Want to make it clear that we intended to populate the service registry with all the names from the Protocol and Services registry used by WKS to avoid issues with applications/protocols that has been registered and think they have name they can use in for example DNS SRVs. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lear@cisco.com Thu Nov 19 08:23:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D343A6AAD; Thu, 19 Nov 2009 08:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.266 X-Spam-Level: X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvr99XrS8IKL; Thu, 19 Nov 2009 08:23:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DBE353A69F2; Thu, 19 Nov 2009 08:22:05 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAP7+BEuQ/uCWe2dsb2JhbACERJdHAQELCyQGoUaHDpBjAoEugQyBK1QE X-IronPort-AV: E=Sophos;i="4.44,771,1249257600"; d="scan'208";a="54770893" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2009 16:22:02 +0000 Received: from ams3-vpn-dhcp7310.cisco.com (ams3-vpn-dhcp7310.cisco.com [10.61.92.141]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAJGM2WH017416; Thu, 19 Nov 2009 16:22:02 GMT Message-ID: <4B0570AA.4000600@cisco.com> Date: Thu, 19 Nov 2009 17:22:02 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091113 Shredder/3.0pre MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [tsvwg] [apps-discuss] service names - one registry vs. two registries References: <200911120326.EAA09199@TR-Sys.de> <4AFBEE3F.9090701@cisco.com> <4B056F70.9070901@ericsson.com> In-Reply-To: <4B056F70.9070901@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 16:23:09 -0000 Magnus, What you write below below makes sense to me. Eliot On 11/19/09 5:16 PM, Magnus Westerlund wrote: > Eliot Lear skrev: > >> Before we get hung up so high in WKS, I have an alternate suggestion. >> Simply deprecate the registry. >> >> > I don't have any opinion on such an action. But from what Olafur > explained it seems an appropriate action for someone to do that. > > Want to make it clear that we intended to populate the service registry > with all the names from the Protocol and Services registry used by WKS > to avoid issues with applications/protocols that has been registered and > think they have name they can use in for example DNS SRVs. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From mnot@mnot.net Thu Nov 19 19:06:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C963A6826 for ; Thu, 19 Nov 2009 19:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=-5.109, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ6o+mIpzI4i for ; Thu, 19 Nov 2009 19:06:36 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 2603D3A6809 for ; Thu, 19 Nov 2009 19:06:35 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.215.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 943C222E253; Thu, 19 Nov 2009 22:06:24 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: New Version Notification - draft-nottingham-site-meta-04.txt Date: Fri, 20 Nov 2009 14:06:23 +1100 References: <20091120030002.3DCB33A67A4@core3.amsl.com> To: "www-tag@w3.org WG" , Apps Discuss Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 03:06:37 -0000 FYI. Begin forwarded message: > From: Internet-Draft@ietf.org > Date: 20 November 2009 2:00:02 PM AEDT > To: mnot@pobox.com, eran@hueniverse.com, = draft-nottingham-site-meta@tools.ietf.org,lisa.dusseault@gmail.com > Subject: New Version Notification - draft-nottingham-site-meta-04.txt=20= >=20 > New version (-04) has been submitted for = draft-nottingham-site-meta-04.txt. > http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-04.txt >=20 > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-site-meta-04 >=20 > IETF Secretariat. -- Mark Nottingham http://www.mnot.net/ From poeml@cmdline.net Fri Nov 27 14:11:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91E33A6975 for ; Fri, 27 Nov 2009 14:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA9QIFzPPeJF for ; Fri, 27 Nov 2009 14:11:20 -0800 (PST) Received: from doozer.poeml.de (doozer.poeml.de [83.133.126.38]) by core3.amsl.com (Postfix) with ESMTP id 50EE53A6A98 for ; Fri, 27 Nov 2009 14:11:17 -0800 (PST) Received: from xdsl-84-44-142-191.netcologne.de ([84.44.142.191] helo=strbske.localdomain) by doozer.poeml.de with esmtpa (Exim 4.71) (envelope-from ) id 1NE91t-0000HJ-S8; Fri, 27 Nov 2009 23:11:06 +0100 Message-Id: From: =?ISO-8859-1?Q?Peter_P=F6ml?= To: apps-discuss@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-1523--267697214 Mime-Version: 1.0 (Apple Message framework v936) Subject: Update regarding draft-bryan-metalink (intro section) Date: Fri, 27 Nov 2009 23:11:00 +0100 X-Mailer: Apple Mail (2.936) Cc: "Neil M." , Tatsuhiro Tsujikawa X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 22:11:25 -0000 --Apple-Mail-1523--267697214 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [re-send with correct list address] Hi! I'm sending an update to the introductory section of the draft-bryan- metalink I-D. The changes are: - mention the multi-protocol (HTTP, FTP, P2P) nature of Metalinks. - describe how verification in Metalinks can solve issues trusting content replicas on mirror servers - distinguish more clearly between human users and user agents - various minor improvements. I hope the changes are acceptable and not too disruptive the review process. Hopefully they make the whole text clearer. I am attaching a text version of the introductory section, as well as a "diff" to the previous version for your convenience. Thanks, Peter --Apple-Mail-1523--267697214 Content-Disposition: attachment; filename=draft-bryan-metalink-23.xml-intro.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="draft-bryan-metalink-23.xml-intro.diff" Content-Transfer-Encoding: 7bit Index: draft-bryan-metalink-23.xml =================================================================== --- draft-bryan-metalink-23.xml (revision 463) +++ draft-bryan-metalink-23.xml (working copy) @@ -64,42 +64,53 @@
Metalink is an XML-based document format that describes a file or list - of files to be added to a download queue. Metalinks can list a number of - files, each with an extensible set of attached metadata. For example, - each file can have a description, checksum, and list of URIs that it is + of files to be downloaded from a server. Metalinks can list a number of + files, each with an extensible set of attached metadata. + Each listed file can have a description, checksum, and a list of URIs that it is available from. - Identical copies of a file are frequently accessible in multiple - locations on the Internet over a variety of protocols (FTP, HTTP, and - Peer-to-Peer). In some cases, Users are shown a list of these multiple - download locations (mirrors) and must manually select a single one on the - basis of geographical location, priority, or bandwidth. This distributes - the load across multiple servers. At times, individual servers can be + Often, identical copies of a file are accessible in multiple locations + on the Internet over a variety of protocols (FTP, HTTP, and + Peer-to-Peer). In some cases, users are shown a list of these multiple + download locations (mirror servers) and must manually select a single one on the + basis of geographical location, priority, or bandwidth. This is done to distribute + the load across multiple servers, and to give human users the opportunity + to choose a download location that they expect to work best for them. + At times, individual servers can be slow, outdated, or unreachable, but this can not be determined until the download has been initiated. This can lead to the user canceling the download and needing to restart it. During downloads, errors in transmission can corrupt the file. There are no easy ways to repair - these files. For large downloads this can be extremely troublesome. Any + these files. For large downloads this can be especially troublesome. Any of the number of problems that can occur during a download lead to - frustration on the part of users. + frustration on the part of users, and bandwith wasted with retransmission. - All the information about a download, including mirrors, checksums, + Knowledge about availability of a download on mirror servers can be + acquired and maintained by the operators of the origin server, or by third + a party. This knowledge, together with checksums, digital signatures, and more can be stored in a machine-readable Metalink - file. This Metalink file transfers the knowledge of the download server - (and mirror database) to the client. Clients can fall back to alternate - mirrors if the current one has an issue. With this knowledge, the client - is enabled to work its way to a successful download even under adverse - circumstances. All this is done transparently to the user and the + file. The Metalink file can transfer this knowledge to the user agent, + which can peruse it in automatic ways or present the information to a human user. + This guidance provided, user agents can fall back to alternate + mirrors if the current one has an issue. Thereby, clients + are enabled to work their way to a successful download even under adverse + circumstances. All this can be done transparently to the human user and the download is much more reliable and efficient. In contrast, a traditional - HTTP redirect to a mirror conveys only extremely minimal information - - one link to one server, and there is no provision in the HTTP protocol to - handle failures. Other features that some clients provide include - multi-source downloads, where chunks of a file are downloaded from - multiple mirrors (and optionally, Peer-to-Peer) simultaneously, which - frequently results in a faster download. Metalinks also provide - structured information about downloads that can be indexed by search - engines. + HTTP redirect to one mirror conveys only comparatively minimal information - + a referral to a single server, and there is no provision in the HTTP protocol to + handle failures. + Other features that some clients provide include multi-source + downloads, where chunks of a file are downloaded from multiple mirrors + (and optionally, Peer-to-Peer) simultaneously, which frequently results + in a faster download. Metalinks can leverage HTTP, FTP and Peer-to-Peer + protocols together, because regardless over which protocol the Metalink + was obtained, it can make a resource accessible through other protocols. + If the Metalink was obtained from a trusted source, included verification + metadata can solve trust issues when downloading files from replica + servers operated by third parties. Metalinks also provide structured + information about downloads that can be indexed by search engines. + [[ Discussion of this draft should take place on discuss@apps.ietf.org. Past discussion has gone on at the Metalink discussion mailing list located at metalink-discussion@googlegroups.com / --Apple-Mail-1523--267697214 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-1523--267697214 Content-Disposition: attachment; filename=draft-bryan-metalink-23-intro.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-bryan-metalink-23-intro.txt" Content-Transfer-Encoding: 7bit Metalink is an XML-based document format that describes a file or list of files to be downloaded from a server. Metalinks can list a number of files, each with an extensible set of attached metadata. Each listed file can have a description, checksum, and a list of URIs that it is available from. Often, identical copies of a file are accessible in multiple locations on the Internet over a variety of protocols (FTP, HTTP, and Peer-to-Peer). In some cases, users are shown a list of these multiple download locations (mirror servers) and must manually select a single one on the basis of geographical location, priority, or bandwidth. This is done to distribute the load across multiple servers, and to give human users the opportunity to choose a download location that they expect to work best for them. At times, individual servers can be slow, outdated, or unreachable, but this can not be determined until the download has been initiated. This can lead to the user canceling the download and needing to restart it. During downloads, errors in transmission can corrupt the file. There are no easy ways to repair these files. For large downloads this can be especially troublesome. Any of the number of problems that can occur during a download lead to frustration on the part of users, and bandwith wasted with retransmission. Knowledge about availability of a download on mirror servers can be acquired and maintained by the operators of the origin server, or by third a party. This knowledge, together with checksums, digital signatures, and more can be stored in a machine-readable Metalink file. The Metalink file can transfer this knowledge to the user agent, which can peruse it in automatic ways or present the information to a human user. This guidance provided, user agents can fall back to alternate mirrors if the current one has an issue. Thereby, clients are enabled to work their way to a successful download even under adverse circumstances. All this can be done transparently to the human user and the download is much more reliable and efficient. In contrast, a traditional HTTP redirect to one mirror conveys only comparatively minimal information - a referral to a single server, and there is no provision in the HTTP protocol to handle failures. Other features that some clients provide include multi-source downloads, where chunks of a file are downloaded from multiple mirrors (and optionally, Peer-to-Peer) simultaneously, which frequently results in a faster download. Metalinks can leverage HTTP, FTP and Peer-to-Peer protocols together, because regardless over which protocol the Metalink was obtained, it can make a resource accessible through other protocols. If the Metalink was obtained from a trusted source, included verification metadata can solve trust issues when downloading files from replica servers operated by third parties. Metalinks also provide structured information about downloads that can be indexed by search engines. --Apple-Mail-1523--267697214 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-1523--267697214-- From alexey.melnikov@isode.com Sat Nov 28 06:55:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4AA3A690F for ; Sat, 28 Nov 2009 06:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEM6LwwHFGUN for ; Sat, 28 Nov 2009 06:55:50 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BCC4B3A68FF for ; Sat, 28 Nov 2009 06:55:49 -0800 (PST) Received: from [92.40.30.65] (92.40.30.65.sub.mbb.three.co.uk [92.40.30.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 28 Nov 2009 14:55:42 +0000 Message-ID: <4B1139D1.5060000@isode.com> Date: Sat, 28 Nov 2009 14:55:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Larry Masinter Subject: Additional comments on draft-duerst-mailto-bis-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 14:55:50 -0000 Hi Martin/Larry, I've requested IETF LC for this document. The following extra comments can be considered as a part of IETF LC. >2. Syntax of a 'mailto' URI > > The syntax of a 'mailto' URI is described using the ABNF of [STD68], > non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and > non-terminal definitions from [STD66] (unreserved, pct-encoded): > > mailtoURI = "mailto:" [ to ] [ hfields ] > to = [ addr-spec *("%2C" addr-spec ) ] > hfields = "?" hfield *( "&" hfield ) > hfield = hfname "=" hfvalue > hfname = *qchar > hfvalue = *qchar > addr-spec = local-part "@" domain > local-part = dot-atom / quoted-string > domain = dot-atom I think you should be using "dot-atom-text" instead: atext = ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / ; characters not including "$" / "%" / ; specials. Used for atoms. "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] dot-atom-text = 1*atext *("." 1*atext) dot-atom = [CFWS] dot-atom-text [CFWS] I.e. I don't think we want CFWS. > qchar = unreserved / pct-encoded / some-delims > some-delims = "!" / "$" / "'" / "(" / ")" / "*" > / "+" / "," / ";" / ":" / "@" [...] > Implementations SHOULD NOT produce two "To:" header fields in a > message; the "To:" header field may occur at most once in a message > ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs SHOULD NOT > include other message header fields multiple times if these header > fields can only be used once in a message. > > Any reasons why these SHOULD NOTs are not MUST NOTs? >From ID-nits: > >Miscellaneous warnings: > ---------------------------------------------------------------------------- > > == The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > > ID-Checklist requires). > > I think this can be fixed by the RFC Editor, but if you have to do a new revision, you might as well fix that. From duerst@it.aoyama.ac.jp Sun Nov 29 23:22:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F163A6919 for ; Sun, 29 Nov 2009 23:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCot-SGRERwG for ; Sun, 29 Nov 2009 23:22:35 -0800 (PST) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 1F9A63A68B6 for ; Sun, 29 Nov 2009 23:22:35 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id nAU7MHM3022972 for ; Mon, 30 Nov 2009 16:22:17 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3d4a_16f63830_dd81_11de_9324_001d096c566a; Mon, 30 Nov 2009 16:22:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39924) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 30 Nov 2009 16:18:39 +0900 Message-ID: <4B137290.7050601@it.aoyama.ac.jp> Date: Mon, 30 Nov 2009 16:21:52 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional comments on draft-duerst-mailto-bis-07.txt References: <4B1139D1.5060000@isode.com> In-Reply-To: <4B1139D1.5060000@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 07:22:37 -0000 Hello Alex, On 2009/11/28 23:55, Alexey Melnikov wrote: > Hi Martin/Larry, > I've requested IETF LC for this document. Thanks. For a while, I wasn't sure how you wanted to proceed, this makes is clear. > The following extra comments > can be considered as a part of IETF LC. Okay. > >> 2. Syntax of a 'mailto' URI >> >> The syntax of a 'mailto' URI is described using the ABNF of [STD68], >> non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and >> non-terminal definitions from [STD66] (unreserved, pct-encoded): >> >> mailtoURI = "mailto:" [ to ] [ hfields ] >> to = [ addr-spec *("%2C" addr-spec ) ] >> hfields = "?" hfield *( "&" hfield ) >> hfield = hfname "=" hfvalue >> hfname = *qchar >> hfvalue = *qchar >> addr-spec = local-part "@" domain >> local-part = dot-atom / quoted-string >> domain = dot-atom > > I think you should be using "dot-atom-text" instead: Instead of what? Instead of "dot-atom" (as used above in "local-part" and "domain")? [I think that's what you mean, and it would make sense, but please confirm.] > atext = ALPHA / DIGIT / ; Printable US-ASCII > "!" / "#" / ; characters not including > "$" / "%" / ; specials. Used for atoms. > "&" / "'" / > "*" / "+" / > "-" / "/" / > "=" / "?" / > "^" / "_" / > "`" / "{" / > "|" / "}" / > "~" Looking at this list actually makes me worry that it's way too open; definitely "%" and "?", and maybe some others, cannot appear directly in that part of a mailto URI (they certainly can appear %-escaped). I'll have to check the text to make sure everything here is correct. > atom = [CFWS] 1*atext [CFWS] > > dot-atom-text = 1*atext *("." 1*atext) > > dot-atom = [CFWS] dot-atom-text [CFWS] > > > I.e. I don't think we want CFWS. > >> qchar = unreserved / pct-encoded / some-delims >> some-delims = "!" / "$" / "'" / "(" / ")" / "*" >> / "+" / "," / ";" / ":" / "@" > > [...] > >> Implementations SHOULD NOT produce two "To:" header fields in a >> message; the "To:" header field may occur at most once in a message >> ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs SHOULD NOT >> include other message header fields multiple times if these header >> fields can only be used once in a message. >> >> > Any reasons why these SHOULD NOTs are not MUST NOTs? Not being a mail expert, I have no experience on what goes wrong if these restrictions are not met. If you think a MUST is more appropriate, that's fine with me. But I didn't find a MUST in RFC 5322, it just says: >>>> The following table indicates limits on the number of times each field *may* occur in the header section of a message... >>>> (emphasis mine). >> From ID-nits: >> >> Miscellaneous warnings: >> ---------------------------------------------------------------------------- >> >> >> == The document seems to lack the recommended RFC 2119 boilerplate, >> even if >> it appears to use RFC 2119 keywords -- however, there's a paragraph with >> a matching beginning. Boilerplate error? >> >> (The document does seem to have the reference to RFC 2119 which the >> >> ID-Checklist requires). >> >> > I think this can be fixed by the RFC Editor, but if you have to do a new > revision, you might as well fix that. I will try. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Mon Nov 30 03:41:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9E73A6A4A for ; Mon, 30 Nov 2009 03:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QixehFqcOi91 for ; Mon, 30 Nov 2009 03:41:13 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 58E603A6900 for ; Mon, 30 Nov 2009 03:41:13 -0800 (PST) Received: from [172.16.2.186] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 30 Nov 2009 11:41:05 +0000 Message-ID: <4B13AF42.4090606@isode.com> Date: Mon, 30 Nov 2009 11:40:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Subject: Re: Additional comments on draft-duerst-mailto-bis-07.txt References: <4B1139D1.5060000@isode.com> <4B137290.7050601@it.aoyama.ac.jp> In-Reply-To: <4B137290.7050601@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 11:41:14 -0000 Martin J. D=FCrst wrote: > Hello Alex, > > On 2009/11/28 23:55, Alexey Melnikov wrote: > >> Hi Martin/Larry, >> I've requested IETF LC for this document. > > Thanks. For a while, I wasn't sure how you wanted to proceed, this=20 > makes is clear. My opinion has changed slightly after I posted my message to the EAI=20 mailing list. >> The following extra comments >> can be considered as a part of IETF LC. > > Okay. > >>> 2. Syntax of a 'mailto' URI >>> >>> The syntax of a 'mailto' URI is described using the ABNF of [STD68], >>> non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and >>> non-terminal definitions from [STD66] (unreserved, pct-encoded): >>> >>> mailtoURI =3D "mailto:" [ to ] [ hfields ] >>> to =3D [ addr-spec *("%2C" addr-spec ) ] >>> hfields =3D "?" hfield *( "&" hfield ) >>> hfield =3D hfname "=3D" hfvalue >>> hfname =3D *qchar >>> hfvalue =3D *qchar >>> addr-spec =3D local-part "@" domain >>> local-part =3D dot-atom / quoted-string >>> domain =3D dot-atom >> >> I think you should be using "dot-atom-text" instead: > > Instead of what? Instead of "dot-atom" (as used above in "local-part"=20 > and "domain")? [I think that's what you mean, and it would make sense,=20 > but please confirm.] Yes. >> atext =3D ALPHA / DIGIT / ; Printable US-ASCII >> "!" / "#" / ; characters not including >> "$" / "%" / ; specials. Used for atoms. >> "&" / "'" / >> "*" / "+" / >> "-" / "/" / >> "=3D" / "?" / >> "^" / "_" / >> "`" / "{" / >> "|" / "}" / >> "~" > > Looking at this list actually makes me worry that it's way too open;=20 > definitely "%" and "?", and maybe some others, cannot appear directly=20 > in that part of a mailto URI (they certainly can appear %-escaped).=20 > I'll have to check the text to make sure everything here is correct. Making the syntax more restrictive would be better, of course.=20 Referencing URI production for the hostname (reg-name?) might be Ok as well. >> atom =3D [CFWS] 1*atext [CFWS] >> >> dot-atom-text =3D 1*atext *("." 1*atext) >> >> dot-atom =3D [CFWS] dot-atom-text [CFWS] >> >> >> I.e. I don't think we want CFWS. >> >>> qchar =3D unreserved / pct-encoded / some-delims >>> some-delims =3D "!" / "$" / "'" / "(" / ")" / "*" >>> / "+" / "," / ";" / ":" / "@" >> From anthonybryan@gmail.com Mon Nov 30 13:44:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249743A692C for ; Mon, 30 Nov 2009 13:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.893 X-Spam-Level: X-Spam-Status: No, score=-4.893 tagged_above=-999 required=5 tests=[AWL=-4.406, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtr5Gj3sA9VN for ; Mon, 30 Nov 2009 13:44:24 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id A00CD3A6924 for ; Mon, 30 Nov 2009 13:44:24 -0800 (PST) Received: by iwn33 with SMTP id 33so2771806iwn.29 for ; Mon, 30 Nov 2009 13:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wCZ8P9F5e5NiGAAD+Q2T6S6Zte/Ko/KubWIf7ODznoI=; b=LDFUWPr0hDOgItpa5xNB74hv4v7yGczPj8h6kS4F7fyar4I6OplLrqNRY8BVutouTO OVXw1Zx2GSsELGfhJdnIgP4CLFQEoeSYg9DeVr12NZ8fLbZt6Bl7TbnUOdF2aj5id1Yt q3XCULxncS8z+MArdrUhSbmuYiyo7LGV+G50s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xKIznLwc2NXxGSCs+8dmX/KDLQ6OyTIK93qcQUtjaypUrHF93vxawvX2SRaa0XA+m3 I98U8eKmfm+4Ac1WtLCd0RU82D8YU1ImPxLKUR+MHzp4tyuGTVQzi3Zg7fBEGKfZq4Yr PrnyMLdA3hdWjWvlEwOj8isabwNyTwvFY70hY= MIME-Version: 1.0 Received: by 10.231.122.36 with SMTP id j36mr759499ibr.21.1259617453364; Mon, 30 Nov 2009 13:44:13 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2009 16:44:13 -0500 Message-ID: Subject: Re: Update regarding draft-bryan-metalink (intro section) From: Anthony Bryan To: =?ISO-8859-1?Q?Peter_P=F6ml?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Neil M." , apps-discuss@ietf.org, Tatsuhiro Tsujikawa X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:44:26 -0000 On Fri, Nov 27, 2009 at 5:11 PM, Peter P=F6ml wrote: > > I'm sending an update to the introductory section of the > draft-bryan-metalink I-D. The changes are: > > - mention the multi-protocol (HTTP, FTP, P2P) nature of Metalinks. > - describe how verification in Metalinks can solve issues trusting conten= t > replicas on mirror servers > - distinguish more clearly between human users and user agents > - various minor improvements. This last week we received some healthy review from Lisa and Eran, document shepherd. We addressed most issues in an interim version that can be found at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ but await clarifications on a few others. The other remaining issues: 1) Can we use Creative Commons for machine readable alternative to our license element (Sec 4.2.8)? 2) Do we need to use ABNF for the generator element (4.2.4)? We talked about using this from HTTP product =3D token ["/" product-version] product-version =3D token 3) metaurl element's type attribute value (4.2.10.2). It uses MIME type, but "torrent" is defined. 4) signature element's type attribute value (4.2.15.1). pgp is defined. 5) We allow one or more OS elements. Should we allow one or more license and language elements? And here is the intro with only a few small changes: Metalink is an XML-based document format that describes a file or list of files to be downloaded from a server. Metalinks can list a number of files, each with an extensible set of attached metadata. Each listed file can have a description, checksum, and a list of URIs that it is available from. Often, identical copies of a file are accessible in multiple locations on the Internet over a variety of protocols (FTP, HTTP, and Peer-to-Peer). In some cases, users are shown a list of these multiple download locations (mirror servers) and must manually select one based on geographical location, priority, or bandwidth. This is done to distribute the load across multiple servers, and to give human users the opportunity to choose a download location that they expect to work best for them. At times, individual servers can be slow, outdated, or unreachable, but this can not be determined until the download has been initiated. This can lead to the user canceling the download and needing to restart it. During downloads, errors in transmission can corrupt the file. There are no easy ways to repair these files. For large downloads this can be especially troublesome. Any of the number of problems that can occur during a download lead to frustration on the part of users, and bandwith wasted with retransmission. Knowledge about availability of a download on mirror servers can be acquired and maintained by the operators of the origin server, or by third a party. This knowledge, together with checksums, digital signatures, and more can be stored in a machine-readable Metalink file. The Metalink file can transfer this knowledge to the user agent, which can peruse it in automatic ways or present the information to a human user. User agents can fall back to alternate mirrors if the current one has an issue. Thereby, clients are enabled to work their way to a successful download even under adverse circumstances. All this can be done transparently to the human user and the download is much more reliable and efficient. In contrast, a traditional HTTP redirect to one mirror conveys only comparatively minimal information - a referral to a single server, and there is no provision in the HTTP protocol to handle failures. Other features that some clients provide include multi-source downloads, where chunks of a file are downloaded from multiple mirrors (and optionally, Peer-to-Peer) simultaneously, which frequently results in a faster download. Metalinks can leverage HTTP, FTP and Peer-to-Peer protocols together, because regardless over which protocol the Metalink was obtained, it can make a resource accessible through other protocols. If the Metalink was obtained from a trusted source, included verification metadata can solve trust issues when downloading files from replica servers operated by third parties. Metalinks also provide structured information about downloads that can be indexed by search engines. Feedback is very welcome! --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads