From msk@cloudmark.com Mon May 2 22:09:12 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D332AE06FE; Mon, 2 May 2011 22:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.91 X-Spam-Level: X-Spam-Status: No, score=-104.91 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADkg46m4u8Uj; Mon, 2 May 2011 22:09:08 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 379FDE069C; Mon, 2 May 2011 22:09:08 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 2 May 2011 22:09:07 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "alexey.melnikov@isode.com" , Barry Leiba , "cyrus@daboo.name" , "aaron@serendipity.cx" Date: Mon, 2 May 2011 22:09:06 -0700 Thread-Topic: apps-review team review for draft-melnikov-sieve-external-lists Thread-Index: AcwJUDoEJ+lqWZL4RTiLJYEf/AcHwg== Message-ID: 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: "iesg@ietf.org" Subject: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2011 05:09:13 -0000 I have been selected as the Applications Area Review Team reviewer for this= draft (for background on apps-review, please see http://www.apps.ietf.org/= content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-melnikov-sieve-external-lists Title: Sieve Extension: Externally Stored Lists Reviewer: Murray S. Kucherawy Review Date: May 2, 2011 IETF Last Call Date: n/a IESG Telechat Date: n/a Summary: This draft is almost ready for publication as a Standards Track RF= C, modulo a few points I'd like to mention below. Major Issues: 1. Altering list behaviour based on data available external to the Sieve pr= ocessing code means alteration of such data presents a vector for attack. = The Security Considerations section should mention this. It does mention s= ome related issues (e.g., authentication) but not the one I have in mind, n= amely that the outcome of the Sieve script becomes dependent on external da= ta not necessarily under direct control of the user. Minor Issues:=20 1. Since the document references the possibility of storing lists in extern= al relational databases, I was surprised not to see a specific reference to= how one might be used. Is it the case that no URI schema exists yet for r= eferring to, say, an SQL query? If such does exist, an example of this wou= ld be good to include, but certainly not required (especially if such a sch= ema has yet to be registered). Nits: 1. ":list" is sometimes quoted in the document and sometimes not. It shoul= d be consistent throughout. Apart from those, it's pretty clean. Nicely done! -MSK From yaojk@cnnic.cn Wed May 4 02:26:42 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B0CE06A2 for ; Wed, 4 May 2011 02:26:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.228 X-Spam-Level: X-Spam-Status: No, score=-98.228 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeX3oGYDObvZ for ; Wed, 4 May 2011 02:26:41 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 221A3E067A for ; Wed, 4 May 2011 02:26:40 -0700 (PDT) Received: (eyou send program); Wed, 04 May 2011 17:26:35 +0800 Message-ID: <504501195.20801@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 04 May 2011 17:26:35 +0800 Message-ID: <6F3EA14AB3B743F29E5893E322F55DF6@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503575952.18670@cnnic.cn> Date: Wed, 4 May 2011 17:26:34 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AA_01CC0A80.6ABCC6F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: idna-update@alvestrand.no Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 09:26:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02AA_01CC0A80.6ABCC6F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNClJlbWluZGVyLiBUaGUgV0cgbGFzdCBjYWxsIHdpbGwgZW5kIHNvb24uIElmIHlvdSBzdGls bCBoYXZlIGFueSBjb21tZW50cywgcGxzDQpraW5kbHkgZ2l2ZSBpdCBiZWZvcmUgdGhlIGRlYWRs aW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWFua2FuZyBZYW8oYXMgYSBjby1jaGFpciBvZiBBUFBT QVdHKQ0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEppYW5rYW5n IFlhbyANCiAgVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCiAgQ2M6IGlkbmEtdXBkYXRlQGFs dmVzdHJhbmQubm8gDQogIFNlbnQ6IFN1bmRheSwgQXByaWwgMjQsIDIwMTEgMTI6MjUgQU0NCiAg U3ViamVjdDogW2FwcHMtZGlzY3Vzc10gV0dMQzogZHJhZnQtZmFsdHN0cm9tLTU4OTJiaXMtMDQu dHh0DQoNCg0KICBEZWFyIGNvbGxlYWd1ZXMsDQoNCiAgVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3 by13ZWVrIFdHTEMgb24gdGhlIGRyYWZ0DQogIGRyYWZ0LWZhbHRzdHJvbS01ODkyYmlzLTA0LnR4 dC4gIFdlIGRpZCBmb3JtYWxseQ0KICBhZG9wdCB0aGlzIEktRCBhcyBhIFdHIGRvY3VtZW50IGEg ZmV3IG1vbnRocyBhZ28uDQogIFRoZXJlIGhhcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGFuZCBhbiBp bmZvcm1hbCBsYXN0IGNhbGwgZm9yIGNvbW1lbnRzIGFib3V0DQogIHRoaXMgZHJhZnQgaW4gdGhl IElETkFiaXMgbGlzdCBpZG5hLXVwZGF0ZUBhbHZlc3RyYW5kLm5vLiAgDQogIFRoZSBlZGl0b3Jz L2F1dGhvcnMgb2YgdGhpcyBkcmFmdCBiZWxpZXZlIHRoYXQgdGhpcyBkcmFmdCBoYXMgYmVlbiBp biBhIHZlcnkgZ29vZCBzaGFwZS4NCg0KICBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdC4gIElmIHlv dSBzdXBwb3J0IHB1YmxpY2F0aW9uLCBwbGVhc2Ugc3RhdGUgYXMNCiAgbXVjaCBvbiB0aGUgbGlz dC4gIElmIHlvdSBhcmUgb3Bwb3NlZCB0byBwdWJsaWNhdGlvbiwgcGxlYXNlIHN0YXRlDQogIHRo YXQgb24gdGhlIGxpc3QgYXMgd2VsbC4gIEl0IGlzIG1vcmUvb25seSBoZWxwZnVsIGlmIHlvdSBn aXZlIHlvdXIgcmVhc29ucyBmb3INCiAgeW91ciBwb3NpdGlvbiBhcyBwYXJ0IG9mIHlvdXIgc3Rh dGVtZW50LiAgDQoNCiAgU2luY2UgdGhpcyBkcmFmdCBpcyB0aGUgV0cgaXRlbSBvZiBBUFBTQVdH LCB3ZSBmYXZvciB0aGF0IHRoZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0IGFyZSBzZW50IHRvIHRo ZSBsaXN0IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZy4gDQoNCiAgVGhlIFdHTEMgd2lsbCBlbmQgb24g TWF5IDA4LCAyMDExIGF0IDIzOjAwIFVUQy4NCg0KICBOb3RlOiBUaGlzIGRyYWZ0IGlzIGEgZG9j dW1lbnQgdGhhdCB1cGRhdGVzIGFuIGVhcmxpZXIgUkZDIGJ5IHN0YXRpbmcgbm90aGluZyBpcyB0 byBiZSB1cGRhdGVkLiANCg0KDQogIEJlc3QgcmVnYXJkcywNCiAgSmlhbmthbmcgWWFvKGFzIGEg Y28tY2hhaXIgb2YgQVBQU0FXRykNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgYXBwcy1k aXNjdXNzIG1haWxpbmcgbGlzdA0KICBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCiAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== ------=_NextPart_000_02AA_01CC0A80.6ABCC6F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MDQ2Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+UmVtaW5kZXIuIFRoZSBXRyBsYXN0IGNhbGwgd2lsbCBlbmQgc29vbi4gSWYgeW91IHN0 aWxsIGhhdmUgDQphbnkgY29tbWVudHMsIHBsczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPmtpbmRseSBnaXZlIGl0IGJlZm9yZSB0aGUgZGVhZGxpbmUuPC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJlc3QgcmVnYXJkcyw8QlI+Smlhbmth bmcgWWFvKGFzIGEgY28tY2hhaXIgb2YgDQpBUFBTQVdHKTxCUj48L0ZPTlQ+PC9ESVY+DQo8QkxP Q0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkct TEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlOyBCQUNL R1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0 aXRsZT15YW9qa0Bjbm5pYy5jbiBocmVmPSJtYWlsdG86eWFvamtAY25uaWMuY24iPkppYW5rYW5n IFlhbzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlIj48Qj5Ubzo8L0I+ IDxBIHRpdGxlPWFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmFwcHMtZGlz Y3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPkNjOjwvQj4gPEEgdGl0bGU9aWRuYS11cGRhdGVAYWx2 ZXN0cmFuZC5ubyANCiAgaHJlZj0ibWFpbHRvOmlkbmEtdXBkYXRlQGFsdmVzdHJhbmQubm8iPmlk bmEtdXBkYXRlQGFsdmVzdHJhbmQubm88L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgy87M5SI+PEI+U2VudDo8L0I+IFN1bmRheSwgQXByaWwgMjQsIDIwMTEgMTI6MjUgQU08L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPlN1YmplY3Q6PC9CPiBbYXBwcy1k aXNjdXNzXSBXR0xDOiANCiAgZHJhZnQtZmFsdHN0cm9tLTU4OTJiaXMtMDQudHh0PC9ESVY+DQog IDxESVY+PEJSPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj4NCiAgPERJVj48Rk9OVCBzaXpl PTI+DQogIDxESVY+PEZPTlQgc2l6ZT0zPkRlYXIgY29sbGVhZ3Vlcyw8QlI+PEJSPlRoaXMgbWVz c2FnZSBzdGFydHMgYSB0d28td2VlayBXR0xDIA0KICBvbiB0aGUgZHJhZnQ8QlI+ZHJhZnQtZmFs dHN0cm9tLTU4OTJiaXMtMDQudHh0LiZuYnNwOyZuYnNwO1dlIA0KICBkaWQmbmJzcDtmb3JtYWxs eTxCUj5hZG9wdCB0aGlzIEktRCBhcyBhIFdHIGRvY3VtZW50IGEgZmV3IG1vbnRocyANCiAgYWdv LjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTM+VGhlcmUgaGFzIGEgbG90IG9mIGRp c2N1c3Npb24gYW5kIGFuIGluZm9ybWFsIGxhc3QgY2FsbCBmb3IgDQogIGNvbW1lbnRzIGFib3V0 PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mz50aGlzIGRyYWZ0IGluIHRoZSBJRE5B YmlzIGxpc3QgPC9GT05UPjxBIA0KICBocmVmPSJtYWlsdG86aWRuYS11cGRhdGVAYWx2ZXN0cmFu ZC5ubyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48Rk9OVCANCiAgc2l6ZT0zPmlkbmEtdXBkYXRl QGFsdmVzdHJhbmQubm88L0ZPTlQ+PC9BPjxGT05UIHNpemU9Mz4uJm5ic3A7IDwvRk9OVD48L0RJ Vj4NCiAgPERJVj48Rk9OVCBzaXplPTM+VGhlIGVkaXRvcnMvYXV0aG9ycyBvZiB0aGlzIGRyYWZ0 IGJlbGlldmUgdGhhdCANCiAgdGhpcyZuYnNwO2RyYWZ0IGhhcyBiZWVuIGluIGEgdmVyeSBnb29k IHNoYXBlLjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTM+PEJSPlBsZWFzZSByZXZp ZXcgdGhlIGRyYWZ0LiZuYnNwOyBJZiB5b3Ugc3VwcG9ydCANCiAgcHVibGljYXRpb24sIHBsZWFz ZSBzdGF0ZSBhczxCUj5tdWNoIG9uIHRoZSBsaXN0LiZuYnNwOyBJZiB5b3UgYXJlIG9wcG9zZWQg dG8gDQogIHB1YmxpY2F0aW9uLCBwbGVhc2Ugc3RhdGU8QlI+dGhhdCBvbiB0aGUgbGlzdCBhcyB3 ZWxsLiZuYnNwOyBJdCBpcyBtb3JlL29ubHkgDQogIGhlbHBmdWwmbmJzcDtpZiB5b3UgZ2l2ZSZu YnNwO3lvdXIgcmVhc29ucyBmb3I8QlI+eW91ciBwb3NpdGlvbiBhcyBwYXJ0IG9mIA0KICB5b3Vy IHN0YXRlbWVudC4mbmJzcDsgPEJSPjxCUj5TaW5jZSB0aGlzIGRyYWZ0IGlzIHRoZSBXRyBpdGVt IG9mIEFQUFNBV0csIHdlIA0KICBmYXZvciB0aGF0IHRoZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0 Jm5ic3A7YXJlIHNlbnQgdG8gdGhlIGxpc3QgPC9GT05UPjxBIA0KICBocmVmPSIiIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+PEZPTlQgDQogIHNpemU9Mz5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L0ZP TlQ+PC9BPjxGT05UIHNpemU9Mz4uJm5ic3A7PC9GT05UPjwvRElWPg0KICA8RElWPjxCUj48Rk9O VCBzaXplPTM+VGhlIFdHTEMgd2lsbCBlbmQgb24gTWF5IDA4LCAyMDExIGF0IDIzOjAwIA0KICBV VEMuPC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJ Vj48Rk9OVCBzaXplPTI+PEZPTlQgc2l6ZT0zPk5vdGU6Jm5ic3A7VGhpcyBkcmFmdCZuYnNwO2lz IGEgZG9jdW1lbnQgdGhhdCANCiAgdXBkYXRlcyBhbiBlYXJsaWVyIFJGQyBieSBzdGF0aW5nIG5v dGhpbmcgaXMgdG8gYmUgdXBkYXRlZC4gDQogIDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mz48QlI+PEJSPkJlc3QgcmVnYXJkcyw8QlI+Smlhbmth bmcgWWFvKGFzIGEgDQogIGNvLWNoYWlyIG9mIEFQUFNBV0cpPEJSPjwvRk9OVD48L0ZPTlQ+PC9E SVY+PC9GT05UPjwvRElWPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5hcHBzLWRpc2N1c3MgbWFpbGlu ZyANCiAgbGlzdDxCUj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48 L0hUTUw+DQo= ------=_NextPart_000_02AA_01CC0A80.6ABCC6F0-- From simon@josefsson.org Wed May 4 02:33:48 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E14E072F for ; Wed, 4 May 2011 02:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdaET5uDcgqh for ; Wed, 4 May 2011 02:33:48 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0F7E06A2 for ; Wed, 4 May 2011 02:33:46 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p449XPtt003384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 May 2011 11:33:26 +0200 From: Simon Josefsson To: "Jiankang YAO" References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110504:idna-update@alvestrand.no::K9fcqDlFI5EI7j1W:0ed7 X-Hashcash: 1:22:110504:apps-discuss@ietf.org::nT+MgSYmPHlRdPvA:7gur X-Hashcash: 1:22:110504:yaojk@cnnic.cn::cvJp+zklvyN4P7v3:cdAo Date: Wed, 04 May 2011 11:33:24 +0200 In-Reply-To: <504501195.20801@cnnic.cn> (Jiankang YAO's message of "Wed, 4 May 2011 17:26:34 +0800") Message-ID: <87mxj2kdy3.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 09:33:48 -0000 "Jiankang YAO" writes: > Reminder. The WG last call will end soon. If you still have any comments, pls > kindly give it before the deadline. Could you please clarify the last sentence in the WGLC? As I asked before, is the intention that this document will be marked as updating any earlier RFC or not? Right now the document does not include any "Update:" tags, so I'm confused by your statement that the document updates an earlier RFC. Thanks, /Simon > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > ----- Original Message ----- > From: Jiankang Yao > To: apps-discuss@ietf.org > Cc: idna-update@alvestrand.no > Sent: Sunday, April 24, 2011 12:25 AM > Subject: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt > > > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt. We did formally > adopt this I-D as a WG document a few months ago. > There has a lot of discussion and an informal last call for comments about > this draft in the IDNAbis list idna-update@alvestrand.no. > The editors/authors of this draft believe that this draft has been > in a very good shape. > > Please review the draft. If you support publication, please state as > much on the list. If you are opposed to publication, please state > that on the list as well. It is more/only helpful if you give your > reasons for > your position as part of your statement. > > Since this draft is the WG item of APPSAWG, we favor that the > comments to this draft are sent to the list apps-discuss@ietf.org. > > The WGLC will end on May 08, 2011 at 23:00 UTC. > > Note: This draft is a document that updates an earlier RFC by > stating nothing is to be updated. > > > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > 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 john-ietf@jck.com Wed May 4 06:47:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE8E0787 for ; Wed, 4 May 2011 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9JwKgZqpoeB for ; Wed, 4 May 2011 06:47:52 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5D500E0682 for ; Wed, 4 May 2011 06:47:52 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QHcQQ-000MCJ-RL; Wed, 04 May 2011 09:47:35 -0400 Date: Wed, 04 May 2011 09:47:33 -0400 From: John C Klensin To: Simon Josefsson , Jiankang YAO Message-ID: <15F3B045D9965C99C66CB2DE@PST.JCK.COM> In-Reply-To: <87mxj2kdy3.fsf@latte.josefsson.org> References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> <87mxj2kdy3.fsf@latte.josefsson.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 13:47:53 -0000 --On Wednesday, May 04, 2011 11:33 +0200 Simon Josefsson wrote: > "Jiankang YAO" writes: > >> Reminder. The WG last call will end soon. If you still have >> any comments, pls kindly give it before the deadline. > > Could you please clarify the last sentence in the WGLC? As I > asked before, is the intention that this document will be > marked as updating any earlier RFC or not? Right now the > document does not include any "Update:" tags, so I'm confused > by your statement that the document updates an earlier RFC. Simon, Personal opinion, speaking for myself only. This is a judgment call. If the document were _changing_ the 5892 specification, e.g., by adding an exception rule, it would clearly be updating 5892. But it doesn't. It has no effect whatsoever other than to document our decision to not do anything. So, if we had the requirement (one that I've often advocated) that any document that says "updates XXX" must describe what was changed and why, it would have to say something like "despite the claim that this updates 5892, it changes absolutely nothing about the spec even though it lets the expected changes in derived tables with Unicode changes happen". Similarly, if 5892 contained a comprehensive explanation of when we do or do not add exceptions, or this 5892bis document did, it would be updating 5892. But 5892 essentially says "judgment call on a case-by-case basis" and 5892bis doesn't change that either == we are just making that call. Our intent, from the original discussions, was that we accumulate that experience and then see if we set out clear rules. I don't think we are much more ready to do that now than we were 18 months ago. At the same time, the document doesn't exist without 5892 and we don't have a category other than "updates" for "hangs off 5892 somehow". My recommendation to the WG is that we not waste time on this. The WG Chairs (or other shepherd) should attach a note to the IESG pointing out the difficulty (borrowing text from your notes and the above if it would be useful) and leaving it to the IESG and RFC Editor to decide whether an "updates" header is appropriate. They will need to decide anyway and the issue is really a procedural and editorial one, not one on which the AppsAWG needs to decide. Sorry Peter and Pete :-) best, john From phoffman@imc.org Wed May 4 07:00:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4AFE0719 for ; Wed, 4 May 2011 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxUkTg2sKyVw for ; Wed, 4 May 2011 07:00:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7FE06A4 for ; Wed, 4 May 2011 07:00:06 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p44DxvXx064259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 May 2011 06:59:58 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <15F3B045D9965C99C66CB2DE@PST.JCK.COM> Date: Wed, 4 May 2011 06:59:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BE91238-09AF-4935-8C9E-C15F27C34F7A@imc.org> References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> <87mxj2kdy3.fsf@latte.josefsson.org> <15F3B045D9965C99C66CB2DE@PST.JCK.COM> To: John C Klensin X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 04 May 2011 15:21:53 -0700 Cc: Simon Josefsson , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 14:00:08 -0000 +1 to all of John's logic, and to his suggestion that we punt the = decision to the IESG. --Paul Hoffman= From joseph.yee@gmail.com Wed May 4 14:27:21 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A54AE07AA for ; Wed, 4 May 2011 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZKgqn736P9E for ; Wed, 4 May 2011 14:27:20 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7EE06A3 for ; Wed, 4 May 2011 14:27:20 -0700 (PDT) Received: by qwc23 with SMTP id 23so1285674qwc.31 for ; Wed, 04 May 2011 14:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1ySdbA6PnP2STY+wa5C3wIQeKmu8M/9LJ7FiHJXfXB0=; b=hjRUFYRhSDjZRki7q8A08hgzwxe5dvpFQHo9Pl6YGbj3t24vfRRWydaEg/RUcmymJg SOuJ8kowSXRiHMvdiNMeVMMPZvIcAo5Q5x2FMTJuJYWB8msPvr84o8Z4fyuvwAM8Yb8x dnSrbH/YHkUpwTMjRRPQAM76seFTP1eOT4jns= 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=EF5fLuDqA8Bnw8QtFsbQQS0nBDAbNGhBuD7tyo4xzEBPGPEpekMDiqJRKzaqcp3SeH 2ZGUClMel7r6MWSgbNI1WUdkMzBxnQVI7cCSuTaLaZlSgSMtIPusvyERTGyAdYHL4KEX ArHThi0gyEaB6QX2BxN9+FSuHHjZe741nJ1l4= MIME-Version: 1.0 Received: by 10.52.173.200 with SMTP id bm8mr679677vdc.24.1304544439835; Wed, 04 May 2011 14:27:19 -0700 (PDT) Received: by 10.52.161.9 with HTTP; Wed, 4 May 2011 14:27:19 -0700 (PDT) In-Reply-To: <504501195.20801@cnnic.cn> References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> Date: Wed, 4 May 2011 17:27:19 -0400 Message-ID: From: Joseph Yee To: Jiankang YAO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 04 May 2011 15:21:54 -0700 Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 May 2011 21:27:21 -0000 I read the draft and support its publication. Regards, Joseph 2011/5/4 Jiankang YAO : > > > Reminder. The WG last call will end soon. If you still have any comments, > pls > kindly give it before the deadline. > > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > ----- Original Message ----- > From: Jiankang Yao > To: apps-discuss@ietf.org > Cc: idna-update@alvestrand.no > Sent: Sunday, April 24, 2011 12:25 AM > Subject: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-faltstrom-5892bis-04.txt.=C2=A0=C2=A0We did=C2=A0formally > adopt this I-D as a WG document a few months ago. > There has a lot of discussion and an informal last call for comments abou= t > this draft in the IDNAbis list idna-update@alvestrand.no. > The editors/authors of this draft believe that this=C2=A0draft has been i= n a very > good shape. > Please review the draft.=C2=A0 If you support publication, please state a= s > much on the list.=C2=A0 If you are opposed to publication, please state > that on the list as well.=C2=A0 It is more/only helpful=C2=A0if you give= =C2=A0your reasons > for > your position as part of your statement. > > Since this draft is the WG item of APPSAWG, we favor that the comments to > this draft=C2=A0are sent to the list > apps-discuss@ietf.org. > The WGLC will end on May 08, 2011 at 23:00 UTC. > > Note:=C2=A0This draft=C2=A0is a document that updates an earlier RFC by s= tating > nothing is to be updated. > > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > ________________________________ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > > From yaojk@cnnic.cn Wed May 4 18:13:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD37E0670 for ; Wed, 4 May 2011 18:13:32 -0700 (PDT) X-Quarantine-ID: <8x-QASA8PDbr> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.326 X-Spam-Level: X-Spam-Status: No, score=-99.326 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x-QASA8PDbr for ; Wed, 4 May 2011 18:13:32 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 89456E0669 for ; Wed, 4 May 2011 18:13:30 -0700 (PDT) Received: (eyou send program); Thu, 05 May 2011 09:13:28 +0800 Message-ID: <504558008.18089@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 05 May 2011 09:13:28 +0800 Message-ID: From: "Jiankang YAO" To: "Simon Josefsson" References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> <504501632.22118@cnnic.cn> Date: Thu, 5 May 2011 09:13:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 01:13:32 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNpbW9uIEpvc2Vmc3NvbiIg PHNpbW9uQGpvc2Vmc3Nvbi5vcmc+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNu Pg0KQ2M6IDxpZG5hLXVwZGF0ZUBhbHZlc3RyYW5kLm5vPjsgPGFwcHMtZGlzY3Vzc0BpZXRmLm9y Zz4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDExIDU6MzMgUE0NClN1YmplY3Q6IFJlOiBb YXBwcy1kaXNjdXNzXSBXR0xDOiBkcmFmdC1mYWx0c3Ryb20tNTg5MmJpcy0wNC50eHQNCg0KDQo+ ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj4gd3JpdGVzOg0KPiANCj4+IFJlbWluZGVy LiBUaGUgV0cgbGFzdCBjYWxsIHdpbGwgZW5kIHNvb24uIElmIHlvdSBzdGlsbCBoYXZlIGFueSBj b21tZW50cywgcGxzDQo+PiBraW5kbHkgZ2l2ZSBpdCBiZWZvcmUgdGhlIGRlYWRsaW5lLg0KPiAN Cj4gQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoZSBXR0xD PyAgDQo+DQoNClRoYXQgc2VudGVuY2UgdHJpZXMgdG8gZXhwcmVzcyB0aGUgbWVhbmluZyB0aGF0 IHRoZSBhdXRob3JzL2VkaXRvcnMgdHJ5IHRvIGRlbGl2ZXIgdG8gdGhlIFdHLg0KSm9obiBDIEts ZW5zaW4sIHRoZSBjb250cmlidXRvciBvZiB0aGlzIGRvY3VtZW50LCBoYXMgZ2l2ZW4gdGhlIGV4 cGxhbmF0aW9uIG9mIHRoaXMgc2VudGVuc2UgaW4gcmVzcG9uc2UgdG8geW91ciBtZXNzYWdlLCBh bmQgUGF1bCBIb2ZmbWFuLCB0aGUgY28tZWRpdG9yL2F1dGhvciBvZiB0aGlzIGRvY3VtZW50IGhh cyBjb25maXJtZWQgaXQuDQoNClRoYW5rcy4NCg0KSmlhbmthbmcgWWFvDQoNCj5BcyBJIGFza2Vk DQo+IGJlZm9yZSwgaXMgdGhlIGludGVudGlvbiB0aGF0IHRoaXMgZG9jdW1lbnQgd2lsbCBiZSBt YXJrZWQgYXMgdXBkYXRpbmcNCj4gYW55IGVhcmxpZXIgUkZDIG9yIG5vdD8gIA0KPg0KDQpKb2hu IGhhcyBzdWdnZXN0ZWQgdGhhdCB3ZSBzaG91bGQgbGVhdmUgaXQgdG8gYmUgZGVjaWRlZCBieSBJ RVNHLg0KUGVyc29uYWxseSwgSSBhZ3JlZSB3aXRoIGhpcyBzdWdnZXN0aW9uLg0KDQoNCj4NCj5S aWdodCBub3cgdGhlIGRvY3VtZW50IGRvZXMgbm90IGluY2x1ZGUgYW55DQo+ICJVcGRhdGU6IiB0 YWdzLCBzbyBJJ20gY29uZnVzZWQgYnkgeW91ciBzdGF0ZW1lbnQgdGhhdCB0aGUgZG9jdW1lbnQN Cj4gdXBkYXRlcyBhbiBlYXJsaWVyIFJGQy4NCj4gDQo+IFRoYW5rcywNCj4gL1NpbW9uDQo+IA0K Pj4gQmVzdCByZWdhcmRzLA0KPj4gSmlhbmthbmcgWWFvKGFzIGEgY28tY2hhaXIgb2YgQVBQU0FX RykNCj4+DQo+PiAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiAgIEZyb206IEpp YW5rYW5nIFlhbyANCj4+ICAgVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCj4+ICAgQ2M6IGlk bmEtdXBkYXRlQGFsdmVzdHJhbmQubm8gDQo+PiAgIFNlbnQ6IFN1bmRheSwgQXByaWwgMjQsIDIw MTEgMTI6MjUgQU0NCj4+ICAgU3ViamVjdDogW2FwcHMtZGlzY3Vzc10gV0dMQzogZHJhZnQtZmFs dHN0cm9tLTU4OTJiaXMtMDQudHh0DQo+Pg0KPj4NCj4+ICAgRGVhciBjb2xsZWFndWVzLA0KPj4N Cj4+ICAgVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3by13ZWVrIFdHTEMgb24gdGhlIGRyYWZ0DQo+ PiAgIGRyYWZ0LWZhbHRzdHJvbS01ODkyYmlzLTA0LnR4dC4gIFdlIGRpZCBmb3JtYWxseQ0KPj4g ICBhZG9wdCB0aGlzIEktRCBhcyBhIFdHIGRvY3VtZW50IGEgZmV3IG1vbnRocyBhZ28uDQo+PiAg IFRoZXJlIGhhcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGFuZCBhbiBpbmZvcm1hbCBsYXN0IGNhbGwg Zm9yIGNvbW1lbnRzIGFib3V0DQo+PiAgIHRoaXMgZHJhZnQgaW4gdGhlIElETkFiaXMgbGlzdCBp ZG5hLXVwZGF0ZUBhbHZlc3RyYW5kLm5vLiAgDQo+PiAgIFRoZSBlZGl0b3JzL2F1dGhvcnMgb2Yg dGhpcyBkcmFmdCBiZWxpZXZlIHRoYXQgdGhpcyBkcmFmdCBoYXMgYmVlbg0KPj4gaW4gYSB2ZXJ5 IGdvb2Qgc2hhcGUuDQo+Pg0KPj4gICBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdC4gIElmIHlvdSBz dXBwb3J0IHB1YmxpY2F0aW9uLCBwbGVhc2Ugc3RhdGUgYXMNCj4+ICAgbXVjaCBvbiB0aGUgbGlz dC4gIElmIHlvdSBhcmUgb3Bwb3NlZCB0byBwdWJsaWNhdGlvbiwgcGxlYXNlIHN0YXRlDQo+PiAg IHRoYXQgb24gdGhlIGxpc3QgYXMgd2VsbC4gIEl0IGlzIG1vcmUvb25seSBoZWxwZnVsIGlmIHlv dSBnaXZlIHlvdXINCj4+IHJlYXNvbnMgZm9yDQo+PiAgIHlvdXIgcG9zaXRpb24gYXMgcGFydCBv ZiB5b3VyIHN0YXRlbWVudC4gIA0KPj4NCj4+ICAgU2luY2UgdGhpcyBkcmFmdCBpcyB0aGUgV0cg aXRlbSBvZiBBUFBTQVdHLCB3ZSBmYXZvciB0aGF0IHRoZQ0KPj4gY29tbWVudHMgdG8gdGhpcyBk cmFmdCBhcmUgc2VudCB0byB0aGUgbGlzdCBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcuDQo+Pg0KPj4g ICBUaGUgV0dMQyB3aWxsIGVuZCBvbiBNYXkgMDgsIDIwMTEgYXQgMjM6MDAgVVRDLg0KPj4NCj4+ ICAgTm90ZTogVGhpcyBkcmFmdCBpcyBhIGRvY3VtZW50IHRoYXQgdXBkYXRlcyBhbiBlYXJsaWVy IFJGQyBieQ0KPj4gc3RhdGluZyBub3RoaW5nIGlzIHRvIGJlIHVwZGF0ZWQuDQo+Pg0KPj4NCj4+ ICAgQmVzdCByZWdhcmRzLA0KPj4gICBKaWFua2FuZyBZYW8oYXMgYSBjby1jaGFpciBvZiBBUFBT QVdHKQ0KPj4NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4NCj4+ICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAgYXBw cy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPj4gICBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4+ICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBhcHBzLWRp c2N1c3MgbWFpbGluZyBsaXN0DQo+PiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWls aW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNz From presnick@qualcomm.com Wed May 4 21:23:58 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00639E0697 for ; Wed, 4 May 2011 21:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7grWET8VZJZ for ; Wed, 4 May 2011 21:23:57 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4288DE0618 for ; Wed, 4 May 2011 21:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1304569437; x=1336105437; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DC1F76B.5030106@qualcomm.com>|Date:=20We d,=204=20May=202011=2018:03:39=20-0700|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20|CC:=20Simon=20Josefsson=20,=20Jiankang=20YAO=20,=0D=0A=09,=20|Subject:=20 Re:=20[apps-discuss]=20WGLC:=20draft-faltstrom-5892bis-04 .txt|References:=20<503575952.18670@cnnic.cn>=20<50450119 5.20801@cnnic.cn>=09<87mxj2kdy3.fsf@latte.josefsson.org> =20<15F3B045D9965C99C66CB2DE@PST.JCK.COM>|In-Reply-To:=20 <15F3B045D9965C99C66CB2DE@PST.JCK.COM>|Content-Type:=20te xt/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=Non5VC/GxtmSgevl0g3iyJigyxp7lbHA2nDVczN/3ds=; b=A0a6RsL+TckG7lRjdC0F2L2QYn/MbPRxVxRLx2r1VpZ1stxw4PAKsm4e r5s2fVuzFVUIeG4DcdoNbVxEnmqxEiSYOCpR1rnHy+GYFgpsfbDv1Ob9U lTnhUvdBaO7NVHFONo1Btu1RmnhEBkow6NTBYN2/2C6pyHrr4jKbd7b+B k=; X-IronPort-AV: E=McAfee;i="5400,1158,6336"; a="89607601" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 04 May 2011 21:23:56 -0700 X-IronPort-AV: E=Sophos;i="4.64,318,1301900400"; d="scan'208";a="48432315" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 May 2011 21:23:56 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 4 May 2011 21:21:22 -0700 Message-ID: <4DC1F76B.5030106@qualcomm.com> Date: Wed, 4 May 2011 18:03:39 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> <87mxj2kdy3.fsf@latte.josefsson.org> <15F3B045D9965C99C66CB2DE@PST.JCK.COM> In-Reply-To: <15F3B045D9965C99C66CB2DE@PST.JCK.COM> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Simon Josefsson , idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 04:23:58 -0000 On 5/4/11 8:47 AM, John C Klensin wrote: > My recommendation to the WG is that we not waste time on this. > The WG Chairs (or other shepherd) should attach a note to the > IESG pointing out the difficulty (borrowing text from your notes > and the above if it would be useful) and leaving it to the IESG > and RFC Editor to decide whether an "updates" header is > appropriate. They will need to decide anyway and the issue is > really a procedural and editorial one, not one on which the > AppsAWG needs to decide. > > Sorry Peter and Pete:-) > Of things the IESG is asked to deal with, this seems not the worst. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From simon@josefsson.org Wed May 4 23:53:00 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21CDE069F for ; Wed, 4 May 2011 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi-hryHrHVqQ for ; Wed, 4 May 2011 23:52:59 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEAAE0651 for ; Wed, 4 May 2011 23:52:59 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p456qd5x032087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 May 2011 08:52:41 +0200 From: Simon Josefsson To: "Jiankang YAO" References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> <504501632.22118@cnnic.cn> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110505:yaojk@cnnic.cn::jU+dK85A5QIqc7On:7N0Q X-Hashcash: 1:22:110505:apps-discuss@ietf.org::JngEKK/yWcrTtD1B:AO6b X-Hashcash: 1:22:110505:idna-update@alvestrand.no::ZTrS41QJECtV1+A9:Y5o4 Date: Thu, 05 May 2011 08:52:39 +0200 In-Reply-To: (Jiankang YAO's message of "Thu, 5 May 2011 09:13:30 +0800") Message-ID: <87oc3hd4g8.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: idna-update@alvestrand.no, apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 06:53:00 -0000 "Jiankang YAO" writes: > ----- Original Message ----- > From: "Simon Josefsson" > To: "Jiankang YAO" > Cc: ; > Sent: Wednesday, May 04, 2011 5:33 PM > Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt > > >> "Jiankang YAO" writes: >> >>> Reminder. The WG last call will end soon. If you still have any comments, pls >>> kindly give it before the deadline. >> >> Could you please clarify the last sentence in the WGLC? >> > > That sentence tries to express the meaning that the authors/editors > try to deliver to the WG. > John C Klensin, the contributor of this document, has given the > explanation of this sentense in response to your message, and Paul > Hoffman, the co-editor/author of this document has confirmed it. > > Thanks. > > Jiankang Yao > >>As I asked >> before, is the intention that this document will be marked as updating >> any earlier RFC or not? >> > > John has suggested that we should leave it to be decided by IESG. > Personally, I agree with his suggestion. Thanks for response -- this seems fine to me as well. /Simon From joseph.yee@gmail.com Thu May 5 05:27:29 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D867E0752 for ; Thu, 5 May 2011 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wem5rGYZ6ZNp for ; Thu, 5 May 2011 05:27:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2245EE0721 for ; Thu, 5 May 2011 05:27:28 -0700 (PDT) Received: by vxg33 with SMTP id 33so2697954vxg.31 for ; Thu, 05 May 2011 05:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=OpvERIwlkZqWQGnOhMUZ/M8ihg2P/9J9smz1m3erZ5I=; b=u9+Ame+Wjdwr9yN+x86W6JFl7CCCTuGSqHOehlJiGBLhOpt8TrG+c1z534dctMIN1Y APEVpHA0NLLvNDrMFboJTg6Q6gAcZjw8q8Xhfq0DE8G65EGjmt/mHv39qrSlQIcww9H4 cosOdqxAZ95yE9NudsUlUciHVDL4EWTIvE5Dk= 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 :content-type:content-transfer-encoding; b=LsTuypGXKw7JKeKsF7SwjRK6pkAky/G8f4OFt+rT3Zq/6ee0sYd+lSFMc2oxAqL1lZ 2OxuZmfxQ83H0JQ59HbX8RbUozzRqGzmLTlxmePcQywfyR6/jjRF4a953CoRYehu+2rl B1XiBjysrXnjRPVfu+gJgelQoMP3bPzYV4Ee0= MIME-Version: 1.0 Received: by 10.52.98.137 with SMTP id ei9mr2981281vdb.64.1304598447402; Thu, 05 May 2011 05:27:27 -0700 (PDT) Received: by 10.52.161.9 with HTTP; Thu, 5 May 2011 05:27:27 -0700 (PDT) In-Reply-To: References: <503575952.18670@cnnic.cn> <504501195.20801@cnnic.cn> Date: Thu, 5 May 2011 08:27:27 -0400 Message-ID: From: Joseph Yee To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 12:27:29 -0000 I read the draft and support its publication. Regards, Joseph > 2011/5/4 Jiankang YAO : >> >> >> Reminder. The WG last call will end soon. If you still have any comments= , >> pls >> kindly give it before the deadline. >> >> Best regards, >> Jiankang Yao(as a co-chair of APPSAWG) >> >> ----- Original Message ----- >> From: Jiankang Yao >> To: apps-discuss@ietf.org >> Cc: idna-update@alvestrand.no >> Sent: Sunday, April 24, 2011 12:25 AM >> Subject: [apps-discuss] WGLC: draft-faltstrom-5892bis-04.txt >> Dear colleagues, >> >> This message starts a two-week WGLC on the draft >> draft-faltstrom-5892bis-04.txt.=C2=A0=C2=A0We did=C2=A0formally >> adopt this I-D as a WG document a few months ago. >> There has a lot of discussion and an informal last call for comments abo= ut >> this draft in the IDNAbis list idna-update@alvestrand.no. >> The editors/authors of this draft believe that this=C2=A0draft has been = in a very >> good shape. >> Please review the draft.=C2=A0 If you support publication, please state = as >> much on the list.=C2=A0 If you are opposed to publication, please state >> that on the list as well.=C2=A0 It is more/only helpful=C2=A0if you give= =C2=A0your reasons >> for >> your position as part of your statement. >> >> Since this draft is the WG item of APPSAWG, we favor that the comments t= o >> this draft=C2=A0are sent to the list >> apps-discuss@ietf.org. >> The WGLC will end on May 08, 2011 at 23:00 UTC. >> >> Note:=C2=A0This draft=C2=A0is a document that updates an earlier RFC by = stating >> nothing is to be updated. >> >> Best regards, >> Jiankang Yao(as a co-chair of APPSAWG) >> >> ________________________________ >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> _______________________________________________ >> Idna-update mailing list >> Idna-update@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/idna-update >> >> > From vumip1@gmail.com Thu May 5 09:28:37 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA54E08C5 for ; Thu, 5 May 2011 09:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oWUn-82I3mm for ; Thu, 5 May 2011 09:28:37 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D819CE08A6 for ; Thu, 5 May 2011 09:28:36 -0700 (PDT) Received: by yic13 with SMTP id 13so1005744yic.31 for ; Thu, 05 May 2011 09:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ZQn2SXkHr+xOvx+VZqeGCgLA24mXmFsTIcYYvpm6RTc=; b=ov516ofuKgb0zhYTXUNcuRkD09xNqsiHboB9nITOKJo/uuPWJ01hfuRBeWBoLWY+Xf c+Nr1dIVdAxXf+kgYA0cvkz6yRe2mjv42yjeNHZGydFHcwKx5vxUxXROj35z3Dt1hs1+ PGB1XETaFN+QeA2vQH4wClmNoMOYYXl1KA1UY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j/JGaPq1RbkuZ9PrceuSKbm2obQ89qeRs8nMw67x7HW4f3edn4IVEcrUL0+dD5XZoH 6LEWNNnwucpUq6gvmeNvOlIOLNR4sDoFErXYN7ug9HpvfrXwzAMyAkR+RZvpA7WWyhsV NCgB4v4kEbuCPefSXi84h98jQPDOG2RYt8heg= MIME-Version: 1.0 Received: by 10.236.154.97 with SMTP id g61mr2544440yhk.289.1304612916055; Thu, 05 May 2011 09:28:36 -0700 (PDT) Received: by 10.236.110.12 with HTTP; Thu, 5 May 2011 09:28:36 -0700 (PDT) Date: Thu, 5 May 2011 12:28:36 -0400 Message-ID: From: Bhumip Khasnabish To: "So, Ning" , Apps Discuss Content-Type: multipart/alternative; boundary=20cf303dd7586e4eb904a289ddcd Subject: [apps-discuss] pls note that invitation for tomorow's VDI call will be announced to apps-discuss@ietf.org only. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 16:28:37 -0000 --20cf303dd7586e4eb904a289ddcd Content-Type: text/plain; charset=ISO-8859-1 Ning, Please note that the invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only. PLS let me know ASAP if it is OK to announce. Thanks Best Regards. Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com) http://www.linkedin.com/in/bhumipkhasnabish --20cf303dd7586e4eb904a289ddcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ning,
=A0
Please note that the invitation for tomorrow's VDI call will be an= nounced to apps-discuss@ietf.org only.
=A0
PLS let me know ASAP if it is OK to announce. Thanks
=

=A0
--20cf303dd7586e4eb904a289ddcd-- From adrian@olddog.co.uk Thu May 5 11:26:15 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA133E07B3 for ; Thu, 5 May 2011 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx5cTyEMHyaE for ; Thu, 5 May 2011 11:26:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 773C1E093B for ; Thu, 5 May 2011 11:26:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p45IPuB0020575; Thu, 5 May 2011 19:25:56 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p45IPsh0020560; Thu, 5 May 2011 19:25:54 +0100 From: "Adrian Farrel" To: "'Bhumip Khasnabish'" , "'So, Ning'" , "'Apps Discuss'" Date: Thu, 5 May 2011 19:25:55 +0100 Message-ID: <095c01cc0b51$e005ba30$a0112e90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_095D_01CC0B5A.41DF7EF0" X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AcwLUd3Hp9K8eAhlQLSiM4p0he6jxg== Subject: Re: [apps-discuss] pls note that invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:26:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_095D_01CC0B5A.41DF7EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the status of this call? Is it a closed Design Team call, or an open call for any IETF participant? Thanks, Adrian From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Bhumip Khasnabish Sent: 05 May 2011 17:29 To: So, Ning; Apps Discuss Subject: [apps-discuss] pls note that invitation for tomorow's VDI call will be announced to apps-discuss@ietf.org only. Ning, Please note that the invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only. PLS let me know ASAP if it is OK to announce. Thanks Best Regards. Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com) http://www.linkedin.com/in/bhumipkhasnabish ------=_NextPart_000_095D_01CC0B5A.41DF7EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the status of this = call?

Is it a closed Design Team = call, or an open call for any IETF participant?

 

Thanks,

Adrian

 

From: = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Bhumip Khasnabish
Sent: 05 May 2011 = 17:29
To: So, Ning; Apps Discuss
Subject: = [apps-discuss] pls note that invitation for tomorow's VDI call will be = announced to apps-discuss@ietf.org = only.

 

Ning,

 

Please note that the invitation for tomorrow's VDI = call will be announced to apps-discuss@ietf.org = only.

 

PLS let me know ASAP if it is OK to announce. = Thanks

Best Regards.

Bhumip Khasnabish = (Mobile:+001-781-752-8003, vumip1@gmail.com)
http://www.linkedin.com/in/bhumipkhasnabish


 

------=_NextPart_000_095D_01CC0B5A.41DF7EF0-- From vumip1@gmail.com Thu May 5 18:27:43 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FE2E075F for ; Thu, 5 May 2011 18:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1AwKxkdrdtN for ; Thu, 5 May 2011 18:27:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60A26E075C for ; Thu, 5 May 2011 18:27:42 -0700 (PDT) Received: by ywi6 with SMTP id 6so1212295ywi.31 for ; Thu, 05 May 2011 18:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UVo+ARmtG6w0rlIFvd4ANyn6aFyHbCc1W+rFOcy9fYU=; b=FmE46GmkbfDfOKqT6V9dgACWBSCx+3Vfska0VuzE7yEhDqRTc77BUwQdsPwDMYoBk5 kZvjDKZklMZ4SG3RR95XmkmGgTQ+oIvFysPmlUea+O1P2FADNoJ0fvf7J/Xrq6cUrYCq phAjxXuCFBTm1H6phrjn+RGCaRt4ptLQqyJM0= 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=bVZiCDVkqIYAtECAKGHOuayed95WOw4yrZAZcKdi2sgzufbo0D/NuqPw712KMoKz2w jq/wLm6TQJTpxPU7U/W37J1K0XCss3X/VTEtRAQpuOYOf++Nixcgh4GksGgXsQr1VLNL GVF+6Z6Y6AOp6o+TgOxfH/b+R4uyZ04S3TvR4= MIME-Version: 1.0 Received: by 10.236.31.103 with SMTP id l67mr3918931yha.21.1304645261747; Thu, 05 May 2011 18:27:41 -0700 (PDT) Received: by 10.236.110.12 with HTTP; Thu, 5 May 2011 18:27:41 -0700 (PDT) In-Reply-To: <095c01cc0b51$e005ba30$a0112e90$@olddog.co.uk> References: <095c01cc0b51$e005ba30$a0112e90$@olddog.co.uk> Date: Thu, 5 May 2011 21:27:41 -0400 Message-ID: From: Bhumip Khasnabish To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=000e0cd50ae66267a504a29165d2 Cc: "So, Ning" , Apps Discuss Subject: Re: [apps-discuss] pls note that invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:27:43 -0000 --000e0cd50ae66267a504a29165d2 Content-Type: text/plain; charset=ISO-8859-1 For tomorrow's mtg., we plan to hold a discussion among the VDI related drafts' (existing/proposed) authors/contributors. Thanks. On Thu, May 5, 2011 at 2:25 PM, Adrian Farrel wrote: > What is the status of this call? > > Is it a closed Design Team call, or an open call for any IETF participant? > > > > Thanks, > > Adrian > > > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Bhumip Khasnabish > *Sent:* 05 May 2011 17:29 > *To:* So, Ning; Apps Discuss > *Subject:* [apps-discuss] pls note that invitation for tomorow's VDI call > will be announced to apps-discuss@ietf.org only. > > > > Ning, > > > > Please note that the invitation for tomorrow's VDI call will be announced > to apps-discuss@ietf.org only. > > > > PLS let me know ASAP if it is OK to announce. Thanks > > Best Regards. > > Bhumip Khasnabish (Mobile:+001-781-752-8003, vumip1@gmail.com) > http://www.linkedin.com/in/bhumipkhasnabish > > > > --000e0cd50ae66267a504a29165d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For tomorrow's mtg., we plan to=A0hold=A0a discussion among the VD= I related drafts' (existing/proposed) authors/contributors. Thanks.
=
On Thu, May 5, 2011 at 2:25 PM, Adrian Farrel <adrian@olddog.co= .uk> wrote:

What= is the status of this call?

Is i= t a closed Design Team call, or an open call for any IETF participant?

=A0<= /span>

Than= ks,

Adri= an

=A0<= /span>

Fr= om: apps-discuss-bounces@= ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Bhumip = Khasnabish
Sent: 05 May 2011 17:29
To: So, Ning; Apps Discuss
S= ubject: [apps-discuss] pls note that invitation for tomorow's VDI c= all will be announced to apps-discuss@ietf.org only.

=A0

Ning,

=A0

Please note that the invitation for tomorrow's V= DI call will be announced to apps-discuss@ietf.org only.

=A0

PLS let me know ASAP if it is OK to announce. Thanks=


=A0

--000e0cd50ae66267a504a29165d2-- From barryleiba.mailing.lists@gmail.com Fri May 6 08:03:18 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EF2E071D; Fri, 6 May 2011 08:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5W-XXuJW7nX; Fri, 6 May 2011 08:03:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC77FE06EA; Fri, 6 May 2011 08:03:17 -0700 (PDT) Received: by yxk30 with SMTP id 30so1465166yxk.31 for ; Fri, 06 May 2011 08:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=se6poWpwEQasIHLT8jnICIfJnk9xVIu8Fn9MVX0s1Ks=; b=LnX1gCEZoB6vhxB18bxddF56+IU8nSxSNfuUmxlzhq14Sf40W0ihCQLAfIeUmS4sh2 DqM5PJ8w/utCDMur9Rx3k2Im2k3uKEklJW+pOpOrDxbtnyp6EBAOXi5G3APRAWmyLnb3 z89T6nfRVJe0e6xk6KM0LJ6DtLqH5rLrbS0kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hLTSIbJZCjgbn3roJE9mlohMVOmjbqPCnV9tWiJpckvNZlLC7zx15FXtU1C4cLTiJO JT3PPbVqmLTThrj4+wNq3nTXHuUhECr/yrXOoC0SyYFEzTpjqCl5L2//gebxZBRZ7LMk CCm5xo5QLcJH/nl9UN1eNBm+ERxrqt+mroAHY= MIME-Version: 1.0 Received: by 10.146.242.14 with SMTP id p14mr3293125yah.25.1304694196627; Fri, 06 May 2011 08:03:16 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Fri, 6 May 2011 08:03:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2011 11:03:16 -0400 X-Google-Sender-Auth: rR1ZIED1u9HzH-2cgyk0M6Es8tA Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 15:03:18 -0000 Thanks for the review, Murray. First, just making sure you reviewed the right document: > Document: draft-melnikov-sieve-external-lists It hasn't been that for a long time, and the correct current version is draft-ietf-sieve-external-lists-07 : http://tools.ietf.org/html/draft-ietf-sieve-external-lists > Major Issues: > 1. Altering list behaviour based on data available external to the Sieve = processing > code means alteration of such data presents a vector for attack. =A0The S= ecurity > Considerations section should mention this. =A0It does mention some relat= ed issues > (e.g., authentication) but not the one I have in mind, namely that the ou= tcome of > the Sieve script becomes dependent on external data not necessarily under= direct > control of the user. Hm. I'd have thought that to be sufficiently obvious as not to require mention -- we *are* going out to an *external* list, after all. But I'm happy to put something in for that, sure. How about inserting the following paragraph after the one about "confidentiality and authentication"?: ------------- Having the processing and outcome of a Sieve script depend on the contents of external data can allow someone with control of the external data to hav= e unusual, and perhaps unauthorized, control of the script -- and, consequent= ly, of the disposition of the user's email. A user using such a list for spam control, for example, might find important mail being discarded because of tampering with the list. Someone using redirect to an external list could have her e= mail redirected to the wrong eyes because of such tampering. Security and integ= rity protection of external lists is as important as protection of the Sieve scr= ipt itself. ------------- > 1. Since the document references the possibility of storing lists in exte= rnal > relational databases, I was surprised not to see a specific reference to = how > one might be used. =A0Is it the case that no URI schema exists yet for re= ferring > to, say, an SQL query? =A0If such does exist, an example of this would be= good > to include, but certainly not required (especially if such a schema has y= et to > be registered). As I've said on the mailing lists about examples: I'm a fan of having many examples, and I'll be happy to add more if someone would provide me with specific text. I'm loath to try to concoct more off the top of my head at this point, and will rely on dependable submissions. > Nits: > 1. ":list" is sometimes quoted in the document and sometimes not. > It should be consistent throughout. It should; I've changed that in my working version. Barry From msk@cloudmark.com Fri May 6 08:10:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC12E06E6; Fri, 6 May 2011 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.926 X-Spam-Level: X-Spam-Status: No, score=-104.926 tagged_above=-999 required=5 tests=[AWL=-1.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PJFYwT-+m-A; Fri, 6 May 2011 08:10:31 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF7E06BB; Fri, 6 May 2011 08:10:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 6 May 2011 08:10:30 -0700 From: "Murray S. Kucherawy" To: Barry Leiba Date: Fri, 6 May 2011 08:10:29 -0700 Thread-Topic: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists Thread-Index: AcwL/r1cjUczv5jYQLWwR27CYhiMNAAAGVOw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 15:10:32 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Friday, May 06, 2011 8:03 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; alexey.melnikov@isode.com; cyrus@daboo.name; a= aron@serendipity.cx; iesg@ietf.org > Subject: Re: [apps-discuss] apps-review team review for draft-melnikov-si= eve-external-lists >=20 > Thanks for the review, Murray. >=20 > First, just making sure you reviewed the right document: > > Document: draft-melnikov-sieve-external-lists > It hasn't been that for a long time, and the correct current version > is draft-ietf-sieve-external-lists-07 : > http://tools.ietf.org/html/draft-ietf-sieve-external-lists Sorry, yes; I copied it from the top of that URL which has a link to the or= iginal name. I did look at the newest one. > Hm. I'd have thought that to be sufficiently obvious as not to > require mention -- we *are* going out to an *external* list, after > all. But I'm happy to put something in for that, sure. How about > inserting the following paragraph after the one about "confidentiality > and authentication"?: > ------------- > Having the processing and outcome of a Sieve script depend on the content= s > of external data can allow someone with control of the external data to h= ave > unusual, and perhaps unauthorized, control of the script -- and, conseque= ntly, > of the disposition of the user's email. A user using such a list for spa= m control, > for example, might find important mail being discarded because of tamperi= ng > with the list. Someone using redirect to an external list could have her= email > redirected to the wrong eyes because of such tampering. Security and int= egrity > protection of external lists is as important as protection of the Sieve s= cript > itself. > ------------- That or something like it would be ideal. > As I've said on the mailing lists about examples: I'm a fan of having > many examples, and I'll be happy to add more if someone would provide > me with specific text. I'm loath to try to concoct more off the top > of my head at this point, and will rely on dependable submissions. Fair enough, and I'm not even sure there's an SQL URI scheme yet upon which= to base one. It just seems an obvious one to add since it's referenced. > > Nits: > > 1. ":list" is sometimes quoted in the document and sometimes not. > > It should be consistent throughout. >=20 > It should; I've changed that in my working version. Thanks! -MSK From alexey.melnikov@isode.com Fri May 6 12:42:44 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DD7E079B; Fri, 6 May 2011 12:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE18y+XF51NM; Fri, 6 May 2011 12:42:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 50116E0789; Fri, 6 May 2011 12:42:43 -0700 (PDT) Received: from [188.29.153.57] (188.29.153.57.threembb.co.uk [188.29.153.57]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 6 May 2011 20:42:40 +0100 Message-ID: <4DC44F25.309@isode.com> Date: Fri, 06 May 2011 20:42:29 +0100 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: "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 19:42:45 -0000 Hi Murray, Murray S. Kucherawy wrote: >>As I've said on the mailing lists about examples: I'm a fan of having >>many examples, and I'll be happy to add more if someone would provide >>me with specific text. I'm loath to try to concoct more off the top >>of my head at this point, and will rely on dependable submissions. >> >> >Fair enough, and I'm not even sure there's an SQL URI scheme yet upon which to base one. It just seems an obvious one to add since it's referenced. > > I don't know of any URI scheme related to SQL. From internet-drafts@ietf.org Fri May 6 15:01:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13503E0858; Fri, 6 May 2011 15:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MabsyMwqxaAf; Fri, 6 May 2011 15:01:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6689E069A; Fri, 6 May 2011 15:01:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 15:01:30 -0700 X-Mailman-Approved-At: Sat, 07 May 2011 09:05:04 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 22:01:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Terminology Used in Internationalization in the IETF Author(s) : Paul Hoffman John C Klensin Filename : draft-ietf-appsawg-rfc3536bis-00.txt Pages : 46 Date : 2011-05-03 This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-00.txt From evnikita2@gmail.com Sun May 8 22:05:39 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B24E068E for ; Sun, 8 May 2011 22:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=-2.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqpR6UuNsSnT for ; Sun, 8 May 2011 22:05:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA6E0669 for ; Sun, 8 May 2011 22:05:37 -0700 (PDT) Received: by bwz13 with SMTP id 13so4388749bwz.31 for ; Sun, 08 May 2011 22:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=kNdksvq/tGw1oPqfcbWvYAkfaHjdRaErFrwIEwkTggY=; b=Mk/pyn1VbOLcnE87cmRscJQH09dfUUqTODMG/38ZqWaLliMtAWYMNVd36OLMe87biX Ln9RIk/gf+Svw1GMTLGaQMju8DIL/t9xzCGfR5gFce3eNAXB1omUNwHCmqavoeUmfOlr hJHxClhyuAIyZ6B1Wvs6OY5zlsbB1AC+Vy4SE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=qhawzadX2EwKkF72Rz8PB4rkzDL5c1lqEkpYSb3kwvwlkxKvk+XapWmqyXTDhXlKzh AVZgEFSG/ETIQ3Gq9721noO7dgKJ8a7stALOw6sqwqwDSuh1kbmeq5QOaesytw2UAuzm WfQvmG/Ru4ioXyngRCQ37ZwPs8hWDqILqdqrY= Received: by 10.204.19.20 with SMTP id y20mr1130585bka.170.1304917535039; Sun, 08 May 2011 22:05:35 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id u15sm3429529bkf.4.2011.05.08.22.05.32 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 22:05:33 -0700 (PDT) Message-ID: <4DC77648.1040903@gmail.com> Date: Mon, 09 May 2011 08:06:16 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> In-Reply-To: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030909050405090300060702" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 05:05:39 -0000 This is a multi-part message in MIME format. --------------030909050405090300060702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, We've recently adopted draft-hoffman-rfc3536bis as WG document. I'd like to provide some comments on it. From Section 1.1, last paragraph: > This document uses definitions from many documents that have been > developed outside the IETF. The primary documents used are: > > [ ... ] > > o IETF RFCs, including the Character Set Policy specification > [RFC2277 ] This sounds a bit confusing, since the previous sentence says "outside the IETF" and the next one mentions IETF RFCs. So I propose to change it as follows: > This document uses definitions from many documents, including those > developed outside the IETF. Mostly, the following documents > were used: > > [ as current draft ] From Section 2, "language" definition: > language > > A language is a way that humans interact. The use of language > occurs in many forms, the most common of which are speech, > writing, and signing. I think this definition is not correct. "A way that humans interact" is too generalized. I suppose the following definition would suit better here. > language > > A language is a set of conventions on rules affecting humans' > speech. The most common use of a language is speaking and > writing. > > [ as in current draft ] Also "character" definition. It would be useful to mention that "character" is often abbreviated to "char" From Section 4.1: > punctuation > > Characters that separate units of text, [ . . . ] they are also used in > mathematical and scientific formulae, for example. > > symbol > > One of a set of characters [ . . . ] > > Examples of symbols include characters for mathematical operators, > [ . . . ] I see these two definitions give a bit contiguous specification of where chars used in formula. You should either clarify the use of punctuation marks in formula or consider such chars belonging to one of such category. Also from Section 4.1: > control character I think we can clarify a bit this definition by mentioning: "The semantics of control characters depend on the application they are used with. The most common control characters semantics are specified in ISO/IEC 6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, like this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control functions for coded character sets",1992." Proposal for inclusion of definition in Section 8. I think we could also define "noncharacter" here (and appropriate entry in the Index). My proposed definition: > noncharacter > > A noncharacter is a code point that is permanently reserved > in some particular coded character set and is generally > forbidden to be used in open data interchange. Some comments on References: > [UNICODE] The Unicode Consortium, "The Unicode Standard, Version > 5.2.0", Mountain View, CA: The Unicode Consortium, This version - 5.2.0 - is obsolete. It is superseded by 6.0.0; the reference should be: "The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6) " > [ISO3166] ISO, "ISO 3166-1:2006 - Codes for the representation of > names of countries and their subdivisions -- Part 1: > Country codes", 20066. I don't think they've invented time machine to write this in 20066 :-) Obviously, this is a typo: s/20066/2006 I also think the reference to [CHARMOD] is a bit incorrect as well. I propose: > Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and > T. Texin, Ed., "Character Model for the World Wide Web 1.0", W3C > Recommendation, February 2005. To finish, why the intended status for this draft is BCP? Longstanding IETF practice is to publish glossaries as Informational docs (previously, FYIs); examples are http://tools.ietf.org/html/rfc1208, http://tools.ietf.org/html/rfc1983, http://tools.ietf.org/html/rfc4949 and the predecessor of this draft itself - http://tools.ietf.org/html/rfc3536. I think Informational would suit better here. All the best, Mykyta Yevstifeyev 07.05.2011 1:01, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Terminology Used in Internationalization in the IETF > Author(s) : Paul Hoffman > John C Klensin --------------030909050405090300060702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all,

We've recently adopted draft-hoffman-rfc3536bis as WG document.  I'd like to provide some comments on it.

From Section 1.1, last paragraph:

   This document uses definitions from many documents that have been
   developed outside the IETF.  The primary documents used are:

  [ ... ]  

   o  IETF RFCs, including the Character Set Policy specification
      [RFC2277]
This sounds a bit confusing, since the previous sentence says "outside the IETF" and the next one mentions IETF RFCs.  So I propose to change it as follows:

     This document uses definitions from many documents, including those
     developed outside the IETF.  Mostly, the following documents
     were used:

     [ as current draft ]

From Section 2, "language" definition:

   language

      A language is a way that humans interact.  The use of language
      occurs in many forms, the most common of which are speech,
      writing, and signing. <NONE>
I think this definition is not correct.  "A way that humans interact" is too generalized.  I suppose the following definition would suit better here.

    language
 
       A language is a set of conventions on rules affecting humans'
       speech.  The most common use of a language is speaking and
       writing. <NONE>

       [ as in current draft ]

Also "character" definition.  It would be useful to mention that "character" is often abbreviated to "char"

From Section 4.1:
         
   punctuation

      Characters that separate units of text,  [ . . . ] they are also used in
      mathematical and scientific formulae, for example. <UNICODE>

   symbol

      One of a set of characters  [ . . . ]

      Examples of symbols include characters for mathematical operators,
       [ . . . ]

I see these two definitions give a bit contiguous specification of where chars used in formula.  You should either clarify the use of punctuation marks in formula or consider such chars belonging to one of such category.

Also from Section 4.1:

   control character
I think we can clarify a bit this definition by mentioning: "The semantics of control characters depend on the application they are used with.  The most common control characters semantics are specified in ISO/IEC 6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, like this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control functions for coded character sets",1992."

Proposal for inclusion of definition in Section 8.  I think we could also define "noncharacter" here (and appropriate entry in the Index).  My proposed definition:

     noncharacter
      
        A noncharacter is a code point that is permanently reserved
        in some particular coded character set and is generally
        forbidden to be used in open data interchange. <UNICODE>

Some comments on References:

   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              5.2.0", Mountain View, CA: The Unicode Consortium,
This version - 5.2.0 - is obsolete.  It is superseded by 6.0.0; the reference should be: "The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6) <http://www.unicode.org/versions/Unicode6.0.0/>"

   [ISO3166]  ISO, "ISO 3166-1:2006 - Codes for the representation of
              names of countries and their subdivisions -- Part 1:
              Country codes", 20066.
I don't think they've invented time machine to write this in 20066 :-)  Obviously, this is a typo: s/20066/2006

I also think the reference to [CHARMOD] is a bit incorrect as well.  I propose:

Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and T. Texin, Ed., "Character Model for the World Wide Web 1.0", W3C Recommendation, February 2005.  <http://www.w3.org/TR/charmod/>
To finish, why the intended status for this draft is BCP?  Longstanding IETF practice is to publish glossaries as Informational docs (previously, FYIs); examples are http://tools.ietf.org/html/rfc1208, http://tools.ietf.org/html/rfc1983, http://tools.ietf.org/html/rfc4949 and the predecessor of this draft itself - http://tools.ietf.org/html/rfc3536.  I think Informational would suit better here.

All the best,
Mykyta Yevstifeyev

07.05.2011 1:01, internet-drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Terminology Used in Internationalization in the IETF
	Author(s)       : Paul Hoffman
                          John C Klensin

--------------030909050405090300060702-- From paul.hoffman@vpnc.org Mon May 9 08:23:25 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C09E0743 for ; Mon, 9 May 2011 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.769 X-Spam-Level: X-Spam-Status: No, score=-100.769 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, MANGLED_MEDS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMgKDKaemYFX for ; Mon, 9 May 2011 08:23:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C5476E06A4 for ; Mon, 9 May 2011 08:23:23 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p49FNIjn001809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 08:23:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DC77648.1040903@gmail.com> Date: Mon, 9 May 2011 08:23:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 15:23:25 -0000 On May 8, 2011, at 10:06 PM, Mykyta Yevstifeyev wrote: > This sounds a bit confusing, since the previous sentence says "outside = the IETF" and the next one mentions IETF RFCs. Fixed. > =46rom Section 2, "language" definition: >=20 >> language >>=20 >> A language is a way that humans interact. The use of language >> occurs in many forms, the most common of which are speech, >> writing, and signing. >>=20 > I think this definition is not correct. "A way that humans interact" = is too generalized. I suppose the following definition would suit = better here. >=20 >> language >> =20 >> A language is a set of conventions on rules affecting humans'=20= >> speech. The most common use of a language is speaking and=20 >> writing. >>=20 >> [ as in current draft ] Your definition is too limiting. Clearly, we are not only talking about = speech. > Also "character" definition. It would be useful to mention that = "character" is often abbreviated to "char" Noted. > =46rom Section 4.1: > =20 >> punctuation >>=20 >> Characters that separate units of text, [ . . . ] they are = also used in >> mathematical and scientific formulae, for example. >>=20 >> symbol >>=20 >> One of a set of characters [ . . . ] >>=20 >> Examples of symbols include characters for mathematical = operators, >> [ . . . ] >>=20 >=20 > I see these two definitions give a bit contiguous specification of = where chars used in formula. You should either clarify the use of = punctuation marks in formula or consider such chars belonging to one of = such category. A particular character can be considered both punctuation and a symbol. > Also from Section 4.1: >=20 >> control character >>=20 > I think we can clarify a bit this definition by mentioning: "The = semantics of control characters depend on the application they are used = with. The most common control characters semantics are specified in = ISO/IEC 6429:1992 [ISO6429]" and adding the appropriate reference to ISO = 6429, like this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- = Control functions for coded character sets",1992." This seems like overkill. We don't define the semantics of any other = code points; why do it for control characters? > Proposal for inclusion of definition in Section 8. I think we could = also define "noncharacter" here (and appropriate entry in the Index). = My proposed definition: >=20 >> noncharacter >> =20 >> A noncharacter is a code point that is permanently reserved >> in some particular coded character set and is generally=20 >> forbidden to be used in open data interchange. "noncharacter" is not a term commonly used in internationalization, I = believe. > Some comments on References: >=20 >> [UNICODE >> ] The Unicode Consortium, "The Unicode Standard, Version >> 5.2.0", Mountain View, CA: The Unicode Consortium, >>=20 > This version - 5.2.0 - is obsolete. It is superseded by 6.0.0; the = reference should be: "The Unicode Consortium. The Unicode Standard, = Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN = 978-1-936213-01-6) " Noted. >=20 >> [ISO3166 >> ] ISO, "ISO 3166-1:2006 - Codes for the representation of >> names of countries and their subdivisions -- Part 1: >> Country codes", 20066. >>=20 > I don't think they've invented time machine to write this in 20066 :-) = Obviously, this is a typo: s/20066/2006 Good catch. > I also think the reference to [CHARMOD] is a bit incorrect as well. I = propose: >=20 >> Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and = T. Texin, Ed., "Character Model for the World Wide Web 1.0", W3C = Recommendation, February 2005. Disagree. Listing a bunch of folks does not help the reference at all. > To finish, why the intended status for this draft is BCP? = Longstanding IETF practice is to publish glossaries as Informational = docs (previously, FYIs); examples are = http://tools.ietf.org/html/rfc1208, http://tools.ietf.org/html/rfc1983, = http://tools.ietf.org/html/rfc4949 and the predecessor of this draft = itself - http://tools.ietf.org/html/rfc3536. I think Informational = would suit better here. As you are well aware, there is differing opinion on this. We'll let the = higher-ups decide. --Paul Hoffman From john-ietf@jck.com Mon May 9 09:11:24 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470DCE0765 for ; Mon, 9 May 2011 09:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xidg-I2WsxOI for ; Mon, 9 May 2011 09:11:22 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2DAE0787 for ; Mon, 9 May 2011 09:11:22 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QJT3B-000Pve-3b; Mon, 09 May 2011 12:11:13 -0400 Date: Mon, 09 May 2011 12:11:12 -0400 From: John C Klensin To: Paul Hoffman , Mykyta Yevstifeyev Message-ID: <92692BD42992CA277C7F3421@PST.JCK.COM> In-Reply-To: <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 16:11:24 -0000 --On Monday, May 09, 2011 08:23 -0700 Paul Hoffman wrote: >... >> Proposal for inclusion of definition in Section 8. I think >> we could also define "noncharacter" here (and appropriate >> entry in the Index). My proposed definition: >> >>> noncharacter >>> >>> A noncharacter is a code point that is permanently >>> reserved in some particular coded character set and >>> is generally forbidden to be used in open data >>> interchange. > > "noncharacter" is not a term commonly used in > internationalization, I believe. The term is also fairly Unicode-specific. While I agree with Paul's answer, two additional observations: (1) This document is about internationalization terminology, not about characters, character sets, and terminology about them. It is impossible to have a discussion about i18n (at least in written text) without dealing with a lot of character set issues, but that does not imply that all character set issues and terminology should be included. (2) With a possible exception when some definitional universe falls cleanly into "A and not-A", one is always better off defining things as what they are (or what the category includes), rather than what they aren't. While I understand what the Unicode folks were trying to do and why, and am relieved that no one asked me about a better term, "noncharacter" isn't a strict opposite of "character". Indeed, if one adopts some common definitions of the "character" category, "noncharacter" becomes a subset with a particular set of properties. In that context, the definition above isn't really a definition but a description because "generally forbidden" is insufficient to define what is in the category and what isn't. That is not a problem for Unicode because also all of their terminology is descriptive: category-assignment is not a consequence of definitions but of tables. If we were to define it, we would have to include disclaimers about using the term. I don't see that as worthwhile unless the term were used prominently in i18n contexts in the IETF and, as Paul suggests, it isn't. >> To finish, why the intended status for this draft is BCP? >> Longstanding IETF practice is to publish glossaries as >> Informational docs (previously, FYIs); examples are >> http://tools.ietf.org/html/rfc1208, >> http://tools.ietf.org/html/rfc1983, >> http://tools.ietf.org/html/rfc4949 and the predecessor of >> this draft itself - http://tools.ietf.org/html/rfc3536. I >> think Informational would suit better here. > As you are well aware, there is differing opinion on this. Actually, "longstanding IETF practice" is to publish materials that are normatively required for standards-track documents as BCPs or on the standards-track, both because that makes sense and because it avoids "normative reference" problems (I note that draft-housley-two-maturity-levels makes no provision for downward references to Informational documents, leaving RFC 3967 unchanged as the only way to deal with such references). The most-widely-cited example of this is BCP 2119. One way to look at the distinction is that some documents (RFCs 1208, 1392, and 4949 included) are glossaries that are essentially descriptive of common contemporary practice. So, arguably, was 3536 itself. Other documents are efforts to normatively establish terminology and conventions for use (especially) in standards-track documents. While a good document of that sort is always going to be written to avoid confusion with popular terminology that is then in use, and to identify that confusion when necessary), it is intended to establish a usage model, not just describe one. This document joins 2119, 5137, and the "terminology" sections of many, many, standards-track documents in that category. > We'll let the higher-ups decide. Yes. But, IMO, this makes sense to publish as Informational iff there is a simultaneous RFC 3967 action to make it ok to reference it normatively from standards-track documents. That would seem to me to be a poor use of resources, especially given the precedents discussed above, but others may disagree. regards, john From eran@hueniverse.com Mon May 9 12:22:41 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A278E079A for ; Mon, 9 May 2011 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0s1FyFlezmn for ; Mon, 9 May 2011 12:22:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id DEDF8E0692 for ; Mon, 9 May 2011 12:22:35 -0700 (PDT) Received: (qmail 24965 invoked from network); 9 May 2011 19:22:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 19:22:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 May 2011 12:22:27 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Mon, 9 May 2011 12:22:23 -0700 Thread-Topic: HTTP MAC Authentication Scheme Thread-Index: AcwOfmxmPIi74XcpSTyynQcwm/I2bw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , "http-state@ietf.org" , OAuth WG , "'Adam Barth \(adam@adambarth.com\)'" , HTTP Working Group Subject: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 19:22:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Please discuss this draft on the Apps-Discuss mail= ing list) http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token The draft includes: * An HTTP authentication scheme using a MAC algorithm to authenticate reque= sts (via a pre-arranged MAC key). * An extension to the Set-Cookie header, providing a method for associating= a MAC key with a session cookie. * An OAuth 2.0 binding, providing a method of returning MAC credentials as = an access token. Some background: OAuth 1.0 introduced an HTTP authentication scheme using H= MAC for authenticating an HTTP request with partial cryptographic protectio= n of the HTTP request (namely, the request URI, host, and port). The OAuth = 1.0 scheme was designed for delegation-based use cases, but is widely "abus= ed" for simple client-server authentication (the poorly named 'two-legged' = use case). This functionality has been separated from OAuth 2.0 and has bee= n reintroduced as a standalone, generally applicable HTTP authentication sc= heme called MAC. Comments and feedback is greatly appreciated. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Please discuss = this draft on the Apps-Discuss <apps-discuss@ietf.org> mailing list)<= o:p>

 

ht= tp://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token

=

 

The draft in= cludes:

 

* An HTTP authentication scheme using a MAC algorithm to authenti= cate requests (via a pre-arranged MAC key).

* An extension to the Set-Cookie header, providing a method for associa= ting a MAC key with a session cookie.

* = An OAuth 2.0 binding, providing a method of returning MAC credentials as an= access token.

 

Some background: OAuth 1.0 introduced an HTTP authenticati= on scheme using HMAC for authenticating an HTTP request with partial crypto= graphic protection of the HTTP request (namely, the request URI, host, and = port). The OAuth 1.0 scheme was designed for delegation-based use cases, bu= t is widely “abused” for simple client-server authentication (t= he poorly named ‘two-legged’ use case). This functionality has = been separated from OAuth 2.0 and has been reintroduced as a standalone, ge= nerally applicable HTTP authentication scheme called MAC.

 

Comments and fe= edback is greatly appreciated.

&nbs= p;

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA8EAP3PW5EX1MB01E_-- From nico@cryptonector.com Mon May 9 13:03:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090F8E08E5; Mon, 9 May 2011 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.083 X-Spam-Level: X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNpf2rgjseBe; Mon, 9 May 2011 13:03:13 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 282DFE065A; Mon, 9 May 2011 13:03:13 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 93968598065; Mon, 9 May 2011 13:03:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=v7b9UT5KM1oDyJl5C7u44 nBGuK+J66Y5iY5Bgx8h9HGZs4rEN7X5cKeGhMy1g0+xC3rcpSTsH3CzBxXKBdCM5 S3Zb4h9TBRee7QQyQQYrWq7B7h9z0ZgnoM16mAA5m6BqYRwZqORKScN7hxTEgzCH Z8kmBOchxHfSTG9JI7C1Cg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=867L0OFw+3JjQAnttm4g NxRjmTg=; b=SF2/Zg+EvyyE8SWgKbeJ6UuImTkjODJl+3DNcMcMyluoxRtOtxL7 6imhYs+/b/BpWJyZYl09qQBVFOXoF2TmUiyxDeZSSee+Ru4SZUZwOfhbNNxFQNDu qzyXvgmDS1uo54WgAXSArQWwpt1iDbojyFwciKetEzDkMew/QH26glg= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 471C0598058; Mon, 9 May 2011 13:03:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so4209729qwc.31 for ; Mon, 09 May 2011 13:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.170 with SMTP id m10mr387072vdv.160.1304971391490; Mon, 09 May 2011 13:03:11 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Mon, 9 May 2011 13:03:11 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 15:03:11 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 20:03:14 -0000 On Mon, May 9, 2011 at 2:39 PM, Paul Hoffman wrote: > Of interest to some here. Indeed. My GSS-REST proposal uses something like this too. Regarding the question of when to include a hash of the body in the normalized request string that gets MACed... If one is using TLS, then I suggest adding the TLS channel binding into the MAC input string and drop the body hash. This will speed up operation, since there's no need to hash the body (think of the performance impact of hashing the request body in an implementation that uses sendfile()!). I don't see the point of attempting to provide only partial integrity protection (e.g., the draft doesn't say to include ever request header into the MAC input) if there's no TLS. In fact, I don't see the point of not using TLS, but if TLS avoidance is desired then all of the request (minus the MAC) and response should be covered by the MAC. The response headers also should get a MAC. Using channel binding means that the MAC input string can be much smaller -- it need only be fresh if the TLS CB type is tls-server-end-point. If the CB type is tls-unique then no nonce nor credential age elements are needed to establish freshness. And back to the tls-server-end-point case, if the freshness element is a sequence number then the MACs can be pre-computed, with a small sliding window (implemented as a small bitmap and highest number seen state elements). Finally, presumably it's the application that generates and validates the MACs, not HTTP itself. Correct? Nico -- From Jeff.Hodges@KingsMountain.com Mon May 9 13:40:38 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69EBE092F for ; Mon, 9 May 2011 13:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.544 X-Spam-Level: X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dks9v+LwolQ for ; Mon, 9 May 2011 13:40:37 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfa.amsl.com (Postfix) with SMTP id 54066E07C8 for ; Mon, 9 May 2011 13:40:37 -0700 (PDT) Received: (qmail 17013 invoked by uid 0); 9 May 2011 20:30:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 9 May 2011 20:30:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=v8cTWbusix0zW2NwL128No9qfIuCfqPRceM94DbPwro6c4fcDW6ixslSjRUZWgSwIzBN3lQIn/xjzYaRxWodPQQDTmfCvwRUTAf802t+ZkmFWxz8mS0pLtDSKzv1iTSS; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.83]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QJX6U-00030h-1W; Mon, 09 May 2011 14:30:54 -0600 Message-ID: <4DC84EFE.8030409@KingsMountain.com> Date: Mon, 09 May 2011 13:30:54 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Discussion List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: Dave CROCKER , Apps Discuss Subject: [apps-discuss] IETF-80 Technical Plenary minutes (was: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 20:40:38 -0000 Subject: [www.ietf.org/rt #37575] transcript of IETF-80 tech plenary discussion? From: "Wanda Lo via RT" Date: Mon, 09 May 2011 10:28:23 -0700 To: Jeff.Hodges@KingsMountain.com Hi Jeff, http://www.ietf.org/proceedings/80/minutes/plenaryt.txt The minutes are based on Renee's transcript. Wanda From eran@hueniverse.com Mon May 9 14:30:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E1DE0969 for ; Mon, 9 May 2011 14:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wu4cvYF7Wo7 for ; Mon, 9 May 2011 14:30:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A6228E0946 for ; Mon, 9 May 2011 14:30:00 -0700 (PDT) Received: (qmail 27835 invoked from network); 9 May 2011 20:29:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 20:29:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 May 2011 13:29:40 -0700 From: Eran Hammer-Lahav To: Nico Williams Date: Mon, 9 May 2011 13:29:36 -0700 Thread-Topic: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme Thread-Index: AcwOhEsKVvl9Wqa3Tu6lCSXcEMcV6wAAecww Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 21:30:01 -0000 Hi Nico, > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Nico Williams > Sent: Monday, May 09, 2011 1:03 PM > Regarding the question of when to include a hash of the body in the > normalized request string that gets MACed... If one is using TLS, then I > suggest adding the TLS channel binding into the MAC input string and drop > the body hash. This will speed up operation, since there's no need to ha= sh > the body (think of the performance impact of hashing the request body in = an > implementation that uses sendfile()!). It is still not clear when hashing the body is really important, and if thi= s should be just an optional feature or something that is required. If it i= s optional, it is not clear how the server should indicate to the client th= at it is required for any particular protected resource. We're still debati= ng that and waiting for some deployment experience to guide us. > I don't see the point of attempting to provide only partial integrity pro= tection > (e.g., the draft doesn't say to include ever request header into the MAC > input) if there's no TLS. In fact, I don't see the point of not using TL= S, but if > TLS avoidance is desired then all of the request (minus the MAC) and > response should be covered by the MAC. The point is to be practical given the target audience and use cases we hav= e for this: web developers. We have 3 years of experience asking web developers to perform request norm= alization and the results are pretty sad. OAuth 1.0 includes a pretty simpl= e normalization of the request URI which ended up being a huge problem for = many developers. If someone can come up with a simple way to canonicalize a= n HTTP request in a way that works with proxies and other intermediaries, a= nd is easy to implement and debug, I'm happy to reconsider. =20 > The response headers also should get a MAC. We're considering adding response verification, but not sure where to put i= t. > Using channel binding means that the MAC input string can be much smaller= - > - it need only be fresh if the TLS CB type is tls-server-end-point. If t= he CB > type is tls-unique then no nonce nor credential age elements are needed t= o > establish freshness. And back to the tls-server-end-point case, if the > freshness element is a sequence number then the MACs can be pre- > computed, with a small sliding window (implemented as a small bitmap and > highest number seen state elements). Channel binding is hard to implement the way most web frameworks are used, = as well as how browsers manage their stack. Also, lack of TLS is the main d= river behind this proposal. > Finally, presumably it's the application that generates and validates the > MACs, not HTTP itself. Correct? Not sure what you mean, but this operates just like HTTP Basic and Digest i= n terms of its relation to HTTP. EHL From presnick@qualcomm.com Mon May 9 17:10:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE33E06E2 for ; Mon, 9 May 2011 17:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQkGhiuaGJFu for ; Mon, 9 May 2011 17:10:21 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 39B59E0681 for ; Mon, 9 May 2011 17:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1304986221; x=1336522221; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DC88255.3070403@qualcomm.com>|Date:=20Mo n,=209=20May=202011=2019:09:57=20-0500|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Apps=20Discuss=20|Subject:=20On=20"supporting=20the=20publicatio n=20of=20this=20document"|Content-Type:=20text/plain=3B =20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=Xtl9T/TCoZWdC9xU5gudQqRaIhWXTHpEXaRqt3qLnE8=; b=cICup0QCepYow6AsyCP97GQeW6e8MCDTx0E0QyN9kGv3gg2ZCV1/5ueh QDs0hXDfj0GhGl5UV/jZt5HvpQ1lgPp0TH6p8+xoOpbQhuxLCSFietWle YiiBQXB2v1iKrlS1ubGctKLPz9B0LCSheZktgdllsxPR0oCaAPLNomwVw I=; X-IronPort-AV: E=McAfee;i="5400,1158,6341"; a="90426107" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 09 May 2011 17:10:19 -0700 X-IronPort-AV: E=Sophos;i="4.64,340,1301900400"; d="scan'208";a="50336097" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 May 2011 17:10:19 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 9 May 2011 17:09:59 -0700 Message-ID: <4DC88255.3070403@qualcomm.com> Date: Mon, 9 May 2011 19:09:57 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 00:10:23 -0000 [Starting with Apps Discuss; maybe I'll post this on the IETF list at some point.] Philosophical thought for the day: During last call, I occasionally see comments to the effect of, "I have read and support the publication of this document." I have to say that, as one of the people who has to judge consensus on a document, I find these statements...well...useless. Kind of like cotton candy (or "candy floss" or "fairy floss" to some of you): Sweet, but completely without substance. If you don't tell me *why* you "support publication of the document" (e.g., "I think the solution proposed is the right one", or "the solution stinks, but it's the only one we have"), then I have no way to judge consensus on the *content* of the document. If all you mean is that you have no objection to the *content* document, a much better formulation would be, "I've read this document. There's nothing in here I disagree with, and it doesn't impact any other protocol I care about." But without explanation, I have to assume that the reason you "support publication" is because you have a wager on how soon we will get to RFC 10000. :-) Objections to the *content* of a document are extremely important to hear. Support of or rebuttal to objections to the *content* of a document are very important to hear. Claims that the *content* of the document solves a problem for you are good to hear. Asserting that you have no objections to the *content* of a document is of some interest. Commentary on the *publication* itself is, really, truly, not important. OK, back to real work. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From ajs@shinkuro.com Mon May 9 17:32:14 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3574AE08B1 for ; Mon, 9 May 2011 17:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noc1KBmI60Pl for ; Mon, 9 May 2011 17:32:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0FE08AD for ; Mon, 9 May 2011 17:32:13 -0700 (PDT) Received: from shinkuro.com (spliair.spotnik.ADSL.akn.ca [66.135.98.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 83A491ECB41D for ; Mon, 9 May 2011 22:04:20 +0000 (UTC) Date: Mon, 9 May 2011 18:04:04 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110509220403.GA1224@crankycanuck.ca> References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC77648.1040903@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 00:32:14 -0000 On Mon, May 09, 2011 at 08:06:16AM +0300, Mykyta Yevstifeyev wrote: > > language > > > > A language is a way that humans interact. The use of language > > occurs in many forms, the most common of which are speech, > > writing, and signing. > I think this definition is not correct. "A way that humans > interact" is too generalized. I suppose the following definition > would suit better here. > > > language > > > > A language is a set of conventions on rules affecting humans' > > speech. The most common use of a language is speaking and > > writing. Please, no. Apart from the other remarks that Paul and John made, this imports a controversial position about how language works. It is not at all clear that language is either a set of conventions or a set of rules, unless you define "conventions" or "rules" broadly enough so that computer geeks' heads would explode. If one is too uncomfortable with "interact", I could contemplate an argument for "communicate" instead. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From chris@bentzel.net Mon May 9 18:00:04 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7FE0940 for ; Mon, 9 May 2011 18:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gixViFejA3DG for ; Mon, 9 May 2011 18:00:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 596B2E093F for ; Mon, 9 May 2011 18:00:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so714490vxg.31 for ; Mon, 09 May 2011 18:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.234 with SMTP id dn10mr2037527vdb.66.1304989202740; Mon, 09 May 2011 18:00:02 -0700 (PDT) Received: by 10.52.108.230 with HTTP; Mon, 9 May 2011 18:00:02 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 21:00:02 -0400 Message-ID: From: Chris Bentzel To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=20cf307d0174dd73c304a2e179fe Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:00:04 -0000 --20cf307d0174dd73c304a2e179fe Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 9, 2011 at 3:22 PM, Eran Hammer-Lahav wrote: > (Please discuss this draft on the Apps-Discuss > mailing list) > Should there be support for more headers in the Normalized Request String [Section 3.3.1] to minimize MITM attacks? Could this be done on all non-hop-by-hop headers? One concern is reordering of headers by middle-boxes. Should the body hash be a separate header from the Authorization header? This may allow a User-Agent to do a Chunked-Encoding POST with a trailing header containing the body hash, preventing the need to buffer all of the body in the User-Agent before sending over the wire. However, it would lead to some duplication of the parameters included in the Authorization header. --20cf307d0174dd73c304a2e179fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 9, 2011 at 3:22 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrot= e:

(Please discuss this draft on the Apps-Discuss <apps-discuss@ietf.org> mailin= g list)


Should there be support for mo= re headers in the Normalized Request String [Section 3.3.1] to minimize MIT= M attacks? Could this be done on all non-hop-by-hop headers? One concern is= reordering of headers by middle-boxes.

Should the body hash be a separate header from the Auth= orization header? This may allow a User-Agent to do a Chunked-Encoding POST= with a trailing header containing the body hash, preventing the need to bu= ffer all of the body in the User-Agent before sending over the wire. Howeve= r, it would lead to some duplication of the parameters included in the Auth= orization header.


--20cf307d0174dd73c304a2e179fe-- From eran@hueniverse.com Mon May 9 18:19:57 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7531DE0994 for ; Mon, 9 May 2011 18:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG7yIQVhq9yi for ; Mon, 9 May 2011 18:19:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id DF1A9E08BD for ; Mon, 9 May 2011 18:19:47 -0700 (PDT) Received: (qmail 20474 invoked from network); 10 May 2011 01:13:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 01:13:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 May 2011 18:12:32 -0700 From: Eran Hammer-Lahav To: Chris Bentzel , "apps-discuss@ietf.org" Date: Mon, 9 May 2011 18:12:28 -0700 Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme Thread-Index: AcwOriIrN9ztYReJTuaMWhgOFtEGGAAAFvOQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA9D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723447581DA9D7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:19:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA9D7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, There is no good way to include headers in the normalized request string. A= nything we've tried was just impractical for web adoption. Coming up with a= canonicalization logic for HTTP headers that can survive all the allowed m= anipulations, and does not require repeating the headers in some encoded bl= og (say, base64 everything that is included in the MAC and include that blo= g with the request), is just too hard and error prone. It requires hard cod= ing rules for each header given the number of exceptions in format and rule= s. As for the body hash, we're looking for a way to make it useful for form-en= coded bodies and API calls. It isn't really meant for large file uploads. W= e're trying to implement it in the browser and will make decisions based on= that experience. EHL From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Chris Bentzel Sent: Monday, May 09, 2011 6:00 PM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme On Mon, May 9, 2011 at 3:22 PM, Eran Hammer-Lahav > wrote: (Please discuss this draft on the Apps-Discuss > mailing list) Should there be support for more headers in the Normalized Request String [= Section 3.3.1] to minimize MITM attacks? Could this be done on all non-hop-= by-hop headers? One concern is reordering of headers by middle-boxes. Should the body hash be a separate header from the Authorization header? Th= is may allow a User-Agent to do a Chunked-Encoding POST with a trailing hea= der containing the body hash, preventing the need to buffer all of the body= in the User-Agent before sending over the wire. However, it would lead to = some duplication of the parameters included in the Authorization header. --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA9D7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,=

 <= /p>

There is no good way to include headers in t= he normalized request string. Anything we’ve tried was just impractic= al for web adoption. Coming up with a canonicalization logic for HTTP heade= rs that can survive all the allowed manipulations, and does not require rep= eating the headers in some encoded blog (say, base64 everything that is inc= luded in the MAC and include that blog with the request), is just too hard = and error prone. It requires hard coding rules for each header given the nu= mber of exceptions in format and rules.

 

As f= or the body hash, we’re looking for a way to make it useful for form-= encoded bodies and API calls. It isn’t really meant for large file up= loads. We’re trying to implement it in the browser and will make deci= sions based on that experience.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

EHL

 

 

 

= From:= apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On= Behalf Of Chris Bentzel
Sent: Monday, May 09, 2011 6:00 PMTo: apps-discuss@ietf.org
Subject: Re: [apps-discuss] HT= TP MAC Authentication Scheme

 

On Mon, May 9, 2011 at 3:= 22 PM, Eran Hammer-Lahav <eran@hu= eniverse.com> wrote:

(Please discuss this draft on the = Apps-Discuss <apps-discuss@ietf.org> mailing list)

 

Should there be support for more headers in the Normalized Req= uest String [Section 3.3.1] to minimize MITM attacks? Could this be done on= all non-hop-by-hop headers? One concern is reordering of headers by middle= -boxes.

 

=

Should the body hash be a separate header f= rom the Authorization header? This may allow a User-Agent to do a Chunked-E= ncoding POST with a trailing header containing the body hash, preventing th= e need to buffer all of the body in the User-Agent before sending over the = wire. However, it would lead to some duplication of the parameters included= in the Authorization header.

 

 

=
= --_000_90C41DD21FB7C64BB94121FBBC2E723447581DA9D7P3PW5EX1MB01E_-- From chris@bentzel.net Mon May 9 18:23:01 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA902E09A6 for ; Mon, 9 May 2011 18:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNIckrdCTrN9 for ; Mon, 9 May 2011 18:22:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3256E099D for ; Mon, 9 May 2011 18:22:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so735852vxg.31 for ; Mon, 09 May 2011 18:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.234 with SMTP id dn10mr2056055vdb.66.1304990576740; Mon, 09 May 2011 18:22:56 -0700 (PDT) Received: by 10.52.108.230 with HTTP; Mon, 9 May 2011 18:22:56 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA9D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA9D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 May 2011 21:22:56 -0400 Message-ID: From: Chris Bentzel To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=20cf307d0174c30a9a04a2e1cb86 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:23:01 -0000 --20cf307d0174c30a9a04a2e1cb86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, May 9, 2011 at 9:12 PM, Eran Hammer-Lahav wrot= e: > > As for the body hash, we=92re looking for a way to make it useful for > form-encoded bodies and API calls. It isn=92t really meant for large file > uploads. We=92re trying to implement it in the browser and will make deci= sions > based on that experience. > This may be reasonable. auth-int on Digest is not supported by many browser= s due to the buffering concerns. The MAC spec seems to allow the client to choose whether it wants body integrity on a per-request basis, so some heuristic based on body size might be reasonable given your use case. --20cf307d0174c30a9a04a2e1cb86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, May 9, 2011 at 9:12 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:


As for the body ha= sh, we=92re looking for a way to make it useful for form-encoded bodies and= API calls. It isn=92t really meant for large file uploads. We=92re trying = to implement it in the browser and will make decisions based on that experi= ence.


This may be reasonable. auth-i= nt on Digest is not supported by many browsers due to the buffering concern= s. The MAC spec seems to allow the client to choose whether it wants body i= ntegrity on a per-request basis, so some heuristic based on body size might= be reasonable given your use case.

--20cf307d0174c30a9a04a2e1cb86-- From nico@cryptonector.com Mon May 9 23:45:32 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D570E06C7; Mon, 9 May 2011 23:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv82-PiG1ARA; Mon, 9 May 2011 23:45:31 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E15BFE067E; Mon, 9 May 2011 23:45:31 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 7064642806E; Mon, 9 May 2011 23:45:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=KblccKOWG9KOEOpu/sJpFTp8sdq8xV/MLunfQPZ3XFp5 ifSD+m2NIcIJR4TWZhyzVvsZwy5hB/O5BmXXaJ0qqoeQarIiZBLc1g9O9ypGBgJI 5QPe/aVa5jnksqMUxLhBoudg91DPD7v1fjt0jTbkRIGzhtx0I3ip319ajE+/PgU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=pFQ1Qs9KLnhRa4o9oIZAoia7MAA=; b=LvPijMPsnMR /atmKIVQP5/S3PCOmEHi+Kra5tGIyxW7Jgemk+UkGtF4I4zYqMn20t0PH3b2tID2 +di4an4EpZjgk5ir5i5loETRQJ7AlvW9nz0KOAKvS+9HDfIK9yxEGNjZcCTPbkaH ure2qtsIyI883dx5FLTQhE/07Ih+8Mcs= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 37CAC428014; Mon, 9 May 2011 23:45:31 -0700 (PDT) Received: by vws12 with SMTP id 12so370804vws.31 for ; Mon, 09 May 2011 23:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.178.33 with SMTP id cv1mr771174vdc.277.1305009930450; Mon, 09 May 2011 23:45:30 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Mon, 9 May 2011 23:45:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 10 May 2011 01:45:30 -0500 Message-ID: From: Nico Williams To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org, Apps Discuss Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 06:45:32 -0000 On Mon, May 9, 2011 at 3:29 PM, Eran Hammer-Lahav wro= te: >> Regarding the question of when to include a hash of the body in the >> normalized request string that gets MACed... If one is using TLS, then I >> suggest adding the TLS channel binding into the MAC input string and dro= p >> the body hash. =C2=A0This will speed up operation, since there's no need= to hash >> the body (think of the performance impact of hashing the request body in= an >> implementation that uses sendfile()!). > > It is still not clear when hashing the body is really important, and if t= his should be just an optional feature or something that is required. If it= is optional, it is not clear how the server should indicate to the client = that it is required for any particular protected resource. We're still deba= ting that and waiting for some deployment experience to guide us. See below. >> I don't see the point of attempting to provide only partial integrity pr= otection >> (e.g., the draft doesn't say to include ever request header into the MAC >> input) if there's no TLS. =C2=A0In fact, I don't see the point of not us= ing TLS, but if >> TLS avoidance is desired then all of the request (minus the MAC) and >> response should be covered by the MAC. > > The point is to be practical given the target audience and use cases we h= ave for this: web developers. Surely not. Surely the point is to make some attack more difficult. Yes, surely it's nice to make it easy for developers to use it, but that's a secondary issue. The primary issue, what I'm not getting from the I-D, is what you're trying to protect against. "What is your threat model?" Nico -- From sm@resistor.net Tue May 10 00:00:08 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79803E0792 for ; Tue, 10 May 2011 00:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLt+AAAnFmIH for ; Tue, 10 May 2011 00:00:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84944E065A for ; Tue, 10 May 2011 00:00:03 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4A6xqt0026024; Mon, 9 May 2011 23:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1305010798; bh=xsI7sQ21QDPFoIPAFWdqWGTZDKBvwY3WyeOljSGysUY=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=DokwS4aVnIu7csThIRjlRimcGmBckX5XKJqEtmR2CnfGGOoTEh0jc6ZwoxypNKzvO JD/1wFuTMEF/YTLyjRkxIJCl35hXbhFtTcasRbqG7vJwNO71ixtShb5dg9tv0dco/B d+YMhq2RYmJPKWfZ8OfuPVjGZfApHhwE3N+9Fv8c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1305010798; bh=xsI7sQ21QDPFoIPAFWdqWGTZDKBvwY3WyeOljSGysUY=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=zCAxwsi5ZQsDJIKtMUMuIr27BaP0pIGCgeUmC6Bn36NJeyLBhnLqKYUIkz3SjoEMl lRxRaAnvT+5Od22MHy5Mv3tWhRE2gCM5KZ7gZ035zvmxh3l5VN6cXOaLiZAZiOuYlN mc/4Zq2OVcQRXFh+KPAL6USYMusM52Y/CHXORHCY= Message-Id: <6.2.5.6.2.20110509234249.03822348@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 May 2011 23:58:09 -0700 To: Pete Resnick From: SM In-Reply-To: <4DC88255.3070403@qualcomm.com> References: <4DC88255.3070403@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 07:00:08 -0000 Hi Pete, At 17:09 09-05-2011, Pete Resnick wrote: >Philosophical thought for the day: > >During last call, I occasionally see comments to the effect of, "I >have read and support the publication of this document." I have to >say that, as one of the people who has to >judge consensus on a document, I find these >statements...well...useless. Kind of like Can I +1 instead? :-) >cotton candy (or "candy floss" or "fairy floss" to some of you): >Sweet, but completely without substance. If you don't tell me *why* >you "support publication of the document" (e.g., "I think the >solution proposed is the right one", or "the solution stinks, but >it's the only one we have"), then I have no way to judge consensus >on the *content* of the document. If all you mean is that you have >no objection to the *content* document, a much better formulation >would be, "I've read this document. There's nothing in here I >disagree with, and it doesn't impact any other protocol I care >about." But without explanation, I have to assume that the reason >you "support publication" is because you have a wager on how soon we >will get to RFC 10000. :-) Telling you why I support publication of a document requires: (i) Thinking (ii) Reading the previous comments to avoid restating the same points BTW, your note touches any interesting topic, i.e. how to judge consensus. >Objections to the *content* of a document are extremely important to hear. >Support of or rebuttal to objections to the *content* of a document >are very important to hear. >Claims that the *content* of the document solves a problem for you >are good to hear. >Asserting that you have no objections to the *content* of a document >is of some interest. Explain what problem the document solves for you. Avoid ambivalent statements as far as possible as they will be misunderstood in 99.7% percent of cases. >Commentary on the *publication* itself is, really, truly, not important. I don't understand the above sentence. Regards, -sm From eran@hueniverse.com Tue May 10 00:06:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70171E06A4 for ; Tue, 10 May 2011 00:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SH+Eq-vdVlW for ; Tue, 10 May 2011 00:06:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D6FD4E0840 for ; Tue, 10 May 2011 00:06:32 -0700 (PDT) Received: (qmail 3056 invoked from network); 10 May 2011 07:06:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2011 07:06:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 10 May 2011 00:06:27 -0700 From: Eran Hammer-Lahav To: Nico Williams Date: Tue, 10 May 2011 00:06:22 -0700 Thread-Topic: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme Thread-Index: AcwO3dwSAJ0GFgZeSi2aLK8HDXFhZgAAkNug Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "saag@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 07:06:33 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmljbyBXaWxsaWFtcyBb bWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXkgMDksIDIw MTEgMTE6NDYgUE0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBBcHBzIERpc2N1c3M7 IHNhYWdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFtzYWFnXSBGd2Q6 IEhUVFAgTUFDIEF1dGhlbnRpY2F0aW9uIFNjaGVtZQ0KPiANCj4gT24gTW9uLCBNYXkgOSwgMjAx MSBhdCAzOjI5IFBNLCBFcmFuIEhhbW1lci1MYWhhdg0KPiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4g d3JvdGU6DQo+ID4+IFJlZ2FyZGluZyB0aGUgcXVlc3Rpb24gb2Ygd2hlbiB0byBpbmNsdWRlIGEg aGFzaCBvZiB0aGUgYm9keSBpbiB0aGUNCj4gPj4gbm9ybWFsaXplZCByZXF1ZXN0IHN0cmluZyB0 aGF0IGdldHMgTUFDZWQuLi4gSWYgb25lIGlzIHVzaW5nIFRMUywNCj4gPj4gdGhlbiBJIHN1Z2dl c3QgYWRkaW5nIHRoZSBUTFMgY2hhbm5lbCBiaW5kaW5nIGludG8gdGhlIE1BQyBpbnB1dA0KPiA+ PiBzdHJpbmcgYW5kIGRyb3AgdGhlIGJvZHkgaGFzaC4gwqBUaGlzIHdpbGwgc3BlZWQgdXAgb3Bl cmF0aW9uLCBzaW5jZQ0KPiA+PiB0aGVyZSdzIG5vIG5lZWQgdG8gaGFzaCB0aGUgYm9keSAodGhp bmsgb2YgdGhlIHBlcmZvcm1hbmNlIGltcGFjdCBvZg0KPiA+PiBoYXNoaW5nIHRoZSByZXF1ZXN0 IGJvZHkgaW4gYW4gaW1wbGVtZW50YXRpb24gdGhhdCB1c2VzIHNlbmRmaWxlKCkhKS4NCj4gPg0K PiA+IEl0IGlzIHN0aWxsIG5vdCBjbGVhciB3aGVuIGhhc2hpbmcgdGhlIGJvZHkgaXMgcmVhbGx5 IGltcG9ydGFudCwgYW5kIGlmIHRoaXMNCj4gc2hvdWxkIGJlIGp1c3QgYW4gb3B0aW9uYWwgZmVh dHVyZSBvciBzb21ldGhpbmcgdGhhdCBpcyByZXF1aXJlZC4gSWYgaXQgaXMNCj4gb3B0aW9uYWws IGl0IGlzIG5vdCBjbGVhciBob3cgdGhlIHNlcnZlciBzaG91bGQgaW5kaWNhdGUgdG8gdGhlIGNs aWVudCB0aGF0IGl0IGlzDQo+IHJlcXVpcmVkIGZvciBhbnkgcGFydGljdWxhciBwcm90ZWN0ZWQg cmVzb3VyY2UuIFdlJ3JlIHN0aWxsIGRlYmF0aW5nIHRoYXQgYW5kDQo+IHdhaXRpbmcgZm9yIHNv bWUgZGVwbG95bWVudCBleHBlcmllbmNlIHRvIGd1aWRlIHVzLg0KPiANCj4gU2VlIGJlbG93Lg0K PiANCj4gPj4gSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIGF0dGVtcHRpbmcgdG8gcHJvdmlkZSBv bmx5IHBhcnRpYWwgaW50ZWdyaXR5DQo+ID4+IHByb3RlY3Rpb24gKGUuZy4sIHRoZSBkcmFmdCBk b2Vzbid0IHNheSB0byBpbmNsdWRlIGV2ZXIgcmVxdWVzdA0KPiA+PiBoZWFkZXIgaW50byB0aGUg TUFDDQo+ID4+IGlucHV0KSBpZiB0aGVyZSdzIG5vIFRMUy4gwqBJbiBmYWN0LCBJIGRvbid0IHNl ZSB0aGUgcG9pbnQgb2Ygbm90DQo+ID4+IHVzaW5nIFRMUywgYnV0IGlmIFRMUyBhdm9pZGFuY2Ug aXMgZGVzaXJlZCB0aGVuIGFsbCBvZiB0aGUgcmVxdWVzdA0KPiA+PiAobWludXMgdGhlIE1BQykg YW5kIHJlc3BvbnNlIHNob3VsZCBiZSBjb3ZlcmVkIGJ5IHRoZSBNQUMuDQo+ID4NCj4gPiBUaGUg cG9pbnQgaXMgdG8gYmUgcHJhY3RpY2FsIGdpdmVuIHRoZSB0YXJnZXQgYXVkaWVuY2UgYW5kIHVz ZSBjYXNlcyB3ZSBoYXZlDQo+IGZvciB0aGlzOiB3ZWIgZGV2ZWxvcGVycy4NCj4gDQo+IFN1cmVs eSBub3QuICBTdXJlbHkgdGhlIHBvaW50IGlzIHRvIG1ha2Ugc29tZSBhdHRhY2sgbW9yZSBkaWZm aWN1bHQuDQo+IFllcywgc3VyZWx5IGl0J3MgbmljZSB0byBtYWtlIGl0IGVhc3kgZm9yIGRldmVs b3BlcnMgdG8gdXNlIGl0LCBidXQgdGhhdCdzIGENCj4gc2Vjb25kYXJ5IGlzc3VlLiAgVGhlIHBy aW1hcnkgaXNzdWUsIHdoYXQgSSdtIG5vdCBnZXR0aW5nIGZyb20gdGhlIEktRCwgaXMNCj4gd2hh dCB5b3UncmUgdHJ5aW5nIHRvIHByb3RlY3QgYWdhaW5zdC4NCj4gDQo+ICJXaGF0IGlzIHlvdXIg dGhyZWF0IG1vZGVsPyINCg0KQW4gZWF2ZXNkcm9wcGVyIGdyYWJiaW5nIHBsYWludGV4dCBjcmVk ZW50aWFscyBhbmQgdXNpbmcgdGhlbSB0byBnYWluIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3Vy Y2VzLiBUaGF0J3MgOTklIG9mIGl0LCB3aXRoIHRoZSBvdGhlciAxJSBiZWluZyB0aGF0IHNlbmRp bmcgcGxhaW50ZXh0IGNyZWRlbnRpYWxzIG92ZXIgVExTIGNhbiBzdGlsbCBsZWFrIGR1ZSB0byBp bmNvcnJlY3QgaW1wbGVtZW50YXRpb24sIG9yIGF0dGFja3Mgb24gZHluYW1pYyBjb25maWd1cmF0 aW9uLCBsZWFkaW5nIHRoZSBjbGllbnQgdG8gc2VuZCBpdHMgcGxhaW50ZXh0IGNyZWRlbnRpYWxz IG92ZXIgVExTIHRvIHRoZSB3cm9uZyBzZXJ2ZXIuDQoNCkVITA0KDQoNCg0K From nico@cryptonector.com Tue May 10 00:28:31 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6BE06D3; Tue, 10 May 2011 00:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBLvTXe-VBGV; Tue, 10 May 2011 00:28:30 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 19740E06A1; Tue, 10 May 2011 00:28:30 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by hapkido.dreamhost.com (Postfix) with ESMTP id 7512E178990; Tue, 10 May 2011 00:28:29 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 064F5B8058; Tue, 10 May 2011 00:28:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mk92Z5DDkEJUF9xkCvze64aL7T8wf8h+YUUx4RAouVgy y4ESqIeR2EaPmWBtEppc/3kY+eSnUme7d2Nuo41t0wyHk1XvevVcWBUZISitPDaf C1JADsoCLJBcdOJrobDcIOTdVW+ApYoWlWVUyKKXNMjphc5/Og5SQqVfHelwRhY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=OoMbxSARWjURs+gW+89BLptMRlk=; b=T+fUhi8BOOU sbQDLdwJNt2jL+5Wx1K6Svfzk1TTtS/Ysd+HNb4biEeKObzAgz5nPVZIzlMgpWLK mt3kPMBXYOQ0itdrU9pArVN1Hl+XgjbiSgRxuUrMB0B/a9xOF65rG9xpKX0CPXzf iLE0v0U/Xvow09DY3/zLMZCyqNes3gYc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id BB7B6B8057; Tue, 10 May 2011 00:28:28 -0700 (PDT) Received: by vws12 with SMTP id 12so391320vws.31 for ; Tue, 10 May 2011 00:28:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.199 with SMTP id cc7mr571378vdc.197.1305012508190; Tue, 10 May 2011 00:28:28 -0700 (PDT) Received: by 10.52.155.4 with HTTP; Tue, 10 May 2011 00:28:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723447581DA9EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 10 May 2011 02:28:28 -0500 Message-ID: From: Nico Williams To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "saag@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 07:28:31 -0000 On Tue, May 10, 2011 at 2:06 AM, Eran Hammer-Lahav wr= ote: >> "What is your threat model?" > > An eavesdropper grabbing plaintext credentials and using them to gain acc= ess to protected resources. That's 99% of it, with the other 1% being that = sending plaintext credentials over TLS can still leak due to incorrect impl= ementation, or attacks on dynamic configuration, leading the client to send= its plaintext credentials over TLS to the wrong server. That's what I thought. If you add channel binding (meaning, to make it real simple: add the server's certificate, or hash thereof, to the MAC inputs -- the server cert is available in at least some JavaScript implementations, like Firefox's) then you'll avoid those attacks that you mention when using TLS. It's not clear to me if you want to allow use of this MAC without using TLS. From the above I guess so, since the MAC alone will take care of the eavesdroppers. Nico -- From dave@cridland.net Tue May 10 02:34:30 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3373E086C for ; Tue, 10 May 2011 02:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, FROM_BLANK_NAME=0.76, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVeErv66YxLQ for ; Tue, 10 May 2011 02:34:11 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 00EBFE06DC for ; Tue, 10 May 2011 02:34:10 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B7D6D1168093; Tue, 10 May 2011 10:34:06 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWwV5nMhYl+X; Tue, 10 May 2011 10:34:05 +0100 (BST) Received: from [192.168.1.125] (unknown [62.3.217.253]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 8C40B116808D; Tue, 10 May 2011 10:34:03 +0100 (BST) Date: Tue, 10 May 2011 10:32:44 +0100 From: "" To: presnick@qualcomm.com MIME-Version: 1.0 X-Mailer: LCG ProfiMail Message-ID: <5344842612.989490764@cridland.net> References: <4DC88255.3070403@qualcomm.com> Content-Type: text/plain; charset=utf-8; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] =?utf-8?q?On_=22supporting_the_publication_of_this?= =?utf-8?q?_document=22?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 09:34:31 -0000 ------- Original message ------- > From: Pete Resnick > To: apps-discuss@ietf.org > Sent: 10.5.'11, 1:09 > > [Starting with Apps Discuss; maybe I'll post this on the IETF list at > some point.] > > Philosophical thought for the day: > > During last call, I occasionally see comments to the effect of, "I have > read and support the publication of this document." I have read and support the sending of this email message. From john@jlc.net Tue May 10 04:31:20 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4FE067A for ; Tue, 10 May 2011 04:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h08K5wMcxPkB for ; Tue, 10 May 2011 04:31:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 71B55E0670 for ; Tue, 10 May 2011 04:31:19 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 64CED33C23; Tue, 10 May 2011 07:31:18 -0400 (EDT) Date: Tue, 10 May 2011 07:31:18 -0400 From: John Leslie To: dave@cridland.net Message-ID: <20110510113118.GM49185@verdi> References: <4DC88255.3070403@qualcomm.com> <5344842612.989490764@cridland.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5344842612.989490764@cridland.net> User-Agent: Mutt/1.4.1i Cc: presnick@qualcomm.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 11:31:20 -0000 dave@cridland.net wrote: > From: Pete Resnick > >> Philosophical thought for the day: >> >> During last call, I occasionally see comments to the effect of, "I have >> read and support the publication of this document." > > I have read and support the sending of this email message. Exactly! ;^) (I always thought the purpose of such LastCall comments was to keep folks like me from pointing out too many flaws in the spec... ;^) -- John Leslie From scott.brim@gmail.com Tue May 10 06:33:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA089E06CD for ; Tue, 10 May 2011 06:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcvLJgmuPzdg for ; Tue, 10 May 2011 06:33:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06D9DE067C for ; Tue, 10 May 2011 06:33:22 -0700 (PDT) Received: by iwn39 with SMTP id 39so6699521iwn.31 for ; Tue, 10 May 2011 06:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s5Cs3Mrd+RX9zKb9Sxg1rgrnJnMn7O9zVOcyy7tM1Lg=; b=R48xuMpjCXc7mkLvIz8nv37ECWttW7XgJDE+ZSB16N1E2CtmusmPdOoFW6Rwwwcc5J nrUQ5Lba21N6f5rb7vqG4M0+Z8hToVH2SxV9OrVmcRVDW8oWEaSLz5hvXVnZtDYEj39o DhtuW3iBgvrZVVk9cuIAqlnI975GpATaZzYYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=euNnoQFgmIUetWHKx2ucucRZW/NYGkOEji9xAfYug63bOR7vYt5ySxI4s1NGLsfyiZ 2Y4Lxg38h7KpsZcK+QFM1tfMKJ1yd7QGwrfiWbxEFwxYt3uOUB4aiTpQEg+9sHBczTLn rslfpnvDhxqu5noCsMhJb4xOcgX7+Z8ZHALL8= Received: by 10.42.247.198 with SMTP id md6mr7740046icb.518.1305034402601; Tue, 10 May 2011 06:33:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.205 with HTTP; Tue, 10 May 2011 06:33:02 -0700 (PDT) In-Reply-To: <4DC88255.3070403@qualcomm.com> References: <4DC88255.3070403@qualcomm.com> From: Scott Brim Date: Tue, 10 May 2011 09:33:02 -0400 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 13:33:24 -0000 On Mon, May 9, 2011 at 20:09, Pete Resnick wrote: > During last call, I occasionally see comments to the effect of, "I have read > and support the publication of this document." I have to say that, as one of > the people who has to judge consensus on a document, I find these > statements...well...useless. +1 :-) I find allowing responses like that to count to be vulnerable to flash crowd invasions, political or competitive manipulation, etc. I prefer at least one original, substantive sentence about why. From evnikita2@gmail.com Tue May 10 07:19:33 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159D2E06DF for ; Tue, 10 May 2011 07:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_00=-2.599, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxtcyrhe4Flz for ; Tue, 10 May 2011 07:19:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6925E0593 for ; Tue, 10 May 2011 07:19:31 -0700 (PDT) Received: by bwz13 with SMTP id 13so5790369bwz.31 for ; Tue, 10 May 2011 07:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vGiuTE/jGmBSI53UMGLtPmRFFGv3iJIfkRjawd6U4Rw=; b=foHZbVP9gkYsw+BfndH9JC3SUAmqLeIdq8gbn5XfaKc3PzSN7RxnicLqb3RdZc8/So vXt7pbx2e+0nqbrWR0hqld3I/w6i2jbRPSL3Iw2r2S65tqn77F1P+GIiq3OutgeeR9mt cm0//y4+JqmoSvvAQx1kzcKVdXKBSIIvZOIa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Vdr+DW3MY4ccO9cbD+M4pYLNePDhochSkxE9tQHimUM9qg6puIH69wBPP3D6mf4LOL 0LadHgK6DRZuFcb5zI5EYgsrCp44ndAwIr/u0RIxmAPgm1lixXJIFjzDMzTFAqn9tvcb WBGU0PUAcus9UBFyTv3h50DuFmnhJds8r9gto= Received: by 10.205.82.197 with SMTP id ad5mr3439729bkc.80.1305037170435; Tue, 10 May 2011 07:19:30 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id u15sm4348035bkf.16.2011.05.10.07.19.28 (version=SSLv3 cipher=OTHER); Tue, 10 May 2011 07:19:29 -0700 (PDT) Message-ID: <4DC9499C.1060409@gmail.com> Date: Tue, 10 May 2011 17:20:12 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Hoffman References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> In-Reply-To: <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 14:19:33 -0000 09.05.2011 18:23, Paul Hoffman wrote: > On May 8, 2011, at 10:06 PM, Mykyta Yevstifeyev wrote: > >> This sounds a bit confusing, since the previous sentence says "outside the IETF" and the next one mentions IETF RFCs. > Fixed. Ok. >> From Section 2, "language" definition: >> >>> language >>> >>> A language is a way that humans interact. The use of language >>> occurs in many forms, the most common of which are speech, >>> writing, and signing. >>> >> I think this definition is not correct. "A way that humans interact" is too generalized. I suppose the following definition would suit better here. >> >>> language >>> >>> A language is a set of conventions on rules affecting humans' >>> speech. The most common use of a language is speaking and >>> writing. >>> >>> [ as in current draft ] > Your definition is too limiting. Clearly, we are not only talking about speech. Agreed; but the current isn't appropriate as well. Considering a language being the humans interaction way is correct in its concept, but I think we should think about more exact definition. >> Also "character" definition. It would be useful to mention that "character" is often abbreviated to "char" > Noted. Thanks for this as well. >> From Section 4.1: >> >>> punctuation >>> >>> Characters that separate units of text, [ . . . ] they are also used in >>> mathematical and scientific formulae, for example. >>> >>> symbol >>> >>> One of a set of characters [ . . . ] >>> >>> Examples of symbols include characters for mathematical operators, >>> [ . . . ] >>> >> I see these two definitions give a bit contiguous specification of where chars used in formula. You should either clarify the use of punctuation marks in formula or consider such chars belonging to one of such category. > A particular character can be considered both punctuation and a symbol. OK; please clarify this in these definitions. >> Also from Section 4.1: >> >>> control character >>> >> I think we can clarify a bit this definition by mentioning: "The semantics of control characters depend on the application they are used with. The most common control characters semantics are specified in ISO/IEC 6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, like this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control functions for coded character sets",1992." > This seems like overkill. We don't define the semantics of any other code points; why do it for control characters? I proposed to add at least some phrase on the role of control characters. ISO/IEC 6429 suits for this purpose fine, I think. >> Proposal for inclusion of definition in Section 8. I think we could also define "noncharacter" here (and appropriate entry in the Index). My proposed definition: >> >>> noncharacter >>> >>> A noncharacter is a code point that is permanently reserved >>> in some particular coded character set and is generally >>> forbidden to be used in open data interchange. > "noncharacter" is not a term commonly used in internationalization, I believe. However Unicode is quite contiguous with the i18n topic; speaking about it we mostly speak about Unicode, this term is related to. >> Some comments on References: >> >>> [UNICODE >>> ] The Unicode Consortium, "The Unicode Standard, Version >>> 5.2.0", Mountain View, CA: The Unicode Consortium, >>> >> This version - 5.2.0 - is obsolete. It is superseded by 6.0.0; the reference should be: "The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6)" > Noted. > Thanks for this. >>> [ISO3166 >>> ] ISO, "ISO 3166-1:2006 - Codes for the representation of >>> names of countries and their subdivisions -- Part 1: >>> Country codes", 20066. >>> >> I don't think they've invented time machine to write this in 20066 :-) Obviously, this is a typo: s/20066/2006 > Good catch. The same. >> I also think the reference to [CHARMOD] is a bit incorrect as well. I propose: >> >>> Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and T. Texin, Ed., "Character Model for the World Wide Web 1.0", W3C Recommendation, February 2005. > Disagree. Listing a bunch of folks does not help the reference at all. You could then mention "Duerst, M., et al, ...". See, we're not mentioning IETF as an author of RFCs; the same is with W3C. >> To finish, why the intended status for this draft is BCP? Longstanding IETF practice is to publish glossaries as Informational docs (previously, FYIs); examples arehttp://tools.ietf.org/html/rfc1208,http://tools.ietf.org/html/rfc1983,http://tools.ietf.org/html/rfc4949 and the predecessor of this draft itself -http://tools.ietf.org/html/rfc3536. I think Informational would suit better here. > As you are well aware, there is differing opinion on this. We'll let the higher-ups decide. So let's leave this for IESG to decide. Mykyta Yevstifeyev > --Paul Hoffman > > From dhc@dcrocker.net Tue May 10 08:44:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB12E0766 for ; Tue, 10 May 2011 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU5vRoa6VHtV for ; Tue, 10 May 2011 08:44:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7022FE06CC for ; Tue, 10 May 2011 08:43:49 -0700 (PDT) Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4AEjC0F014400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 07:45:18 -0700 Message-ID: <4DC94F74.30905@dcrocker.net> Date: Tue, 10 May 2011 07:45:08 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pete Resnick References: <4DC88255.3070403@qualcomm.com> In-Reply-To: <4DC88255.3070403@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 May 2011 07:45:18 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 15:44:24 -0000 On 5/9/2011 5:09 PM, Pete Resnick wrote: > [Starting with Apps Discuss; maybe I'll post this on the IETF list at some point.] > > Philosophical thought for the day: > > During last call, I occasionally see comments to the effect of, "I have read and > support the publication of this document." I have to say that, as one of the > people who has to judge consensus on a document, I find these > statements...well...useless. For the last twenty years, I've understood that one of the IESG essential questions for a Last Call is whether anyone cares about the document being considered for publication. It well could be of interest to a few die-hard protocol specifiers, but no one else in the industry, and it used to be that broad support was a criterion. During my own time as an AD, long ago, this question was explicit within the IESG and simple statements of support were helpful for answering it. Is this no longer a concern? Your note suggests that, at the least, the text of a Last Call should make much more clear what sorts of comments are being sought (and why and probably from whom.) The community should not have to guess what sorts of responses are useful for the IESG. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qualcomm.com Tue May 10 09:33:53 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D72E0828 for ; Tue, 10 May 2011 09:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8aofupv4FIV for ; Tue, 10 May 2011 09:33:52 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3A3E084B for ; Tue, 10 May 2011 09:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305045230; x=1336581230; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DC9688B.3070701@qualcomm.com>|Date:=20Tu e,=2010=20May=202011=2011:32:11=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20|Subject:=20Re:=20[apps-discuss]=20On=20"supporting=20th e=20publication=20of=20this=20document"|References:=20<4D C88255.3070403@qualcomm.com>=20<4DC94F74.30905@dcrocker.n et>|In-Reply-To:=20<4DC94F74.30905@dcrocker.net> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=O5h69bArDuHVcNyg7JgiPSL5Li9NNH0A0rekRwB/t1Q=; b=QR/1Jiy5V6s5Mg6j1eYClUJ9PoAbCtaekJYmsKr2J/dLK4Huu7wMzA9B VGjXlrM0M5X82LAmOl8YZC67Tmm5j1BgqKgRfFpYOwqSXlwCNSHrIbS9+ jrxy09TdcFvKgvNEXk/q+gzScfJ41FWKq8CohjtaZucOFDhYHf+QMoxBy Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6341"; a="90373214" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 10 May 2011 09:32:42 -0700 X-IronPort-AV: E=Sophos;i="4.64,346,1301900400"; d="scan'208";a="50712474" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 May 2011 09:32:41 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 09:32:13 -0700 Message-ID: <4DC9688B.3070701@qualcomm.com> Date: Tue, 10 May 2011 11:32:11 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> In-Reply-To: <4DC94F74.30905@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 16:33:54 -0000 On 5/10/11 9:45 AM, Dave CROCKER wrote: > On 5/9/2011 5:09 PM, Pete Resnick wrote: >> [Starting with Apps Discuss; maybe I'll post this on the IETF list at >> some point.] >> >> Philosophical thought for the day: >> >> During last call, I occasionally see comments to the effect of, "I >> have read and >> support the publication of this document." I have to say that, as one >> of the >> people who has to judge consensus on a document, I find these >> statements...well...useless. > > For the last twenty years, I've understood that one of the IESG > essential questions for a Last Call is whether anyone cares about the > document being considered for publication. It well could be of > interest to a few die-hard protocol specifiers, but no one else in the > industry, and it used to be that broad support was a criterion. > > During my own time as an AD, long ago, this question was explicit > within the IESG and simple statements of support were helpful for > answering it. > > Is this no longer a concern? It is a concern, but see Scott and SM's notes: Saying "I have read and support the publication of this document" is indistinguishable from, "My co-worker/friend/third-cousin-twice-removed told me I should send in a message supporting this document, so I did." All I'm saying is that additional text indicating *why* you support this document is the important part. Your statement of support is, in and of itself, relatively uninteresting. > Your note suggests that, at the least, the text of a Last Call should > make much more clear what sorts of comments are being sought (and why > and probably from whom.) Nope. I'm interested in any and all substantive comments. The problem with "I support the document" is that I can't tell whether it's substantive without me asking more questions and the sender doing a bit more writing. Sometimes I have enough context (long-time contributor to the group says so), but if I've got that context, then I probably know *why* they are saying that. (Generally, long-time contributors say, "I think the document is ready" rather than "I support its publication".) But its probably better to not assume that the reader has the context and explain your support. > The community should not have to guess what sorts of responses are > useful for the IESG. I am not clear on what guessing you think is involved. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From ted.ietf@gmail.com Tue May 10 11:13:46 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631A1E083E for ; Tue, 10 May 2011 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4bMvi0QGPWh for ; Tue, 10 May 2011 11:13:45 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD467E067C for ; Tue, 10 May 2011 11:13:45 -0700 (PDT) Received: by pwi5 with SMTP id 5so3966954pwi.31 for ; Tue, 10 May 2011 11:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wkAP/wds7TXQdYi7yjROTRxL60eo0A49eNl3HuGb6Ks=; b=hyF/9r4J3rpwwAc7WxZwAb28fWzMmcjkmb5dTHjZ5mNPfN6HzwHYaw0Suo7bs7OSzf pSdNDoQ0Ah1jE0eniuDkhLbrbfbv7Li46gAxG3DkhT6KCtmMFJ6rM8Ra1NauOT7RcWP3 81TGQ4JZZ5J0cjLyO+ehtzONoKKFlIT30/Qkg= 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=GPsoeNKQD7toBf/3vNsq0sNUByeuEbq1wYcBupGZbotyGwHmHtIGTNML0THx1XulSu 0T/RB0xBpV0n3ZuhXF82PvnylF/R//1wNGbiq0JW3ZjFzY7r02tqU8tGgVdk2EX8P6J8 wv4vYJBhF8pnBfjasovZu1s1Esi/QSbvhonzQ= MIME-Version: 1.0 Received: by 10.68.55.10 with SMTP id n10mr11084493pbp.476.1305051225013; Tue, 10 May 2011 11:13:45 -0700 (PDT) Received: by 10.68.51.198 with HTTP; Tue, 10 May 2011 11:13:44 -0700 (PDT) In-Reply-To: <4DC9688B.3070701@qualcomm.com> References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com> Date: Tue, 10 May 2011 11:13:44 -0700 Message-ID: From: Ted Hardie To: Pete Resnick Content-Type: multipart/alternative; boundary=bcaec53aec2eae3f7604a2efea15 Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 18:13:46 -0000 --bcaec53aec2eae3f7604a2efea15 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 10, 2011 at 9:32 AM, Pete Resnick wrote: > > It is a concern, but see Scott and SM's notes: Saying "I have read and > support the publication of this document" is indistinguishable from, "My > co-worker/friend/third-cousin-twice-removed told me I should send in a > message supporting this document, so I did." All I'm saying is that > additional text indicating *why* you support this document is the important > part. Your statement of support is, in and of itself, relatively > uninteresting. > > > To put this slightly differently, a statement of support where the AD has no context is hard to evaluate. For some people, the AD's knowledge of the individual is the context. If Steve Bellovin says he has read and supports a security document, the AD's knowledge of Steve's history in that space is probably context enough. IF you know the individual, in other words, you know whether they are really speaking for themselves or the cousin-twice-removed. But this has some bad scaling problems. Having someone say something like "I plan to implement this, and I think the document is good enough for me to do so" or "I have implemented this" is more data than "I think this is good". Having them say "This answers problem FOO which I face, so I will be pointing my vendors to this as a requirement" is similar. Saying "I support this over proprietary solution BAR" hints that the reason is the individual prefers a standards-based approach to a proprietary one, but it would be even better if they made that explicit. Consensus as "no objections heard" is a fine thing, and it is often enough. We can assume that the original impetus to the work is just carrying through to delivery. But when an AD (or the IESG) is trying to gauge whether their own possible objections should be treated as the rough part of the rough consensus, concrete statements help a lot. Just my two cents, of course, Ted --bcaec53aec2eae3f7604a2efea15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, May 10, 2011 at 9:32 AM, Pete Resnick <presnick@qualcomm.com> wrot= e:

It is a concern, but see Scott and SM's notes: Saying "I have read= and support the publication of this document" is indistinguishable fr= om, "My co-worker/friend/third-cousin-twice-removed told me I should s= end in a message supporting this document, so I did." All I'm sayi= ng is that additional text indicating *why* you support this document is th= e important part. Your statement of support is, in and of itself, relativel= y uninteresting.



To put this slightly differe= ntly, a statement of support where the AD has no context is hard to evaluat= e. =A0For some people, the AD's knowledge of the individual is the cont= ext. =A0If Steve Bellovin says he has read and supports a security document= , the AD's knowledge of Steve's history in that space is probably c= ontext enough. =A0IF you know the individual, in other words, you know whet= her they are really speaking for themselves or the cousin-twice-removed. = =A0But this has some bad scaling problems. =A0

Having someone say something like "I plan to imple= ment this, and I think the document is good enough for me to do so" or= "I have implemented this" is more data than "I think this i= s good". =A0 Having them say "This answers problem FOO which I fa= ce, so I will be pointing my vendors to this as a requirement" is simi= lar. =A0 Saying "I support this over proprietary solution BAR" hi= nts that the reason is the individual prefers a standards-based approach to= a proprietary one, but it would be even better if they made that explicit.=

Consensus as "no objections heard" is a fine = thing, and it is often enough. We can assume that the original impetus to t= he work is just carrying through to delivery. =A0But when an AD (or the IES= G) is trying to gauge whether their own possible objections should be treat= ed as the rough part of the rough consensus, concrete statements help a lot= .

Just my two cents, of course,

= Ted
--bcaec53aec2eae3f7604a2efea15-- From msk@cloudmark.com Tue May 10 11:54:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387E3E07FE for ; Tue, 10 May 2011 11:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.437 X-Spam-Level: X-Spam-Status: No, score=-104.437 tagged_above=-999 required=5 tests=[AWL=-1.838, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyYxh7G9Iglz for ; Tue, 10 May 2011 11:54:21 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id C176AE0726 for ; Tue, 10 May 2011 11:54:21 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 May 2011 11:52:18 -0700 From: "Murray S. Kucherawy" To: Barry Leiba Date: Tue, 10 May 2011 11:52:16 -0700 Thread-Topic: FW: Comments on Malformed Message BCP draft Thread-Index: Acv+wT2xcycdJJ02QYyjh5LFuB3OrgQgeYjg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-822@imc.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: Comments on Malformed Message BCP draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 18:54:23 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Tuesday, April 19, 2011 11:40 AM > To: Murray S. Kucherawy > Cc: ietf-822@imc.org; apps-discuss@ietf.org > Subject: Re: FW: Comments on Malformed Message BCP draft >=20 > On reading all the comments about this, and thinking about it myself, > I'm of a very mixed mind. >=20 > First: I have no sympathy for the comments that we should fix this > stuff in 5322, and not in some "add-on". This is *not* "fixing" > anything. This is *not* saying that any of the "malformed" messages > are now valid. This is not changing anything at all in 5322. What > this is doing is acknowledging that senders often violate 5322, and > that those violations are *wrong*. What it adds is that it also > acknowledges the reality that, as Nathaniel and others have said, we > can't just throw those wrong messages away, and there's some value in > agreeing how to handle them. This document -- or its final version -- > is an attempt to document that agreement. >=20 > Agents along the way -- MSAs, MTAs, MDAs, and MUAs -- will make their > guesses and fix-ups, and I do think it's in the best interest of > everyone for us to document less-harmful avenues to take, as well as > roads to hell. So I support this document for that reason. > [...] Since it was about to expire, I've posted a -01 version of this draft. The= re are no changes to the meat of it yet as the focus has been more about wh= ere this fits rather than the details of what it should say, but rather the= abstract and intro now make clear the sentiments of Barry's second paragra= ph above, which does indeed reflect my original intent for bringing the wor= k in the first place. From barryleiba.mailing.lists@gmail.com Tue May 10 12:46:11 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071DEE0704 for ; Tue, 10 May 2011 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zLAeG+mKkkD for ; Tue, 10 May 2011 12:46:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20D1CE069F for ; Tue, 10 May 2011 12:46:05 -0700 (PDT) Received: by gyf3 with SMTP id 3so2857498gyf.31 for ; Tue, 10 May 2011 12:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YycU0vDKREJSiws3ceqEJ3mJVZfPaQfwJFLxXd6ge0Q=; b=r3RZx9CYy2eWSlCGo3SVEbnfa9tjg5ROdzxASaf+hsDsRlc1h3SETvY+QadtQgnvtD WPyWVYYXCXN3bBZl7D9PLTEzlxbcw5ipgAt6B0HgdyBq4/m5GUrWuHVWtPUxRMY3/gdw SgRNeuSJehnbYLLoBjU+jMqpPAuI1Zb7P8XZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=hVclRIFqA6h8Iqb6kFzVPL3/sv2Dpzvs25l8Ue7F+q9aD2uVKcLyVlsk6VEexCHu/2 QFFDUP1dM64eNN7Frfzm02ghNrMXLK+nDhs4IjIVCdknA4ET6EkMswvJzQ9wr7QUA2im KWJAkJiaPldM8ODa7c86+FQvjUQ57YryXXCdQ= MIME-Version: 1.0 Received: by 10.151.99.10 with SMTP id b10mr7566640ybm.49.1305056765356; Tue, 10 May 2011 12:46:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 12:46:05 -0700 (PDT) In-Reply-To: <4DC9688B.3070701@qualcomm.com> References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com> Date: Tue, 10 May 2011 15:46:05 -0400 X-Google-Sender-Auth: Ug7UVr3pXzxTCctFlArBVoXNUzM Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 19:46:11 -0000 > It is a concern, but see Scott and SM's notes: Saying "I have read and > support the publication of this document" is indistinguishable from, "My > co-worker/friend/third-cousin-twice-removed told me I should send in a > message supporting this document, so I did." All I'm saying is that > additional text indicating *why* you support this document is the important > part. And you really think that my TCTR couldn't tell me I should send a message saying that I think the document is valuable and clear, and that I could implement from it? Or whatever? And you really think that if Dave says the document is valuable and clear, and that he could implement from it, and that's the same thing *I* wanted to say, I shouldn't just say "+1", or "I agree"? As I said in my off-list note to you, simply the fact that I read the document (or, at least, claimed to) and took the time to send a comment should be enough to give you valuable information -- it's absolutely NOT "useless". I appreciate that you might *also* like more than that, and if I have more than that to say, I will. But the idea that the IESG might ignore such comments as "useless" gives me more than a bit of fright. Barry From barryleiba.mailing.lists@gmail.com Tue May 10 13:10:36 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7AE0898 for ; Tue, 10 May 2011 13:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.521 X-Spam-Level: X-Spam-Status: No, score=-101.521 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ezr7EcSBMMy for ; Tue, 10 May 2011 13:10:35 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B198E089C for ; Tue, 10 May 2011 13:09:44 -0700 (PDT) Received: by gwb20 with SMTP id 20so2861356gwb.31 for ; Tue, 10 May 2011 13:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cAbUoxusz/r/qcxIZD02j3c6hE9vmKbBgZF3l+llZHE=; b=aUx4fIaTp23CPkQnYdqE16Ep7T6tD850RehHe738LnpcoMG/Mm2gX8pPoeriAGbS5t yqgarQO8zwWD7Jfe7NnvLt0ZPiBwdWM+JD+H709cQhrg0D6umYJjQp+y82ZETgn8rkFl AdIAtyXnUhKC3Mb+P+jjUXgcS6TkK6gyzTLlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CxOG7U0FUiB6Xktw8/upRKenRDc0ZrgMmAkO15FekW+B2zcPg7m4isaq5R7XwZtBCr tkBnXaZN+EMCOxJj4ott2T6AkbMVLuunDgFy4JLn0jNwpP8qhpmkPlAHLvdpFN5ltcSk jXmATCTZZ7yDpx78LmjTndy/aNYuCMoYREQ74= MIME-Version: 1.0 Received: by 10.146.47.14 with SMTP id u14mr4004622yau.35.1305058183465; Tue, 10 May 2011 13:09:43 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 13:09:43 -0700 (PDT) In-Reply-To: <4DC9499C.1060409@gmail.com> References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com> Date: Tue, 10 May 2011 16:09:43 -0400 X-Google-Sender-Auth: pHdFUcGtnBUer5OvozSfJhR6Iq0 Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 20:10:36 -0000 >>> I think this definition is not correct. =A0"A way that humans interact"= is >>> too generalized. =A0I suppose the following definition would suit bette= r here. ... >> Your definition is too limiting. Clearly, we are not only talking about >> speech. > > Agreed; but the current isn't appropriate as well. =A0Considering a langu= age > being the humans interaction way is correct in its concept, but I think w= e > should think about more exact definition. I don't. I think the text is fine as it is, and we should stop pushing on this point and leave it alone. [The only change I can see supporting is inserting "verbal" before "way". But there are non-verbal languages, as well.] >>> I think we can clarify a bit this definition by mentioning: "The >>> semantics of control characters depend on the application they are used >>> with. =A0The most common control characters semantics are specified in = ISO/IEC >>> 6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, = like >>> this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control >>> functions for coded character sets",1992." >> >> This seems like overkill. We don't define the semantics of any other cod= e >> points; why do it for control characters? > > I proposed to add at least some phrase on the role of control characters. > =A0ISO/IEC 6429 suits for this purpose fine, I think. I'm ambivalent here. On the one hand, I think the text is sufficient as it is, and that we should move on. On the other hand, with a whole generation brought up with SmartPhones, I think fewer people understand what control characters were -- WHY this set of codepoints is special. A bit of history wouldn't be a bad thing, if not strictly necessary. In any case, I don't support using ISO 6429 for it. A few words of background here would be enough, IF we want to put them in. Pointing to an 80-page, 150-euro document doesn't cut it for me. >>> I also think the reference to [CHARMOD] is a bit incorrect as well. =A0= I >>> propose: >>> >>>> Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and = T. >>>> Texin, Ed., "Character Model for the World Wide Web 1.0", W3C >>>> Recommendation, February 2005. >> >> Disagree. Listing a bunch of folks does not help the reference at all. > > You could then mention "Duerst, M., et al, ...". =A0See, we're not mentio= ning > IETF as an author of RFCs; the same is with W3C. Paul's been consistent in using the organization as the author for all non-IETF documents -- there's another W3C citation, many from Unicode, a couple from ISO (ugh), and so on. That seems the right thing to do here, too. He does have a note in asking the RFC Editor to normalize the citations, and I think we should leave this issue to the RFC Editor and their style guide. Barry, as participant From presnick@qualcomm.com Tue May 10 13:53:03 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A414E06F1 for ; Tue, 10 May 2011 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.429 X-Spam-Level: X-Spam-Status: No, score=-106.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUK32yPcA8+P for ; Tue, 10 May 2011 13:53:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 78DCAE06D4 for ; Tue, 10 May 2011 13:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305060782; x=1336596782; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DC9A557.9040504@qualcomm.com>|Date:=20Tu e,=2010=20May=202011=2015:51:35=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20|Subject:=20Re: =20[apps-discuss]=20On=20"supporting=20the=20publication =20of=20this=20document"|References:=20<4DC88255.3070403@ qualcomm.com>=20<4DC94F74.30905@dcrocker.net>=09<4DC9688B .3070701@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/ plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=2+EdxkoK+J1MFn93HkNciYH9Jz5Ezt1ZOxZEBMQacBE=; b=DsJCbFvUPxRfBpoKv2v8btt9wsq2hUWz/FnBtYx/j3aKI3omXI7z7CR7 OeETyDe9BaeLy0V98arkvCRk6qFgVYYuJck542yu+ZLV6FenfSOexyBoC czQy1VqET2XnbT4J1jPg25cpwU8T9VWqT+U22KrRWEbXRDiOzlPdUOAQk k=; X-IronPort-AV: E=McAfee;i="5400,1158,6342"; a="90432670" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 10 May 2011 13:53:00 -0700 X-IronPort-AV: E=Sophos;i="4.64,346,1301900400"; d="scan'208";a="138962392" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 May 2011 13:52:40 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 13:51:38 -0700 Message-ID: <4DC9A557.9040504@qualcomm.com> Date: Tue, 10 May 2011 15:51:35 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 20:53:03 -0000 On 5/10/11 2:46 PM, Barry Leiba wrote: >> Saying "I have read and >> support the publication of this document" is indistinguishable from, "My >> co-worker/friend/third-cousin-twice-removed told me I should send in a >> message supporting this document, so I did." All I'm saying is that >> additional text indicating *why* you support this document is the important >> part. >> > And you really think that my TCTR couldn't tell me I should send a > message saying that I think the document is valuable and clear, and > that I could implement from it? Or whatever? Well, your cousin could try to tell you how to do that. But it gets harder for people to pull this off with a straight face if, as a group, we start giving more elaborate comments. People who are normal participants in the group start asking the right kinds of questions of those folks and they get marginalized. But getting rid of process abusers is only a secondary goal here. Really my point is, I want us all to get in the habit of taking responsibility for documents; to not assume that the AD is going to be the final backstop, but instead assuming that the AD may be a dope and needs this stuff explained to him or her. > And you really think that if Dave says the document is valuable and > clear, and that he could implement from it, and that's the same thing > *I* wanted to say, I shouldn't just say "+1", or "I agree"? > cf. Ted's comment about context. I might take you or Dave as saying something more interesting because I have a context of who you are. And given that context, you or Dave might well say, "(*grunt*)" instead of "I support the document", because really I'm not judging consensus on what you say, but on the context entirely. (That's what I mean by the statement being "useless".) But grunts and dependence on context makes it really difficult for new folks to know what's going on (be they ADs, chairs, or just participants), and it sets up the idea that what we're doing here is voting rather than coming to consensus. So if that means that folks we know well all have to add a sentence or two more during LC to set a good example, I'm OK with that. > As I said in my off-list note to you, simply the fact that I read the > document (or, at least, claimed to) and took the time to send a > comment should be enough to give you valuable information -- it's > absolutely NOT "useless". I appreciate that you might *also* like > more than that, and if I have more than that to say, I will. But the > idea that the IESG might ignore such comments as "useless" gives me > more than a bit of fright. > Of course the "or, at least, claimed to" is exactly what gives me a bit of fright. But understand that I really *might* ignore comments that come without context because there really is no way to evaluate what they mean. I'd rather get a bit of extra context. That makes it easier to point to later. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From stpeter@stpeter.im Tue May 10 14:10:25 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3025EE06F0 for ; Tue, 10 May 2011 14:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEO0bEtb7hkN for ; Tue, 10 May 2011 14:10:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1171AE06DB for ; Tue, 10 May 2011 14:10:23 -0700 (PDT) Received: from dhcp-64-101-72-221.cisco.com (dhcp-64-101-72-221.cisco.com [64.101.72.221]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B9696400F9; Tue, 10 May 2011 15:10:22 -0600 (MDT) Message-ID: <4DC9A9B9.3010702@stpeter.im> Date: Tue, 10 May 2011 15:10:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> In-Reply-To: <4DC94F74.30905@dcrocker.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000808000808010201000602" Cc: Pete Resnick , apps-discuss@ietf.org Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 21:10:25 -0000 This is a cryptographically signed message in MIME format. --------------ms000808000808010201000602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/10/11 8:45 AM, Dave CROCKER wrote: > Your note suggests that, at the least, the text of a Last Call should > make much more clear what sorts of comments are being sought (and why > and probably from whom.) The community should not have to guess what > sorts of responses are useful for the IESG. FWIW, over in the XMPP Standards Foundation (xmpp.org) we ask the following questions in each of our Last Call announcements: # Please consider the following questions during this Last Call and # send your feedback to the standards@xmpp.org discussion list: # # 1. Is this specification needed to fill gaps in the XMPP # protocol stack or to clarify an existing protocol? # 2. Does the specification solve the problem stated in the # introduction and requirements? # 3. Do you plan to implement this specification in your code? # If not, why not? # 4. Do you have any security concerns related to this specification? # 5. Is the specification accurate and clearly written? Whether that's the right set of questions is another issue... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000808000808010201000602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx MDIxMTAxN1owIwYJKoZIhvcNAQkEMRYEFLMpa7UcbaqKqr9Vk8sSfquOKgkfMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQATVXWivcMGBfkImQm+w850q5UaaSfuN+qmTD0tq56eEqKw/WoAhGyZii6i AkwdVw42mCy/GQcLl87IddLC1RB7R6jNbJWNI9h5wYY80WOK8ssrKZJeCk7hVK1d2I83QBY1 hDCYPXUrtKPQZ1LnWMOK7hXp5mFB/G2YDPrCpm1Nqv7soJaZ3AWgLiipYLDg10F5ZdDeT0zx eETaFHQQTH5138wYUQhPyON6599li/JO6Wq+QHsjoDtor2Q6eAzAObnCGPi3AVGpgAg49N7+ 1hKWNJk3bavAkyfH/czYd5j4+8WhPn7n7G1QFCLxdjexwYDjDnV1fxuYEoqZ4UJy8UfBAAAA AAAA --------------ms000808000808010201000602-- From msk@cloudmark.com Tue May 10 15:35:50 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C1E08AB for ; Tue, 10 May 2011 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.922 X-Spam-Level: X-Spam-Status: No, score=-104.922 tagged_above=-999 required=5 tests=[AWL=-1.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+AjyPkRxC-V for ; Tue, 10 May 2011 15:35:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id EBE83E06D9 for ; Tue, 10 May 2011 15:35:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 May 2011 15:35:49 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 10 May 2011 15:35:47 -0700 Thread-Topic: [apps-discuss] On "supporting the publication of this document" Thread-Index: AcwPVrbzRN+yH8xDQt6Bc0r8QpuI3AAC7YIQ Message-ID: References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im> In-Reply-To: <4DC9A9B9.3010702@stpeter.im> 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 Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 22:35:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2VudDogVHVlc2RheSwgTWF5IDEwLCAyMDExIDI6 MTAgUE0NCj4gVG86IGRjcm9ja2VyQGJiaXcubmV0DQo+IENjOiBQZXRlIFJlc25pY2s7IGFwcHMt ZGlzY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gT24gInN1cHBv cnRpbmcgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQiDQo+IA0KPiAjICAgIFBsZWFz ZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucyBkdXJpbmcgdGhpcyBMYXN0IENhbGwg YW5kDQo+ICMgICAgc2VuZCB5b3VyIGZlZWRiYWNrIHRvIHRoZSBzdGFuZGFyZHNAeG1wcC5vcmcg ZGlzY3Vzc2lvbiBsaXN0Og0KPiAjDQo+ICMgICAgMS4gSXMgdGhpcyBzcGVjaWZpY2F0aW9uIG5l ZWRlZCB0byBmaWxsIGdhcHMgaW4gdGhlIFhNUFANCj4gIyAgICAgICBwcm90b2NvbCBzdGFjayBv ciB0byBjbGFyaWZ5IGFuIGV4aXN0aW5nIHByb3RvY29sPw0KPiAjICAgIDIuIERvZXMgdGhlIHNw ZWNpZmljYXRpb24gc29sdmUgdGhlIHByb2JsZW0gc3RhdGVkIGluIHRoZQ0KPiAjICAgICAgIGlu dHJvZHVjdGlvbiBhbmQgcmVxdWlyZW1lbnRzPw0KPiAjICAgIDMuIERvIHlvdSBwbGFuIHRvIGlt cGxlbWVudCB0aGlzIHNwZWNpZmljYXRpb24gaW4geW91ciBjb2RlPw0KPiAjICAgICAgIElmIG5v dCwgd2h5IG5vdD8NCj4gIyAgICA0LiBEbyB5b3UgaGF2ZSBhbnkgc2VjdXJpdHkgY29uY2VybnMg cmVsYXRlZCB0byB0aGlzIHNwZWNpZmljYXRpb24/DQo+ICMgICAgNS4gSXMgdGhlIHNwZWNpZmlj YXRpb24gYWNjdXJhdGUgYW5kIGNsZWFybHkgd3JpdHRlbj8NCj4gDQo+IFdoZXRoZXIgdGhhdCdz IHRoZSByaWdodCBzZXQgb2YgcXVlc3Rpb25zIGlzIGFub3RoZXIgaXNzdWUuLi4NCg0KVGhpcywg YW5kIGVzcGVjaWFsbHkgdGhhdCBsYXN0IG9uZSwgbWFrZXMgaXQgc291bmQgbGlrZSBhIFBST1RP IHdyaXRlLXVwLiAgQXJlIHlvdSBzdXJlIHlvdSB3YW50IHRoYXQgZnJvbSBhIHBvdGVudGlhbGx5 IGh1Z2UgbGlzdCBvZiBwZW9wbGU/DQoNCg== From barryleiba.mailing.lists@gmail.com Tue May 10 18:15:23 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B84E070C for ; Tue, 10 May 2011 18:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.378 X-Spam-Level: X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq1a2baSEMpv for ; Tue, 10 May 2011 18:15:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39941E0708 for ; Tue, 10 May 2011 18:15:20 -0700 (PDT) Received: by gwb20 with SMTP id 20so13133gwb.31 for ; Tue, 10 May 2011 18:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rhuXYmrB2mSHN85mT5/5iALvvYpsZAFhWtEViHxCOYk=; b=vdvruWHFTez4LYj/KWsGxPWwwm86KoTqkOFWpWxHF2vAYXDHUqDFkuiODPheGiwouj QWMZosF3PmAnIDCRRaDJ1VMI4a/zGRuZgFT6BsuX08LnFuIVfRpx9VWu4nPRdqf8LrJx SXLn+UdBNjiu2YNyTm5b23zYXaGuyRU8AFDGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=az1XnbXlPn6qa7zPtPcsaiyY1X1TGcZuxzTbkOAvzPsUM4T10FxEWz9IdBAvWFxf0O MeY6i5RJTCMzn5bgeHjOtySWewSzDJueLKMRsRAHg1+NXNyM4kz+5ZJvtycTGFnZLNO7 CzGQ03p05Ref6BGZlEefge4MtbXbQAVxdpJKQ= MIME-Version: 1.0 Received: by 10.151.92.15 with SMTP id u15mr7062992ybl.220.1305076519471; Tue, 10 May 2011 18:15:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.13 with HTTP; Tue, 10 May 2011 18:15:19 -0700 (PDT) In-Reply-To: References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im> Date: Tue, 10 May 2011 21:15:19 -0400 X-Google-Sender-Auth: KXJjWqMwyncJynPbBgBCp5a0jRc Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:15:23 -0000 >> # =A0 =A0Please consider the following questions during this Last Call a= nd >> # =A0 =A0send your feedback to the standards@xmpp.org discussion list: >> # >> # =A0 =A01. Is this specification needed to fill gaps in the XMPP >> # =A0 =A0 =A0 protocol stack or to clarify an existing protocol? >> # =A0 =A02. Does the specification solve the problem stated in the >> # =A0 =A0 =A0 introduction and requirements? >> # =A0 =A03. Do you plan to implement this specification in your code? >> # =A0 =A0 =A0 If not, why not? >> # =A0 =A04. Do you have any security concerns related to this specificat= ion? >> # =A0 =A05. Is the specification accurate and clearly written? >> >> Whether that's the right set of questions is another issue... > > This, and especially that last one, makes it sound like a PROTO write-up. >=A0Are you sure you want that from a potentially huge list of people? Interesting: I think the last question is the *most* important, and the one that *least* seems like it came out of a PROTO write-up. Yes, that's the question I *do* most want to see *all* reviews answer. Barry From stpeter@stpeter.im Tue May 10 18:27:04 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163ADE068D for ; Tue, 10 May 2011 18:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtkIsPK94X67 for ; Tue, 10 May 2011 18:27:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DFD90E0689 for ; Tue, 10 May 2011 18:27:02 -0700 (PDT) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0CB2F400ED; Tue, 10 May 2011 19:27:00 -0600 (MDT) Message-ID: <4DC9E5DB.6030005@stpeter.im> Date: Tue, 10 May 2011 19:26:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060601000501000207080500" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] On "supporting the publication of this document" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 01:27:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060601000501000207080500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/10/11 4:35 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.= org] On Behalf Of Peter Saint-Andre >> Sent: Tuesday, May 10, 2011 2:10 PM >> To: dcrocker@bbiw.net >> Cc: Pete Resnick; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] On "supporting the publication of this doc= ument" >> >> # Please consider the following questions during this Last Call and= >> # send your feedback to the standards@xmpp.org discussion list: >> # >> # 1. Is this specification needed to fill gaps in the XMPP >> # protocol stack or to clarify an existing protocol? >> # 2. Does the specification solve the problem stated in the >> # introduction and requirements? >> # 3. Do you plan to implement this specification in your code? >> # If not, why not? >> # 4. Do you have any security concerns related to this specificatio= n? >> # 5. Is the specification accurate and clearly written? >> >> Whether that's the right set of questions is another issue... >=20 > This, and especially that last one, makes it sound like a PROTO write-u= p. Are you sure you want that from a potentially huge list of people? Well, that's what we ask at xmpp.org. I'm not suggesting that we do so at ietf.org. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060601000501000207080500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx MTAxMjY1MVowIwYJKoZIhvcNAQkEMRYEFB+AX96d+zm+H9FOAEYBAVjf6NLrMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQColtlP9kPBLGcPTS7dh7alkKMVHDr+yc0wT3s1+TSl1Ta4r/XYCr3lGxjb C5EpuvU7Aplf4q8R893zJmevrXz8VwuhhLmJJzQvJqi0wanMnOYgmEgfyu2k39WgGVOwrC1N 9oA2TeuG1wjz/Vm8o7HToxZZ6AGY/w2h25dmjusqqCy6QL2RizLxSFaJHMn8rY9cuC3K2aZ/ mWAD+Wqtn/RLkojrItvMg0CMDHV8/KBKF+qXH8UadqIBrMAJDd+N4t9ic9IBup2jDI4X0wXj f277pA8UnOoKh0WEfwhvIaV/AgtiWdH3uiqetvZYk1UsEIe+j9k8gQ9/ELwg3cAcAjqfAAAA AAAA --------------ms060601000501000207080500-- From evnikita2@gmail.com Wed May 11 03:58:18 2011 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DA9E07E7 for ; Wed, 11 May 2011 03:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMewiFEWpLEH for ; Wed, 11 May 2011 03:58:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77DECE07DE for ; Wed, 11 May 2011 03:58:17 -0700 (PDT) Received: by bwz13 with SMTP id 13so397707bwz.31 for ; Wed, 11 May 2011 03:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=6fpj2DEaQlVyv7LxhVFjVOLicbJ1WrYV262LsswcckM=; b=Jsm7MgTeXKwgZfBFlD44Lq4/p6ZX8bNQUT+Tg6UQNi8s5wHfl90jLgpaGVd0KFYhC5 Y49qWx4IMViGMCrd6oVIS5GpL5A3F0RI/K5FHk9iI1RHT+8T97Vlva83QQ4sedHeBOv2 Zzt63KUGLw8IGLeaoIF3AaaZ8hVwBLsaiQsvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=wkNKDa/5sAF1jtvRYYfDqL6VvgCZX8xlBW29A/QPREfkDM0JRc+JIjlN2dPToeWKVZ rEJIfmeIWFtn311WlSYCPd2ckmILTWVaGtuaqW44w+m9w99iNEPHq8RiYWqLhufirLyM q9nzCWl8mBalQlpBEj13bFHusT5GwtczPatig= Received: by 10.204.75.1 with SMTP id w1mr19135bkj.132.1305111495856; Wed, 11 May 2011 03:58:15 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d11sm18845bka.19.2011.05.11.03.58.13 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 03:58:14 -0700 (PDT) Message-ID: <4DCA6BF1.4010702@gmail.com> Date: Wed, 11 May 2011 13:58:57 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Barry Leiba References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070400070807010602000803" Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 May 2011 10:58:18 -0000 This is a multi-part message in MIME format. --------------070400070807010602000803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 10.05.2011 23:09, Barry Leiba wrote: >>>> I think this definition is not correct. "A way that humans interact" is >>>> too generalized. I suppose the following definition would suit better here. > ... >>> Your definition is too limiting. Clearly, we are not only talking about >>> speech. >> Agreed; but the current isn't appropriate as well. Considering a language >> being the humans interaction way is correct in its concept, but I think we >> should think about more exact definition. > I don't. I think the text is fine as it is, and we should stop > pushing on this point and leave it alone. [The only change I can see > supporting is inserting "verbal" before "way". But there are > non-verbal languages, as well.] Adding "verbal" seems fine to me; this will clarify the definition a bit. >>>> I think we can clarify a bit this definition by mentioning: "The >>>> semantics of control characters depend on the application they are used >>>> with. The most common control characters semantics are specified in ISO/IEC >>>> 6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, like >>>> this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control >>>> functions for coded character sets",1992." >>> This seems like overkill. We don't define the semantics of any other code >>> points; why do it for control characters? >> I proposed to add at least some phrase on the role of control characters. >> ISO/IEC 6429 suits for this purpose fine, I think. > I'm ambivalent here. On the one hand, I think the text is sufficient > as it is, and that we should move on. On the other hand, with a whole > generation brought up with SmartPhones, I think fewer people > understand what control characters were -- WHY this set of codepoints > is special. A bit of history wouldn't be a bad thing, if not strictly > necessary. > > In any case, I don't support using ISO 6429 for it. A few words of > background here would be enough, IF we want to put them in. Pointing > to an 80-page, 150-euro document doesn't cut it for me. How about the following text: control character The control character (also known as control code) is a special-purpose codepoint in a particular coded character set that generally does not represent any written symbol. Generally, control characters are used to control handling of data; they can be considered to be and in-band signaling in the context of character encoding. Currently, there are 65 control characters, occupying the ranges U+0000..U+001F and U+007F..U+009F. The basic space character, U+0020, is often considered as a control character as well, making the total number 66. In terminology adopted by Unicode from ASCII and the ISO 8859 standards, these codes are treated as belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for U+0080...U+009F), and the single control character "DEL" (U+007F). >>>> I also think the reference to [CHARMOD] is a bit incorrect as well. I >>>> propose: >>>> >>>>> Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and T. >>>>> Texin, Ed., "Character Model for the World Wide Web 1.0", W3C >>>>> Recommendation, February 2005. >>> Disagree. Listing a bunch of folks does not help the reference at all. >> You could then mention "Duerst, M., et al, ...". See, we're not mentioning >> IETF as an author of RFCs; the same is with W3C. > Paul's been consistent in using the organization as the author for all > non-IETF documents -- there's another W3C citation, many from Unicode, > a couple from ISO (ugh), and so on. That seems the right thing to do > here, too. He does have a note in asking the RFC Editor to normalize > the citations, and I think we should leave this issue to the RFC > Editor and their style guide. OK, let's leave this for RFC Editor. Mykyta Yevstifeyev > Barry, as participant > --------------070400070807010602000803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 10.05.2011 23:09, Barry Leiba wrote: 
I think this definition is not correct.  "A way that humans interact" is
too generalized.  I suppose the following definition would suit better here.

...

Your definition is too limiting. Clearly, we are not only talking about
speech.

Agreed; but the current isn't appropriate as well.  Considering a language
being the humans interaction way is correct in its concept, but I think we
should think about more exact definition.

I don't.  I think the text is fine as it is, and we should stop
pushing on this point and leave it alone.  [The only change I can see
supporting is inserting "verbal" before "way".  But there are
non-verbal languages, as well.]
Adding "verbal" seems fine to me; this will clarify the definition a bit.

      

        

          

            
I think we can clarify a bit this definition by mentioning: "The
semantics of control characters depend on the application they are used
with.  The most common control characters semantics are specified in ISO/IEC
6429:1992 [ISO6429]" and adding the appropriate reference to ISO 6429, like
this: "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control
functions for coded character sets",1992."


          

          
This seems like overkill. We don't define the semantics of any other code
points; why do it for control characters?


        

        
I proposed to add at least some phrase on the role of control characters.
 ISO/IEC 6429 suits for this purpose fine, I think.


      

      
I'm ambivalent here.  On the one hand, I think the text is sufficient
as it is, and that we should move on.  On the other hand, with a whole
generation brought up with SmartPhones, I think fewer people
understand what control characters were -- WHY this set of codepoints
is special.  A bit of history wouldn't be a bad thing, if not strictly
necessary.

In any case, I don't support using ISO 6429 for it.  A few words of
background here would be enough, IF we want to put them in.  Pointing
to an 80-page, 150-euro document doesn't cut it for me.


    

    How about the following text:

    

    
   control character

      The control character (also known as control code) is a special-purpose
      codepoint in a particular coded character set that generally does not 
      represent any written symbol.  Generally, control characters are used 
      to control handling of data; they can be considered to be and in-band
      signaling in the context of character encoding.  <NONE>
   
      Currently, there are 65 control characters, occupying the ranges 
      U+0000..U+001F and U+007F..U+009F.  The basic space character, U+0020,
      is often considered as a control character as well, making the total 
      number 66.  In terminology adopted by Unicode from ASCII and the 
      ISO 8859 standards, these codes are treated as belonging to three 
      ranges: "C0" (for U+0000..U+001F), "C1" (for U+0080...U+009F), and 
      the single control character "DEL" (U+007F).

    

    

      

      

        

          

            
I also think the reference to [CHARMOD] is a bit incorrect as well.  I
propose:



            

              
Duerst, M., Ed., Yergeau, F., Ed., Ishida, R., Ed., Wolf, M., Ed. and T.
Texin, Ed., "Character Model for the World Wide Web 1.0", W3C
Recommendation, February 2005.<http://www.w3.org/TR/charmod/>


            

          

          
Disagree. Listing a bunch of folks does not help the reference at all.


        

        
You could then mention "Duerst, M., et al, ...".  See, we're not mentioning
IETF as an author of RFCs; the same is with W3C.


      

      
Paul's been consistent in using the organization as the author for all
non-IETF documents -- there's another W3C citation, many from Unicode,
a couple from ISO (ugh), and so on.  That seems the right thing to do
here, too.  He does have a note in asking the RFC Editor to normalize
the citations, and I think we should leave this issue to the RFC
Editor and their style guide.


    

    OK, let's leave this for RFC Editor.

    

    Mykyta Yevstifeyev

    

      
Barry, as participant



    

    

  


--------------070400070807010602000803--

From paul.hoffman@vpnc.org  Wed May 11 07:07:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A719DE073A for ; Wed, 11 May 2011 07:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.284
X-Spam-Level: 
X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bKZtH6dSbhf for ; Wed, 11 May 2011 07:07:10 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DAA27E0706 for ; Wed, 11 May 2011 07:07:09 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BE74cQ011793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 07:07:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman 
In-Reply-To: <4DCA6BF1.4010702@gmail.com>
Date: Wed, 11 May 2011 07:07:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <34096E38-A149-4B7C-A289-0124EF113BC4@vpnc.org>
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com>	<4DC77648.1040903@gmail.com>	<8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org>	<4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com>
To: Mykyta Yevstifeyev 
X-Mailer: Apple Mail (2.1084)
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:07:10 -0000

On May 11, 2011, at 3:58 AM, Mykyta Yevstifeyev wrote:

> 10.05.2011 23:09, Barry Leiba wrote:
>>>>> I think this definition is not correct.  "A way that humans =
interact" is
>>>>> too generalized.  I suppose the following definition would suit =
better here.
>>>>>=20
>> ...
>>=20
>>>> Your definition is too limiting. Clearly, we are not only talking =
about
>>>> speech.
>>>>=20
>>> Agreed; but the current isn't appropriate as well.  Considering a =
language
>>> being the humans interaction way is correct in its concept, but I =
think we
>>> should think about more exact definition.
>>>=20
>> I don't.  I think the text is fine as it is, and we should stop
>> pushing on this point and leave it alone.  [The only change I can see
>> supporting is inserting "verbal" before "way".  But there are
>> non-verbal languages, as well.]
>>=20
> Adding "verbal" seems fine to me; this will clarify the definition a =
bit.

As Barry said, there are non-verbal languages as well. As co-author of =
this document, I would be very hesitant to disqualify the languages used =
by tens (maybe hundreds) of millions of people with this change unless =
the WG has a good reason to do so.

> How about the following text:
>=20
>    control character
>=20
>       The control character (also known as control code) is a =
special-purpose
>       codepoint in a particular coded character set that generally =
does not=20
>       represent any written symbol.  Generally, control characters are =
used=20
>       to control handling
>  of data; they can be considered to be and i
> n-band
>       signaling in the context of character encoding.  
>   =20
>       Currently, there are 65 control characters, occupying the ranges=20=

>       U+0000..U+001F and U+007F..U+009F.  The basic space character, =
U+0020,
>       is often considered as a control character as well, making the =
total=20
>       number 66.  In terminology adopted by Unicode from ASCII and the=20=

>       ISO 8859 standards, these codes are treated as belonging to =
three=20
>       ranges: "C0" (for U+0000..U+001F), "C1" (for U+0080...U+009F), =
and=20
>       the single control character "DEL" (U+007F).

You are again ignoring what others have said. What does this proposed =
text have to do with internationalization?

--Paul Hoffman


From ajs@shinkuro.com  Wed May 11 07:25:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C13E0728 for ; Wed, 11 May 2011 07:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eku5njjCf8n for ; Wed, 11 May 2011 07:25:25 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BFB61E0704 for ; Wed, 11 May 2011 07:25:25 -0700 (PDT)
Received: from shinkuro.com (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 71E671ECB41D for ; Wed, 11 May 2011 14:25:24 +0000 (UTC)
Date: Wed, 11 May 2011 10:25:17 -0400
From: Andrew Sullivan 
To: apps-discuss@ietf.org
Message-ID: <20110511142516.GA4578@crankycanuck.ca>
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DCA6BF1.4010702@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:25:26 -0000

On Wed, May 11, 2011 at 01:58:57PM +0300, Mykyta Yevstifeyev wrote:
> >pushing on this point and leave it alone.  [The only change I can see
> >supporting is inserting "verbal" before "way".  But there are
> >non-verbal languages, as well.]
> Adding "verbal" seems fine to me; this will clarify the definition a bit.

I am strongly opposed to the qualification "verbal".  It's flat out wrong.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From evnikita2@gmail.com  Wed May 11 08:00:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22513E080C for ; Wed, 11 May 2011 08:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.151,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDKpgCSiB9oV for ; Wed, 11 May 2011 08:00:15 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 261BFE0736 for ; Wed, 11 May 2011 08:00:14 -0700 (PDT)
Received: by bwz13 with SMTP id 13so633205bwz.31 for ; Wed, 11 May 2011 08:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K/smi4030J2QQE+rUg5fbCJIERMlYYPpaIL3+m9ccv0=; b=Cez1qn4V892SxR78Q2iUvUQw/Jn2ZpRGFFRRaZmjNdmnSp6le1xMIBdBhKG4jObIEP XX40Cb9AlqIL6LGOFd9KYKE6M3Bg0w37S8UMZ4RY81UCCPKaYMb0zPs7WYP5HXz39L7H 1lwABsKuuaR5TOorneBozC001FBPVVyMdpDyE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=e43ksKv29YD96F92DBGplwX0exflCcxKBhHEGGf1kAsFYQXZC9txAzd/Tm96rP57gO VGaj65na9aJNYiPSRYU78becKoyCRCvTvrzCWuX+l+i+AWLSmpv/C+TEOC/2PZvm1DC5 ZUL2x4rKmDB2ZrGfCHdxFPakO3akUsnBM8zKU=
Received: by 10.204.46.162 with SMTP id j34mr1550387bkf.210.1305126014116; Wed, 11 May 2011 08:00:14 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q24sm165572bks.9.2011.05.11.08.00.12 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 08:00:13 -0700 (PDT)
Message-ID: <4DCAA4A8.9030806@gmail.com>
Date: Wed, 11 May 2011 18:00:56 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Paul Hoffman 
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com>	<4DC77648.1040903@gmail.com>	<8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org>	<4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com> <34096E38-A149-4B7C-A289-0124EF113BC4@vpnc.org>
In-Reply-To: <34096E38-A149-4B7C-A289-0124EF113BC4@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:00:16 -0000

11.05.2011 17:07, Paul Hoffman wrote:
> On May 11, 2011, at 3:58 AM, Mykyta Yevstifeyev wrote:
>
> [ . . . ]
>> How about the following text:
>>
>>     control character
>>
>>        The control character (also known as control code) is a special-purpose
>>        codepoint in a particular coded character set that generally does not
>>        represent any written symbol.  Generally, control characters are used
>>        to control handling
>>   of data; they can be considered to be and i
>> n-band
>>        signaling in the context of character encoding.
>>
>>        Currently, there are 65 control characters, occupying the ranges
>>        U+0000..U+001F and U+007F..U+009F.  The basic space character, U+0020,
>>        is often considered as a control character as well, making the total
>>        number 66.  In terminology adopted by Unicode from ASCII and the
>>        ISO 8859 standards, these codes are treated as belonging to three
>>        ranges: "C0" (for U+0000..U+001F), "C1" (for U+0080...U+009F), and
>>        the single control character "DEL" (U+007F).
> You are again ignoring what others have said. What does this proposed text have to do with internationalization?
Then should we consider the existing text to be unfamiliar to i18n?  It 
is just what we currently have with addition of some background info.

If you want to keep this document strictly on the internalization topic, 
you should consider many definitions of terms such as "formatting 
character", "compatibility character", "case" etc. inappropriate to it; 
but RFC 3536 itself and your draft actually define these terms.
> --Paul Hoffman
>
>


From dhc@dcrocker.net  Wed May 11 08:27:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC4E06F6 for ; Wed, 11 May 2011 08:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3GKggT0J9Q7 for ; Wed, 11 May 2011 08:27:00 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DA98FE0704 for ; Wed, 11 May 2011 08:26:59 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4BFQsCK013948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 08:26:59 -0700
Message-ID: <4DCAAAB9.3080702@dcrocker.net>
Date: Wed, 11 May 2011 08:26:49 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im>
In-Reply-To: <4DC9A9B9.3010702@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 May 2011 08:26:59 -0700 (PDT)
Cc: Pete Resnick 
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2011 15:27:01 -0000

On 5/10/2011 2:10 PM, Peter Saint-Andre wrote:
> On 5/10/11 8:45 AM, Dave CROCKER wrote:
>
>> Your note suggests that, at the least, the text of a Last Call should make
>> much more clear what sorts of comments are being sought (and why and
>> probably from whom.)  The community should not have to guess what sorts of
>> responses are useful for the IESG.
>
> FWIW, over in the XMPP Standards Foundation (xmpp.org) we ask the following
> questions in each of our Last Call announcements:


It has the considerable benefit of guiding the respondent to provide pragmatic
detail.

The IETF would do well to include some form of similar guidance in its Last Call
announcement.


n 5/10/2011 6:15 PM, Barry Leiba wrote:
>>> #    Please consider the following questions during this Last Call and #
>>> send your feedback to the standards@xmpp.org discussion list: # #    1.
>>> Is this specification needed to fill gaps in the XMPP #       protocol
>>> stack or to clarify an existing protocol? #    2. Does the specification
>>> solve the problem stated in the #       introduction and requirements? #
>>> 3. Do you plan to implement this specification in your code? #       If
>>> not, why not? #    4. Do you have any security concerns related to this
>>> specification? #    5. Is the specification accurate and clearly
>>> written?
>>>
>>> Whether that's the right set of questions is another issue...
>>
>> This, and especially that last one, makes it sound like a PROTO write-up.
>> Are you sure you want that from a potentially huge list of people?
>
> Interesting: I think the last question is the *most* important, and the one
> that *least* seems like it came out of a PROTO write-up.  Yes, that's the
> question I *do* most want to see *all* reviews answer.

Whereas I think each of these questions is quite important, with the last one
likely to get the most pro-forma responses, since it is the most difficult to
answer knowledgeably.


> On 5/10/2011 3:35 PM, Murray S. Kucherawy wrote:
...
>> This, and especially that last one, makes it sound like a PROTO write-up.
>> Are you sure you want that from a potentially huge list of people?

I don't see a problem with having a potential large number of people supply 
detailed responses.  (For one thing, I doubt that the typical case is/will be a 
large number...)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From scott.brim@gmail.com  Wed May 11 08:35:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B43E081F for ; Wed, 11 May 2011 08:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LEn5QnUwS8W for ; Wed, 11 May 2011 08:35:42 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87E50E0816 for ; Wed, 11 May 2011 08:35:42 -0700 (PDT)
Received: by iwn39 with SMTP id 39so798484iwn.31 for ; Wed, 11 May 2011 08:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hFbd//A3q1Hy6dFvBl1Z+uBFWcJxfYcPrlpkheSQeUY=; b=ADdZSfR0ngdbIS7C9q4/VjQIHrqvI0fy80ukvHe6wHMNcvG/K3pEeSdYE/JfagBmKg fLx8fYB9rSLXjhK4oaYWzhIZsYzmjPNoeu3jeMOx/xHiyenBfL8+f8k6X8rjm8kktXd/ LYR+o0AexCqL4OWZFmaOpa5v3u8gP0Xi8IhpQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=TtLGIfUpT4/yiUsaHjdE5H6VZIVJY+30QcJpDkdmQ7OEDO/yf2rvSvXhpuWN++Vwfm ndxSo2n7McsLf8OkFoaCbmFmC0dkgEX97jIwJEfNvxDO0APW0KwGEVQL9y1i7v9gb6uz +sBwPRLU/5L7TBGZQOfWUJleYiMacWHqd9tDk=
Received: by 10.231.51.17 with SMTP id b17mr6918807ibg.0.1305128142095; Wed, 11 May 2011 08:35:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.30.205 with HTTP; Wed, 11 May 2011 08:35:21 -0700 (PDT)
In-Reply-To: <4DCAAAB9.3080702@dcrocker.net>
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im> <4DCAAAB9.3080702@dcrocker.net>
From: Scott Brim 
Date: Wed, 11 May 2011 11:35:21 -0400
Message-ID: 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:35:43 -0000

On Wed, May 11, 2011 at 11:26, Dave CROCKER  wrote:
> It has the considerable benefit of guiding the respondent to provide
> pragmatic detail.
>
> The IETF would do well to include some form of similar guidance in its La=
st
> Call announcement.

> I don't see a problem with having a potential large number of people supp=
ly
> detailed responses. =A0(For one thing, I doubt that the typical case is/w=
ill
> be a large number...)

Glad to hear it.  I couldn't tell where you were headed.

Scott

From barryleiba.mailing.lists@gmail.com  Wed May 11 09:07:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B0E0811 for ; Wed, 11 May 2011 09:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.363
X-Spam-Level: 
X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgMiHMcOU9sc for ; Wed, 11 May 2011 09:07:24 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13915E07C2 for ; Wed, 11 May 2011 09:07:23 -0700 (PDT)
Received: by yxk30 with SMTP id 30so275928yxk.31 for ; Wed, 11 May 2011 09:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5SYtNtuhLCdQTX7DstI0K28P9yv0NuvJadIyLhmnqtc=; b=AH4juEnjNxLTyFuCLmtetPmR7jfkVAWbpLux0gYNT4HVKQzlW3NXcyUVbJsEaiuVlg cF1JDJlS/2094a3jFPxGEvEC/H2peHZhs6TSG4HdXXaS1MfevFJyEV9NMJKhgI8Hnk6N OavlRoYAJG1J6SZhbO8bhyhQdyPkOweGhBOQY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aBbWF3ER17DrbtFKhJKzJE2GgOpOcm4Wm21T0dcmMXXQdlQpN4u/q5VhkVgNru/x10 AlVhI8Ci9GL+RKAmGknSi894TQo7pe0i3Mgd2RP473jlMqnxe2FcVbneH5Ll4108tgJ6 Zp4wyHUiCRV1wTDavgsGpTMZ2e+rHS2hQBIyw=
MIME-Version: 1.0
Received: by 10.150.73.41 with SMTP id v41mr8440384yba.106.1305130043372; Wed, 11 May 2011 09:07:23 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 09:07:22 -0700 (PDT)
In-Reply-To: <34096E38-A149-4B7C-A289-0124EF113BC4@vpnc.org>
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com> <34096E38-A149-4B7C-A289-0124EF113BC4@vpnc.org>
Date: Wed, 11 May 2011 12:07:22 -0400
X-Google-Sender-Auth: NNg87RL15oXPpIAStq2VKQ0z2j0
Message-ID: 
From: Barry Leiba 
To: Paul Hoffman 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 16:07:24 -0000

>>>>>> I think this definition is not correct. =A0"A way that humans intera=
ct" is
>>>>>> too generalized. =A0I suppose the following definition would suit be=
tter here.
>>>>>>
>>>>> Your definition is too limiting. Clearly, we are not only talking abo=
ut
>>>>> speech.
>>>>>
>>>> Agreed; but the current isn't appropriate as well. =A0Considering a la=
nguage
>>>> being the humans interaction way is correct in its concept, but I thin=
k we
>>>> should think about more exact definition.
>>>>
>>> I don't. =A0I think the text is fine as it is, and we should stop
>>> pushing on this point and leave it alone. =A0[The only change I can see
>>> supporting is inserting "verbal" before "way". =A0But there are
>>> non-verbal languages, as well.]
>>>
>> Adding "verbal" seems fine to me; this will clarify the definition a bit=
.
>
> As Barry said, there are non-verbal languages as well. As co-author of th=
is
> document, I would be very hesitant to disqualify the languages used by te=
ns
> (maybe hundreds) of millions of people with this change unless the WG has
> a good reason to do so.

This, plus Andrew's opposition, and the fact that there's been no
other call for changing the definition of "Language" here, leads me to
make the chair declaration that this is decided: the text remains as
it stands.

Barry, as chair

From jyee@afilias.info  Wed May 11 09:08:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1CE07DA for ; Wed, 11 May 2011 09:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxhDNSQAGe3o for ; Wed, 11 May 2011 09:08:33 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id D8DD3E07C2 for ; Wed, 11 May 2011 09:08:32 -0700 (PDT)
Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QKBxg-0002qr-3J for apps-discuss@ietf.org; Wed, 11 May 2011 16:08:32 +0000
Received: from mail-gw0-f50.google.com ([74.125.83.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QKBxf-0000Lh-8t for apps-discuss@ietf.org; Wed, 11 May 2011 16:08:31 +0000
Received: by gwj16 with SMTP id 16so226884gwj.9 for ; Wed, 11 May 2011 09:08:31 -0700 (PDT)
Received: by 10.91.198.23 with SMTP id a23mr7928007agq.45.1305130109919; Wed, 11 May 2011 09:08:29 -0700 (PDT)
Received: from jyee-lt.tor.afilias-int.info (tor-gateway.afilias.info [199.15.87.4]) by mx.google.com with ESMTPS id d36sm120088and.30.2011.05.11.09.08.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 09:08:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee 
In-Reply-To: <20110511142516.GA4578@crankycanuck.ca>
Date: Wed, 11 May 2011 12:08:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <50B99149-A579-4E96-8C4C-1E86C5B7FC08@afilias.info>
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com> <20110511142516.GA4578@crankycanuck.ca>
To: Andrew Sullivan 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 16:08:33 -0000

On 2011-05-11, at 10:25 AM, Andrew Sullivan wrote:

> On Wed, May 11, 2011 at 01:58:57PM +0300, Mykyta Yevstifeyev wrote:
>>> pushing on this point and leave it alone.  [The only change I can =
see
>>> supporting is inserting "verbal" before "way".  But there are
>>> non-verbal languages, as well.]
>> Adding "verbal" seems fine to me; this will clarify the definition a =
bit.
>=20
> I am strongly opposed to the qualification "verbal".  It's flat out =
wrong.
>=20
> A

+1, Strong oppose to "verbal", and support to replace "interact" to =
"communicate"

The definition of language is to make a generic term for all kinds of =
communication and then narrow down to writing related terminologies =
(script, writing system, character, etc).

Joseph

>=20
> --=20
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From alexey.melnikov@isode.com  Wed May 11 10:01:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C6FE0864 for ; Wed, 11 May 2011 10:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.166
X-Spam-Level: 
X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D56Aok14DACC for ; Wed, 11 May 2011 10:01:10 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2692CE0819 for ; Wed, 11 May 2011 10:01:09 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Wed, 11 May 2011 18:01:08 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4DCAC0AC.80001@isode.com>
Date: Wed, 11 May 2011 18:00:28 +0100
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: dcrocker@bbiw.net
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9A9B9.3010702@stpeter.im> <4DCAAAB9.3080702@dcrocker.net>
In-Reply-To: <4DCAAAB9.3080702@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:01:10 -0000

Dave CROCKER wrote:

> On 5/10/2011 2:10 PM, Peter Saint-Andre wrote:
>
>> On 5/10/11 8:45 AM, Dave CROCKER wrote:
>>
>>> Your note suggests that, at the least, the text of a Last Call 
>>> should make
>>> much more clear what sorts of comments are being sought (and why and
>>> probably from whom.)  The community should not have to guess what 
>>> sorts of
>>> responses are useful for the IESG.
>>
>> FWIW, over in the XMPP Standards Foundation (xmpp.org) we ask the 
>> following
>> questions in each of our Last Call announcements:
>
> It has the considerable benefit of guiding the respondent to provide 
> pragmatic
> detail.
>
> The IETF would do well to include some form of similar guidance in its 
> Last Call
> announcement.

+1.

> On 5/10/2011 6:15 PM, Barry Leiba wrote:
>
>>>> #    Please consider the following questions during this Last Call 
>>>> and #
>>>> send your feedback to the standards@xmpp.org discussion list: # 
>>>> #    1.
>>>> Is this specification needed to fill gaps in the XMPP #       protocol
>>>> stack or to clarify an existing protocol? #    2. Does the 
>>>> specification
>>>> solve the problem stated in the #       introduction and 
>>>> requirements? #
>>>> 3. Do you plan to implement this specification in your code? 
>>>> #       If
>>>> not, why not? #    4. Do you have any security concerns related to 
>>>> this
>>>> specification? #    5. Is the specification accurate and clearly
>>>> written?
>>>>
>>>> Whether that's the right set of questions is another issue...
>>>
>>> This, and especially that last one, makes it sound like a PROTO 
>>> write-up.
>>> Are you sure you want that from a potentially huge list of people?
>>
>> Interesting: I think the last question is the *most* important, and 
>> the one
>> that *least* seems like it came out of a PROTO write-up.  Yes, that's 
>> the
>> question I *do* most want to see *all* reviews answer.
>
> Whereas I think each of these questions is quite important, with the 
> last one
> likely to get the most pro-forma responses, since it is the most 
> difficult to
> answer knowledgeably.

+1.


From presnick@qualcomm.com  Wed May 11 10:05:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB04E0866 for ; Wed, 11 May 2011 10:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gryVKH1v97v6 for ; Wed, 11 May 2011 10:05:20 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1F901E0864 for ; Wed, 11 May 2011 10:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305133520; x=1336669520; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCAC1CB.3050905@qualcomm.com>|Date:=20We d,=2011=20May=202011=2012:05:15=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Apps=20Discuss=20|Subject:=20Applicability=20Statements |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=J5r/TgyMMVuqOxhbn1VSjfGlykoo9XJ7NJEtji86Wjc=; b=NJ4PQCbugsOyXnhmPApjUtfW98lV5gI25lTZpwko8XNfHPk8dJWZqK+y F8lmR99ii11/tkNtaK/GOF7kJPN05Ob29xtsMGgmCZ7xaxH+L56WyNAQn Jo3gIQg8YMXXtQJgTNFsVvksYMh1+btgenM53z32Lx+v96qLR1jfqNYte A=;
X-IronPort-AV: E=McAfee;i="5400,1158,6342"; a="90609806"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 11 May 2011 10:05:19 -0700
X-IronPort-AV: E=Sophos;i="4.64,353,1301900400"; d="scan'208";a="104657012"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 May 2011 10:05:19 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 10:05:19 -0700
Message-ID: <4DCAC1CB.3050905@qualcomm.com>
Date: Wed, 11 May 2011 12:05:15 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Apps Discuss 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Subject: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:05:22 -0000

At the IESG Retreat, we had a discussion on how we publish 
implementation advice, conformance specifications, protocol profiles, 
and the like. Right now, we often put these sorts of things in BCP or 
Informational documents. Unfortunately, these are both second class 
citizens in our document series: They don't get published as "standards" 
and they can't be reviewed and progressed along the standards track even 
though they often have information that we want to review for success.

There is a way to deal with these sorts of documents that we haven't 
tried in a very long time: RFC 2026 defines two kinds of standards track 
documents: Technical Specifications (TS), which we publish all of the 
time, and Applicability Statements (AS), which we haven't. According to 
2026, an AS can be any of the following:

     "identifies the relevant TSs and the specific way in which they are 
to be combined"
     "specify particular values or ranges of TS parameters or 
subfunctions of a TS protocol that must be implemented"
     "specifies the circumstances in which the use of a particular TS is 
required, recommended, or elective"
     "describe particular methods of using a TS in a restricted 'domain 
of applicability'"
     "comprehensive conformance specification"

That sounds to me like exactly what we're trying to do. And an AS can be 
standards track, so long as it is at the same or lower maturity level 
than any of the TSs it references, so it can get full standards track 
treatment.

So, here's my proposal, which I've already gotten some positive feedback 
from the chairs of WGs that I cover in the apps area, and which the IESG 
has agreed to go along with: For my WGs in the apps area, we're going to 
try an informal experiment and submit documents like the above to the 
IESG for Proposed Standard AS. (I already have two such documents in 
mind: The potential MARF "BCP" and the the Malformed Header document.) 
Other ADs may join in, but I'll at least start the ball rolling. I'll 
try to get some early feedback from IESG folks as we get some I-Ds 
together to sanity check, and with any luck we'll get a few of these 
published as Proposed Standard. Then the IESG can talk about the 
criteria for advancement. However it works out, the worst case will be 
that we back off and publish these things as BCP or Informational 
instead, but I'm hopeful. After we get some experience, we'll see where 
else the use of AS might make sense.

What do folks think?

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From john@jck.com  Wed May 11 10:16:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03318E073C for ; Wed, 11 May 2011 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDtz3Vq1u4RO for ; Wed, 11 May 2011 10:16:04 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1FE0867 for ; Wed, 11 May 2011 10:16:04 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKD10-000GC7-Bb; Wed, 11 May 2011 13:16:02 -0400
Date: Wed, 11 May 2011 13:16:01 -0400
From: John C Klensin 
To: Pete Resnick , Apps Discuss 
Message-ID: <653ADDA5F1A34D89FA899549@PST.JCK.COM>
In-Reply-To: <4DCAC1CB.3050905@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:16:05 -0000

--On Wednesday, May 11, 2011 12:05 -0500 Pete Resnick
 wrote:

> At the IESG Retreat, we had a discussion on how we publish
> implementation advice, conformance specifications, protocol
> profiles, and the like. Right now, we often put these sorts of
> things in BCP or Informational documents. Unfortunately, these
> are both second class citizens in our document series: They
> don't get published as "standards" and they can't be reviewed
> and progressed along the standards track even though they
> often have information that we want to review for success.
>
> There is a way to deal with these sorts of documents that we
> haven't tried in a very long time: RFC 2026 defines two kinds
> of standards track documents: Technical Specifications (TS),
> which we publish all of the time, and Applicability Statements
> (AS), which we haven't. According to 2026, an AS can be any of
> the following:
>...
 > So, here's my proposal, which I've already gotten some
> positive feedback from the chairs of WGs that I cover in the
> apps area, and which the IESG has agreed to go along with: For
> my WGs in the apps area, we're going to try an informal
> experiment and submit documents like the above to the IESG for
> Proposed Standard AS. (I already have two such documents in
> mind: The potential MARF "BCP" and the the Malformed Header
> document.) Other ADs may join in, but I'll at least start the
> ball rolling. I'll try to get some early feedback from IESG
> folks as we get some I-Ds together to sanity check, and with
> any luck we'll get a few of these published as Proposed
> Standard. Then the IESG can talk about the criteria for
> advancement. However it works out, the worst case will be that
> we back off and publish these things as BCP or Informational
> instead, but I'm hopeful. After we get some experience, we'll
> see where else the use of AS might make sense.
> 
> What do folks think?

Pete,

I think this is entirely sensible.  I've felt for some time that
we have underutilized the AS option.  Sometimes we incorporate
AS elements into a TS, but it has been a long time since they
have been done standalone.  You didn't mention it explicitly,
but use of AS documents eliminates another issue that has
annoyed lots of people about some BCPs: An AS is entirely
appropriate for recommendations about what we think is the least
bad thing to do under some set of circumstances.  When we make
that sort of recommendation in a BCP, we expose ourselves to the
criticism that the recommendation is neither best (as distinct
from a bad compromise), nor current (as distinct from a
recommendation about future behavior), nor actively practiced.

So, from my point of view, go for it.   And my thanks to you and
the IESG for being willing to try this out.

    john


From dhc@dcrocker.net  Wed May 11 10:24:40 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94821E0867 for ; Wed, 11 May 2011 10:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2V4iIVTtPSD for ; Wed, 11 May 2011 10:24:39 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA3DCE0866 for ; Wed, 11 May 2011 10:24:39 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4BHOXBF016920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 11 May 2011 10:24:39 -0700
Message-ID: <4DCAC64D.2090207@dcrocker.net>
Date: Wed, 11 May 2011 10:24:29 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com>	<4DC77648.1040903@gmail.com>	<8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org>	<4DC9499C.1060409@gmail.com>		<4DCA6BF1.4010702@gmail.com>	<20110511142516.GA4578@crankycanuck.ca> <50B99149-A579-4E96-8C4C-1E86C5B7FC08@afilias.info>
In-Reply-To: <50B99149-A579-4E96-8C4C-1E86C5B7FC08@afilias.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 May 2011 10:24:39 -0700 (PDT)
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2011 17:24:40 -0000

> +1, Strong oppose to "verbal", and support to replace "interact" to
> "communicate"
>
> The definition of language is to make a generic term for all kinds of
> communication and then narrow down to writing related terminologies (script,
> writing system, character, etc).


Correct.

Throughout this thread, people seem to be confusing "verbal" with "oral".  The
latter refers to speech.  Formally, the former is about verbs; that is, words.
So, for example, sign languages are verbal.

That said, the confusion is common enough to represent an emerging change in the
language to produce an equivalence of the words.

(See 3rd definition:  http://dictionary.reference.com/browse/verbal)


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From barryleiba.mailing.lists@gmail.com  Wed May 11 11:01:50 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A2E076D for ; Wed, 11 May 2011 11:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.549
X-Spam-Level: 
X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGmLKXsVEfAD for ; Wed, 11 May 2011 11:01:49 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99948E089E for ; Wed, 11 May 2011 11:01:49 -0700 (PDT)
Received: by yxk30 with SMTP id 30so323774yxk.31 for ; Wed, 11 May 2011 11:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bkiY3sgWboGfy7ynnscVPXTYgdk7+D18q2+uU8KqstY=; b=Zl+rZ3lk2pGGBu4sAsRHby4eERDuDV3AWpkdRToaRUgkaFP4FnS1Z2ZyT6/1nXpomE PXiQrE7WTyeGx6moDBVPWWrP5yjPjjx/Rb23p88ETD9tNtN9O/XYxzs1x4TuAkSZaLPD PlU/pru6oBaBV7FPl0lHEmIRGZPje4obzhezI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZqFPB7HSSuVS1Q85OLOmjAUj5mIrbOR2oyDmXICE9LSFvsL0NV6esqhaCtvzZoOrps SMn7b3Cae2H9yT45XiiWCizP4gr88lWOPK4y1C132CRgkp41rFZChd8MwAE0w2j+R27l bxGfIms9iED/Wa9gDG0JrGY1HyF5/JIASL8H0=
MIME-Version: 1.0
Received: by 10.236.154.199 with SMTP id h47mr11835359yhk.149.1305136908993; Wed, 11 May 2011 11:01:48 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 11:01:48 -0700 (PDT)
In-Reply-To: <4DCAC64D.2090207@dcrocker.net>
References: <20110506220130.29448.74168.idtracker@ietfa.amsl.com> <4DC77648.1040903@gmail.com> <8678291D-9406-4BCB-AA41-E0F131B4E38F@vpnc.org> <4DC9499C.1060409@gmail.com>  <4DCA6BF1.4010702@gmail.com> <20110511142516.GA4578@crankycanuck.ca> <50B99149-A579-4E96-8C4C-1E86C5B7FC08@afilias.info> <4DCAC64D.2090207@dcrocker.net>
Date: Wed, 11 May 2011 14:01:48 -0400
X-Google-Sender-Auth: 8bQpP3eCyxNhhNX6u92sms8zCqA
Message-ID: 
From: Barry Leiba 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:01:50 -0000

> Throughout this thread, people seem to be confusing "verbal" with "oral".

When I suggested "verbal", I specifically meant "in words", not
"oral".  But there's objection to making that change, and I don't
think there's value in messing with the definition in the doc at that
level.

Barry

From barryleiba.mailing.lists@gmail.com  Wed May 11 11:04:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E99E076D for ; Wed, 11 May 2011 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.491
X-Spam-Level: 
X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36ehmrSMu9vI for ; Wed, 11 May 2011 11:04:31 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7585CE066E for ; Wed, 11 May 2011 11:04:31 -0700 (PDT)
Received: by ywi6 with SMTP id 6so324557ywi.31 for ; Wed, 11 May 2011 11:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UPTXGHk4q5Ejv79eE9Q2VZyG19wMAQYgwo/XzSegj/o=; b=Mef3rBnXrpkm46NW6d1UdfFSlkB/F4l4FKfUjvX217uWGnQ2exV+Qut5HjCWWu3g3h DX9Aq3k33dFvvY2dMKy80nAEiItppCkF3pVSoYTgDm+3p7cupHS963UETq0Abh2j2PQL 6QbCMIYdqNTWT03d/ptvTh9c9dFsipZKU50Pc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qOhTWN0aYsWXUILj5NX+o34x+//0OSpJqC98BTv1ETEyZGVifMDV+IsKzy3ADfb8VF yX34F+SExwMzckoOshXtlcYK319oxRyH2vMpVAM6znL2WVL2nR3VSxGeCXbnzRDphZ8T PTsExXx79OUB+mbaFkCVjTYYAuar5eg/3TwWo=
MIME-Version: 1.0
Received: by 10.236.191.71 with SMTP id f47mr10790103yhn.15.1305137070542; Wed, 11 May 2011 11:04:30 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 11:04:30 -0700 (PDT)
In-Reply-To: <653ADDA5F1A34D89FA899549@PST.JCK.COM>
References: <4DCAC1CB.3050905@qualcomm.com> <653ADDA5F1A34D89FA899549@PST.JCK.COM>
Date: Wed, 11 May 2011 14:04:30 -0400
X-Google-Sender-Auth: sd6X217y8GGYno4rNpQ5VTejzQM
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:04:32 -0000

> I think this is entirely sensible. =A0I've felt for some time that
> we have underutilized the AS option. =A0Sometimes we incorporate
> AS elements into a TS, but it has been a long time since they
> have been done standalone. =A0You didn't mention it explicitly,
> but use of AS documents eliminates another issue that has
> annoyed lots of people about some BCPs: An AS is entirely
> appropriate for recommendations about what we think is the least
> bad thing to do under some set of circumstances. =A0When we make
> that sort of recommendation in a BCP, we expose ourselves to the
> criticism that the recommendation is neither best (as distinct
> from a bad compromise), nor current (as distinct from a
> recommendation about future behavior), nor actively practiced.

This is exactly what I'd have said if John hadn't said it.  Or, put
another way, "I support the publi...."  No, wait.  Um.

Yes, let's go ahead with it.

Barry

From sm@resistor.net  Wed May 11 12:33:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E48E07F1 for ; Wed, 11 May 2011 12:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZuGPrYWbvD0 for ; Wed, 11 May 2011 12:33:05 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1562E088E for ; Wed, 11 May 2011 12:33:02 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4BJWo2r001263;  Wed, 11 May 2011 12:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1305142379; bh=k7iftnnsPNulZJV1S8QrtVCYwD3XOUN43m2L6S0ZKvw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=ZwyX1MkXhlTV4JphgtqzmwSy6+jf3Mc3vZMmRBMQJFtvJThtvfzdBuiU+TDLq0Lj6 CgRHelvtbtjFfyxVkYX0z8PCLRnBQyBf+VpfcqMhVE6UxGY7jHK4gZG1Rd7D0SBboV y/KaEsmVQg/Ci+3HUmtXbzfmeRBdBb/miCBI6d50=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1305142379; bh=k7iftnnsPNulZJV1S8QrtVCYwD3XOUN43m2L6S0ZKvw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=bV6ZxtcYTMMJQ3+Wlc+4NFL7Kp7ZNYLk0cubbaCTaHW2EkwDRHn/QmzCtj81hNXDZ llD1zKV1sdiXoLPfypZ/u3AEe30jON2hl7P9UGZIF2bpD2EymuUAO+DoaKLyZVKmkV kmuZbWXQWHi2bo/FcBD9qenx5ftW0XbU5gwwAihI=
Message-Id: <6.2.5.6.2.20110511115259.051cd3f8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 11 May 2011 12:32:01 -0700
To: Pete Resnick 
From: SM 
In-Reply-To: <4DCAC1CB.3050905@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 19:33:06 -0000

Hi Pete,
At 10:05 11-05-2011, Pete Resnick wrote:
>There is a way to deal with these sorts of documents that we haven't 
>tried in a very long time: RFC 2026 defines two kinds of standards 
>track documents: Technical Specifications (TS), which we publish all 
>of the time, and Applicability Statements (AS), which we haven't. 
>According to 2026, an AS can be any of the following:
>
>     "identifies the relevant TSs and the specific way in which they 
> are to be combined"
>     "specify particular values or ranges of TS parameters or 
> subfunctions of a TS protocol that must be implemented"
>     "specifies the circumstances in which the use of a particular 
> TS is required, recommended, or elective"
>     "describe particular methods of using a TS in a restricted 
> 'domain of applicability'"
>     "comprehensive conformance specification"
>
>That sounds to me like exactly what we're trying to do. And an AS 
>can be standards track, so long as it is at the same or lower 
>maturity level than any of the TSs it references, so it can get full 
>standards track treatment.
>
>So, here's my proposal, which I've already gotten some positive 
>feedback from the chairs of WGs that I cover in the apps area, and 
>which the IESG has agreed to go along with: For my WGs in the apps 
>area, we're going to try an informal experiment and submit documents 
>like the above to the IESG for Proposed Standard AS. (I already have 
>two such documents in mind: The potential MARF "BCP" and the the 
>Malformed Header document.) Other ADs may join in, but I'll at least 
>start the ball rolling. I'll try to get some early feedback from 
>IESG folks as we get some I-Ds together to sanity check, and with 
>any luck we'll get a few of these published as Proposed Standard. 
>Then the IESG can talk about the criteria for advancement. However 
>it works out, the worst case will be that we back off and publish 
>these things as BCP or Informational instead, but I'm hopeful. After 
>we get some experience, we'll see where else the use of AS might make sense.

This is like two ADs and a lamb voting on what to have for lunch. :-)

I like the idea on the grounds that BCP has more value if it 
documents best (existing) current practices instead of what we 
believe should be best practice.  RFC 4130 is an example of what is 
discussed above.

Regards,
-sm 


From john-ietf@jck.com  Wed May 11 13:37:13 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15EE07BA for ; Wed, 11 May 2011 13:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptkd3Yi3x1nh for ; Wed, 11 May 2011 13:37:08 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE88E0693 for ; Wed, 11 May 2011 13:37:08 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKG9V-000J8p-P0; Wed, 11 May 2011 16:37:01 -0400
Date: Wed, 11 May 2011 16:37:00 -0400
From: John C Klensin 
To: Barry Leiba , Pete Resnick 
Message-ID: <2B12C8610935B58EA60D9ADC@PST.JCK.COM>
In-Reply-To: 
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net>	<4DC9688B.3070701@qualcomm.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:37:13 -0000

--On Tuesday, May 10, 2011 15:46 -0400 Barry Leiba
 wrote:

>...
> As I said in my off-list note to you, simply the fact that I
> read the document (or, at least, claimed to) and took the time
> to send a comment should be enough to give you valuable
> information -- it's absolutely NOT "useless".  I appreciate
> that you might *also* like more than that, and if I have more
> than that to say, I will.  But the idea that the IESG might
> ignore such comments as "useless" gives me more than a bit of
> fright.

Barry,

>From my point of view, Pete is being explicit, and offering to
be consistent, about something that, to some degree, I think
most ADs do at one thing or another.    Both "explicit" and
"consistent" are good, at least IMO.  In less explicit form, ADs
figure out that, in measuring consensus about the technical
quality of a document, its interactions (or lack thereof) with
other work and protocols, etc., informed opinions from experts
who have studied a document carefully are simply worth more
than, to state the extreme case, endorsements from the clueless.
Most of the time (I hope), when the IESG is doing a technical
evaluation, they are looking at comments and criticisms
(positive or negative), not counting the number of those
comments.  One well-reasoned analysis that identifies a
persuasive showstopper should, and usually does, stop a document
until the problem is remedied no matter how many people say "I
didn't notice any problems".  Worse (and this is where my view
aligns with Ted's "context" comments), unless the practical
definition of "expert" is "someone whom the AD already considers
an expert", people need to give the AD a clue that their
comments should be taken seriously and the best clue is a
carefully-written review statement.  By contrast, "I like it"
isn't a very good clue, one way or the other.

A distinction I don't think Pete made is that the IESG is called
upon to evaluate and determine consensus, not just about
technical quality and relationships, but about interest (and,
ideally, commitment).  Those two determinations are almost
orthogonal.  For the purpose of determining consensus about
interest, a statement such as "I like this and think it should
be published" is actually very helpful, especially for a non-WG
document (for a WG document, there is a presumption of interest
and commitment that arises from getting chartered).  

So, I wouldn't have said "useless".  I might have said "of very
limited value in helping the IESG with its determination of
consensus about technical quality and adequacy of review".

   john





From brian.e.carpenter@gmail.com  Wed May 11 13:44:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F970E084F for ; Wed, 11 May 2011 13:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEDlXwUaOGfZ for ; Wed, 11 May 2011 13:44:17 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2258E079B for ; Wed, 11 May 2011 13:44:17 -0700 (PDT)
Received: by pvh1 with SMTP id 1so553440pvh.31 for ; Wed, 11 May 2011 13:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z+sqkveCvBvGNKS3gV63zQZu49E/bqmXvW8iRztEGzU=; b=W5+S0D7U1c3Mfty9FNCFGaDt4d5Ot2Zf2VpRLrkG4qZEtOQFePJhUA8ARfrKrBS2Y+ 1RbAWokdfAY+5bxZqA1Q30Q0iQpjT58lOEKohD1zI1L6SJCOML2sCC5tUgecrvza/HBE EuDf8rAA4Sb1r8gD0wyfn+AFAT/KojeHGJri0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nN3yoRUPNejkly7GtvzDhmWqZuDB8rciauOXI8iDiCv+0lzmcjCbFqqDcqrTTGeV+y +Irzi1q+0sboNFgoFhC+4hliEvAOWapL8dz+3bJEZHIrP82FjD6uVf2yMIA2KR7DK/W3 24IhcwfJnmLggxPGpVPHG2t0WJ7wuYM9yGeV4=
Received: by 10.68.28.137 with SMTP id b9mr4972260pbh.191.1305146657378; Wed, 11 May 2011 13:44:17 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l7sm192497pbo.44.2011.05.11.13.44.12 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 13:44:16 -0700 (PDT)
Message-ID: <4DCAF507.5030508@gmail.com>
Date: Thu, 12 May 2011 08:43:51 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Barry Leiba 
References: <4DCAC1CB.3050905@qualcomm.com>	<653ADDA5F1A34D89FA899549@PST.JCK.COM> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , John C Klensin , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:44:18 -0000

On 2011-05-12 06:04, Barry Leiba wrote:
>> I think this is entirely sensible.  I've felt for some time that
>> we have underutilized the AS option.  Sometimes we incorporate
>> AS elements into a TS, but it has been a long time since they
>> have been done standalone.  You didn't mention it explicitly,
>> but use of AS documents eliminates another issue that has
>> annoyed lots of people about some BCPs: An AS is entirely
>> appropriate for recommendations about what we think is the least
>> bad thing to do under some set of circumstances.  When we make
>> that sort of recommendation in a BCP, we expose ourselves to the
>> criticism that the recommendation is neither best (as distinct
>> from a bad compromise), nor current (as distinct from a
>> recommendation about future behavior), nor actively practiced.
> 
> This is exactly what I'd have said if John hadn't said it.  Or, put
> another way, "I support the publi...."  No, wait.  Um.
> 
> Yes, let's go ahead with it.

+1. I would recommend it to all Areas in fact, but it's good for
somebody to start.

   Brian

From stpeter@stpeter.im  Wed May 11 13:47:06 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC3E0868 for ; Wed, 11 May 2011 13:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ9xzLPGn+mF for ; Wed, 11 May 2011 13:47:05 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5871AE0866 for ; Wed, 11 May 2011 13:47:05 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 08777400A6; Wed, 11 May 2011 14:47:03 -0600 (MDT)
Message-ID: <4DCAF5C6.6070806@stpeter.im>
Date: Wed, 11 May 2011 14:47:02 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4DCAC1CB.3050905@qualcomm.com>	<653ADDA5F1A34D89FA899549@PST.JCK.COM>	 <4DCAF507.5030508@gmail.com>
In-Reply-To: <4DCAF507.5030508@gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020702040406020608000901"
Cc: Pete Resnick , John C Klensin , Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:47:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms020702040406020608000901
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/11/11 2:43 PM, Brian E Carpenter wrote:
> On 2011-05-12 06:04, Barry Leiba wrote:
>>> I think this is entirely sensible.  I've felt for some time that
>>> we have underutilized the AS option.  Sometimes we incorporate
>>> AS elements into a TS, but it has been a long time since they
>>> have been done standalone.  You didn't mention it explicitly,
>>> but use of AS documents eliminates another issue that has
>>> annoyed lots of people about some BCPs: An AS is entirely
>>> appropriate for recommendations about what we think is the least
>>> bad thing to do under some set of circumstances.  When we make
>>> that sort of recommendation in a BCP, we expose ourselves to the
>>> criticism that the recommendation is neither best (as distinct
>>> from a bad compromise), nor current (as distinct from a
>>> recommendation about future behavior), nor actively practiced.
>>
>> This is exactly what I'd have said if John hadn't said it.  Or, put
>> another way, "I support the publi...."  No, wait.  Um.
>>
>> Yes, let's go ahead with it.
>=20
> +1. I would recommend it to all Areas in fact, but it's good for
> somebody to start.

Pete dreamed this up as something we could try in the Applications Area,
and I'm on board with it. Once we have some practical results to show to
other area directors, we might convince them to try it, too.

Peter

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




--------------ms020702040406020608000901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MTIwNDcwMlowIwYJKoZIhvcNAQkEMRYEFMOrJ/gPHZr22sMQnM0npd11ZfO8MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQACjhZCpZqiXmNPN3DY/R3eSYmBCGI89fGjue5g5i0qYdLh//eOQk5ow10b
Tkxo/muaI8nglxNlQKPR8kotgBwKPCXQkUYCJU7Uf43CbxrLtYz1CMCzLQEVf99/CsfYmJRe
5gqSHnzIDN2HYVyeIpxlOMEGCEYkpfeFAms3E/qP8rMvknMWBjOA+bw7JvUi9TN8wMjLyMj+
nhkf2xRfeRvnRPsAaYI4JcfZWFZwN31LnT+rlwouhhs1AXJe8RCB01wEW8EuXRZLnW+zB8VQ
FMrjKX8c2Zv/GG2UvHfKbiS4PW5ZYXW/NNOy2CprlTMT2fIhTddlaNPflnu0t3goRay/AAAA
AAAA
--------------ms020702040406020608000901--

From presnick@qualcomm.com  Wed May 11 13:48:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E682E084F for ; Wed, 11 May 2011 13:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deIRr6yudHmR for ; Wed, 11 May 2011 13:48:37 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id CA8CAE079B for ; Wed, 11 May 2011 13:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305146917; x=1336682917; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCAF61F.10000@qualcomm.com>|Date:=20Wed, =2011=20May=202011=2015:48:31=20-0500|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20SM=20|CC:=20A pps=20Discuss=20|Subject:=20Re:=20 [apps-discuss]=20Applicability=20Statements|References: =20<4DCAC1CB.3050905@qualcomm.com>=20<6.2.5.6.2.201105111 15259.051cd3f8@resistor.net>|In-Reply-To:=20<6.2.5.6.2.20 110511115259.051cd3f8@resistor.net>|Content-Type:=20text/ plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=oJKzx6KwkQCmJvjsk03L7OMjfbIgtPxGLdFzV+bIZD0=; b=oUiKbkQLdUNB3qE0zRZI3xBaQMVmeqg0ezbszGNQYlZSL12i/gHl/BWp G6GT4W77tZwiNfeCxwTjypJnbH/QC6LZeLF74TRf3xiCp3lM/ietZkz3y 5Vs7bgN32z0u72jnonkP8fblCYZwTYZQ/fCrgv5HXFuolS11JrMFJFYbp Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,6343"; a="90657795"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 11 May 2011 13:48:37 -0700
X-IronPort-AV: E=Sophos;i="4.64,353,1301900400"; d="scan'208";a="139056955"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 May 2011 13:48:37 -0700
Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 13:48:33 -0700
Message-ID: <4DCAF61F.10000@qualcomm.com>
Date: Wed, 11 May 2011 15:48:31 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: SM 
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net>
In-Reply-To: <6.2.5.6.2.20110511115259.051cd3f8@resistor.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:48:38 -0000

On 5/11/11 2:32 PM, SM wrote:
> This is like two ADs and a lamb voting on what to have for lunch. :-)

Smiley face understood but:

We have no lambs in this organization. Or wolves. Or kings. Or better 
yet, we are *all* all of those things.

I asked for thoughts. I take them seriously. What makes the IETF a good 
place to work is that it's full of people much smarter than me.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From barryleiba.mailing.lists@gmail.com  Wed May 11 14:06:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3219E079B for ; Wed, 11 May 2011 14:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.044
X-Spam-Level: 
X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax+Rfg+oo-D1 for ; Wed, 11 May 2011 14:06:36 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 380CFE06AE for ; Wed, 11 May 2011 14:06:36 -0700 (PDT)
Received: by gwb20 with SMTP id 20so393548gwb.31 for ; Wed, 11 May 2011 14:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=22F29FESOK/hA6k7cwS+qtLdI76G45/38ZVfmXL2d1k=; b=dT/IGn51EMcpTtAuGXlxSK5AUQdq4kaTQ/49F7AbZglGskl62akdkqwZCMoAO2v66w IGY0ncQpXJooovghu+JLEPdguoUVA7pdFvoC8lfzh9zn+LfB3vhZbiNWkMibBOKxCiaq hr0yW9PqWHH7el4a+gxbfWz9Ason06rr9Bfm4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jCnTMzAAhTiUPWVUcR9IfYyJN196DZCZ27ywka1myuJFU8tX8EZX7ClvoVFbVLzAVT tUBt0ArNJg6nmfpd9FN7asE9/yHpzVbQr+nPSpdXkGX8Z8t7VJ1HMwwOGAWpwXhgwGOA pDMez0xMgVaL37q9kY3ZQ44O3cRDLqN6zJ/3k=
MIME-Version: 1.0
Received: by 10.150.73.41 with SMTP id v41mr8724483yba.106.1305147995409; Wed, 11 May 2011 14:06:35 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 14:06:35 -0700 (PDT)
In-Reply-To: <2B12C8610935B58EA60D9ADC@PST.JCK.COM>
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <2B12C8610935B58EA60D9ADC@PST.JCK.COM>
Date: Wed, 11 May 2011 17:06:35 -0400
X-Google-Sender-Auth: 70SG9ckOdejOI_zgx_g4BCPenvc
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Pete Resnick , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:06:36 -0000

> figure out that, in measuring consensus about the technical
> quality of a document, its interactions (or lack thereof) with
> other work and protocols, etc., informed opinions from experts
> who have studied a document carefully are simply worth more
> than, to state the extreme case, endorsements from the clueless.
> Most of the time (I hope), when the IESG is doing a technical
> evaluation, they are looking at comments and criticisms
> (positive or negative), not counting the number of those
> comments.

OK.  I hadn't looked at Pete's comments that way, and I certainly
agree with this.

Barry

From dhc@dcrocker.net  Wed May 11 14:10:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF2E079B for ; Wed, 11 May 2011 14:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK0cucVzjs8S for ; Wed, 11 May 2011 14:10:13 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 660B3E06AE for ; Wed, 11 May 2011 14:10:12 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4BLA6M0021815 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 14:10:11 -0700
Message-ID: <4DCAFB2A.8030408@dcrocker.net>
Date: Wed, 11 May 2011 14:10:02 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Pete Resnick 
References: <4DC88255.3070403@qualcomm.com>	<4DC94F74.30905@dcrocker.net>	<4DC9688B.3070701@qualcomm.com>	 <4DC9A557.9040504@qualcomm.com>
In-Reply-To: <4DC9A557.9040504@qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 May 2011 14:10:12 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 May 2011 21:10:31 -0000

On 5/10/2011 1:51 PM, Pete Resnick wrote:
> But getting rid of process abusers is only a secondary goal here. Really my
> point is, I want us all to get in the habit of taking responsibility for
> documents; to not assume that the AD is going to be the final backstop, but
> instead assuming that the AD may be a dope and needs this stuff explained to him
> or her.


Your original line of comment started with the negative of what you aren't 
lokking for.  I think this whole discussion gets much more constructive by 
starting with a statement like the above.  It says what you /are/ looking for, 
and it declares a goal with a broad, basic benefit.

Taking responsibility requires establishing one's involvement.  Within an 
on-going working group discussion, a context exists and a "+1" is an efficient 
tool within that.  (Note that a review tends to start with a factual summary of 
what is being reviews; this establishes that the reviewer has enough 
understanding to offer an opinion.)

For a Last Call, there typically is no such context for most of the folk 
submitting an opinion. Therefore, each person submitting an opinion should 
assume that the first requirement is to establish the basis for their 
involvement, knowledge, interest, or the like in the paper.

No doubt there are a few IETF Well-Known Culprits (WKC) who might respond to one 
person's posting by just adding a +1, and the rest of us will know how to 
interpret it.  But that's a poor rule for general commenting.  (That is, a +1 
for a LC makes sense if you are a WKC and know you are...)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From stpeter@stpeter.im  Wed May 11 14:36:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BC6E089C for ; Wed, 11 May 2011 14:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcN1ArSJWvux for ; Wed, 11 May 2011 14:36:11 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 80DE6E088B for ; Wed, 11 May 2011 14:36:09 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6647E400A6 for ; Wed, 11 May 2011 15:36:08 -0600 (MDT)
Message-ID: <4DCB0146.9060307@stpeter.im>
Date: Wed, 11 May 2011 15:36:06 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020803060502060601010706"
Subject: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:36:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms020803060502060601010706
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Folks, we've created a chatroom where your area directors can be found
when they're online:

xmpp:app-ads@jabber.ietf.org

This is the real-time equivalent of the existing email alias:

mailto:app-ads@ietf.org

Feel free to stop by if you have questions or comments!

Peter

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




--------------ms020803060502060601010706
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MTIxMzYwNlowIwYJKoZIhvcNAQkEMRYEFC84VBAp9yMq9Xz1f5AW086OAQJ9MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCfRsYI2finCJSaiIBf0GZeSqPyj/plTLg1pzU3uH7ssPDwEqmJ1nxCu2pY
evLearWs3cgDueqq6ZHsgOODXc98IbIqY9tJPtHZ5mUBWDnT0U63RVXPmWOiDOrMeN1dkAus
tGGtnKNWwPVUWpOEO6GiEia8u4EuAEA1N11dolzq4Z+z53Y+g+aVwH+uSmwlb9XBCUCKElAD
Jw8opT6DExKHuey9PjKeuAcclIVFm8BSMC6x1CKMb4LznLnipCxaJCLTgi8myBnMukZL84qc
SsJ/jD7YlQqmcjDGohZ0JJIxk6ENaOPyhKS/Fa1HwSJT8SCBFSTTbtn9vYdzAu59AHAUAAAA
AAAA
--------------ms020803060502060601010706--

From sm@resistor.net  Wed May 11 14:39:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46D7E089F for ; Wed, 11 May 2011 14:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+IoxCbiluu6 for ; Wed, 11 May 2011 14:39:45 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB9E089C for ; Wed, 11 May 2011 14:39:44 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4BLdbbk007757;  Wed, 11 May 2011 14:39:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1305149982; bh=VN0VX/+BSgR67V5uIvj6dWF2gvo23Qx3OQB4rXjnraY=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=yvREeafJfAO1CsttA7kCc+h5jHoncoUhDnPkOLbOwFVGtOClcdfzxcZ3GX/ON3PWl XOwZqY4+qFO/BsrMa5XOEq3hqKFMGZ14ZwDTpdB5nnD1fqZoIVLgORXBXcoqcYFXfX MB7UDLyylhsYTSkV6U52ggldxViNrFBo2jBn9BDY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1305149982; bh=VN0VX/+BSgR67V5uIvj6dWF2gvo23Qx3OQB4rXjnraY=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=e14++bBNuxHEyggJRkQwtNlXHzCOw0UrcrqmxAWHN2uJ0OIS/sqnII9vIoK9pQo3s bTVU0L1S9ezSLoS1NhjHCzUdBXxgW9c0+FIP+qa+EPQIbx2sSgNPM1ofDHtX8AzAy2 H/N3IrhA/yV2YxOrQsOqjt82Udt2ubEVXFpVLR6o=
Message-Id: <6.2.5.6.2.20110511141027.032dd408@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 11 May 2011 14:39:09 -0700
To: Pete Resnick 
From: SM 
In-Reply-To: <4DCAF61F.10000@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Apps Discuss 
Subject: [apps-discuss] We have no lambs (was: Applicability Statements)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:39:49 -0000

Hi Pete,
At 13:48 11-05-2011, Pete Resnick wrote:
>Smiley face understood but:
>
>We have no lambs in this organization. Or wolves. Or kings. Or 
>better yet, we are *all* all of those things.
>
>I asked for thoughts. I take them seriously. What makes the IETF a 
>good place to work is that it's full of people much smarter than me.

That's how I read the threads that you opened.  It would be good if a 
broader audience throws in their two cents.  In plain English, read 
the thoughts as coming from Pete, the individual who does not have 
any IETF track record, and tell him what you think.  The IETF does 
not work when people remain silent.

At 13:37 11-05-2011, John C Klensin wrote:
>So, I wouldn't have said "useless".  I might have said "of very
>limited value in helping the IESG with its determination of
>consensus about technical quality and adequacy of review".

That is the politically correct way of stating it.  It may help some 
people understand what the IESG would like.  However, sentences like 
that are against IETF best practices. :-)

Pete has taken a rather unusual approach.  I would qualify it as 
open.  It is to encourage discussion on an equal footing.

Regards,
-sm 


From nico@cryptonector.com  Wed May 11 15:07:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1297CE0898 for ; Wed, 11 May 2011 15:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level: 
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yYtiHkDobPD for ; Wed, 11 May 2011 15:07:54 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 78054E0838 for ; Wed, 11 May 2011 15:07:54 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 2C46821DE65 for ; Wed, 11 May 2011 15:07:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AG0XpymRPN109ifdBTcpGZoEyUekHFglZxS29yOv+NLl CtilxGCVCr2ErWO1UWQlS/xZ3ULnRV+bJnnzpf4Uy3Uz0ONRqNZAg4vF/B20TBEA jzeGoOUXtRi3nwWI6rGcByk2I0YbPR7YxBAcbq8Mua9maF9pulKwNV+m+nSJIwo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=1wDN2el8DaAyFc6b7oW/ap3aNvI=; b=LohRbrhu76E qyPcFsk76h6NVUGiz2s2IKVtsPGBUJB1h83DfPCpY+qog9nDnPjSNXTUtZ0BNWWv DzLmasMuzjyIdffSBI+g84+LDJ0lPe+KKYAJzlvx+P4mZCldiPVwtUQjYI6GhsfU RenEGfhiMOPvhO6OZlYezA7jpFeZszkY=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 04C6621DE59 for ; Wed, 11 May 2011 15:07:52 -0700 (PDT)
Received: by vxg33 with SMTP id 33so848651vxg.31 for ; Wed, 11 May 2011 15:07:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.199 with SMTP id cc7mr2119425vdc.197.1305151672409; Wed, 11 May 2011 15:07:52 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Wed, 11 May 2011 15:07:52 -0700 (PDT)
In-Reply-To: <4DCAFB2A.8030408@dcrocker.net>
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <4DC9A557.9040504@qualcomm.com> <4DCAFB2A.8030408@dcrocker.net>
Date: Wed, 11 May 2011 17:07:52 -0500
Message-ID: 
From: Nico Williams 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:07:55 -0000

On Wed, May 11, 2011 at 4:10 PM, Dave CROCKER  wrote:
> On 5/10/2011 1:51 PM, Pete Resnick wrote:
> Taking responsibility requires establishing one's involvement. =C2=A0With=
in an
> on-going working group discussion, a context exists and a "+1" is an
> efficient tool within that. =C2=A0(Note that a review tends to start with=
 a
> factual summary of what is being reviews; this establishes that the revie=
wer
> has enough understanding to offer an opinion.)
>
> For a Last Call, there typically is no such context for most of the folk

I assume you mean an IETF LC, not WG LC here.

> submitting an opinion. Therefore, each person submitting an opinion shoul=
d
> assume that the first requirement is to establish the basis for their
> involvement, knowledge, interest, or the like in the paper.

I worry that this approach will lead to an obnoxious level of
formalism (a formalism that may be quite fine for lists like secdir),
where reviewers start their comments with:

"I have read I-D draft-....  My comments are below.  My background
is...  I'm interested in this work for the following reasons...  Blah,
blah, blah."

Seems a bit much.

Good technical opinions are good regardless of the speaker.

I'm not sure I care to see each commenter establish the basis for
their involvement, etcetera.  There are anonymous and pseudonymous
participants too, and I don't really care to ignore them for being so,
or to force them to disclose information about themselves that they
might wish to keep private.  New or infrequent participants should be
encouraged to make some such statements provided they are comfortable
doing so.

It's one thing to ask for more substantive statements than "I support
publication", and quite another to ask for people to establish their
bonafides (something we've never really done at the IETF merely for
participating).  I oppose the latter.  But even the former seems a bit
much wherever it means effectively repeating what has already been
stated.  "+1" is concise, and depending on context can also be quite
precise.  There's no need to be exceedingly verbose (and now I must
watch the length of this reply).

> No doubt there are a few IETF Well-Known Culprits (WKC) who might respond=
 to
> one person's posting by just adding a +1, and the rest of us will know ho=
w
> to interpret it. =C2=A0But that's a poor rule for general commenting. =C2=
=A0(That is,
> a +1 for a LC makes sense if you are a WKC and know you are...)

If there's any doubt one can always ask for clarification.  ISTM that
the best thing to do is to ask *in the LC announcement* for
substantive statements of support or opposition, and that any "+1"s or
"me too"s be clear as to what's being agreed to.

Nico
--

From barryleiba.mailing.lists@gmail.com  Wed May 11 15:31:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2996E08B4 for ; Wed, 11 May 2011 15:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.452
X-Spam-Level: 
X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMceRD+RRKn5 for ; Wed, 11 May 2011 15:31:45 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F325E0870 for ; Wed, 11 May 2011 15:31:45 -0700 (PDT)
Received: by yic13 with SMTP id 13so422693yic.31 for ; Wed, 11 May 2011 15:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bnn09nVg9+spi4BiUsGK6E0I0AHVt0BaKloB53bEOPQ=; b=QqzJny5RwQVTbMHUtPnjhn0LDw5qIomHPDHRUAzTMbiNSIx9stmG0ksI92pbiIMoKq ClFx5TT3udiPaGxRCgEhTKRDs5Z89cT89Il/NddXObUdgbZu/gFj6AyZ85fVlHUORYqC 5VdLnxC2zeiyUKF3bZemULsQ5Kpt9vJt3kPNI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VjL3hzgnNielLg/Z0wQ4laVhrvpe42pO/swJw8w97MDDb27tovGhaPALm71TFns6qH 5lpw3nERDLueHEdWKs/EFEfHEpBxlVcdG6AWdItpF0xTo3/CgjKLKADLLnjYWXYga/y1 9OYWHeeyAjOOi0s745qw8PjchNh+4Tp+APNX4=
MIME-Version: 1.0
Received: by 10.236.185.100 with SMTP id t64mr8154351yhm.82.1305153104415; Wed, 11 May 2011 15:31:44 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 15:31:44 -0700 (PDT)
In-Reply-To: <4DCB0146.9060307@stpeter.im>
References: <4DCB0146.9060307@stpeter.im>
Date: Wed, 11 May 2011 18:31:44 -0400
X-Google-Sender-Auth: HhaesJG6F5UuuOZ9d_erwpPsCoQ
Message-ID: 
From: Barry Leiba 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:31:45 -0000

On Wed, May 11, 2011 at 5:36 PM, Peter Saint-Andre  wrote:
> Folks, we've created a chatroom where your area directors can be found
> when they're online:
>
> xmpp:app-ads@jabber.ietf.org

I just stopped in to say hey and to bookmark the room, and PSA was
very welcoming.  We need to figure out a way to serve tea over xmpp.

Barry

From barryleiba.mailing.lists@gmail.com  Wed May 11 15:43:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D052E07F0 for ; Wed, 11 May 2011 15:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.42
X-Spam-Level: 
X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-wKdoiRODkb for ; Wed, 11 May 2011 15:43:43 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E677FE07D4 for ; Wed, 11 May 2011 15:43:42 -0700 (PDT)
Received: by yxk30 with SMTP id 30so426285yxk.31 for ; Wed, 11 May 2011 15:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LvjRUp1ZTT4V/xMWr793+6lYdUHQQqIsy0ru5mymBao=; b=UTQen9kxFXkMaCh9GRhmdSVFgRurtdcmuJiLAv7YL7zL2xhsmTw3xJAjRgNs3WLWz6 hoUcO0DW7+Qhya+Ojo0ouXuElguOaqiodyNeueWMG6dea6kWcS3VNsE511HIQxcIfnVt F+Tsz5kRlObGwkNWIfWbPwwPPIwjw/s8sOvb8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=x+1gZXLoFVrwJ41XllVpVCttv+m515vuRxDIpPFCVuHCF7X2Gs3BGOLAPbV+g5sLV/ 0Y3ql0psOSIez4hSzTXED9r1aCTqm2FZu7rZLZmUqjXDUwuWNKCai/NhO6xgnnyDUtTK ruwnZ2lp5c/p5Rt/jVExa9ik9JLEgqin7d6eY=
MIME-Version: 1.0
Received: by 10.236.182.229 with SMTP id o65mr11199570yhm.216.1305153822264; Wed, 11 May 2011 15:43:42 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.137.13 with HTTP; Wed, 11 May 2011 15:43:42 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20110511141027.032dd408@resistor.net>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com> <6.2.5.6.2.20110511141027.032dd408@resistor.net>
Date: Wed, 11 May 2011 18:43:42 -0400
X-Google-Sender-Auth: KnSASHSIe5YQq_7V3cWHae4e4Vo
Message-ID: 
From: Barry Leiba 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] We have no lambs (was: Applicability Statements)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:43:43 -0000

Hm.  I thought I wouldn't comment on this, but I think I will, because
I want to make something clear about how I think about this.

On Wed, May 11, 2011 at 5:39 PM, SM  wrote:
>
> At 13:37 11-05-2011, John C Klensin wrote:
>> So, I wouldn't have said "useless". =A0I might have said "of very
>> limited value in helping the IESG with its determination of
>> consensus about technical quality and adequacy of review".
>
> That is the politically correct way of stating it. =A0It may help some pe=
ople
> understand what the IESG would like. =A0However, sentences like that are
> against IETF best practices. :-)
>
> Pete has taken a rather unusual approach. =A0I would qualify it as open. =
=A0It
> is to encourage discussion on an equal footing.

Here's why I think being "politically correct" is important:
If it's someone's manner to be blunt, and to expect that we won't take
him *too* much at his exact words, that's fine, and we learn that.
And if someone is wont to say "Eff all y'all.  I'm going to ignore any
comments I choose to," well, again, we consider who's saying it and to
what extent we think he really means that... and everyone has a right
not to pay attention to anyone in particular.  Except....

When someone accepts a position on the IESG, the IAB, or the IAOC --
I*, as we collectively call them -- s/he no longer gets to be the
gruff "eff all y'all" person s/he once may have been.  S/he has to
support the open system we have, and not be closed to input.  That's
why someone on I* saying "I won't listen unless you say it the way I
want to hear it," bothers me.  That's why I think it's important to
put it more the way John did -- so people understand that you're not
just brushing people off, but see what you need and why.

So I don't really look at it as being "politically correct", but as
being clear without being exclusive.

That's all.  I don't think we need to belabour this any more, so I'll
leave it here.

Barry

From stephen.farrell@cs.tcd.ie  Wed May 11 15:52:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA08E08E3 for ; Wed, 11 May 2011 15:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhMp39Rrzv52 for ; Wed, 11 May 2011 15:52:00 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78579E0870 for ; Wed, 11 May 2011 15:52:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 654321577E2; Wed, 11 May 2011 23:51:58 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1305154318; bh=+sSWLh1kZA2IqR hA7CEYyVzMJnhKeGXDgM/W5AboXgo=; b=bgJcfEBeS2SCPHxnYKp7qaIj4nFFWy 8zhlXK3NBp3o3Js03hPmGSBHjMTr0Y+Bf4coGq0Q5UXg5VO3MMgtaxD4v904UcJK ZJdHSYYyWZTofcGrs6qSUp8viAWc2eqZw29a5yQpv3IR+ExKwglB28RhLFS+HMVt Eqip/8RyETk0P20xH06J1EFuKCd6xEUkogtIy7sJkgK/4XkkTTm8cFu3zg73y47T 4TUKp2EYf6uyugoty6Q9aAQqpbKOvRuacY351Br9hdhYu411BR1N7ysv+wPpGJLc NrzzoaCvOzZMi3rm30rdT8aSsl816dtbYfPOm8e2GlcUPbSLsz7VhHqQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id c7+Tahw229GN; Wed, 11 May 2011 23:51:58 +0100 (IST)
Received: from [10.87.48.9] (unknown [86.42.28.159]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0F9D11538B5; Wed, 11 May 2011 23:51:58 +0100 (IST)
Message-ID: <4DCB1303.8090403@cs.tcd.ie>
Date: Wed, 11 May 2011 23:51:47 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Barry Leiba 
References: <4DCAC1CB.3050905@qualcomm.com>	<6.2.5.6.2.20110511115259.051cd3f8@resistor.net>	<4DCAF61F.10000@qualcomm.com>	<6.2.5.6.2.20110511141027.032dd408@resistor.net> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss 
Subject: Re: [apps-discuss] We have no lambs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:52:01 -0000

On 11/05/11 23:43, Barry Leiba wrote:
> When someone accepts a position on the IESG, the IAB, or the IAOC --
> I*, as we collectively call them -- s/he no longer gets to be the
> gruff "eff all y'all" person s/he once may have been...

Sheesh, guess I better sign up for that Swiss finishing school I never
made it to first time 'round ;-)

S.

From lyndon@orthanc.ca  Wed May 11 16:55:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3839FE0663 for ; Wed, 11 May 2011 16:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXeWFqR-Y799 for ; Wed, 11 May 2011 16:55:10 -0700 (PDT)
Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8CE0691 for ; Wed, 11 May 2011 16:55:10 -0700 (PDT)
Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id p4BNt0aa037200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 16:55:08 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id p4BNt09a037199; Wed, 11 May 2011 16:55:00 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: from smeagol.orthanc.ca (smeagol.orthanc.ca [172.16.0.13]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id p4BNswsh052274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 16:54:58 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Date: Wed, 11 May 2011 16:54:58 -0700 (PDT)
From: Lyndon Nerenberg 
To: Barry Leiba 
In-Reply-To: 
Message-ID: 
References: <4DCB0146.9060307@stpeter.im> 
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 23:55:11 -0000

> I just stopped in to say hey and to bookmark the room, and PSA was
> very welcoming.  We need to figure out a way to serve tea over xmpp.

"There's a MIME type for that."

Oh wait, there isn't.  I'll start working on a draught for single malt. 
I'm more of a subject matter expert on that vs. lapsang souchong.

--lyndon

From johnl@iecc.com  Wed May 11 17:28:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0761BE06DA for ; Wed, 11 May 2011 17:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.199
X-Spam-Level: 
X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+AmZQoP33RA for ; Wed, 11 May 2011 17:28:10 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id B83B1E0593 for ; Wed, 11 May 2011 17:28:04 -0700 (PDT)
Received: (qmail 39156 invoked from network); 12 May 2011 00:28:03 -0000
Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 May 2011 00:28:03 -0000
Date: 12 May 2011 00:27:41 -0000
Message-ID: <20110512002741.67577.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 00:28:11 -0000

>Oh wait, there isn't.  I'll start working on a draught for single malt. 
>I'm more of a subject matter expert on that vs. lapsang souchong.

Wouldn't that be multipart/blended ?

R's,
John

From singer@apple.com  Wed May 11 17:29:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0DE069C for ; Wed, 11 May 2011 17:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXQPggX-+1Ug for ; Wed, 11 May 2011 17:29:31 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 83C68E0593 for ; Wed, 11 May 2011 17:29:31 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL200ME940VH431@mail-out.apple.com> for apps-discuss@ietf.org; Wed, 11 May 2011 17:29:26 -0700 (PDT)
X-AuditID: 11807136-b7c6bae000004a34-11-4dcb29e6596d
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay15.apple.com (Apple SCV relay) with SMTP id 28.5A.18996.6E92BCD4; Wed, 11 May 2011 17:29:26 -0700 (PDT)
From: David Singer 
In-reply-to: <6.2.5.6.2.20110419000054.055c8c10@elandnews.com>
Date: Wed, 11 May 2011 17:29:24 -0700
Message-id: 
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>  <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com>
To: S Moonesamy 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
Cc: Randall Gellens , Per Frojdh , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 00:29:32 -0000

should I upload a new version?  I have not heard anything in a while.  what happens next?

David Singer
Multimedia and Software Standards, Apple Inc.


From lyndon@orthanc.ca  Wed May 11 17:36:31 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66549E084F for ; Wed, 11 May 2011 17:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1CCCpYt2nwq for ; Wed, 11 May 2011 17:36:31 -0700 (PDT)
Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB437E0711 for ; Wed, 11 May 2011 17:36:30 -0700 (PDT)
Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id p4C0aNki037371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 17:36:30 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id p4C0aNbF037370; Wed, 11 May 2011 17:36:23 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: from smeagol.orthanc.ca (smeagol.orthanc.ca [172.16.0.13]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id p4C0aK48056855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 17:36:21 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Date: Wed, 11 May 2011 17:36:20 -0700 (PDT)
From: Lyndon Nerenberg 
To: John Levine 
In-Reply-To: <20110512002741.67577.qmail@joyce.lan>
Message-ID: 
References: <20110512002741.67577.qmail@joyce.lan>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 00:36:31 -0000

> Wouldn't that be multipart/blended ?

Not in my lifetime.

From randy@qualcomm.com  Wed May 11 22:15:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DFBE06AB for ; Wed, 11 May 2011 22:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDqVQ04hIG+H for ; Wed, 11 May 2011 22:15:10 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3EE06A7 for ; Wed, 11 May 2011 22:15:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1305177310; x=1336713310; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20|References:=20<6.2.5.6.2.20110416051507.05ba6868@ elandnews.com>=0D=0A=20=0D=0A=20<147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.c om>=0D=0A=20<6.2.5.6.2.20110419000054.055c8c10@elandnews. com>=0D=0A=20|X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Wed, =2011=20May=202011=2022:14:46=20-0700|To:=20David=20Singe r=20,=20S=20Moonesamy=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20Apps-team=20review=20of=20draft-gellens -mime-bucket-bis-03|CC:=20Randall=20Gellens=20,=20,=20Per=20Frojdh=0D =0A=09|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.48.1]; bh=s8NskOIeFp+nzFQlzPQ9t3/qxFQY0vHIGv1v5saqHcw=; b=GswdMngMGA3Ip4yUzY1MvSFm06ncB70H3WWSzayD5X0M4ZoL3wVimBEd qfxoOQsDSAc+pIj83YL6voFzb2929dnd5Ucr/jnvEFzHTwHF8kOtK8WLO Rkf35jUnGbHndszQOzcvLaZsoNL2NaMKNUPlaVHPslxDNEgxlJj4CpiRm 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6343"; a="90724743"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 11 May 2011 22:15:09 -0700
X-IronPort-AV: E=Sophos;i="4.64,355,1301900400"; d="scan'208";a="139092621"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 May 2011 22:15:09 -0700
Received: from loud.pensive.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 11 May 2011 22:14:49 -0700
Message-ID: 
In-Reply-To: 
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>  <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com> 
X-Mailer: Eudora for Mac OS X
Date: Wed, 11 May 2011 22:14:46 -0700
To: David Singer , S Moonesamy 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Cc: Randall Gellens , Per Frojdh , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:15:11 -0000

At 5:29 PM -0700 5/11/11, David Singer wrote:

>  should I upload a new version?  I have not heard anything in a 
> while.  what happens next?

Please do upload a revision (-04) and let the Area Director know. 
The draft is not yet in IETF Last Call, so there are no "Discuss"es 
which need to be formally cleared.  There was a review by the Apps 
directorate, which provided some helpful comments that we addressed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Little Jack Horner
Sits in a corner
Extracting cube roots to infinity.
An assignment for boys
That will minimize noise
And produce a more peaceful vicinity.
      --Frederick Winsor, "A Space-Child's Mother Goose"

From nico@cryptonector.com  Wed May 11 22:37:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E37DE06C3 for ; Wed, 11 May 2011 22:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=0.324,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwPZPGpGmK7k for ; Wed, 11 May 2011 22:37:03 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 860B3E06B7 for ; Wed, 11 May 2011 22:37:03 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 188AD1B4059 for ; Wed, 11 May 2011 22:37:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=DOl/e88QUNtxNm9d33DdK grbc4+raLonFNyHuz4Vsq1aaI3L7Yx0BAKgvTQTyqG6rMwlRkuYSwE8DOnC554Rp DJfkeS4QrDoUw2Xg7hsbNy/kH/okKG8s19arTQkFpTMe1UeMLsTR5A4GMbbDiaxh visKXn8Tal9DHWIdMEIdTM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TtbWugpxBOLQvJPZs6mM 2XSgQNs=; b=iQl/WT3ASbcv0b2LSRv75uSFkLsl1EcxlURr1t1lIHJENK0B1twa Kg4mee2MN8bQEtyTsq6Qm/fs+2fMkZplGeeiXSzNgJgJ3iBuMtRhfQTRwBxANOaR 7Ngh3ivL2ZmCz610zp7uONkRZ4+QY8zGx3VxjQdxkHscGFCjcG2zNRI=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E09B91B4058 for ; Wed, 11 May 2011 22:37:02 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1043830vxg.31 for ; Wed, 11 May 2011 22:37:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.71.111 with SMTP id t15mr34374vdu.37.1305178622091; Wed, 11 May 2011 22:37:02 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Wed, 11 May 2011 22:37:02 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Wed, 11 May 2011 22:37:02 -0700 (PDT)
In-Reply-To: <4DCB0146.9060307@stpeter.im>
References: <4DCB0146.9060307@stpeter.im>
Date: Thu, 12 May 2011 00:37:02 -0500
Message-ID: 
From: Nico Williams 
To: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=20cf3071c978235fff04a30d94fa
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:37:04 -0000

--20cf3071c978235fff04a30d94fa
Content-Type: text/plain; charset=UTF-8

My phone only displayed part of the subject line (due to its length) in the
mailbox index, cropping off the last two letters.  For a second I thought
the rest might be "ulette"...  Heh.

Nico
--

--20cf3071c978235fff04a30d94fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


My phone only displayed part of the subject line (due to its length) in =
the mailbox index, cropping off the last two letters.=C2=A0 For a second I =
thought the rest might be "ulette"...=C2=A0 Heh.


Nico

-- 


--20cf3071c978235fff04a30d94fa--

From sm@elandsys.com  Wed May 11 22:53:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C112E06AC for ; Wed, 11 May 2011 22:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCCKXjXxMgwy for ; Wed, 11 May 2011 22:53:08 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD0E06A7 for ; Wed, 11 May 2011 22:53:08 -0700 (PDT)
Received: from subman.elandsys.com ([41.136.237.146]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p4C5quWc000666; Wed, 11 May 2011 22:53:01 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1305179584; bh=Du9aqNg0mMJzKHS7tQeZu4CM2+M=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=QN5WpBkspdBZa2vbvGvNzS3jFk8jQiU7qDfYbvfCnyg7nvWT7l4IJGH8HhzEx6M4/ VkBMIl/dT4OxBxR/LR1v/lZlHDraxLmcNlvVvcPEGOCe/nD5hLTkRdxvYwi0+dSauJ fEciJGH3fZMBCnFpDhAwDciQ6Y9zTor6uDBsisjc=
Message-Id: <6.2.5.6.2.20110511225020.02ce8c70@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 11 May 2011 22:51:55 -0700
To: David Singer 
From: S Moonesamy 
In-Reply-To: <8AAEA3D2-F482-4700-A846-83C8A4B10992@apple.com>
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>  <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com> <8AAEA3D2-F482-4700-A846-83C8A4B10992@apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Randall Gellens , Per Frojdh , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:53:09 -0000

Hi David,
At 17:47 21-04-2011, David Singer wrote:
>I put back the "Note that"

Thanks.  The changes you did addresses all the comments.

Regards,
S. Moonesamy 


From ietfc@btconnect.com  Thu May 12 01:27:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6C0E071D for ; Thu, 12 May 2011 01:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjLq8PWjhGSL for ; Thu, 12 May 2011 01:27:07 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9C80AE070C for ; Thu, 12 May 2011 01:27:06 -0700 (PDT)
Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr07.btconnect.com with SMTP id CZN57982; Thu, 12 May 2011 09:26:50 +0100 (BST)
Message-ID: <003501cc1075$c2fd4ce0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Pete Resnick" , "Barry Leiba" 
References: <4DC88255.3070403@qualcomm.com><4DC94F74.30905@dcrocker.net>	<4DC9688B.3070701@qualcomm.com> <4DC9A557.9040504@qualcomm.com>
Date: Thu, 12 May 2011 09:25:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DCB99C9.0099, actions=TAG
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.12.74217:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __C230066_P5, __CP_NOT_1, __INT_PROD_COMP, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4DCB99D3.00A3,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 08:27:11 -0000

----- Original Message -----
From: "Pete Resnick" 
To: "Barry Leiba" 
Cc: 
Sent: Tuesday, May 10, 2011 10:51 PM
> On 5/10/11 2:46 PM, Barry Leiba wrote:
> >> Saying "I have read and
> >> support the publication of this document" is indistinguishable from, "My
> >> co-worker/friend/third-cousin-twice-removed told me I should send in a
> >> message supporting this document, so I did." All I'm saying is that
> >> additional text indicating *why* you support this document is the important
> >> part.
> >>
> > And you really think that my TCTR couldn't tell me I should send a
> > message saying that I think the document is valuable and clear, and
> > that I could implement from it?  Or whatever?
>
> Well, your cousin could try to tell you how to do that. But it gets
> harder for people to pull this off with a straight face if, as a group,
> we start giving more elaborate comments. People who are normal
> participants in the group start asking the right kinds of questions of
> those folks and they get marginalized.
>
> But getting rid of process abusers is only a secondary goal here. Really
> my point is, I want us all to get in the habit of taking responsibility
> for documents; to not assume that the AD is going to be the final
> backstop, but instead assuming that the AD may be a dope and needs this
> stuff explained to him or her.

I didn't realise you were writing this in the role of AD but, even so,
I think that you are wrong.  I never used to post messages to say that I
had read and supported the advancement of an I-D, but, increasingly,
I see plaintive notes from WG Chairs to the effect that nothing is going
to happen unless and until someone posts something, and that a note
saying 'I have read and support this document' is helpful.

So I have started posting such notes and will continue to do so
(although I usually manage to point out a few grammatical errors at
the same time).  If ADs do not want to see them - tough - you
will just have to black list my mail:-)

WG Chairs will normally have had the opportunity to recognise my
e-mail address since, normally, I will have participated in the
discussions beforehand.  Perhaps the problem with ADs is that
they do not have the time to follow the mail list discussions as
much as they might and so are not familiar with the posters.

Tom Petch

> > And you really think that if Dave says the document is valuable and
> > clear, and that he could implement from it, and that's the same thing
> > *I* wanted to say, I shouldn't just say "+1", or "I agree"?
> >
>
> cf. Ted's comment about context. I might take you or Dave as saying
> something more interesting because I have a context of who you are. And
> given that context, you or Dave might well say, "(*grunt*)" instead of
> "I support the document", because really I'm not judging consensus on
> what you say, but on the context entirely. (That's what I mean by the
> statement being "useless".) But grunts and dependence on context makes
> it really difficult for new folks to know what's going on (be they ADs,
> chairs, or just participants), and it sets up the idea that what we're
> doing here is voting rather than coming to consensus. So if that means
> that folks we know well all have to add a sentence or two more during LC
> to set a good example, I'm OK with that.
>
> > As I said in my off-list note to you, simply the fact that I read the
> > document (or, at least, claimed to) and took the time to send a
> > comment should be enough to give you valuable information -- it's
> > absolutely NOT "useless".  I appreciate that you might *also* like
> > more than that, and if I have more than that to say, I will.  But the
> > idea that the IESG might ignore such comments as "useless" gives me
> > more than a bit of fright.
> >
>
> Of course the "or, at least, claimed to" is exactly what gives me a bit
> of fright. But understand that I really *might* ignore comments that
> come without context because there really is no way to evaluate what
> they mean. I'd rather get a bit of extra context. That makes it easier
> to point to later.
>
> pr
>
> --
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From GK@ninebynine.org  Thu May 12 02:08:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8FCE06CB for ; Thu, 12 May 2011 02:08:42 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suhx1-dRQgoe for ; Thu, 12 May 2011 02:08:38 -0700 (PDT)
Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id B610AE0744 for ; Thu, 12 May 2011 02:08:38 -0700 (PDT)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1QKRsr-00013w-GC; Thu, 12 May 2011 10:08:37 +0100
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKRsq-0002yI-8l; Thu, 12 May 2011 10:08:36 +0100
Message-ID: <4DCBA219.4070402@ninebynine.org>
Date: Thu, 12 May 2011 10:02:17 +0100
From: Graham Klyne 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCB0146.9060307@stpeter.im>
In-Reply-To: <4DCB0146.9060307@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 09:08:42 -0000

Do I need to be "authorized" to join in?  My client (MacOS/Adium) seems to think 
so, but maybe I'm just doing it wrong.  So far I've only used XMPP for 
person-to-person chat - is a chatroom significantly different to use?

#g
--

Peter Saint-Andre wrote:
> Folks, we've created a chatroom where your area directors can be found
> when they're online:
> 
> xmpp:app-ads@jabber.ietf.org
> 
> This is the real-time equivalent of the existing email alias:
> 
> mailto:app-ads@ietf.org
> 
> Feel free to stop by if you have questions or comments!
> 
> Peter
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From duerst@it.aoyama.ac.jp  Thu May 12 03:34:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531DE074E for ; Thu, 12 May 2011 03:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.79
X-Spam-Level: 
X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9-77QSnhRBW for ; Thu, 12 May 2011 03:34:32 -0700 (PDT)
Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 50BBAE06EE for ; Thu, 12 May 2011 03:34:32 -0700 (PDT)
Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4CAYVXL005565 for ; Thu, 12 May 2011 19:34:31 +0900
Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 490a_25af_6bd61bde_7c83_11e0_998c_001d096c5b62; Thu, 12 May 2011 19:34:31 +0900
Received: from [IPv6:::1] ([133.2.210.5]:50389) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Thu, 12 May 2011 19:34:31 +0900
Message-ID: <4DCBB7A3.5050001@it.aoyama.ac.jp>
Date: Thu, 12 May 2011 19:34:11 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCAC1CB.3050905@qualcomm.com>	<653ADDA5F1A34D89FA899549@PST.JCK.COM>		<4DCAF507.5030508@gmail.com> <4DCAF5C6.6070806@stpeter.im>
In-Reply-To: <4DCAF5C6.6070806@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , John C Klensin , Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 10:34:33 -0000

On 2011/05/12 5:47, Peter Saint-Andre wrote:

>> +1. I would recommend it to all Areas in fact, but it's good for
>> somebody to start.
>
> Pete dreamed this up as something we could try in the Applications Area,
> and I'm on board with it. Once we have some practical results to show to
> other area directors, we might convince them to try it, too.

The *Applica*tion area is all about *Applica*bility :-).

Regards,   Martin.

From john-ietf@jck.com  Thu May 12 07:20:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7EE0680 for ; Thu, 12 May 2011 07:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL3dIb1+zxKo for ; Thu, 12 May 2011 07:20:29 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 78360E06A1 for ; Thu, 12 May 2011 07:20:29 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKWkD-0007lc-7X; Thu, 12 May 2011 10:20:01 -0400
Date: Thu, 12 May 2011 10:20:00 -0400
From: John C Klensin 
To: SM , Pete Resnick 
Message-ID: <35CAD4FD66C1EDA5E82D49F8@PST.JCK.COM>
In-Reply-To: <6.2.5.6.2.20110511141027.032dd408@resistor.net>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com> <6.2.5.6.2.20110511141027.032dd408@resistor.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Apps Discuss 
Subject: [apps-discuss] On "supporting the publication of this document" (was: Re: We have no lambs (was: Applicability Statements))
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:20:30 -0000

(I think these last few messages slipped into the wrong thread.
Restoring...)

--On Wednesday, May 11, 2011 14:39 -0700 SM 
wrote:

>...
> At 13:37 11-05-2011, John C Klensin wrote:
>> So, I wouldn't have said "useless".  I might have said "of
>> very limited value in helping the IESG with its determination
>> of consensus about technical quality and adequacy of review".
> 
> That is the politically correct way of stating it.  It may
> help some people understand what the IESG would like.
> However, sentences like that are against IETF best practices.
> :-)

I think you may have missed my point, although the style I adopt
in the IETF rarely results in my being accused of saying things
to be politically correct.  :-)

The determination the IESG needs to make is multidimensional.
There is no agreed-upon statement of the dimensions, but I would
try the following as components.  They should require different
levels of certainty at different maturity levels, e.g., for
Proposed Standard, "no known technical defects" is supposed to
be adequate while, for higher levels, there should be some
conviction that no such defects exist, not merely that no one
has noticed.

(1) Is the document technically adequate?

(2) Is the document clear enough to be implemented in a
consistent and interoperable way?

(3) Are there interactions between the protocol specified in the
document that would have negative effects on the Internet or on
specific existing protocols?

(4) Do enough people in the community care about this spec that
the IETF should put its stamp of approval on it?

A "I think this is ok and should be published" statement may be
very useful for (4), especially for non-WG documents.   One
important characteristic of (4) is that the IESG actually does
have to count, even if the counting process doesn't correspond
to normal arithmetic.  For (1)-(3) high-information-content
technical arguments are important, especially if they take a
"don't publish" or "don't publish without..." position.  And, at
least in theory, there is no counting at all -- it doesn't make
any difference if a particular technical position is stated by
one person or by five (whether explicitly or by "+1"
endorsement): the issue should be the contents of that position.


Of course, it would reasonable for the IESG to take the position
that one reported problem is a bug that needs fixing but that
two dozen independent reported problems suggest that the spec
needs more fundamental work, but that ought to mean two dozen
comments of the type that I think Pete was asking for, not two
dozen endorsements of one such comment.

> Pete has taken a rather unusual approach.  I would qualify it
> as open.  It is to encourage discussion on an equal footing.

I think the only thing that is unusual about Pete's approach is
that he is trying to be explicit about the criteria he is going
to use to evaluate and weight comments.  I think that is A Good
Thing, but I don't think the criteria he suggests are in any way
new or unusual.

    john


From julian.reschke@gmx.de  Thu May 12 07:29:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E8BE06A3 for ; Thu, 12 May 2011 07:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HirvXxJTxT0t for ; Thu, 12 May 2011 07:29:00 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9C571E06A1 for ; Thu, 12 May 2011 07:28:59 -0700 (PDT)
Received: (qmail invoked by alias); 12 May 2011 14:28:58 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.148]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 12 May 2011 16:28:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX196nIZAEb569IZfpfuz5+ghEObB2kONoaYro+tPSb V/KcxC/B1b/DrF
Message-ID: <4DCBEEA2.6050900@gmx.de>
Date: Thu, 12 May 2011 16:28:50 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCB0146.9060307@stpeter.im>
In-Reply-To: <4DCB0146.9060307@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:29:00 -0000

On 11.05.2011 23:36, Peter Saint-Andre wrote:
> Folks, we've created a chatroom where your area directors can be found
> when they're online:
>
> xmpp:app-ads@jabber.ietf.org
> ...

Interesting enough, Thunderbird auto-links that as email address...

From hannes.tschofenig@gmx.net  Thu May 12 07:31:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C335E06A1 for ; Thu, 12 May 2011 07:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujVpeHKQUaob for ; Thu, 12 May 2011 07:31:35 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1520CE06C8 for ; Thu, 12 May 2011 07:31:33 -0700 (PDT)
Received: (qmail invoked by alias); 12 May 2011 14:31:32 -0000
Received: from h87.s239.verisign.com (EHLO [10.131.32.72]) [216.168.239.87] by mail.gmx.net (mp014) with SMTP; 12 May 2011 16:31:32 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18e4D1V80IeQEQvZiu6vsq9pGf/jTFl+d9ZuP1f5H kV6zZTHDyEsTnz
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <4DCAC1CB.3050905@qualcomm.com>
Date: Thu, 12 May 2011 17:31:29 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F5978D0-C48E-4B15-81E9-B33E430211E2@gmx.net>
References: <4DCAC1CB.3050905@qualcomm.com>
To: Pete Resnick 
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:31:39 -0000

Hi Pete,=20

I do not find this effort useful and see it as a waste of time. Sorry to =
say that.=20
I believe you should let the application area spend more time with =
relevant technical work rather than letting them spend time with process =
aspects.=20

Ciao
Hannes

On May 11, 2011, at 8:05 PM, Pete Resnick wrote:

> At the IESG Retreat, we had a discussion on how we publish =
implementation advice, conformance specifications, protocol profiles, =
and the like. Right now, we often put these sorts of things in BCP or =
Informational documents. Unfortunately, these are both second class =
citizens in our document series: They don't get published as "standards" =
and they can't be reviewed and progressed along the standards track even =
though they often have information that we want to review for success.
>=20
> There is a way to deal with these sorts of documents that we haven't =
tried in a very long time: RFC 2026 defines two kinds of standards track =
documents: Technical Specifications (TS), which we publish all of the =
time, and Applicability Statements (AS), which we haven't. According to =
2026, an AS can be any of the following:
>=20
>    "identifies the relevant TSs and the specific way in which they are =
to be combined"
>    "specify particular values or ranges of TS parameters or =
subfunctions of a TS protocol that must be implemented"
>    "specifies the circumstances in which the use of a particular TS is =
required, recommended, or elective"
>    "describe particular methods of using a TS in a restricted 'domain =
of applicability'"
>    "comprehensive conformance specification"
>=20
> That sounds to me like exactly what we're trying to do. And an AS can =
be standards track, so long as it is at the same or lower maturity level =
than any of the TSs it references, so it can get full standards track =
treatment.
>=20
> So, here's my proposal, which I've already gotten some positive =
feedback from the chairs of WGs that I cover in the apps area, and which =
the IESG has agreed to go along with: For my WGs in the apps area, we're =
going to try an informal experiment and submit documents like the above =
to the IESG for Proposed Standard AS. (I already have two such documents =
in mind: The potential MARF "BCP" and the the Malformed Header =
document.) Other ADs may join in, but I'll at least start the ball =
rolling. I'll try to get some early feedback from IESG folks as we get =
some I-Ds together to sanity check, and with any luck we'll get a few of =
these published as Proposed Standard. Then the IESG can talk about the =
criteria for advancement. However it works out, the worst case will be =
that we back off and publish these things as BCP or Informational =
instead, but I'm hopeful. After we get some experience, we'll see where =
else the use of AS might make sense.
>=20
> What do folks think?
>=20
> pr
>=20
> --=20
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: =
(858)651-1102
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From stpeter@stpeter.im  Thu May 12 07:42:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242EE0729 for ; Thu, 12 May 2011 07:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nld2ztMBhRlH for ; Thu, 12 May 2011 07:42:41 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 26761E072F for ; Thu, 12 May 2011 07:42:37 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9DCF5400A6; Thu, 12 May 2011 08:42:35 -0600 (MDT)
Message-ID: <4DCBF1DA.6080404@stpeter.im>
Date: Thu, 12 May 2011 08:42:34 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Julian Reschke 
References: <4DCB0146.9060307@stpeter.im> <4DCBEEA2.6050900@gmx.de>
In-Reply-To: <4DCBEEA2.6050900@gmx.de>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020107060901030005010005"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:42:46 -0000

This is a cryptographically signed message in MIME format.

--------------ms020107060901030005010005
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/12/11 8:28 AM, Julian Reschke wrote:
> On 11.05.2011 23:36, Peter Saint-Andre wrote:
>> Folks, we've created a chatroom where your area directors can be found=

>> when they're online:
>>
>> xmpp:app-ads@jabber.ietf.org
>> ...
>=20
> Interesting enough, Thunderbird auto-links that as email address...

Well, there are only two URI schemes, you know: http and mailto...

Peter

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




--------------ms020107060901030005010005
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MjE0NDIzNFowIwYJKoZIhvcNAQkEMRYEFDwfuxiyE3LjQWuDOv2CXJTprJT9MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQB/ePfy8ewrhgWMcSYpHjEGnyGGdVC1YCWV9iV6QdF2aiKIBNOx2FWBubbK
0kbEaPTrOCTX68HmHVVClCbH+8EmDGNwa+IdQ8LP2k9TriVFa/2YMkETMi5Ivn06jQYYCP6N
hwwiCpn47I4Zl27TgHfH4+6An+oHFAbmYUvr9SwTuZWVCUnLFBg8m13wUrRjAKBFmdNixhw4
TAWjitIrDmhtG8F3Ws2bl1ltfInoZYyMOqkaY1lrw0ZPkOqM/wBCPPtooBcvX95V+omwXnFp
tUFrwEzOX59GWV6bF4LRgQpk1jKJ7LXAPPUm2CtsrGxbzuXLm6tEFgefMPOD0HqwU8BfAAAA
AAAA
--------------ms020107060901030005010005--

From john-ietf@jck.com  Thu May 12 07:48:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190ACE071E for ; Thu, 12 May 2011 07:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zV4sl4LfJB2 for ; Thu, 12 May 2011 07:48:00 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC8DE06C8 for ; Thu, 12 May 2011 07:48:00 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKXBF-0008P3-8W; Thu, 12 May 2011 10:47:57 -0400
Date: Thu, 12 May 2011 10:47:56 -0400
From: John C Klensin 
To: Hannes Tschofenig , Pete Resnick 
Message-ID: 
In-Reply-To: <0F5978D0-C48E-4B15-81E9-B33E430211E2@gmx.net>
References: <4DCAC1CB.3050905@qualcomm.com> <0F5978D0-C48E-4B15-81E9-B33E430211E2@gmx.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:48:01 -0000

--On Thursday, May 12, 2011 17:31 +0300 Hannes Tschofenig
 wrote:

> Hi Pete, 
> 
> I do not find this effort useful and see it as a waste of
> time. Sorry to say that.  I believe you should let the
> application area spend more time with relevant technical work
> rather than letting them spend time with process aspects. 

Hi Hannes,

I guess I don't understand your comment.  I didn't understand
Pete to be suggesting the creation of a single new document or
piece of work, only that we stop trying to disguise materials
that some readings of 2026 would classify as Applicability
Statements as BCPs or Information documents, but instead publish
them as AS documents.     If no work is done, then there are no
documents to be published in any category.  If someone says
"publish this as a BCP" and the content is essentially that of
an AS, Pete intends to push back and say "AS instead".  That
isn't extra work or "process aspects".  If something were
published and someone decides it needs updating, revision, or
confirmation, then the effort needs to be made to generate an
updated version: that doesn't change whether the document is a
BCP or an AS either.. the only thing that changes is being clear
to all concerned about what is being done and, as I pointed out
in an earlier note, we get away from the notion than an untried
idea to address a practical, often operational, problem with a
protocol is a "best current practice".

   best,
    john


From julian.reschke@gmx.de  Thu May 12 07:52:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0197AE072E for ; Thu, 12 May 2011 07:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfNt7Ua9LvJb for ; Thu, 12 May 2011 07:52:34 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 69D1CE0685 for ; Thu, 12 May 2011 07:52:34 -0700 (PDT)
Received: (qmail invoked by alias); 12 May 2011 14:52:32 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.148]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 12 May 2011 16:52:32 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/7It8Vzw37qociP1kahSHJEK6v0JRW+niDb+Tf8Q 9Kw0KVqJw7EOZa
Message-ID: <4DCBF42A.3080800@gmx.de>
Date: Thu, 12 May 2011 16:52:26 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCB0146.9060307@stpeter.im> <4DCBEEA2.6050900@gmx.de> <4DCBF1DA.6080404@stpeter.im>
In-Reply-To: <4DCBF1DA.6080404@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:52:39 -0000

On 12.05.2011 16:42, Peter Saint-Andre wrote:
> On 5/12/11 8:28 AM, Julian Reschke wrote:
>> On 11.05.2011 23:36, Peter Saint-Andre wrote:
>>> Folks, we've created a chatroom where your area directors can be found
>>> when they're online:
>>>
>>> xmpp:app-ads@jabber.ietf.org
>>> ...
>>
>> Interesting enough, Thunderbird auto-links that as email address...
>
> Well, there are only two URI schemes, you know: http and mailto...

...funny enough it transforms it into a mailto:.

-> 

Best regards, Julian

From dhc@dcrocker.net  Thu May 12 08:53:12 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE5E06F6 for ; Thu, 12 May 2011 08:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level: 
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faV8-HgQIILM for ; Thu, 12 May 2011 08:53:08 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01872E0671 for ; Thu, 12 May 2011 08:53:08 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CFr1XQ013722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 08:53:06 -0700
Message-ID: <4DCC0257.1050705@dcrocker.net>
Date: Thu, 12 May 2011 08:52:55 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Nico Williams 
References: <4DC88255.3070403@qualcomm.com>	<4DC94F74.30905@dcrocker.net>	<4DC9688B.3070701@qualcomm.com>		<4DC9A557.9040504@qualcomm.com>	<4DCAFB2A.8030408@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 08:53:07 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 15:53:12 -0000

On 5/11/2011 3:07 PM, Nico Williams wrote:
> I worry that this approach will lead to an obnoxious level of
> formalism

The IETF has quite a bit of formalist, along with it's famously having quite a 
bit of informality.  When introducing rules, the challenge for us is to get it 
right.  That's why we need to be careful that our formality, here, is about the 
/nature/ of what is provided and not the form.  (We often get this confused, of 
course...)

For establishing credibility, the need is to say enough to show actual knowledge 
of the document, not to regurgitate a CV.


> Good technical opinions are good regardless of the speaker.

Indeed they are, but providing enough information to know that they are good is 
the issue here.

For example, compare:

      This document specifies a technique that won't scale.

versus:

      I have worked on the design of a number of protocols that have become 
popular for wide-scale use on the Internet, namely xxx, yyy and zzz.  I've also 
worked on a number that failed to gain popularity, namely aaa and bbb.

      Based on this experience I believe this document specifies a technique 
that won't scale.  In particular, the foo mechanism requires manual updating, 
which is extremely expensive and error prone.


So, which bit of input would you expect to be more useful when making a decision 
about the documenet?


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From dhc@dcrocker.net  Thu May 12 09:00:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E001CE07C2 for ; Thu, 12 May 2011 09:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level: 
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpRE1lLjfnN5 for ; Thu, 12 May 2011 09:00:13 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACBFE07C0 for ; Thu, 12 May 2011 09:00:09 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CG04qH013876 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 09:00:09 -0700
Message-ID: <4DCC03FD.3070608@dcrocker.net>
Date: Thu, 12 May 2011 08:59:57 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Pete Resnick 
References: <4DCAC1CB.3050905@qualcomm.com>
In-Reply-To: <4DCAC1CB.3050905@qualcomm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 09:00:09 -0700 (PDT)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 16:00:18 -0000

On 5/11/2011 10:05 AM, Pete Resnick wrote:
> There is a way to deal with these sorts of documents that we haven't tried in a
> very long time:
...
>   For my WGs in the apps area, we're going to try an informal
> experiment and submit documents like the above to the IESG for Proposed Standard
> AS.


AS is a failed experiment.  The failure was complete and not a matter of opinion.

If you want to repeat it, you need to change the conditions, and explain how 
those changes are likely to make it succeed this time.

I'm not stating an opinion about whether I think the construct is good or bad, 
or whether it's worth conducting the experiment, but of the need to specify the 
details that give sufficient guidance and make it (more) likely that the label 
will be useful this time.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From nico@cryptonector.com  Thu May 12 10:24:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53047E0758 for ; Thu, 12 May 2011 10:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9QMpHoYecxr for ; Thu, 12 May 2011 10:24:21 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B6702E06C8 for ; Thu, 12 May 2011 10:24:21 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 37808778061 for ; Thu, 12 May 2011 10:24:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ofabNVvK8VSp7TIqoAg6vUWQHBN+fa+O63B9giQa5EMO t4ac7uSgfKE8/IdGtPGSEI2/lBweQC/lJjAmo5D2Eu/7RrEoA+qxJmIJeYaC4Thy jETwIjoRgH2sXsK441h4suGFsSquJ9qOIx5hs9VBQ9vn+0s9csZzR8DcluAIVJ0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EVU8CT6O9K/ECAvTMh7ZIlYhkcM=; b=XzKerh1bD3B 0GUyJCas2fdvlzAjgNbTVHS49CGfwpSoJuTedJKENX3VojRR/CUnfaiqzYjMyu9M AIUTFJinqDiEX44zt0mnkqsTR7z4htEZ7hDPu4YqcdHa6QhHgZHF/b0r7RE3GRu4 fmRpbEjz2j8O1IAoAwagh35xfyfXpWY8=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 04EB6778057 for ; Thu, 12 May 2011 10:24:20 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1536421vxg.31 for ; Thu, 12 May 2011 10:24:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.170 with SMTP id m10mr679553vdv.160.1305221060424; Thu, 12 May 2011 10:24:20 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 10:24:20 -0700 (PDT)
In-Reply-To: <4DCC0257.1050705@dcrocker.net>
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <4DC9A557.9040504@qualcomm.com> <4DCAFB2A.8030408@dcrocker.net>  <4DCC0257.1050705@dcrocker.net>
Date: Thu, 12 May 2011 12:24:20 -0500
Message-ID: 
From: Nico Williams 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:24:22 -0000

On Thu, May 12, 2011 at 10:52 AM, Dave CROCKER  wrote:
> On 5/11/2011 3:07 PM, Nico Williams wrote:
>>
>> I worry that this approach will lead to an obnoxious level of
>> formalism
>
> The IETF has quite a bit of formalist, along with it's famously having qu=
ite
> a bit of informality. =C2=A0When introducing rules, the challenge for us =
is to
> get it right. =C2=A0That's why we need to be careful that our formality, =
here, is
> about the /nature/ of what is provided and not the form. =C2=A0(We often =
get this
> confused, of course...)

Well, I prefer formalism for specifications, and informality for the
social aspects of standards-setting.  We could argue about both till
the cows come home.  As long it's personal preferences that we're
stating then there's no need to argue about these.  But regarding
bonafides establishment, I have fairly strong feelings here:

> For establishing credibility, the need is to say enough to show actual
> knowledge of the document, not to regurgitate a CV.

Sure, this may be _advisable_ for non-usual-suspects, and occasionally
advisable for usual suspects (namely: when necessary as a result of
participation by new participants).  (I don't really care for a lot of
tedious repetition.)  But I've grave reservations about this as a
formal part of argument at the IETF (see below).

>> Good technical opinions are good regardless of the speaker.
>
> Indeed they are, but providing enough information to know that they are g=
ood
> is the issue here.

When there's reason to doubt a statement, yes.  But it's not always
necessary.  For example, a person I rarely see posts from posted to
KRB-WG the other day to point out a security flaw in one PKINIT
variant.  The flaw was obvious once described.  There was no need for
the poster to describe their experience, nor should there have been.
You give an example where I can imagine that the poster's experience
will contribute weight to the statement, but the statement will need
to be explored in detail in such a case anyways, and I still wouldn't
really care what the poster's experience was once we're done
establishing the value of that statement:

> For example, compare:
>
> =C2=A0 =C2=A0 This document specifies a technique that won't scale.
>
> versus:
>
> =C2=A0 =C2=A0 I have worked on the design of a number of protocols that h=
ave become
> popular for wide-scale use on the Internet, namely xxx, yyy and zzz. =C2=
=A0I've
> also worked on a number that failed to gain popularity, namely aaa and bb=
b.
>
>     Based on this experience I believe this document specifies a techniqu=
e
> that won't scale.  In particular, the foo mechanism requires manual
> updating, which is extremely expensive and error prone.
I believe statements like the above can be made, and convincingly so,
without reference to personal experience.  Personal experience helps
illustrate the truth of such a statement, but the personal experience
can be distilled into a detailed rationale without having to describe
the actual personal experience.

I prefer dispassionate argument (though I admit that on occasion I
allow my passions to bleed into my arguments -- a personal failing).

Dispassionate argument, it seems to me, is best served by trying to
distill personal experience.  Dispassionate argument does not require
that one not present personal experience, of course, but I think it's
advisable to distill such experience as well, if not first.

> So, which bit of input would you expect to be more useful when making a
> decision about the documenet?

Neither.  I'd prefer:

    I believe the proposed design will not scale well for the
following reasons: .  [optional]
This comes from having observed similar failures in the field
.

Here the personal experience helps shed light on the rationale given,
but the rationale given ought to stand on its own.  Moreover, the
truth of such a statement might be obvious once the statement is made,
in which case the personal experience becomes irrelevant.  Moreover
still, if the truth of such a statement can easily be established, it
should not matter that the speaker has little or even no experience in
the field.

Put differently:  Argument by experience can be fallacious and/or
fraudulent at worst, often being just a point of view easily countered
by others' personal experience.  Then the degree to which the speaker
is a usual suspect or otherwise "important" becomes a key to giving
weight to their argument.  I don't think that would be a good thing,
particularly if we should *formalize* such a mode of argument (which
would make lambs of many participants, and wolfs of a few).

Nico
--

From dhc@dcrocker.net  Thu May 12 10:32:37 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA9E06C8 for ; Thu, 12 May 2011 10:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGauf-rGpl-j for ; Thu, 12 May 2011 10:32:36 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8319DE0679 for ; Thu, 12 May 2011 10:32:36 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CHWUr5015845 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 10:32:36 -0700
Message-ID: <4DCC19A8.3070807@dcrocker.net>
Date: Thu, 12 May 2011 10:32:24 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Nico Williams 
References: <4DC88255.3070403@qualcomm.com>	<4DC94F74.30905@dcrocker.net>	<4DC9688B.3070701@qualcomm.com>		<4DC9A557.9040504@qualcomm.com>	<4DCAFB2A.8030408@dcrocker.net>		<4DCC0257.1050705@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 10:32:36 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 17:32:37 -0000

On 5/12/2011 10:24 AM, Nico Williams wrote:
> On Thu, May 12, 2011 at 10:52 AM, Dave CROCKER  wrote:

> I prefer dispassionate argument

This isn't about passion (1st definition) but well might be about partiality 
from experience (2d/3rd definition).

Note that your own alternative example actually demonstrates that:

> Neither.  I'd prefer:
>
>      I believe the proposed design will not scale well for the
> following reasons:.  [optional]

How is the random reader to know that the speaker has that experience, unless it 
is declared.

Yes, it is better to state well-known or obvious facts.  ("This calls for a very 
large table but uses a linear search and that won't scale".)

However many interesting problems involve judgment about what will work. 
Experience of the speaker informs the likelihood that their opinion is well-founded.


> This comes from having observed similar failures in the field
> .

I'd class this as a useful version of what I was trying to describe.  Glad to 
see we agree...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From nico@cryptonector.com  Thu May 12 10:34:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACEEE06C8 for ; Thu, 12 May 2011 10:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdyVKM-Bgnrx for ; Thu, 12 May 2011 10:34:32 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2126BE0679 for ; Thu, 12 May 2011 10:34:32 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id D16776B0082 for ; Thu, 12 May 2011 10:34:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=RKFUouG5A8yeeihz7ga3rQMn8vFQn/3kjiWYXDN73FT0 lWBk/JsCLgy/rl6ibAe6qfjlgRadF4akja+udMvZ9l8HdKjpKTDRtbW3awTvAks8 +lnm1Us0ksqR3a6lUdM667FJZDr5lD9jQGQlGGUI27uqfQlF0LTD1AkuuLfWSD0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=T2oehcTA/AjHAbKj1rhsLptmMSg=; b=Y4zgImCnSdc bvR9nlvwUy3CMraRWW/uXgXcuycvXZistPmFzdhfQAEC4tlf8a1zQZVXq1bS6FD6 HrCU25yiktJO02CAZ0CnIDy1bp5dQezP1AwNQz4Jw9o2MDc7kT68r3L/isaSDcI4 5UzjaiZYjLDhagMQZHrjnLu4DnoBI1Z0=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 92DB36B0081 for ; Thu, 12 May 2011 10:34:31 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1544073vxg.31 for ; Thu, 12 May 2011 10:34:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.199 with SMTP id cc7mr644895vdc.197.1305221670974; Thu, 12 May 2011 10:34:30 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 10:34:30 -0700 (PDT)
In-Reply-To: <4DCC03FD.3070608@dcrocker.net>
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>
Date: Thu, 12 May 2011 12:34:30 -0500
Message-ID: 
From: Nico Williams 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:34:32 -0000

On Thu, May 12, 2011 at 10:59 AM, Dave CROCKER  wrote:
> On 5/11/2011 10:05 AM, Pete Resnick wrote:
> AS is a failed experiment. =C2=A0The failure was complete and not a matte=
r of
> opinion.

Given that we never issue any anymore, I agree.  Heck, I was never
even aware of ASes as a document type.

Are there any RFCs that are ASes?  Why did AS fail?

> If you want to repeat it, you need to change the conditions, and explain =
how
> those changes are likely to make it succeed this time.

Sure, but a little more background as to why AS failed might help.

Right now I have no opinion on this subject.

Nico
--

From sm@resistor.net  Thu May 12 10:38:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF35E0767 for ; Thu, 12 May 2011 10:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPUa26F8pnqT for ; Thu, 12 May 2011 10:38:28 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F6BE0758 for ; Thu, 12 May 2011 10:38:27 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4CHcHNf011651;  Thu, 12 May 2011 10:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1305221904; bh=zqBY0s01W51uVoIJfX7UIj4wGfb7uyP1cKqGn5mpWmk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=QZXh2XZVV/VSBrBhLQklm3ri3YpQdyn8ufRlCLv5NzthMbI24LF8D/qsNEpL3fZok xaAQt9WpF/JV43rkPh45yiJq32XAz7XkMl/BuaVr1QUcIk5kpEeGqRNcPQv9bASb9S ZC0HeaRSMu3pynGY+Jz6+LJBi8y6PD7wgz6juZPg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1305221904; bh=zqBY0s01W51uVoIJfX7UIj4wGfb7uyP1cKqGn5mpWmk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=vjeJVrEfb6nGjMk7YrjlHuB15C4ttUEYm4fQcz4H7seaWjTY+5WEpZuxB8ftiqUl/ 7LXggjHSIDeISjoGkM24Am3JxxmKNLM5xzRHo9t5pG15JpgQaJtJECeXCvuE7dvn37 mN//ubYit7OMY7uIzKoWm1szYuch18UtlRZMRu7w=
Message-Id: <6.2.5.6.2.20110512084206.048c5280@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 12 May 2011 10:08:05 -0700
To: John C Klensin 
From: SM 
In-Reply-To: <35CAD4FD66C1EDA5E82D49F8@PST.JCK.COM>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com> <6.2.5.6.2.20110511141027.032dd408@resistor.net> <35CAD4FD66C1EDA5E82D49F8@PST.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Apps Discuss 
Subject: Re: [apps-discuss] On "supporting the publication of this document" (was: Re: We have no lambs (was: Applicability Statements))
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:38:32 -0000

Hi John,
At 07:20 12-05-2011, John C Klensin wrote:
>I think you may have missed my point, although the style I adopt
>in the IETF rarely results in my being accused of saying things
>to be politically correct.  :-)

I was commenting on the two different angles.  I should not have used 
"politically correct" as it is an incorrect description.

>The determination the IESG needs to make is multidimensional.
>There is no agreed-upon statement of the dimensions, but I would
>try the following as components.  They should require different
>levels of certainty at different maturity levels, e.g., for
>Proposed Standard, "no known technical defects" is supposed to
>be adequate while, for higher levels, there should be some
>conviction that no such defects exist, not merely that no one
>has noticed.

Agreed.

[snip]

>(4) Do enough people in the community care about this spec that
>the IETF should put its stamp of approval on it?
>
>A "I think this is ok and should be published" statement may be
>very useful for (4), especially for non-WG documents.   One
>important characteristic of (4) is that the IESG actually does
>have to count, even if the counting process doesn't correspond
>to normal arithmetic.  For (1)-(3) high-information-content
>technical arguments are important, especially if they take a
>"don't publish" or "don't publish without..." position.  And, at
>least in theory, there is no counting at all -- it doesn't make
>any difference if a particular technical position is stated by
>one person or by five (whether explicitly or by "+1"
>endorsement): the issue should be the contents of that position.

I'll say yes to the above without going into the details.  As a 
comment on the "+1", I'll refer to Ted Hardie's comment about "context" [1].

[snip]

>I think the only thing that is unusual about Pete's approach is
>that he is trying to be explicit about the criteria he is going
>to use to evaluate and weight comments.  I think that is A Good
>Thing, but I don't think the criteria he suggests are in any way
>new or unusual.

My comment was not about the criteria; it was more about posting a 
message about the thinking.  It is not always an easy decision for 
the individual making the determination.  Should the person be open 
about how he or she will make the decision?  There are two choices:

  (i)  Stick to text from BCPs when making public statements and not voicing
       out any thoughts that might be misconstrued as bias.

  (ii) Be candid about likes and dislikes while being able to overcome the
       dislikes to avoid being biased.

The first option leaves people to second guess what the person might 
decide.  It is the favored option and it leaves less room for people 
to object to the decision.  The second option is interesting; people 
can come up and say "excuse me, you may have overlooked the '+1' 
posted by person X who is not a well-known suspect.  Person X is 
working on this specification".

If the community prefers to have ADs who have made it through Swiss 
finishing school, it won't see statements of support such as the 
"Walled Garden Standard" [2].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02580.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg50789.html 


From nico@cryptonector.com  Thu May 12 10:47:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A071FE06A1 for ; Thu, 12 May 2011 10:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4LdLI3MI3-D for ; Thu, 12 May 2011 10:47:05 -0700 (PDT)
Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29EBFE0679 for ; Thu, 12 May 2011 10:47:05 -0700 (PDT)
Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id EF9D87E4073 for ; Thu, 12 May 2011 10:47:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mKXTn/Wvz70PEB/h76mdXH5x2q8jKzqaxA3JN2DKcYIc PfRMSZ4P4ZK7QWgg3/srJp6PkM4UnoyJQizov/79f/DBbKwZGTzrYhcjjeDqO8M1 LVz87Obv97E/SK1+FmKRs6E5+o/R1iO62J2jzEpQAAbuEQ+JQAM3O37CKZbsAfo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=nxnDy70fRU6xodfSjSRcpH4ejog=; b=ot/b07Tfmac jYTw6HWEV89JpJL5shswBkDye5TZhgWvBU77ONp0ssQym+ZJ7UfElpLdRnvjceiI knhCCcSNuUYRnfSFLRQIKUlqI9BMerBQXWZYklBoy83rTPZpNBB36r6545aMgRIB 5K6urbE55X7yNnDflowL3zet4TP9rJjE=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id B3B1B7E4072 for ; Thu, 12 May 2011 10:47:04 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1553554vxg.31 for ; Thu, 12 May 2011 10:47:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.96.71 with SMTP id dq7mr651649vdb.157.1305222423956; Thu, 12 May 2011 10:47:03 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 10:47:03 -0700 (PDT)
In-Reply-To: <4DCC19A8.3070807@dcrocker.net>
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <4DC9A557.9040504@qualcomm.com> <4DCAFB2A.8030408@dcrocker.net>  <4DCC0257.1050705@dcrocker.net>  <4DCC19A8.3070807@dcrocker.net>
Date: Thu, 12 May 2011 12:47:03 -0500
Message-ID: 
From: Nico Williams 
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:47:05 -0000

On Thu, May 12, 2011 at 12:32 PM, Dave CROCKER  wrote:
> On 5/12/2011 10:24 AM, Nico Williams wrote:
>> On Thu, May 12, 2011 at 10:52 AM, Dave CROCKER =C2=A0w=
rote:
>> I prefer dispassionate argument
>
> This isn't about passion (1st definition) but well might be about partial=
ity
> from experience (2d/3rd definition).
>
> Note that your own alternative example actually demonstrates that:

Are you referring to dictionary definitions?  If so, which dictionary?
 As to my example, see below.

>> Neither. =C2=A0I'd prefer:
>>
>> =C2=A0 =C2=A0 I believe the proposed design will not scale well for the
>> following reasons:. =C2=A0[optional]
>
> How is the random reader to know that the speaker has that experience,
> unless it is declared.

I'm asserting that it is possible, at least sometimes (I gave a
real-world example from this very week, thus I have an existence
proof), to distill information from experience such that the
information stands alone.  I'm also asserting that whenever that is
possible, it's also preferable over stating experience as an
authority.  I'm also asserting that we might otherwise fall into a
habit of using the argument from authority fallacy as a mode of
argument.

> Yes, it is better to state well-known or obvious facts. =C2=A0("This call=
s for a
> very large table but uses a linear search and that won't scale".)
>
> However many interesting problems involve judgment about what will work.
> Experience of the speaker informs the likelihood that their opinion is
> well-founded.

Indeed, and I don't argue that personal experience should be left out
of the speaker's statements.  I'm arguing that it shouldn't be
*required*, not even strongly recommended.  I believe the speaker will
figure out from others reactions when his statements are unconvincing
and when to reach for personal experience (in the hopes that others
will be better able to distill useful information from it, as opposed
to in the hopes of winning an argument from authority).

Moreover, I think this sub-thread is a bit of a waste of time.  It
seems quite contrary to the spirit of the IETF, and thus also risible,
that IETF LC participants should have to open their posts with any
sort of boilerplate designed to state their authority, or anything
remotely resembling the same.  I'm shocked that anything even
resembling such a thing is being proposed, and I hope I just horribly
misunderstood the actual proposal.

>> This comes from having observed similar failures in the field
>> .
>
> I'd class this as a useful version of what I was trying to describe. =C2=
=A0Glad
> to see we agree...

To the extent that I get a whiff of a proposal to require that
participants lead their arguments this way, I disagree, vehemently.
Otherwise we do agree, or at least fail to disagree (indeed, I might
not care enough to agree or not).

Can we get a clear statement as to what's being proposed?  If I
misread it, either I'm a poor reader or the proposal is not clear.

Nico
--

From presnick@qualcomm.com  Thu May 12 11:02:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9645E06D5 for ; Thu, 12 May 2011 11:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8lCPzpTfbi4 for ; Thu, 12 May 2011 11:02:26 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 066D8E06A1 for ; Thu, 12 May 2011 11:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305223346; x=1336759346; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCC20AF.7060206@qualcomm.com>|Date:=20Th u,=2012=20May=202011=2013:02:23=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Nico=20Williams=20|CC:=20,=20Apps=20Discuss =20|Subject:=20Re:=20[apps-discuss ]=20Applicability=20Statements|References:=20<4DCAC1CB.30 50905@qualcomm.com>=09<4DCC03FD.3070608@dcrocker.net>=20< BANLkTikU79k4iR+rSYXKsXKzhW1w-EKKbg@mail.gmail.com> |In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"IS O-8859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-Originating-IP:=20[172.30.39.5]; bh=8i8RDwe3zTlpyLeE4BAX2+1lRoErfoROQoHruHH036g=; b=tJGHpoSRIT3qtiKzT8GRVelTdVjrrKPZBCY8xgRP8wrcLvjN7vmzmWAd luTbGyuM2OjSCn7nABHAGT029rVYOodVWxadNaFVZrScvFpQXyS6N/zBd bU7dG6bf46iRmfzjIp/076x4bPkgWpHSG7idUGusvd6tMk2lTEH41DQ5W I=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="90853250"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 12 May 2011 11:02:25 -0700
X-IronPort-AV: E=Sophos;i="4.64,358,1301900400"; d="scan'208";a="73060265"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 12 May 2011 11:02:25 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 11:02:24 -0700
Message-ID: <4DCC20AF.7060206@qualcomm.com>
Date: Thu, 12 May 2011 13:02:23 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Nico Williams 
References: <4DCAC1CB.3050905@qualcomm.com>	<4DCC03FD.3070608@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:02:26 -0000

On 5/12/11 12:34 PM, Nico Williams wrote:
> On Thu, May 12, 2011 at 10:59 AM, Dave CROCKER  wrote:
>    
>> AS is a failed experiment.  The failure was complete and not a matter of
>> opinion.
>>      
> Given that we never issue any anymore, I agree.  Heck, I was never
> even aware of ASes as a document type.
>    

So I would not characterize this as a "failed" experiment. I would 
characterize it as an "unimplemented" experiment. To wit: If I say, 
"Gee, it think it would be very beneficial if we substituted broccoli 
for the cookies during IETF meeting breaks; I propose that we run an 
experiment to put out broccoli and see if it is beneficial" and the 
secretariat (because they are wise folks) don't ever try putting out 
broccoli instead of cookies, I would not say that the broccoli 
experiment "failed". It was never tried. Who knows...it might have been 
successful if tried.

Nobody ever really tried what was described in 2026. For whatever reason 
(I think mostly because 2026 was ambiguous), people started publishing 
the types of documents we are talking about as BCPs instead of 
standards-track BCPs. I am simply suggesting that we actually *start* 
the experiment that 2026 envisions: Separate out certain kinds of 
documents we've to date been labeling as BCPs and make put them into the 
standards-track as AS.

> Are there any RFCs that are ASes?

There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as 
BCPs. The experiment is really not introducing ASs per se. The 
experiment is to put them on the standards track and call them out as 
2026 AS documents.

There is no evidence whatsoever that the experiment failed. That's not a 
matter of opinion.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From nico@cryptonector.com  Thu May 12 11:05:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA986E0706 for ; Thu, 12 May 2011 11:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=-0.533,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYd43ZF+uEf for ; Thu, 12 May 2011 11:05:58 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 63A62E06D5 for ; Thu, 12 May 2011 11:05:58 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id F36482F406D for ; Thu, 12 May 2011 11:05:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=rxij7etleTsc0GtLa7huZ cMJQzMgezhhLEj2inHuxCm2iwrlAX7ex+ZtplKo59XxPrgnQUBinC919vLjid2O2 ZcDroJZg0acDByr1HqVtmlRtwkCZWrIodei7XNHbvGeqZo4VlskvT778jiX//O9w rYXa6tanEFihY52qyVc1QE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=p2Y/RTyhuRdI0RNYdXoM 7YCwCpo=; b=e3rL5ZifyBUmZgFSe9/uR4HZpYOzUEWelE5bmki4tGY6n54S/jHE RO+6YcKmFSYHvM4t6DYLCsul/ELdyxFoBZPXvd/1xLj3qk0067rfj9kd9cDv/r2K 2FwG4j7n9cCF7njE7oJnoi/+nc7ftqo+9xtChHRzYS0UjHfjEJkpcAQ=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id C0F472F4055 for ; Thu, 12 May 2011 11:05:57 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1567801vxg.31 for ; Thu, 12 May 2011 11:05:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.99 with SMTP id bz3mr713425vdc.117.1305223557090; Thu, 12 May 2011 11:05:57 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 11:05:57 -0700 (PDT)
In-Reply-To: <4DCC20AF.7060206@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>
Date: Thu, 12 May 2011 13:05:57 -0500
Message-ID: 
From: Nico Williams 
To: Pete Resnick 
Content-Type: text/plain; charset=UTF-8
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:05:59 -0000

On Thu, May 12, 2011 at 1:02 PM, Pete Resnick  wrote:
>> Are there any RFCs that are ASes?
>
> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as
> BCPs. The experiment is really not introducing ASs per se. The experiment is
> to put them on the standards track and call them out as 2026 AS documents.

Let me rephrase: are there Standards-Track BCPs?  The RFC-Editor RFC
Search tool does not allow me to search for RFCs that are both, BCPs
and on the Standards-Track, thus making a search for such a thing
difficult.

Nico
--

From presnick@qualcomm.com  Thu May 12 11:09:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A1E06DD for ; Thu, 12 May 2011 11:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfyhb46CKuMl for ; Thu, 12 May 2011 11:09:22 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0C358E06C8 for ; Thu, 12 May 2011 11:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305223762; x=1336759762; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCC2250.8080603@qualcomm.com>|Date:=20Th u,=2012=20May=202011=2013:09:20=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Nico=20Williams=20|CC:=20,=20Apps=20Discuss =20|Subject:=20Re:=20[apps-discuss ]=20Applicability=20Statements|References:=20<4DCAC1CB.30 50905@qualcomm.com>=20<4DCC03FD.3070608@dcrocker.net>=09< BANLkTikU79k4iR+rSYXKsXKzhW1w-EKKbg@mail.gmail.com>=09<4D CC20AF.7060206@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20tex t/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=N+LXdSOt15Kl+5hu6vqCI7HM7z6Cj4D8b5N+bN9ZUcA=; b=QKuBjiCW0C4nWmSUVPxghF69IU+NPjRtdH6eMOmfbfO0ebMaBU4/fhDw apQp9tCvCVizEEyaVgayvBIUUTX2qqkFd3qL9I0WB0OagVEpC59xa4m6G qRNG0Ls3tY3RYDwRJ7zkgUlbX1zZCrW/Ohp1BCB0YVFVPX5a4YLjMALNG s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="91052605"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 12 May 2011 11:09:21 -0700
X-IronPort-AV: E=Sophos;i="4.64,358,1301900400"; d="scan'208";a="51978549"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 12 May 2011 11:09:21 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 11:09:21 -0700
Message-ID: <4DCC2250.8080603@qualcomm.com>
Date: Thu, 12 May 2011 13:09:20 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Nico Williams 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>		<4DCC20AF.7060206@qualcomm.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:09:23 -0000

On 5/12/11 1:05 PM, Nico Williams wrote:
> On Thu, May 12, 2011 at 1:02 PM, Pete Resnick  wrote:
>    
>>> Are there any RFCs that are ASes?
>>>        
>> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as
>> BCPs. The experiment is really not introducing ASs per se. The experiment is
>> to put them on the standards track and call them out as 2026 AS documents.
>>      
> Let me rephrase: are there Standards-Track BCPs?  The RFC-Editor RFC
> Search tool does not allow me to search for RFCs that are both, BCPs
> and on the Standards-Track, thus making a search for such a thing
> difficult.
>    

Ah. No, in 2026, BCPs cannot be Standards-Track and Standards-Track 
documents cannot be BCPs. They are mutually exclusive categories.

The problem is that there are some things that we've been making BCPs 
(i.e., AS documents) that I think would be better served by being 
Standards-Track. The experiment is (for future documents of this sort) 
that we try Standards-Track instead of BCP for ASs.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From nico@cryptonector.com  Thu May 12 11:34:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C8E06D5 for ; Thu, 12 May 2011 11:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx11MQqUfZZD for ; Thu, 12 May 2011 11:34:15 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 53935E06A1 for ; Thu, 12 May 2011 11:34:15 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 2A985B806D for ; Thu, 12 May 2011 11:34:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=scBogi1nS62u8Z16YVrb60+FUWRsk2pwkhgwPhUyQscV Qx9H9yj1QUm4Y5ihjjSdlq8svL5m/gN3Vr9seo36hWY8PVZzIOrXvZbBcEUgmkGH z5IbOwWKhoPj3KUmqNhEc9F+Efx/9WHNYbTlJnMqMqMuONlqrgN1LOeZyQmkU3A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/dUjOjUOcaGrteVdt/QwmwJhyOA=; b=RNBbaC198Su Fc2Ftmfl1SuNl4kqMks//K93yRB+2bWEyyTgEeSETafFegnsYk6KTWqU0F+8nemq gUWeDWoAVMlhQKNlOvOHbWe9scXPhPeAUmUeh3yxIOdv5XhJCvM/GXPdJeSfdpTl v+60MvNQmDWMD/gNfDOu+pQljcJKXtzM=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id F1C3EB806B for ; Thu, 12 May 2011 11:34:14 -0700 (PDT)
Received: by vws12 with SMTP id 12so1597093vws.31 for ; Thu, 12 May 2011 11:34:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.99 with SMTP id bz3mr757540vdc.117.1305225254404; Thu, 12 May 2011 11:34:14 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 11:34:14 -0700 (PDT)
In-Reply-To: <4DCC2250.8080603@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>  <4DCC2250.8080603@qualcomm.com>
Date: Thu, 12 May 2011 13:34:14 -0500
Message-ID: 
From: Nico Williams 
To: Pete Resnick 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:34:16 -0000

On Thu, May 12, 2011 at 1:09 PM, Pete Resnick  wrote=
:
> On 5/12/11 1:05 PM, Nico Williams wrote:
>>>> Are there any RFCs that are ASes?
>>>
>>> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as
>>> BCPs. [...]
>>
>> Let me rephrase: are there Standards-Track BCPs? =C2=A0[...]
>
> Ah. No, in 2026, BCPs cannot be Standards-Track and Standards-Track
> documents cannot be BCPs. They are mutually exclusive categories.

Let me go back to my original phrasing then: are there any existing
ASes?  I'm not asking if there's BCPs that should have been ASes.

I note that the RFC-Editor has an index of BCPs, STDs, FYIs, and RFCs,
but no index of ASes.  I take this to mean that there are no ASes.

Another question: if there are indeed no ASes as such, have there ever
been any attempts to publish any such?  My guess is the answer is
"no", in which case the "experiment" hasn't failed -- it hasn't been
attempted.

Nico
--

From dhc@dcrocker.net  Thu May 12 11:42:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465E2E06A1 for ; Thu, 12 May 2011 11:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.585
X-Spam-Level: 
X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKD9WQULk2jI for ; Thu, 12 May 2011 11:42:23 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E5E062A for ; Thu, 12 May 2011 11:42:23 -0700 (PDT)
Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CIgF5v017574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 May 2011 11:42:21 -0700
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <4DCC20AF.7060206@qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dave Crocker 
Date: Thu, 12 May 2011 11:42:14 -0700
To: Pete Resnick , Nico Williams , Pete Resnick , Nico Williams 
Message-ID: 
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 11:42:21 -0700 (PDT)
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:42:24 -0000

Pete Resnick  wrote:

>On 5/12/11 12:34 PM, Nico Williams wrote:
>> On Thu, May 12, 2011 at 10:59 AM, Dave CROCKER 
>wrote:
>>    
>>> AS is a failed experiment.  The failure was complete and not a
>matter of
>>> opinion.
 ...
>> Are there any RFCs that are ASes?
>
>There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as
>
>BCPs. 

That is facile, but it lacks rough consensus.  It eve lacks a clear statement of basis.


>The experiment is really not introducing ASs per se. The 
>experiment is to put them on the standards track and call them out as 
>2026 AS documents.
>
>There is no evidence whatsoever that the experiment failed. That's not
>a. matter of opinion.

how long do we have to wait for a spec to be unused, before being able to calling it a failure?

failure to garner interest is a failure.

while it might be quibbling about versions, AS docs HAVE been tried,  The community never got comfonrtable with their purpose or form.


d/
--
Dave Crocker
bbiw.net

From nico@cryptonector.com  Thu May 12 11:47:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EDDE0718 for ; Thu, 12 May 2011 11:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.404
X-Spam-Level: 
X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8KxhQ+GEwq0 for ; Thu, 12 May 2011 11:47:38 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0EE06D5 for ; Thu, 12 May 2011 11:47:38 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 91F9150807A for ; Thu, 12 May 2011 11:47:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=G1pJ7lJV8CY1VzYKLx+gDOqyEJsXiYkBV9wrK0ORO/94 H1gVWPZoB7+nbeanHhYCg4StfM+oSwnzy2hrasZ/lWHfzUZ5o/QdzZrkCQPYRNze /b6Gogm4wBo2OzxgcCQtzH831JW0jU7tltz5+39M4jKjbk2jyVCMK33+Sorhj+E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=SF1eDmdrHfO6XFL9u/YkXjJvHt4=; b=Hx1EZ7nd7/B 36vd7ziDRDnI3F29iJ58D0W28vHAz3QMfMA73YU//fmr17mXeKN5h26vgPrOq1dj GZfMwO7yAah34jvabarLbrBQQBzx/E+/4tERQMikloIFHSkTV5DfKtxGKphLc6/A GONFbf0xOx7smLAtRF8kBBaPb+bhyIdk=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id DFD70508081 for ; Thu, 12 May 2011 11:47:22 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1600483vxg.31 for ; Thu, 12 May 2011 11:47:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.96.71 with SMTP id dq7mr740502vdb.157.1305226009197; Thu, 12 May 2011 11:46:49 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 11:46:49 -0700 (PDT)
In-Reply-To: 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com> 
Date: Thu, 12 May 2011 13:46:49 -0500
Message-ID: 
From: Nico Williams 
To: Dave Crocker 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:47:38 -0000

On Thu, May 12, 2011 at 1:42 PM, Dave Crocker  wrote:
> while it might be quibbling about versions, AS docs HAVE been tried, =C2=
=A0The community never got comfonrtable with their purpose or form.

Out of curiosity, if nothing else, can you point me an some examples?

From dcrocker@bbiw.net  Thu May 12 11:55:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14ABE0684 for ; Thu, 12 May 2011 11:55:30 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXbUNSu-ow8O for ; Thu, 12 May 2011 11:55:29 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 022FEE0718 for ; Thu, 12 May 2011 11:55:29 -0700 (PDT)
Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CItMms017928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 May 2011 11:55:28 -0700
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>  
User-Agent: K-9 Mail for Android
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dave Crocker 
Date: Thu, 12 May 2011 11:55:20 -0700
To: Nico Williams , Dave Crocker 
Message-ID: 
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 11:55:28 -0700 (PDT)
Cc: Pete Resnick , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:55:30 -0000

Nico Williams  wrote:

>On Thu, May 12, 2011 at 1:42 PM, Dave Crocker  wrote:
>> while it might be quibbling about versions, AS docs HAVE been tried,
> The community never got comfonrtable with their purpose or form.
>
>Out of curiosity, if nothing else, can you point me an some examples?

google ietf applicability statement

d/

d/
--
Dave Crocker
bbiw.net

From nico@cryptonector.com  Thu May 12 12:05:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1AE0758 for ; Thu, 12 May 2011 12:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level: 
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXv0wDOrQZiA for ; Thu, 12 May 2011 12:05:40 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBF7E0718 for ; Thu, 12 May 2011 12:05:40 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E429D678062 for ; Thu, 12 May 2011 12:05:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=EoKKj0n9hHlhxhVyIEEinEl7VG7Fez1f0mm3PifYNvfz uttU4IB2mo1FBj2NQVIlALh1aksiEulmrRyLQ8ZpF92WDsl8TjvFPxgZdjBx+/Tk q28mq1Ca05RN28LjXgcgPybWwVaUljC1m/Pneo8gzFWOjEVNOh80Gf/COknPFE0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FwCIUD58YEvti2F0mQhAEZIDudM=; b=kWT3bHS4PSy lgRIyuZcRbwtamnXC29GS/SBDZq+5PkdELMmKGOOsnMA0iu3E9p6GxapdrwOyT3x f5wKjE1ixuK3fKJYJHUrFJS0ZwfI40dVATK7mC0K1pZtEVibuVVyHY4rgrP2b4yH sTR1SeaN9ULQbAk6VUbJ9MXklw3q0+PM=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 0AAD7678069 for ; Thu, 12 May 2011 12:05:32 -0700 (PDT)
Received: by vws12 with SMTP id 12so1623129vws.31 for ; Thu, 12 May 2011 12:05:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.175.199 with SMTP id cc7mr785162vdc.197.1305227132453; Thu, 12 May 2011 12:05:32 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 12:05:32 -0700 (PDT)
In-Reply-To: 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>   
Date: Thu, 12 May 2011 14:05:32 -0500
Message-ID: 
From: Nico Williams 
To: Dave Crocker 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 19:05:41 -0000

On Thu, May 12, 2011 at 1:55 PM, Dave Crocker  wrote:
> Nico Williams  wrote:
>
>>On Thu, May 12, 2011 at 1:42 PM, Dave Crocker  wrote:
>>> while it might be quibbling about versions, AS docs HAVE been tried,
>>=C2=A0The community never got comfonrtable with their purpose or form.
>>
>>Out of curiosity, if nothing else, can you point me an some examples?
>
> google ietf applicability statement

Actually, this is better: ietf "applicability statement" "Intended
status: standards".

Also: ietf "applicability statement" "category: standards"

So there are standards-track ASes, and there have been I-Ds with
intended status of standards track and with "applicability statement"
in the title.

How has this "experiment" failed then?

Nico
--

From msk@cloudmark.com  Thu May 12 12:07:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B29E078B for ; Thu, 12 May 2011 12:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.099
X-Spam-Level: 
X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXx1lJ2eKTSQ for ; Thu, 12 May 2011 12:07:10 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 34532E0718 for ; Thu, 12 May 2011 12:07:10 -0700 (PDT)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 May 2011 12:07:09 -0700
From: "Murray S. Kucherawy" 
To: "apps-discuss@ietf.org" 
Date: Thu, 12 May 2011 12:07:09 -0700
Thread-Topic: [apps-discuss] App-ADs chatroom
Thread-Index: AcwQhDZdgFgVEDx5SQil8dIFcLVV+AAU4ocQ
Message-ID: 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>
In-Reply-To: <4DCBA219.4070402@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 19:07:10 -0000

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org=
] On Behalf Of Graham Klyne
> Sent: Thursday, May 12, 2011 2:02 AM
> To: Peter Saint-Andre
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] App-ADs chatroom
>=20
> Do I need to be "authorized" to join in?  My client (MacOS/Adium) seems t=
o think
> so, but maybe I'm just doing it wrong.  So far I've only used XMPP for
> person-to-person chat - is a chatroom significantly different to use?

Ditto for me just now with Pidgin.

From john-ietf@jck.com  Thu May 12 12:11:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570E1E0723 for ; Thu, 12 May 2011 12:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTtojWFAGpFc for ; Thu, 12 May 2011 12:11:27 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id AE7FEE0718 for ; Thu, 12 May 2011 12:11:27 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QKbIE-000D5S-Kh; Thu, 12 May 2011 15:11:26 -0400
Date: Thu, 12 May 2011 15:11:25 -0400
From: John C Klensin 
To: Nico Williams 
Message-ID: <896CE22253B47335BBCAF0A0@PST.JCK.COM>
In-Reply-To: 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>  
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 19:11:28 -0000

--On Thursday, May 12, 2011 13:46 -0500 Nico Williams
 wrote:

> On Thu, May 12, 2011 at 1:42 PM, Dave Crocker
>  wrote:
>> while it might be quibbling about versions, AS docs HAVE been
>> tried, =C2=A0The community never got comfonrtable with their
>> purpose or form.
>=20
> Out of curiosity, if nothing else, can you point me an some
> examples? ___

RFCs 1122 and 1123 (or at least large fractions of them)?

Many other documents contain both TS and AS components.  As far
as I know, no one has ever tried to interpret "fall into one of
two categories" (RFC 2026 Section 3) as implying a requirement
for two separate documents unless they were trying to kill a
specification procedurally without addressing its content.  The
language of 2026 seems to make any text that specifies
requirements or conformance part of the AS domain.

   john



From stpeter@stpeter.im  Thu May 12 12:15:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9FBE0723 for ; Thu, 12 May 2011 12:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbg5mWVQ0GIk for ; Thu, 12 May 2011 12:15:16 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC518E0718 for ; Thu, 12 May 2011 12:15:15 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D49AC400A6; Thu, 12 May 2011 13:15:14 -0600 (MDT)
Message-ID: <4DCC31C2.1080405@stpeter.im>
Date: Thu, 12 May 2011 13:15:14 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010808070106040203070509"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 19:15:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms010808070106040203070509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/12/11 1:07 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.=
org] On Behalf Of Graham Klyne
>> Sent: Thursday, May 12, 2011 2:02 AM
>> To: Peter Saint-Andre
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] App-ADs chatroom
>>
>> Do I need to be "authorized" to join in?  My client (MacOS/Adium) seem=
s to think
>> so, but maybe I'm just doing it wrong.  So far I've only used XMPP for=

>> person-to-person chat - is a chatroom significantly different to use?
>=20
> Ditto for me just now with Pidgin.

The room is not set to be members-only or password-protected (although
those are possibilities in XMPP), so anyone can join.

Also, conversations in the room are not logged. This enables Pete and me
to hold off-the-record chats with folks who stop by, if needed.

Peter

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




--------------ms010808070106040203070509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MjE5MTUxNFowIwYJKoZIhvcNAQkEMRYEFGRaILfpF+1MOs4+uiN6SogTHrWBMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQChWPBB4JD9YWwuIWgwehjh4sBHKMlHM0OMpqM1HGmmmoqvaGKALl6FXkTc
/gz9x5TqoVO0cXG/Vi/o0b10O1nThwwdxtkSwAnut7O3TVieqPQJ3JjWrNRGpBe+D7ijAE8g
payv8grd4OYSDSgTLIw0LiXw44ZZdI2H3sW6kVThUTWUfQ0WEAV/DlQyw7y5hSK+SfLrBvUW
dbnQegVZ6gZVJwuo9bkgG1tNnHfVNEugZZiyFN2xN1FnW+Li45lh5Ms9CZoDc/vQbcQIsy/x
0baUoMVwbmqqHrXar29GinMsoKanH18ndtiz+dr3icmSfP85MDElmHwTwqUyYScYxvQ2AAAA
AAAA
--------------ms010808070106040203070509--

From presnick@qualcomm.com  Thu May 12 13:24:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF6E0717 for ; Thu, 12 May 2011 13:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKd0UpVQoU5O for ; Thu, 12 May 2011 13:24:15 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2E45FE06A1 for ; Thu, 12 May 2011 13:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305231855; x=1336767855; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCC41E7.3090608@qualcomm.com>|Date:=20Th u,=2012=20May=202011=2015:24:07=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Dave=20Crocker=20|CC:=20Nico=20Williams=20,=20 ,=20Apps=20Discuss=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20Applicabil ity=20Statements|References:=20<4DCAC1CB.3050905@qualcomm .com>=20<4DCC03FD.3070608@dcrocker.net>=09=09<4DCC20AF.7060206 @qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/plai n=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=lrxh3Okz3PwcrygtS7zB+HMCuglXtvCti1zmoJhJKYY=; b=a/yk/MpQgGZLKNzoStPy8GjdEt/K+trrFXbqedMEAuO7j8CSc6lYVjDs QfX9MoQmzHn+0KAIZzMbq0B1kWDyAc2lEX+78Wh9JKJP/bWGrIHIgqHz0 Cws5UmsVJANtWCZWpZvfdohOHc7D7qUSwgWIPP72IsHkMeapO+18tiwJB c=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="91080835"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 12 May 2011 13:24:09 -0700
X-IronPort-AV: E=Sophos;i="4.64,358,1301900400"; d="scan'208";a="52046870"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 12 May 2011 13:24:09 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 13:24:08 -0700
Message-ID: <4DCC41E7.3090608@qualcomm.com>
Date: Thu, 12 May 2011 15:24:07 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Dave Crocker 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>		<4DCC20AF.7060206@qualcomm.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: dcrocker@bbiw.net, Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:24:16 -0000

On 5/12/11 1:42 PM, Dave Crocker wrote:

> Pete Resnick  wrote:
>
>    
>> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as BCPs.
>>      
> That is facile, but it lacks rough consensus.  It eve lacks a clear statement of basis.
>    

If you are talking about the first sentence, your statement is clearly 
false. As I said in my first message, there are a list of things that 
2026 envisions as ASs:

     "identifies the relevant TSs and the specific way in which they are 
to be combined"
     "specify particular values or ranges of TS parameters or 
subfunctions of a TS protocol that must be implemented"
     "specifies the circumstances in which the use of a particular TS is 
required, recommended, or elective"
     "describe particular methods of using a TS in a restricted 'domain 
of applicability'"
     "comprehensive conformance specification"

I'm happy to point out many of the above types of documents ("oodles" if 
you prefer) that are currently published as BCPs.

If you're complaint is with the second sentence (that as far as I can 
tell all of these ASs are labeled as BCPs), well, I concede the point. 
I'm sure there are Informational documents that are of the above 
categories. And parts of standards track documents. But there are an 
awful lot of these that are published as BCPs, and it is docs of that 
type (AS intended status: BCP) that I wish to put on the standards track.

>> The experiment is really not introducing ASs per se. The
>> experiment is to put them on the standards track and call them out as
>> 2026 AS documents.
>>
>> There is no evidence whatsoever that the experiment failed. That's not
>> a matter of opinion.
>>      
> how long do we have to wait for a spec to be unused, before being able to calling it a failure?
>    

Well, now you've changed horses. Are we talking about the experiment 
failing or are we talking about a spec being a failure? Again, I'm happy 
to concede that section 3.2 and 3.3 of 2026 have not been implemented. 
The reasons it hasn't been implemented are debatable. I've mentioned 
ambiguity. There are actually a couple of weird contradictions in 2026 
around this topic. But I'm not sure what that has to do with whether or 
not it's a good idea to try to put certain kinds of documents on the 
standards track.

> failure to garner interest is a failure.
>    

Well, if that is one of the criteria, then I'd say that a half dozen 
people on this list actually *expressing* "interest" (with reasons) and 
the IESG being "interested" is a good initial sign. But the failure of 
one document to garner interest is not itself evidence that the idea is 
of interest. Now I've got a little prima facia evidence that there is 
some interest in my expression of this idea. I'm happy enough with that.

> while it might be quibbling about versions, AS docs HAVE been tried,  The community never got comfonrtable with their purpose or form.
>    

Uh, now who's making statements without a clear basis?

There is no doubt that there were AS documents prior to 2026 (1122 and 
1123 being good examples). There is no doubt that there are plenty of 
documents that fit the definitions of a 2026 AS that I quoted above 
(with many of them being published as BCP). You can't be arguing that 
the community never got comfortable with the purpose or form of ASs, as 
they demonstrably have, unless you're arguing that they never got 
comfortable with the purpose or form of standards track ASs. I'd like to 
hear some evidence for that conclusion, because I've seen scant few 
examples of the latter. Otherwise, you're simply saying that the 
community never got comfortable with broccoli instead of cookies at 
meeting breaks, and that's either equivocation or false.

(For the record, so far, I have Dave "in the rough" on this topic.)

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From presnick@qualcomm.com  Thu May 12 14:23:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38FE067C for ; Thu, 12 May 2011 14:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9qdHVuTJ384 for ; Thu, 12 May 2011 14:23:39 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 315ADE066E for ; Thu, 12 May 2011 14:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305235419; x=1336771419; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4DCC4FD6.4040205@qualcomm.com>|Date:=20Th u,=2012=20May=202011=2016:23:34=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20Apps=20Discuss=20|Subject:=20Re:=20[apps-discuss]=20We=20have=20no=20lamb s|References:=20<4DCAC1CB.3050905@qualcomm.com>=09<6.2.5. 6.2.20110511115259.051cd3f8@resistor.net>=09<4DCAF61F.100 00@qualcomm.com>=09<6.2.5.6.2.20110511141027.032dd408@res istor.net>=20|In-Reply-To:=20|Content-Type:=20multipart/alternative =3B=0D=0A=09boundary=3D"------------000204050901040005070 906"|X-Originating-IP:=20[172.30.39.5]; bh=cE72E98K1xX2Vw+9GBclp2K5S+c3mXiqZhy2S3CO5x0=; b=Dw9s8SS5IqLo55VmX7LQN24KpWXTkj11y293JOHYbtMHldCn8vsP2YGi IvOonVggXIlqBwOgn5L8Vbrw9OUwUZ+KotW5omfn9wm67bkBFx/rmKUEe zRhoFnFeUWwoNyRs4ciBFPYFDKqediP64wJgfOTu/Mz3bD58zr1ryx4xP c=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="90894208"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 12 May 2011 14:23:38 -0700
X-IronPort-AV: E=Sophos;i="4.64,358,1301900400"; d="scan'208,217";a="41620599"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 12 May 2011 14:23:38 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 14:23:36 -0700
Message-ID: <4DCC4FD6.4040205@qualcomm.com>
Date: Thu, 12 May 2011 16:23:34 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Barry Leiba 
References: <4DCAC1CB.3050905@qualcomm.com>	<6.2.5.6.2.20110511115259.051cd3f8@resistor.net>	<4DCAF61F.10000@qualcomm.com>	<6.2.5.6.2.20110511141027.032dd408@resistor.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000204050901040005070906"
X-Originating-IP: [172.30.39.5]
Cc: Apps Discuss 
Subject: Re: [apps-discuss] We have no lambs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:23:41 -0000

--------------000204050901040005070906
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

Let me say up front that I think this entire conversation is great, and 
I think we are all getting a great deal out of having it. I know I am. 
And I do agree with Barry on some of the more specific points, but I 
suspect that we will end up simply agreeing to disagree on the broader 
issue. And I do think it is worth having this conversation, because I 
hope it will lead to some understanding of not just my style, but my 
motives.

On 5/11/11 5:43 PM, Barry Leiba wrote:
> Hm.  I thought I wouldn't comment on this, but I think I will, because
> I want to make something clear about how I think about this.
>
> On Wed, May 11, 2011 at 5:39 PM, SM  wrote:
>    
>> At 13:37 11-05-2011, John C Klensin wrote:
>>      
>>> So, I wouldn't have said "useless".  I might have said "of very
>>> limited value in helping the IESG with its determination of
>>> consensus about technical quality and adequacy of review".
>>>        
>> That is the politically correct way of stating it.  It may help some people
>> understand what the IESG would like.  However, sentences like that are
>> against IETF best practices. :-)
>>
>> Pete has taken a rather unusual approach.  I would qualify it as open.  It
>> is to encourage discussion on an equal footing.
>>      
> Here's why I think being "politically correct" is important:
> If it's someone's manner to be blunt, and to expect that we won't take
> him *too* much at his exact words, that's fine, and we learn that.
> And if someone is wont to say "Eff all y'all.  I'm going to ignore any
> comments I choose to," well, again, we consider who's saying it and to
> what extent we think he really means that... and everyone has a right
> not to pay attention to anyone in particular.  Except....
>    

First, I don't think you'll find anywhere in my original note on the 
"support publication" thread that I said I would absolutely ignore or be 
closed to the input. I did say that I "find these 
statements...well...useless." I did say that such commentary on the 
publication itself is "really, truly, not important." And I did joke 
(smiley face included) that I would have to assume that the reason for 
such a statement is "because you have a wager on how soon we will get to 
RFC 10000. :-)" But I never did say I'd ignore them. I did say later (in 
reference to Ted's comments) that I "*might* ignore comments that come 
without context because there really is no way to evaluate what they 
mean", but that's just to say that if I can't figure out the meaning of 
a statement, it's simply not going to impact my thinking on a particular 
topic. But all of this is somewhat less important than what follows:

> When someone accepts a position on the IESG, the IAB, or the IAOC --
> I*, as we collectively call them -- s/he no longer gets to be the
> gruff "eff all y'all" person s/he once may have been.  S/he has to
> support the open system we have, and not be closed to input.  That's
> why someone on I* saying "I won't listen unless you say it the way I
> want to hear it," bothers me.  That's why I think it's important to
> put it more the way John did -- so people understand that you're not
> just brushing people off, but see what you need and why.
>    

As I said above, I don't think that anything I said means that "I won't 
listen". However, let's talk for a moment about style:

There is a circumstance in which I think one really does have to take 
care to act and sound as open to all input and impartial as possible: 
when you are in a position of power in a truly hierarchical 
organization. In that case, the fact that you have power over other 
people requires that you not only have be open, but you have to act more 
open than you normally would. A position of power means that the less 
powerful folks will be reluctant to confront you, so you have to be 
exceedingly careful to listen for quieter voices and coax people into 
expressing their views frankly and honestly. And my real concern here is 
the inverse effect of the above: When someone starts acting measured in 
their statements and Solomon-like in their judgments and pronouncements, 
it creates an air of authority. It puts people in mind that you are, by 
virtue of your position, in power.

Call me naïve, but the IETF is not supposed to be a hierarchical 
organization like that (behavior of some folks and some adopted 
procedures notwithstanding). We're supposed to be a consensus 
organization, where we all listen to well-reasoned technical arguments, 
even if they come from someone new; where the mere fact of having grey 
hairs (on the face, head, legs, or otherwise shaved off of any of those) 
does not entitle you to say, "It must be this way and I don't have to 
explain why"; where the people in "leadership" are just other passengers 
on the bus, not kings, to whom one can say, "You're wrong, and here's 
why, and that makes you, Mr./Ms. Leader, in the 'rough' part of the 
rough consensus"; and where the participants in the IETF are the ones 
who take responsibility for the documents being of good quality, not the 
leadership.

Some of that is happening now. Some is definitely not. Not being 
hierarchical and having everyone be responsible makes lots of folks 
(leadership and regular participants alike) very uncomfortable. Being in 
a hierarchy means that there is normally someone above you who can 
direct you to the right path if you need, or take the heat when you make 
a mistake. Being in leadership in a hierarchy means you can make a 
decision and not be pushed back on by people under you. These are all 
very comforting thoughts and not having that backstop is worrisome. And 
many of us now come out of corporate culture (as against academia), 
where hierarchy is what we know. But I'm doing my best to push back on that.

So, when I say that "I support the publication of this document" is 
useless, what I'm saying is: Sure, you can choose to assume that I, or 
other ADs, or the rest of participants, "know who you are" and therefore 
must take such contextless statements seriously. But really, I don't 
think you should say things that way. I think you should state the 
technical (or other) grounds that you think this document is useful or 
important or implementable (or not). Or you might choose to assume that 
such statements count as a vote for the document. But really, this is a 
consensus organization, and you don't get to "count" just because you 
grunted "yes". New folks shouldn't think that "silence followed by 
voting" is a reasonable modus operandi, and you shouldn't act that way 
either. You might count, if I happen to have enough context, but if 
another AD or another participant comes up to me and says, "Who is this 
bozo? I don't believe he ever even read the document", it would be 
rather nice to be able to point back to something more concrete than "+1".

Yes, I definitely want people to feel that I am open to their input. (I 
want people to feel that everyone is open to their input.) On the flip 
side, I also want people to feel responsibility for the output of the 
IETF. And I don't want people thinking that I am some oracle from on 
high that has any particular power over them. I take my role to be (a) 
judging the consensus of the community and (b) inputting my experience 
and expertise when I can, and I take them in that order.

So it comes down to my style to get that ethos instilled. I'm inclined 
to say to people (new and old alike), "You'd better explain your 
reasoning or you're not going to get heard". Now, I take your point that 
such talk might put off some people. And that means that I also have a 
responsibility to mentor new folks (or even not-so-new folks who are 
disinclined to challenge authority) to understand that nobody gets to 
rely on their station to justify their statements, and that anyone can 
push back on anyone else, myself included. But I am taking a risk that 
people will think I'm not going to listen to them. However, I prefer 
that risk to the one where I act "exalted" and speak in such ways and 
end up where people think I'm "in charge". I am not (as a friend of all 
of ours said to me recently) "the Last Defender of Camelot". I'm not 
going to talk like that, and I don't want you to talk to me like that.

You may all feel free to decide that I'm completely full of it. That's 
what this organization is supposed to allow. In fact, if 20 of you think 
that I am sufficiently full of it at any point, we have a procedure to 
deal with that. But I do hope that I am setting up the world in such a 
way that anybody feels they can yell at me first and convince me that I 
am "in the rough."

> So I don't really look at it as being "politically correct", but as
> being clear without being exclusive.
>    

As do I.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


--------------000204050901040005070906
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit




  
  


Let me say up front that I think this entire conversation is great, and
I think we are all getting a great deal out of having it. I know I am.
And I do agree with Barry on some of the more specific points, but I
suspect that we will end up simply agreeing to disagree on the broader
issue. And I do think it is worth having this conversation, because I
hope it will lead to some understanding of not just my style, but my
motives.



On 5/11/11 5:43 PM, Barry Leiba wrote:


  
Hm.  I thought I wouldn't comment on this, but I think I will, because
I want to make something clear about how I think about this.

On Wed, May 11, 2011 at 5:39 PM, SM <sm@resistor.net> wrote:
  

  

    
At 13:37 11-05-2011, John C Klensin wrote:
    

    

      
So, I wouldn't have said "useless".  I might have said "of very
limited value in helping the IESG with its determination of
consensus about technical quality and adequacy of review".
      

    

    
That is the politically correct way of stating it.  It may help some people
understand what the IESG would like.  However, sentences like that are
against IETF best practices. :-)

Pete has taken a rather unusual approach.  I would qualify it as open.  It
is to encourage discussion on an equal footing.
    

  

  
Here's why I think being "politically correct" is important:
If it's someone's manner to be blunt, and to expect that we won't take
him *too* much at his exact words, that's fine, and we learn that.
And if someone is wont to say "Eff all y'all.  I'm going to ignore any
comments I choose to," well, again, we consider who's saying it and to
what extent we think he really means that... and everyone has a right
not to pay attention to anyone in particular.  Except....
  





First, I don't think you'll find anywhere in my original note on the
"support publication" thread that I said I would absolutely ignore or
be closed to the input. I did say that I "find these
statements...well...useless." I did say that such commentary on the
publication itself is "really, truly, not important." And I did joke
(smiley face included) that I would have to assume that the reason for
such a statement is "because you have a wager on how soon we will get
to RFC 10000. :-)"
But I never did say I'd ignore them. I did say later (in reference to
Ted's comments) that I "*might*
ignore comments that come without context because there really is no
way to evaluate what they mean", but that's just to say that if I can't
figure out the meaning of a statement, it's simply not going to impact
my thinking on a particular topic. But all of this is somewhat less
important than what follows:





  
When someone accepts a position on the IESG, the IAB, or the IAOC --
I*, as we collectively call them -- s/he no longer gets to be the
gruff "eff all y'all" person s/he once may have been.  S/he has to
support the open system we have, and not be closed to input.  That's
why someone on I* saying "I won't listen unless you say it the way I
want to hear it," bothers me.  That's why I think it's important to
put it more the way John did -- so people understand that you're not
just brushing people off, but see what you need and why.
  





As I said above, I don't think that anything I said means that "I won't
listen". However, let's talk for a moment about style:



There is a circumstance in which I think one really does have to take
care to act and sound as open to all input and impartial as possible:
when you are in a position of power in a truly hierarchical
organization. In that case, the fact that you have power over other
people requires that you not only have be open, but you have to act
more open than you normally would. A position of power means that the
less powerful folks will be reluctant to confront you, so you have to
be exceedingly careful to listen for quieter voices and coax people
into expressing their views frankly and honestly. And my real concern
here is the inverse effect of the above: When someone starts acting
measured in their statements and Solomon-like in their judgments and
pronouncements, it creates an air of authority. It puts people in mind
that you are, by virtue of your position, in power.



Call me naïve, but the IETF is not supposed to be a hierarchical
organization like that (behavior of some folks and some adopted
procedures notwithstanding). We're supposed to be a consensus
organization, where we all listen to well-reasoned technical arguments,
even if they come from someone new; where the mere fact of having grey
hairs (on the face, head, legs, or otherwise shaved off of any of
those) does not entitle you to say, "It must be this way and I don't
have to explain why"; where the people in "leadership" are just other
passengers on the bus, not kings, to whom one can say, "You're wrong,
and here's why, and that makes you, Mr./Ms. Leader, in the 'rough' part
of the rough consensus"; and where the participants in the IETF are the
ones who take responsibility for the documents being of good quality,
not the leadership.



Some of that is happening now. Some is definitely not. Not being
hierarchical and having everyone be responsible makes lots of folks
(leadership and regular participants alike) very uncomfortable. Being
in a hierarchy means that there is normally someone above you who can
direct you to the right path if you need, or take the heat when you
make a mistake. Being in leadership in a hierarchy means you can make a
decision and not be pushed back on by people under you. These are all
very comforting thoughts and not having that backstop is worrisome. And
many of us now come out of corporate culture (as against academia),
where hierarchy is what we know. But I'm doing my best to push back on
that.



So, when I say that "I support the publication of this document" is
useless, what I'm saying is: Sure, you can choose to assume that I, or
other ADs, or the rest of participants, "know who you are" and
therefore must take such contextless statements seriously. But really,
I don't think you should say things that way. I think you should state
the technical (or other) grounds that you think this document is useful
or important or implementable (or not). Or you might choose to assume
that such statements count as a vote for the document. But really, this
is a consensus organization, and you don't get to "count" just because
you grunted "yes". New folks shouldn't think that "silence followed by
voting" is a reasonable modus operandi, and you shouldn't act that way
either. You might count, if I happen to have enough context, but if
another AD or another participant comes up to me and says, "Who is this
bozo? I don't believe he ever even read the document", it would be
rather nice to be able to point back to something more concrete than
"+1".



Yes, I definitely want people to feel that I am open to their input. (I
want people to feel that everyone is open to their input.) On the flip
side, I also want people to feel responsibility for the output of the
IETF. And I don't want people thinking that I am some oracle from on
high that has any particular power over them. I take my role to be (a)
judging the consensus of the community and (b) inputting my experience
and expertise when I can, and I take them in that order.



So it comes down to my style to get that ethos instilled. I'm inclined
to say to people (new and old alike), "You'd better explain your
reasoning or you're not going to get heard". Now, I take your point
that such talk might put off some people. And that means that I also
have a responsibility to mentor new folks (or even not-so-new folks who
are disinclined to challenge authority) to understand that nobody gets
to rely on their station to justify their statements, and that anyone
can push back on anyone else, myself included. But I am taking a risk
that people will think I'm not going to listen to them. However, I
prefer that risk to the one where I act "exalted" and speak in such
ways and end up where people think I'm "in charge". I am not (as a
friend of all of ours said to me recently) "the Last Defender of
Camelot". I'm not going to talk like that, and I don't want you to talk
to me like that.



You may all feel free to decide that I'm completely full of it. That's
what this organization is supposed to allow. In fact, if 20 of you
think that I am sufficiently full of it at any point, we have a
procedure to deal with that. But I do hope that I am setting up the
world in such a way that anybody feels they can yell at me first and
convince me that I am "in the rough."





  
So I don't really look at it as being "politically correct", but as
being clear without being exclusive.
  





As do I.



pr


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102




--------------000204050901040005070906--

From stpeter@stpeter.im  Thu May 12 14:33:45 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E02E07DD for ; Thu, 12 May 2011 14:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMwmgWJlu1-L for ; Thu, 12 May 2011 14:33:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D68C7E07AA for ; Thu, 12 May 2011 14:33:42 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 51CD2400A6; Thu, 12 May 2011 15:33:41 -0600 (MDT)
Message-ID: <4DCC5232.7050004@stpeter.im>
Date: Thu, 12 May 2011 15:33:38 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Pete Resnick 
References: <4DCAC1CB.3050905@qualcomm.com>	<6.2.5.6.2.20110511115259.051cd3f8@resistor.net>	<4DCAF61F.10000@qualcomm.com>	<6.2.5.6.2.20110511141027.032dd408@resistor.net>	 <4DCC4FD6.4040205@qualcomm.com>
In-Reply-To: <4DCC4FD6.4040205@qualcomm.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020102020305010100090703"
Cc: Barry Leiba , Apps Discuss 
Subject: Re: [apps-discuss] We have no lambs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:33:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms020102020305010100090703
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/12/11 3:23 PM, Pete Resnick wrote:

> where the people in "leadership" are just other passengers
> on the bus, not kings, to whom one can say, "You're wrong, and here's
> why, and that makes you, Mr./Ms. Leader, in the 'rough' part of the
> rough consensus"; and where the participants in the IETF are the ones
> who take responsibility for the documents being of good quality, not th=
e
> leadership.

Yep. And I mentally replace "the leadership" with "those individuals who
are currently serving, temporarily and at the pleasure of the community,
in leadership roles"...

Peter

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




--------------ms020102020305010100090703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MjIxMzMzOFowIwYJKoZIhvcNAQkEMRYEFNbcmrpr6KqFl/gEU8QEc61RgP2BMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCkgFeYoJnTr4HeWnAh1NNyI/Y71sy2V/k/a0gKWt8XblUXLYuwdHc2DpL5
HwTZSLW2JAFUCEH/LeWeasZX9CXS0/eZgIhVT5E7zpH3wnA1xoStdsTBPGvd/ILEpKwhV/EM
XVbWWNfgIf+5fZi0fmd9NyyMIzLjUfgJ5lH03Tqq1kRhbZhPVqThimlqZeS2ym9hrAHXreSd
RD3K2pN7oEZxolxh5PZfNcnrz7Qb/e027nNNr+9AS4glon2qLGvCbcELN49oEng6Qe1PUWcX
1fu7gahRSNZ243aktnc9U/xmdYdHbVY/GJoKucEEjy+ZnaMNxJXxYav8+d65bOysYS5HAAAA
AAAA
--------------ms020102020305010100090703--

From barryleiba@gmail.com  Thu May 12 15:30:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3CE07EC for ; Thu, 12 May 2011 15:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.368
X-Spam-Level: 
X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgVnx+O43WTQ for ; Thu, 12 May 2011 15:30:06 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 929A0E07DF for ; Thu, 12 May 2011 15:30:06 -0700 (PDT)
Received: by yxk30 with SMTP id 30so885749yxk.31 for ; Thu, 12 May 2011 15:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J8uD5eSXkVWKrzg5yo6YN2FwRewwUXAlUoaqtaW7s1c=; b=qI0QlrDkYlaMUjcaVkeerxlOZFFV9wX6gO5VRQcISy8XAp9GBpkxDsrl7ax2JdjJFk l7gjSauZfIcYHmNFIFkeK05ZGKEUq4BozNwcDXYTx7/VpdTAWyMjmiRIuqCFy/pCzb3a 48RnvnJlow3HBVZ3cNinzZzfVruisXssW7gj8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HV8iP5ZeRLyylAbcG1IqsyC9uyDXpWIRdrxNS9TSKyUR+FLVYtrkYi3FIAj/cAlmyC cJiRjYbWROwaWsNLEzyiUgDyYmIqC8M485yMNIFLFpyQ1/NKoz1rgQGwcdKAiQIwttb+ 7nikMKQeC3BQyqcDWFr4HObukGw8P7gliS6Qk=
MIME-Version: 1.0
Received: by 10.236.78.5 with SMTP id f5mr862464yhe.414.1305239405978; Thu, 12 May 2011 15:30:05 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.236.108.49 with HTTP; Thu, 12 May 2011 15:30:05 -0700 (PDT)
In-Reply-To: <4DCC4FD6.4040205@qualcomm.com>
References: <4DCAC1CB.3050905@qualcomm.com> <6.2.5.6.2.20110511115259.051cd3f8@resistor.net> <4DCAF61F.10000@qualcomm.com> <6.2.5.6.2.20110511141027.032dd408@resistor.net>  <4DCC4FD6.4040205@qualcomm.com>
Date: Thu, 12 May 2011 18:30:05 -0400
X-Google-Sender-Auth: -K4J0gLMfXeOR3vOVpVe9CbL3jE
Message-ID: 
From: Barry Leiba 
To: Pete Resnick 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss 
Subject: Re: [apps-discuss] We have no lambs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:30:07 -0000

> Let me say up front that I think this entire conversation is great

And let me say up front that I do, too.  Also:

> You may all feel free to decide that I'm completely full of it. That's wh=
at
> this organization is supposed to allow. In fact, if 20 of you think that =
I
> am sufficiently full of it at any point, we have a procedure to deal with

In no sense did I mean to imply that you're "full of it", completely
or partially.  And, of course, it goes without saying that no
procedures are forthcoming.  This is mostly an academic exercise, to
make sure that everyone's considering the same sorts of things.

> As I said above, I don't think that anything I said means that "I won't
> listen".

This is part of what I was getting at:
"Such input is useless," which, when it's my input turns into, "Your
input is useless," is -- at least to some people -- another way of
saying, "so I won't be paying it any mind."  One response to that
could be -- and is likely to be, for some people -- "Well, geez, then
I might as well go away."

On the other hand, focusing on what you *do* need in order to do your
job is an angle that's more likely to prompt people to give that,
and... be heard.  That's really the core of what I was trying to get
across.

But now you've brought up something else entirely, so let's pursue this:

> Call me na=EFve, but the IETF is not supposed to be a hierarchical
> organization like that (behavior of some folks and some adopted procedure=
s
> notwithstanding). We're supposed to be a consensus organization, where we
> all listen to well-reasoned technical arguments

I don't think for a moment that you're na=EFve, but you're speaking
na=EFvely here, if you really think that there's no hierarchy as things
are perceived by many participants.  *Lots* of people here -- probably
not those participating in this thread, but lots who are less active,
and certainly a great many of the newer participants -- hold the I*
folks up, consider them to be on pedestals, in ivory towers, or
whatever.  There certainly *is* a very strong perception of hierarchy,
and you certainly *do* have to make a special point of being open and
making it clear that you are.  Not to me, not to John Klensin... but
to, oh, say, at least half of the attendees at a face-to-face meeting,
and to a much higher percentage of those on the mailing lists.

You also have more control than you're letting on, here, and more than
many would like you to have, in using DISCUSS positions, in
controlling charters, in controlling BoF scheduling, in appointing
chairs, and so on.  You can have a significant effect on the
documents, and we can all think of our favourite stories of ADs doing
what we consider to be nasty things to our work.

Don't downplay that, and what it means to the responsibility that you
have in light of it.

Barry

From singer@apple.com  Thu May 12 16:48:46 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D26FE06F1 for ; Thu, 12 May 2011 16:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x02l6maEypO for ; Thu, 12 May 2011 16:48:45 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA2DE066E for ; Thu, 12 May 2011 16:48:45 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL30038TWR3GXE0@mail-out.apple.com> for apps-discuss@ietf.org; Thu, 12 May 2011 16:47:40 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-3a-4dcc719c6a5d
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay16.apple.com (Apple SCV relay) with SMTP id 34.D3.12552.C917CCD4; Thu, 12 May 2011 16:47:40 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Thu, 12 May 2011 16:47:39 -0700
Message-id: 
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>  <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com>  
To: Randall Gellens 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
Cc: Per Frojdh , S Moonesamy , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 23:48:46 -0000

On May 11, 2011, at 22:14 , Randall Gellens wrote:

> At 5:29 PM -0700 5/11/11, David Singer wrote:
> 
>> should I upload a new version?  I have not heard anything in a while.  what happens next?
> 
> Please do upload a revision (-04) and let the Area Director know. The draft is not yet in IETF Last Call, so there are no "Discuss"es which need to be formally cleared.  There was a review by the Apps directorate, which provided some helpful comments that we addressed.

-04 uploaded.  what's next?

> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Little Jack Horner
> Sits in a corner
> Extracting cube roots to infinity.
> An assignment for boys
> That will minimize noise
> And produce a more peaceful vicinity.
>     --Frederick Winsor, "A Space-Child's Mother Goose"

David Singer
Multimedia and Software Standards, Apple Inc.


From johnl@iecc.com  Thu May 12 18:00:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACCAE07BE for ; Thu, 12 May 2011 18:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.899
X-Spam-Level: 
X-Spam-Status: No, score=-110.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_53=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydC0wjb4bqfc for ; Thu, 12 May 2011 18:00:47 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8B7E07B8 for ; Thu, 12 May 2011 18:00:47 -0700 (PDT)
Received: (qmail 91111 invoked from network); 13 May 2011 01:00:47 -0000
Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 May 2011 01:00:47 -0000
Date: 13 May 2011 01:00:25 -0000
Message-ID: <20110513010025.62566.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 01:00:48 -0000

>Let me rephrase: are there Standards-Track BCPs?  The RFC-Editor RFC
>Search tool does not allow me to search for RFCs that are both, BCPs
>and on the Standards-Track, thus making a search for such a thing
>difficult.

RFC 3677 is a standards track BCP.

Since it's the only one, perhaps that was a mistake.

R's,
John

PS: the web may seem cool, but nothing beats rsync'ing the whole
set of RFCs and using grep

From johnl@iecc.com  Thu May 12 18:03:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF14130013 for ; Thu, 12 May 2011 18:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.049
X-Spam-Level: 
X-Spam-Status: No, score=-111.049 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQW-vQRr01WC for ; Thu, 12 May 2011 18:03:00 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 08EB813000C for ; Thu, 12 May 2011 18:02:59 -0700 (PDT)
Received: (qmail 91342 invoked from network); 13 May 2011 01:02:59 -0000
Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 May 2011 01:02:59 -0000
Date: 13 May 2011 01:02:37 -0000
Message-ID: <20110513010237.63201.qmail@joyce.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: 
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 01:03:00 -0000

>> Do I need to be "authorized" to join in?  My client (MacOS/Adium) seems to think
>> so, but maybe I'm just doing it wrong.  So far I've only used XMPP for
>> person-to-person chat - is a chatroom significantly different to use?
>
>Ditto for me just now with Pidgin.

I just tried it with Pidgin and it worked fine, no password needed.

R's,
John

From jyee@afilias.info  Thu May 12 19:30:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281FFE065A for ; Thu, 12 May 2011 19:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level: 
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYO280a6e6J1 for ; Thu, 12 May 2011 19:30:15 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 34120E0593 for ; Thu, 12 May 2011 19:30:15 -0700 (PDT)
Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1QKi8s-00076Z-6p for apps-discuss@ietf.org; Fri, 13 May 2011 02:30:14 +0000
Received: from mail-yi0-f50.google.com ([209.85.218.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1QKi8r-0003ps-9X for apps-discuss@ietf.org; Fri, 13 May 2011 02:30:14 +0000
Received: by yie30 with SMTP id 30so691926yie.9 for ; Thu, 12 May 2011 19:30:13 -0700 (PDT)
Received: by 10.151.10.19 with SMTP id n19mr835131ybi.430.1305253812874; Thu, 12 May 2011 19:30:12 -0700 (PDT)
Received: from [192.168.0.101] (76-10-160-139.dsl.teksavvy.com [76.10.160.139]) by mx.google.com with ESMTPS id w15sm131911ybk.16.2011.05.12.19.30.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 19:30:11 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joseph Yee 
In-Reply-To: 
Date: Thu, 12 May 2011 22:30:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <4DC9A557.9040504@qualcomm.com> <4DCAFB2A.8030408@dcrocker.net>  <4DCC0257.1050705@dcrocker.net>  <4DCC19A8.3070807@dcrocker.net> 
To: Nico Williams 
X-Mailer: Apple Mail (2.1084)
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 02:30:19 -0000

[snip]

>=20
> Can we get a clear statement as to what's being proposed?  If I
> misread it, either I'm a poor reader or the proposal is not clear.
>=20
> Nico
> --

Personal guess is ADs hope to see expanded review beyond "read and =
support", with reason of why we support.  I assume that no strict format =
at the beginning (try and evaluate first), otherwise we (as reviewers) =
might just provide a longer form of "read and support" statement.

Joseph

> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nico@cryptonector.com  Thu May 12 22:14:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DEEE06C7 for ; Thu, 12 May 2011 22:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.233
X-Spam-Level: 
X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UVsg-ND-WMG for ; Thu, 12 May 2011 22:14:18 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 45885E06C0 for ; Thu, 12 May 2011 22:14:18 -0700 (PDT)
Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 00B7D77805B for ; Thu, 12 May 2011 22:14:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=u2FYcIRHKvOH4qRli9qtzI28175c0bmuBaq+fQkeK/Bl XnXyEPjdKJCUpXt0CdbMuBGuaqnyygVWv3QnjjK14i1onhs/MHD8O9ltyaNhQxOr eSrFyWYcTMcVVbqumr6v653PUvwbTfaD2C7sVhd4qWmiCM+0rJVaiGa+KhfivbI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=7iKEXfCe3Jun56jcDyRYG179fCE=; b=jCOzXNqp/XX kYTaRIwkDi5avvhDaGQ/gDks/o9Ki9aXucDqvIb8imW3uksjngbJLMEsARF7TzLv WPVdAiJm61oZnFD+6jc5ncZOHhKbTRFA1OAvMDM7H6phaAA0s/S4FFynI4aLBbzx tv7yQlQbVJB547ccHKbTxSJuZgxiDTns=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id C8177778057 for ; Thu, 12 May 2011 22:14:17 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1904310vxg.31 for ; Thu, 12 May 2011 22:14:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.170 with SMTP id m10mr750441vdv.160.1305263657151; Thu, 12 May 2011 22:14:17 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Thu, 12 May 2011 22:14:17 -0700 (PDT)
In-Reply-To: 
References: <4DC88255.3070403@qualcomm.com> <4DC94F74.30905@dcrocker.net> <4DC9688B.3070701@qualcomm.com>  <4DC9A557.9040504@qualcomm.com> <4DCAFB2A.8030408@dcrocker.net>  <4DCC0257.1050705@dcrocker.net>  <4DCC19A8.3070807@dcrocker.net>  
Date: Fri, 13 May 2011 00:14:17 -0500
Message-ID: 
From: Nico Williams 
To: Joseph Yee 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] On "supporting the publication of this document"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:14:18 -0000

On Thu, May 12, 2011 at 9:30 PM, Joseph Yee  wrote:
>> Can we get a clear statement as to what's being proposed? =C2=A0If I
>> misread it, either I'm a poor reader or the proposal is not clear.
>>
>> Nico
>> --
>
> Personal guess is ADs hope to see expanded review beyond "read and suppor=
t", with reason of why we support. =C2=A0I assume that no strict format at =
the beginning (try and evaluate first), otherwise we (as reviewers) might j=
ust provide a longer form of "read and support" statement.

That's what I thought, and I agree with that.  Dave seemed to want to
go much further, but I wasn't sure whether a far-reaching proposal had
been made.

From ietfc@btconnect.com  Fri May 13 01:05:07 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6DE06D5 for ; Fri, 13 May 2011 01:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hslET2+HIqxU for ; Fri, 13 May 2011 01:05:07 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id E6035E06B7 for ; Fri, 13 May 2011 01:05:06 -0700 (PDT)
Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr09.btconnect.com with SMTP id CWM08336; Fri, 13 May 2011 09:04:58 +0100 (BST)
Message-ID: <00ce01cc113b$df5a9520$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Nico Williams" , "Pete Resnick" 
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net><4DCC20AF.7060206@qualcomm.com><4DCC2250.8080603@qualcomm.com> 
Date: Fri, 13 May 2011 09:03:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DCCE629.00EC, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.13.73916:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4DCCE62D.00DA,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 08:05:07 -0000

----- Original Message -----
From: "Nico Williams" 
To: "Pete Resnick" 
Cc: ; "Apps Discuss" 
Sent: Thursday, May 12, 2011 8:34 PM
Subject: Re: [apps-discuss] Applicability Statements


> On Thu, May 12, 2011 at 1:09 PM, Pete Resnick  wrote:
> > On 5/12/11 1:05 PM, Nico Williams wrote:
> >>>> Are there any RFCs that are ASes?
> >>>
> >>> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as
> >>> BCPs. [...]
> >>
> >> Let me rephrase: are there Standards-Track BCPs? [...]
> >
> > Ah. No, in 2026, BCPs cannot be Standards-Track and Standards-Track
> > documents cannot be BCPs. They are mutually exclusive categories.
>
> Let me go back to my original phrasing then: are there any existing
> ASes?  I'm not asking if there's BCPs that should have been ASes.
>
> I note that the RFC-Editor has an index of BCPs, STDs, FYIs, and RFCs,
> but no index of ASes.  I take this to mean that there are no ASes.
>
> Another question: if there are indeed no ASes as such, have there ever
> been any attempts to publish any such?  My guess is the answer is
> "no", in which case the "experiment" hasn't failed -- it hasn't been
> attempted.

Nico

My vade mecum is the RFC-INDEX which lists some 30 Applicability Statements, the
most recent being October 2010.  As has been pointed out, there are many more
appearing as sections of Technical RFC.  There are also areas where an AS is
sadly lacking - MPLS-TP springs to mind.

I find them a commonplace in Routing and Operations, perhaps reflecting
an underlying technical difference, or perhaps reflecting a penchant on the part
of the
ADs and WG chairs.  I think that they are needed early on, when the scope of a
technical solution is expanding rapidly, exploding even, and some bounds are
needed.

Tom Petch

> Nico
> --
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From GK@ninebynine.org  Fri May 13 01:46:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DE4E073E for ; Fri, 13 May 2011 01:46:04 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdjypttA5Ls2 for ; Fri, 13 May 2011 01:46:03 -0700 (PDT)
Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7F302E06C2 for ; Fri, 13 May 2011 01:46:02 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1QKo0X-0000Uh-GC; Fri, 13 May 2011 09:46:01 +0100
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKo0W-00049Y-5T; Fri, 13 May 2011 09:46:00 +0100
Message-ID: <4DCCEFC8.5020509@ninebynine.org>
Date: Fri, 13 May 2011 09:46:00 +0100
From: Graham Klyne 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635@OX.AC.UK
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 08:46:04 -0000

Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Graham Klyne
>> Sent: Thursday, May 12, 2011 2:02 AM
>> To: Peter Saint-Andre
>> Cc: apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] App-ADs chatroom
>>
>> Do I need to be "authorized" to join in?  My client (MacOS/Adium) seems to think
>> so, but maybe I'm just doing it wrong.  So far I've only used XMPP for
>> person-to-person chat - is a chatroom significantly different to use?
> 
> Ditto for me just now with Pidgin.

Ah, could be a client issue, then, as I believe adium is derived from pidgin.

#g
--



From dave@cridland.net  Fri May 13 02:02:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3D2E06BB for ; Fri, 13 May 2011 02:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eJ0ALoQp+xz for ; Fri, 13 May 2011 02:02:47 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 35EC9E0665 for ; Fri, 13 May 2011 02:02:47 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id BF1ED1168090; Fri, 13 May 2011 10:02:39 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu7xHFn+H7Y4; Fri, 13 May 2011 10:02:37 +0100 (BST)
Received: from Sputnik (unknown [62.3.217.253]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 359E81168067; Fri, 13 May 2011 10:02:37 +0100 (BST)
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>  <4DCCEFC8.5020509@ninebynine.org>
In-Reply-To: <4DCCEFC8.5020509@ninebynine.org>
MIME-Version: 1.0
Message-Id: <6944.1305277357.139171@Sputnik>
Date: Fri, 13 May 2011 10:02:37 +0100
From: Dave Cridland 
To: Graham Klyne , General discussion of application-layer protocols ,  "Murray S\. Kucherawy" 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 09:02:48 -0000

On Fri May 13 09:46:00 2011, Graham Klyne wrote:
> Ah, could be a client issue, then, as I believe adium is derived  
> from pidgin.

Both use libpurple, if I recall.

Could also be that you've typoed the room, that would also cause an  
error - if you can list the rooms on jabber.ietf.org, try selecting  
it there.

Otherwise the room name is "app-ads" and the service is  
"jabber.ietf.org", or, if there's only one box for the room address,  
"app-ads@jabber.ietf.org".

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From GK@ninebynine.org  Fri May 13 02:23:29 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A5E0665 for ; Fri, 13 May 2011 02:23:29 -0700 (PDT)
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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EfAinx4JaQy for ; Fri, 13 May 2011 02:23:29 -0700 (PDT)
Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id F108BE067B for ; Fri, 13 May 2011 02:23:28 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1QKoal-0004h5-0e; Fri, 13 May 2011 10:23:27 +0100
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKoal-00052w-3M; Fri, 13 May 2011 10:23:27 +0100
Message-ID: <4DCCF859.3000302@ninebynine.org>
Date: Fri, 13 May 2011 10:22:33 +0100
From: Graham Klyne 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dave Cridland 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>		<4DCCEFC8.5020509@ninebynine.org> <6944.1305277357.139171@Sputnik>
In-Reply-To: <6944.1305277357.139171@Sputnik>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 09:23:29 -0000

Solved!  Turns out to be PEBCAK:  I was trying to connect by adding the chat 
room address to my contact list.

What I needed to do instead was to first "Join Group Chat...", then add group 
chat bookmark to contact list.  That's with Adium.  I don't know if Pidgin is 
similar.

#g
--

Dave Cridland wrote:
> On Fri May 13 09:46:00 2011, Graham Klyne wrote:
>> Ah, could be a client issue, then, as I believe adium is derived from 
>> pidgin.
> 
> Both use libpurple, if I recall.
> 
> Could also be that you've typoed the room, that would also cause an 
> error - if you can list the rooms on jabber.ietf.org, try selecting it 
> there.
> 
> Otherwise the room name is "app-ads" and the service is 
> "jabber.ietf.org", or, if there's only one box for the room address, 
> "app-ads@jabber.ietf.org".
> 
> Dave.


From lear@cisco.com  Fri May 13 05:02:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4282BE06CA for ; Fri, 13 May 2011 05:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj-QnGDPC1MO for ; Fri, 13 May 2011 05:02:07 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D2E0675 for ; Fri, 13 May 2011 05:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=174; q=dns/txt; s=iport; t=1305288127; x=1306497727; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dt45A/15iA3S0nimZBXKyBIG36A90FtsHDxqP5BdjVs=; b=bB/YS7ofIQV5PRV3O3OeMjMsDd06ucWu91J2N17Lye6XCr5ZwUUgRZWu K4fMpiCr5yTyhmLRlBzf7sUweTcgwoufbmiOg1xWCx9zgGE/p4xjfgJRy /rY3TCcjO3nPf/RzIlOeFoGt1i5rBlhmoCrtg3VXAsJAFGnbW79WcSUQO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoEABQdzU2Q/khNgWdsb2JhbACEVqEyFAEBFiYlqAKNA5EigSuDY4EHBJAGjnQ
X-IronPort-AV: E=Sophos;i="4.64,363,1301875200"; d="scan'208";a="88345680"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 May 2011 12:02:06 +0000
Received: from ams3-vpn-dhcp5099.cisco.com (ams3-vpn-dhcp5099.cisco.com [10.61.83.234]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4DC26Bl023311; Fri, 13 May 2011 12:02:06 GMT
Message-ID: <4DCD1D98.7040906@cisco.com>
Date: Fri, 13 May 2011 14:01:28 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>	 <4DCC31C2.1080405@stpeter.im>
In-Reply-To: <4DCC31C2.1080405@stpeter.im>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 12:02:08 -0000

I'm going to hazard a guess that somehow when you and Pete aren't there,
nobody else is let in.  I'm still getting the error and I'm getting it
with both iChat and adium.


From stpeter@stpeter.im  Fri May 13 05:07:09 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F84E06EE for ; Fri, 13 May 2011 05:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.3
X-Spam-Level: 
X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU8bTUUEp93T for ; Fri, 13 May 2011 05:07:08 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6B31E06C1 for ; Fri, 13 May 2011 05:07:07 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AB66A400A6; Fri, 13 May 2011 06:07:06 -0600 (MDT)
Message-ID: <4DCD1EEA.2010103@stpeter.im>
Date: Fri, 13 May 2011 06:07:06 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Eliot Lear 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>	 <4DCC31C2.1080405@stpeter.im> <4DCD1D98.7040906@cisco.com>
In-Reply-To: <4DCD1D98.7040906@cisco.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090005080102070504020402"
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 12:07:09 -0000

This is a cryptographically signed message in MIME format.

--------------ms090005080102070504020402
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/13/11 6:01 AM, Eliot Lear wrote:
> I'm going to hazard a guess that somehow when you and Pete aren't there=
,
> nobody else is let in.=20

That would be a novel "feature" for an XMPP groupchat service.

> I'm still getting the error and I'm getting it
> with both iChat and adium.

I'll test it over the weekend from various accounts of mine.

Peter

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




--------------ms090005080102070504020402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUx
MzEyMDcwNlowIwYJKoZIhvcNAQkEMRYEFF9z5YC37s02G9IWVlmzDTVD9aZLMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCKq3+byknQIJ3YN0ayRewnLHxlM7qCme5V+EbIHQ9IRhz+DipBsp9bIdMa
J39yWjBz8PPorIL4Fx8iphl5ExBMBp2auwLNd3oEgyuSnqTeCJSr5N4P9RRdRuz3xqCBDhTy
JhiajnMRyb83vC2G0fU18JliHhUtQzlNdKRzT78beo9hEQ/tIoI5Y9y8bZdT57tMiwSRRuTX
dyYXLgfBJrlllJwdUV7YF9tCe9E12J2gIFVqcvjOzok87F6m11F844yeWrN+sswyWyw8sROM
hzBBfREVrlIwaUOHVO5abyYukNL7bcI4DoR4SEsUYtLpih/FsdciQPTalY+pR7cPQJEfAAAA
AAAA
--------------ms090005080102070504020402--

From dave@cridland.net  Fri May 13 06:42:10 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EADE06D7 for ; Fri, 13 May 2011 06:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vRPZyKpOMYM for ; Fri, 13 May 2011 06:42:09 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 738A4E069B for ; Fri, 13 May 2011 06:42:09 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A489A1168087; Fri, 13 May 2011 14:42:06 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vt+chOGsB4a; Fri, 13 May 2011 14:42:04 +0100 (BST)
Received: from Sputnik (unknown [62.3.217.253]) by peirce.dave.cridland.net (Postfix) with ESMTPA id A3C801168067; Fri, 13 May 2011 14:42:03 +0100 (BST)
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>  <4DCC31C2.1080405@stpeter.im> <4DCD1D98.7040906@cisco.com>
In-Reply-To: <4DCD1D98.7040906@cisco.com>
MIME-Version: 1.0
Message-Id: <6944.1305294123.579003@Sputnik>
Date: Fri, 13 May 2011 14:42:03 +0100
From: Dave Cridland 
To: Eliot Lear , General discussion of application-layer protocols ,  Peter Saint-Andre 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 13:42:10 -0000

On Fri May 13 13:01:28 2011, Eliot Lear wrote:
> I'm going to hazard a guess that somehow when you and Pete aren't  
> there,
> nobody else is let in.

The implementation used doesn't have that feature as far as I'm  
aware. Nor does mine, and I'm not aware of any implementation having  
that feature.

>   I'm still getting the error and I'm getting it
> with both iChat and adium.

It's unlikely to be an issue with the client.

Also, it is not always obvious whether an error is due to the  
chatroom service refusing entry, or your server being unable to reach  
the chatroom service.

Finally, at least one person has tried to simply add the chatroom to  
the roster - XEP-0045 doesn't work that way, you need to use a "Join  
Chatroom" feature or similar.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From scott.brim@gmail.com  Fri May 13 07:08:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC8FE06EE for ; Fri, 13 May 2011 07:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fbK+fKsvzsd for ; Fri, 13 May 2011 07:08:22 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD29E069B for ; Fri, 13 May 2011 07:08:22 -0700 (PDT)
Received: by iyn15 with SMTP id 15so2730885iyn.31 for ; Fri, 13 May 2011 07:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WtNuoI4VVSQ/biXzNr42pdii2tB4aPcIgWdW/KxUAX4=; b=srNONRJziUubtR/GjCphCIMiw+MEOQuiQ8sI78rBYQPkOpYdgvKGBNKw2hFYuW4060 +EefVYKr3Gz6NQ2DZAb9JYd41g+rC7QPWPebH3soPhAAAA9nh0SsW1XjktWIoO11BM2Q GWvDwLM3CWFsEVXQwnKdrsJ2k6Gnp099dIrSI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=jVvElRNecYU778d5wdimQBxpKqmU47rN+quJAu1fG4u/EwkuyZcaClfRpSTPMHg61i tSUJr0APtCNSPMOSO7MZ1luhY7gfIuU2Mq9PaFmD+VPXADzn77Jau0xkfDSmwTwJsZO0 ovrK3dAgfObxro2LUl/M2aZdvd1e+q6zNWdOI=
Received: by 10.42.247.198 with SMTP id md6mr1733346icb.518.1305295701130; Fri, 13 May 2011 07:08:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.30.205 with HTTP; Fri, 13 May 2011 07:08:01 -0700 (PDT)
In-Reply-To: <00ce01cc113b$df5a9520$4001a8c0@gateway.2wire.net>
References: <4DCAC1CB.3050905@qualcomm.com> <4DCC03FD.3070608@dcrocker.net>  <4DCC20AF.7060206@qualcomm.com>  <4DCC2250.8080603@qualcomm.com>  <00ce01cc113b$df5a9520$4001a8c0@gateway.2wire.net>
From: Scott Brim 
Date: Fri, 13 May 2011 10:08:01 -0400
Message-ID: 
To: "t.petch" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Pete Resnick , Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:08:22 -0000

We have always done the equivalent of applicability statements where
we thought they were necessary.  We are not stupid, and we do produce
what we think people need to be able to use our products effectively.
Sometimes they are in separate documents, sometimes part of "framework
documents", sometimes included in the protocol specs themselves, and
sometimes split across multiple documents with different focus issues.

We have always done applicability "statements", but rarely standalone
application statement documents.  That's okay ... but the problem is
when WGs don't get around to documenting applicability, or do a
haphazard job of it.  Then you get disagreements and incompatibility,
and the IETF hasn't done its job.  So, while we don't usually need
separate applicability documents, we do need to document any
applicability issues for those who weren't in the meeting room.

I believe we should put "deal with applicability questions" on the
shepherding checklist.  The WG decides what the most appropriate way
to document applicability is, but they make an explicit decision about
how to do it.

Scott

From presnick@qualcomm.com  Fri May 13 07:49:34 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05339E076D for ; Fri, 13 May 2011 07:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XdC6FprfFlV for ; Fri, 13 May 2011 07:49:33 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBD4E0786 for ; Fri, 13 May 2011 07:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305298156; x=1336834156; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCD44E7.5030909@qualcomm.com>|Date:=20Fr i,=2013=20May=202011=2009:49:11=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Peter=20Saint-Andre=20|CC:=20"apps-discuss@ietf.org"=20|Subject:=20Re:=20[apps-discuss]=20App-ADs=20c hatroom|References:=20<4DCB0146.9060307@stpeter.im> |In-Reply-To:=20<4DCB0146.9060307@stpeter.im> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=LHVHfvkrJ2zmqKO6A+7SGikvFXAiGtaVJj/VGYy/Ykk=; b=wxaon5tqIqmuPD67dnfi8licABx3ioMVzzQqLrrsGJqfBaLCW8nhrZum WIU8xRKXChuf4v6RLFVAkv7sjGKO3y5gQ2xOvZnB9q0RBlCVXy5BQGLo8 yX/LAQnR6kUvvyBP0CbOTc3DJll106ojpgcA3OvO/Y2IP93K2xLKFU9nB Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="91036184"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 13 May 2011 07:49:15 -0700
X-IronPort-AV: E=Sophos;i="4.64,364,1301900400"; d="scan'208";a="73322034"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 13 May 2011 07:49:15 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 07:49:15 -0700
Message-ID: <4DCD44E7.5030909@qualcomm.com>
Date: Fri, 13 May 2011 09:49:11 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <4DCB0146.9060307@stpeter.im>
In-Reply-To: <4DCB0146.9060307@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:49:34 -0000

A little netiquette thing which maybe isn't obvious:

I've seen a few folks "hanging out" in the app-ads room. This might make 
it a bit uncomfortable for someone who might want to stop by and ask a 
question of the ADs without having others listen in. (No high security 
here; someone can always pop in at the precise moment you say, "Gee, 
Herbert is a jerk", but at least if you see nobody else in the room, you 
might be able to speak a bit more freely.)

If you'd like to "hang out", xmpp:apparea@jabber.ietf.org and 
xmpp:appsawg@jabber.ietf.org are always around for you. Use app-ads for 
just stopping in. (And don't leave your empty beer bottles on the table. 
Recycle please.)

pr

On 5/11/11 4:36 PM, Peter Saint-Andre wrote:
> Folks, we've created a chatroom where your area directors can be found
> when they're online:
>
> xmpp:app-ads@jabber.ietf.org
>
> This is the real-time equivalent of the existing email alias:
>
> mailto:app-ads@ietf.org
>
> Feel free to stop by if you have questions or comments!
>
> Peter
>    
-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From scott.brim@gmail.com  Fri May 13 08:11:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6114BE06ED for ; Fri, 13 May 2011 08:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmFt8JCsE+9p for ; Fri, 13 May 2011 08:11:25 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0929E065A for ; Fri, 13 May 2011 08:11:25 -0700 (PDT)
Received: by iwn39 with SMTP id 39so3006381iwn.31 for ; Fri, 13 May 2011 08:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ijtri8QJxGKfzDRsxWFJFd6f4ZO2bWIrOkaQ7RY1wH8=; b=AdpF0cxgTEzSut5OUuSQwBbhc4gr/0g22DZfZv07uM1+PYL4AmLLtoN0/ebXYTtWCd tMCv52Gds0e1NV+xmC7cDV4DAUrgzISRe8puW20mJE+ngAQDkFY1utxuXQU8Gpl26RrJ 8NYUe5WB28adbR32gHHa8xg7myi9J6ZChhR0w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lX11wx+YerFez2GM7qwAElGQBZ0f6bsE381Fc4hytLblQO91mlhE9Joihwp5WrOBV0 ayyeXfQg2SHlgmdG67pHbuwgc5xbpVSpxvaymc+/VQU3+CPLKcBhSnwsTVMmrZOU67U1 KZWCAJac8hmQ7EuqQTh2iVEG638m8w+UptH9M=
Received: by 10.231.51.17 with SMTP id b17mr1247184ibg.0.1305299485069; Fri, 13 May 2011 08:11:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.30.205 with HTTP; Fri, 13 May 2011 08:11:05 -0700 (PDT)
In-Reply-To: <6944.1305294123.579003@Sputnik>
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>  <4DCC31C2.1080405@stpeter.im> <4DCD1D98.7040906@cisco.com> <6944.1305294123.579003@Sputnik>
From: Scott Brim 
Date: Fri, 13 May 2011 11:11:05 -0400
Message-ID: 
To: Dave Cridland 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:11:26 -0000

On Fri, May 13, 2011 at 09:42, Dave Cridland  wrote:
>> =A0I'm still getting the error and I'm getting it
>> with both iChat and adium.
>
> It's unlikely to be an issue with the client.
>
> Also, it is not always obvious whether an error is due to the chatroom
> service refusing entry, or your server being unable to reach the chatroom
> service.

works for me, Adium 1.4.2b1

From presnick@qualcomm.com  Fri May 13 08:17:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60AE0670 for ; Fri, 13 May 2011 08:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level: 
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A2Y1PowxNvs for ; Fri, 13 May 2011 08:17:52 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2688DE065A for ; Fri, 13 May 2011 08:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305299872; x=1336835872; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCD4B9D.4010708@qualcomm.com>|Date:=20Fr i,=2013=20May=202011=2010:17:49=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20t.petch=20|CC:=20Nico=20Williams=20,=20Apps =20Discuss=0D=0A=09|Subject:=20Re: =20[apps-discuss]=20Applicability=20Statements |References:=20<4DCAC1CB.3050905@qualcomm.com>=09<4DCC03F D.3070608@dcrocker.net><4DCC20AF.7060206@qualcomm.com><4DCC2250.808 0603@qualcomm.com>=09=20<00ce01cc113b$df5a9520$4001a8c0@gate way.2wire.net>|In-Reply-To:=20<00ce01cc113b$df5a9520$4001 a8c0@gateway.2wire.net>|Content-Type:=20text/plain=3B=20c harset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=b/f+hHnGtRzKtySnxI2YUfj5viHcZLBNQAXGO8Ig7ac=; b=Yy6iulPLDQi9D+FpQwejrluAmrB/GLl5JxJgPaf4CWHrEI+g1Q8r+482 0Cky3n5oOBJVyBpX2fhuLuVxJNM2p469wVTT0sL3P7catplSdOPoTFB8n waFV3bfRq7ZkhKbh1YtO1QMRX60L2SFw0eVQxqPMICvGAdQvaPFCxPwAq 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="91041332"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 13 May 2011 08:17:51 -0700
X-IronPort-AV: E=Sophos;i="4.64,364,1301900400"; d="scan'208";a="35065656"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 13 May 2011 08:17:51 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 08:17:51 -0700
Message-ID: <4DCD4B9D.4010708@qualcomm.com>
Date: Fri, 13 May 2011 10:17:49 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: t.petch 
References: <4DCAC1CB.3050905@qualcomm.com>	<4DCC03FD.3070608@dcrocker.net><4DCC20AF.7060206@qualcomm.com><4DCC2250.8080603@qualcomm.com>	 <00ce01cc113b$df5a9520$4001a8c0@gateway.2wire.net>
In-Reply-To: <00ce01cc113b$df5a9520$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: Apps Discuss 
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:17:53 -0000

On 5/13/11 2:03 AM, t.petch wrote:
> My vade mecum is the RFC-INDEX which lists some 30 Applicability Statements, the
> most recent being October 2010.  As has been pointed out, there are many more
> appearing as sections of Technical RFC.

Do note that 2026's definition of AS is broader than what we usually 
call "applicability statements". It includes conformance documents, 
protocol profiles, and implementation instructions. There are actually 
plenty of those sorts of documents that are published as BCP that never 
use the words "applicability statement" in their title. And it's 
actually those kinds of documents that I'm most interested in getting on 
the standards track.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From lear@cisco.com  Fri May 13 08:20:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C63DE0735 for ; Fri, 13 May 2011 08:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXSs7sieorvc for ; Fri, 13 May 2011 08:20:16 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 40A36E065A for ; Fri, 13 May 2011 08:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=180; q=dns/txt; s=iport; t=1305300016; x=1306509616; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8ZAtxfwP+VEaC7nlTHmm9pe4jICIW8nHzurJPZiAeAo=; b=ToD+i1mYdJku05EV8vCGCsjY5fqLwrZGiq0icKB2Yi01MjrQPiVpnTzf NqLvftxe9XHYRjj/Fyb38rnH7eVEzwbuffpi3dAfKnDfBk+JKVjSIlrgF 8CngoqoqGVQbwtl7dafr8tU4o+yTL7wGPXa6OxYIpxlZ/zEMCgQ/M9NKr w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoEAL1LzU2Q/khNgWdsb2JhbACEVqEyFAEBFiYlp1WNA5EQgSuDY4EHBJAGjnQ
X-IronPort-AV: E=Sophos;i="4.64,364,1301875200"; d="scan'208";a="30118812"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 May 2011 15:20:15 +0000
Received: from ams3-vpn-dhcp5099.cisco.com (ams3-vpn-dhcp5099.cisco.com [10.61.83.234]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4DFKF6V013780; Fri, 13 May 2011 15:20:15 GMT
Message-ID: <4DCD4C09.2080203@cisco.com>
Date: Fri, 13 May 2011 17:19:37 +0200
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Scott Brim 
References: <4DCB0146.9060307@stpeter.im> <4DCBA219.4070402@ninebynine.org>  <4DCC31C2.1080405@stpeter.im> <4DCD1D98.7040906@cisco.com> <6944.1305294123.579003@Sputnik> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: General discussion of application-layer protocols 
Subject: Re: [apps-discuss] App-ADs chatroom
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:20:17 -0000

On 5/13/11 5:11 PM, Scott Brim wrote:
> On Fri, May 13, 2011 at 09:42, Dave Cridland  wrote:
> works for me, Adium 1.4.2b1
>

Pilot error.  Nevermind.

From presnick@qualcomm.com  Fri May 13 08:21:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47306E0735 for ; Fri, 13 May 2011 08:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.58
X-Spam-Level: 
X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZeniHo7qN0E for ; Fri, 13 May 2011 08:21:37 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 78C07E0734 for ; Fri, 13 May 2011 08:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305300097; x=1336836097; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DCD4C77.3040500@qualcomm.com>|Date:=20Fr i,=2013=20May=202011=2010:21:27=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20Levine=20|CC:=20|Subject:=20Re:=20[apps- discuss]=20Applicability=20Statements|References:=20<2011 0513010025.62566.qmail@joyce.lan>|In-Reply-To:=20<2011051 3010025.62566.qmail@joyce.lan>|Content-Type:=20text/plain =3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=Tac/mWWwu6g9hZ0/tORQdrrcWSLGBGX1ZCzjjvbMVDA=; b=BXkRgsJgdSzW5p4wZsXqCv6kiPxdihESjQy6uMWDUi0LFlaY8hHIxt5N q+03obRBsxvJ9YxWWpIu1dnGqpzTtOVA/nFRxnkQetUC/mi/t4ENjRXDH bK776SkdStFQBG73mRnCd+1JP+IUvA1mg8WjQ0UzrFfF4Vm5NGhCsPH2l c=;
X-IronPort-AV: E=McAfee;i="5400,1158,6344"; a="91041821"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 13 May 2011 08:21:37 -0700
X-IronPort-AV: E=Sophos;i="4.64,364,1301900400"; d="scan'208";a="139264553"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 13 May 2011 08:21:37 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 08:21:36 -0700
Message-ID: <4DCD4C77.3040500@qualcomm.com>
Date: Fri, 13 May 2011 10:21:27 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: John Levine 
References: <20110513010025.62566.qmail@joyce.lan>
In-Reply-To: <20110513010025.62566.qmail@joyce.lan>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Applicability Statements
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:21:39 -0000

On 5/12/11 8:00 PM, John Levine wrote:
>> Let me rephrase: are there Standards-Track BCPs?  The RFC-Editor RFC
>> Search tool does not allow me to search for RFCs that are both, BCPs
>> and on the Standards-Track, thus making a search for such a thing
>> difficult.
>>      
> RFC 3677 is a standards track BCP.
>
> Since it's the only one, perhaps that was a mistake.
>    

Oh, that's pretty funny. It's gotta just be a typo. I'll mention that to 
the RFC Editor.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From alexey.melnikov@isode.com  Sat May 14 10:16:20 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D95E06ED for ; Sat, 14 May 2011 10:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level: 
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLsftbYcsyed for ; Sat, 14 May 2011 10:16:19 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1CE068B for ; Sat, 14 May 2011 10:16:19 -0700 (PDT)
Received: from [188.28.222.48] (188.28.222.48.threembb.co.uk [188.28.222.48])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id ; Sat, 14 May 2011 18:16:17 +0100
Message-ID: <4DCEB8C4.3060205@isode.com>
Date: Sat, 14 May 2011 18:15:48 +0100
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: apps-discuss@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Private Enterprise Number (PEN) IANA registry
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 14 May 2011 17:16:20 -0000

Hi,
IANA is writing a draft on formalizing how Private Enterprise Numbers 
(PENs) are registered. Is anybody interested in helping out (as 
co-editor) with the document? If yes, please contact me off-list.

Thanks,
Alexey


From ht@inf.ed.ac.uk  Mon May 16 02:04:58 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B28E073A; Mon, 16 May 2011 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzsWAeEtekja; Mon, 16 May 2011 02:04:56 -0700 (PDT)
Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 846D1E06AB; Mon, 16 May 2011 02:04:55 -0700 (PDT)
Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p4G94Vmp011435; Mon, 16 May 2011 10:04:36 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4G94VKA024869; Mon, 16 May 2011 10:04:31 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4G94VUo007291;  Mon, 16 May 2011 10:04:31 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id p4G94TN0007287; Mon, 16 May 2011 10:04:29 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: apps-discuss@ietf.org, Mary Barnes , Chris Boulton , Simon Pietro Romano , Henning Schulzrinne , Alan Johnston , Richard Barnes , iesg@ietf.org
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Mon, 16 May 2011 10:04:29 +0100
Message-ID: 
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205
X-Mailman-Approved-At: Mon, 16 May 2011 08:04:49 -0700
Subject: [apps-discuss] apps-team review of draft-ietf-xcon-ccmp-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 09:04:58 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-xcon-ccmp-13

Title: Centralized Conferencing Manipulation Protocol

Reviewer: Henry S. Thompson

Review Date: 2011-05-13

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication

Major Issues: 

4.2 Data Management

1) The approach to detecting competing updates and their consequences
   specified here seems unnecessarily complex.  Was the alternative of
   including version numbers in _update_ messages (so that the server
   could reject any update whose target version had been superseded)
   considered and rejected?  If so, perhaps a brief explanation of why
   it was rejected might be helful at this point.

2) In a related point, the statement at the end of this section that
   "a client subscribed to . . . notifications . . . will always have
   the most up-to-date version" is clearly false, in-so-far as it
   implies that such a client is guaranteed success for any update, as
   there is clearly a race condition here.

4.3 Data Model Compliance

1) Again this approach seems unnecessarily complex -- why does the
   data model have to constrain the initiation of a conference in this
   way.  why not simply have messages which request new conference or
   new user IDs?

2) I'm also confused by the fact that _elements_ described here as
   "mandatory" are not required by the schema.  Specifically in 5.1 we
   will see that the 'confUserID' and 'confObjID' elements, which
   correspond precisely to XCON-USERID and XCON-URI which are
   described here as mandatory, appear in message type definitions as
   minOccurs="0", i.e. as optional.  If they are optional, why is the
   above gensym complexity needed?  If they are not optional, why
   doesn't the schema say so?

3) It is unusual to refer to aspects of a data model with words such
   as 'element' and 'attribute', which are better reserved for use
   with respect to _XML serializations_ of data model instances.  Ah,
   I see by looking at draft-ietf-xcon-common-data-model that the XCON
   data model is defined as an XML document.  It's undoubtedly too
   late to do anything about that, but confounding data models and XML
   serializations is usually considered to be a mistake. . .

11. XML Schema

An http URI should be provided where this schema document can be found
on its own, and an update policy for it (or, preferably, _two_ URIs,
one for exactly this schema document, and one which will be updated if
this document is revised or superseded).  (Likewise for DataModel.xsd
and rfc4575.xsd.)

12.5 CCMP Protocol Registry

Why are these registries needed?  No role is specified for them
anywhere in the body of the document. Registries are not free, and if
all the information in the registry is also in the published schemas
it's not at all clear what purpose they will serve.

Minor Issues: 

6.2. Alice gets detailed information about a specific blueprint

The blueprintResponse message is not schema-valid per ccmp.xsd.  On
lines 32 and 33 of the example read
                    confirm
                      
The problem really lies in DataModel.xsd -- whereas (correctly)
ccmp.xsd uses xs:token as the base type for enumerated types,
DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
and the string value of the above element is "confirm
                      ", which is not one of the allowed values.  The
example should be corrected, or, for preference, the schema in
draft-ietf-xcon-common-data-model should be changed to use xs:token as
the base type for join-handling-type and all other enumerated types.

A similar problem occurs in the response in 6.3
(floor-request-handling)

6.9 Alice exploits a CCMP server extension

For compatibility with the actual response given, the extension schema
document should have a target namespace, as follows:

   
   

     

     
       
	 
	 
	 
	 
       
     

   

Or, better, the example _and_ the schema should be changed to read as
follows:

   
    
      
	  xcon-userid:Alice@example.com
	  xcon:8977794@example.com
	  retrieve


	  200
	  success
	  
	     confSummaryRequest
	     
		  Alice's conference 
		  active 
		  true 
		  audio 
	     
	  
      
    

    
    

      

      
	
	  
	  
	  
	  
	
      

    

Otherwise I've checked all the schemas for conformance and the
examples for schema-validity.

12.2 XML Schema Registration

Should include pointers to the RFCs which include the text of the
schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the
schema docuemnt given in section 11.

12.3 Media Type Registration

It seems unlikely that the proposed extension of 'ccmpxml' will see
much use---4 characters seems to be the practical limit for
extensions.

Nits: One more proofreading pass over the first three sections would
be a good idea. . .

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

From jfc@morfin.org  Sun May 15 16:27:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB195E0707; Sun, 15 May 2011 16:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2imWeY4R2Sg; Sun, 15 May 2011 16:27:21 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0B3E0700; Sun, 15 May 2011 16:27:21 -0700 (PDT)
Received: from 77.30-227-89.dsl.completel.net ([89.227.30.77]:53225 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1QLkiV-0002l9-DW; Sun, 15 May 2011 16:27:19 -0700
Message-Id: <7.0.1.0.2.20110515191953.07211fe8@morfin.org>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 16 May 2011 01:27:18 +0200
To: apps-discuss@ietf.org,EAI WG list , IDNABIS WG list 
From: "J-F C. Morfin" 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - morfin.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Mailman-Approved-At: Mon, 16 May 2011 08:05:03 -0700
Cc: Paul Hoffman 
Subject: Re: [apps-discuss] Internationalization Terminlogy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 May 2011 23:27:21 -0000

John,
Good work. I have just searched the text for some words. I note that:

- "globalization" is missing which is embarassing as Unicode uses to 
say (if I am correct) globalization = internationalization  + 
localization + language tagging.
- "langtag" term is missing, so is their IANA table (largest by far 
IANA file). RFC 5646 is named. RFC 4647 is  quoted, but not 
explained, so  "language filtering" is not alluded to.
- "linguistic diversity" is missing. Not an IETF word but the IETF 
targets its support?
- "majuscules" are named, but uncorrectly explained: in latin 
languages, at least, an upper case may be a majuscule, but a 
majuscule may not be printed as an upper case, or stays a majuscule 
even if incorrectly printed as a lower case.
- "plurilingual" is not quoted which is different from multilingual?
- "linguistic independance" is not alluded to - ex. using digital codes.
- "orthotypograpy" is missing in IETF

jfc

At 18:28 15/05/2011, John C Klensin wrote:
>Hi.
>
>If you have any significant interest in internationalization,
>and particular terminology used about it in the IETF, please
>have a look at draft-ietf-appsawg-rfc3435bis-00.   Paul and I
>have several editorial and fine-tuning comments queued up, but
>are looking for more comments before we submit another draft and
>ask the Apps Area WG Chairs to generate a Last Call within that
>WG.  In other words, your last and best opportunity to submit
>effective comments is now.
>
>We are particularly interested in comments about what has been
>left out that is relevant and important.  Comments about
>definitions we have gotten wrong are also important.
>
>FWIW, we are determined to keep focus on what the title
>suggests: internationalization terminology used in the IETF (and
>in IETF protocol work in particular).  Unless there is strong
>demand in the community to change goals, we do not want to
>expand this document into a general discussion of either
>i18n/l10n issues that includes ones that the IETF has not
>addressed and is never likely to address, nor a discussion of
>character set terminology that has not been needed for IETF
>work, etc.
>
>Note for EAI participants: It is my hope that EAI documents will
>be consistent with these definitions and will, where
>appropriate, reference this document rather than inventing
>definitions of their own.
>
>Note for IDNABIS participants: Note that this document does not
>alter, or even repeat, any IDNA terminology.  IDNA-specific
>terms are simply listed and cross-referenced to RFC 5890.
>
>Substantive comments to apps-discuss@ietf.org please; editorial
>ones to Paul and myself.
>
>thanks,
>    john
>
>_______________________________________________
>Idna-update mailing list
>Idna-update@alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update


From yaojk@cnnic.cn  Mon May 16 20:11:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8911E079F for ; Mon, 16 May 2011 20:11:52 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -99.093
X-Spam-Level: 
X-Spam-Status: No, score=-99.093 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn1mPmk4Yuu7 for ; Mon, 16 May 2011 20:11:52 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 86090E06D6 for ; Mon, 16 May 2011 20:11:51 -0700 (PDT)
Received: (eyou send program); Tue, 17 May 2011 11:11:42 +0800
Message-ID: <505601902.08550@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 17 May 2011 11:11:42 +0800
Message-ID: 
From: "Jiankang YAO" 
To: 
Date: Tue, 17 May 2011 11:11:41 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Publication request:draft-faltstrom-5892bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 03:11:53 -0000

RGVhciBBRHMsDQoNClRoaXMgbWVzc2FnZSBpcyBhIHJlcXVlc3QgdG8gcHVibGlzaA0KZHJhZnQt
ZmFsdHN0cm9tLTU4OTJiaXMtMDQgb24gdGhlIFN0YW5kYXJkcyBUcmFjay4NClRoZSBkcmFmdCBy
ZXByZXNlbnRzIHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhlIEFQUFNBV0cgV29ya2luZw0KR3Jv
dXAuDQoNCkFzIHJlcXVpcmVkIGJ5IFJGQyA0ODU4LCBiZWxvdyBpcyB0aGUgY29tcGxldGVkIGN1
cnJlbnQgdGVtcGxhdGUgZm9yDQp0aGUgRG9jdW1lbnQgU2hlcGhlcmQgV3JpdGUtVXAuDQoNCg0K
QmVzdCByZWdhcmRzLA0KSmlhbmthbmcgWWFvKGFzIGEgY28tY2hhaXIgb2YgQVBQU0FXRykNCg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpEUkFGVCBG
SUxFTkFNRTogDQogICAgZHJhZnQtZmFsdHN0cm9tLTU4OTJiaXMtMDQNClRJVExFOiANCiAgIFRo
ZSBVbmljb2RlIGNvZGUgcG9pbnRzIGFuZCBJRE5BIC0gVW5pY29kZSA2LjANCg0KDQoNCiAgKDEu
YSkgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRo
ZQ0KICAgICAgICBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHJldmlld2VkIHRoaXMgdmVy
c2lvbiBvZiB0aGUgDQogICAgICAgIGRvY3VtZW50IGFuZCwgaW4gcGFydGljdWxhciwgZG9lcyBo
ZSBvciBzaGUgYmVsaWV2ZSB0aGlzIA0KICAgICAgICB2ZXJzaW9uIGlzIHJlYWR5IGZvciBmb3J3
YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8gDQoNCkppYW5rYW5nIFlhby4gIFll
cywgSSBiZWxpZXZlIGl0IGlzIHJlYWR5Lg0KDQogICgxLmIpIEhhcyB0aGUgZG9jdW1lbnQgaGFk
IGFkZXF1YXRlIHJldmlldyBib3RoIGZyb20ga2V5IFdHIG1lbWJlcnMgDQogICAgICAgIGFuZCBm
cm9tIGtleSBub24tV0cgbWVtYmVycz8gRG9lcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSAN
CiAgICAgICAgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSBy
ZXZpZXdzIHRoYXQgDQogICAgICAgIGhhdmUgYmVlbiBwZXJmb3JtZWQ/DQoNClRoZXJlIGhhcyBh
IGxvdCBvZiBkaXNjdXNzaW9ucyBhbmQgYW4gaW5mb3JtYWwgbGFzdCBjYWxsIGZvciBjb21tZW50
cyBhYm91dA0KdGhpcyBkcmFmdCBpbiB0aGUgSUROQWJpcyBsaXN0IGlkbmEtdXBkYXRlQGFsdmVz
dHJhbmQubm8uICANClRoZSBBUFBTQVdHIGhhcyBiZWVuIHRhbGtpbmcgYWJvdXQgdGhpcyBkcmFm
dCBmb3Igc29tZSB0aW1lLiAgSSBiZWxpZXZlIGl0DQpoYXMgaGFkIGFkZXF1YXRlIHJldmlldy4g
IA0KICANCiAgKDEuYykgRG9lcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBjb25jZXJucyB0
aGF0IHRoZSBkb2N1bWVudCANCiAgICAgICAgbmVlZHMgbW9yZSByZXZpZXcgZnJvbSBhIHBhcnRp
Y3VsYXIgb3IgYnJvYWRlciBwZXJzcGVjdGl2ZSwgDQogICAgICAgIGUuZy4sIHNlY3VyaXR5LCBv
cGVyYXRpb25hbCBjb21wbGV4aXR5LCBzb21lb25lIGZhbWlsaWFyIHdpdGggDQogICAgICAgIEFB
QSwgaW50ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1MPyANCg0KTm8uDQoNCiAgKDEuZCkgRG9lcyB0
aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgDQogICAg
ICAgIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgUmVzcG9uc2libGUgQXJlYSBE
aXJlY3Rvcg0KICAgICAgICBhbmQvb3IgdGhlIElFU0cgc2hvdWxkIGJlIGF3YXJlIG9mPyBGb3Ig
ZXhhbXBsZSwgcGVyaGFwcyBoZSANCiAgICAgICAgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUgd2l0
aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IgDQogICAgICAgIGhhcyBjb25jZXJu
cyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgDQogICAgICAg
IGV2ZW50LCBpZiB0aGUgV0cgaGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kIGhhcyBpbmRp
Y2F0ZWQgDQogICAgICAgIHRoYXQgaXQgc3RpbGwgd2lzaGVzIHRvIGFkdmFuY2UgdGhlIGRvY3Vt
ZW50LCBkZXRhaWwgdGhvc2UgDQogICAgICAgIGNvbmNlcm5zIGhlcmUuIEhhcyBhbiBJUFIgZGlz
Y2xvc3VyZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQgDQogICAgICAgIGJlZW4gZmlsZWQ/IElm
IHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byB0aGUgDQogICAgICAgIGRpc2Nsb3N1
cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbiANCiAg
ICAgICAgdGhpcyBpc3N1ZS4gDQoNClRoaXMgZHJhZnQgaXMgYSBkb2N1bWVudCB0aGF0IHVwZGF0
ZXMgUkZDIDU4OTIgYnkNCiBzdGF0aW5nIG5vdGhpbmcgaXMgdG8gYmUgY2hhbmdlZCB3aXRoIHJl
c3BlY3QgdG8gVW5pY29kZQ0KIHZlcnNpb24gNi4gVGhlIElFU0cgbmVlZHMgdG8gZGVjaWRlIHdo
ZXRoZXIgdGhpcyBkb2N1bWVudA0KIHNob3VsZCBiZSBtYXJrZWQgYXMgInVwZGF0aW5nIiBSRkMg
NTg5MiBvciBub3QuDQoNCg0KDQogICgxLmUpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3Vz
IGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KICAgICAgICByZXByZXNlbnQgdGhlIHN0
cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCANCiAgICAgICAgb3Ro
ZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0YW5kIGFu
ZCANCiAgICAgICAgYWdyZWUgd2l0aCBpdD8gICANCg0KTWFueSBXRyBwYXJ0aWNpcGFudHMgZnJv
bSBJRE5BYmlzIGFuZCBBUFBTQVdHIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQNCiBo
YWQgcmVhc29uYWJseSBzdHJvbmcgV0cgY29uc2Vuc3VzLg0KDQogICgxLmYpIEhhcyBhbnlvbmUg
dGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lIA0KICAg
ICAgICBkaXNjb250ZW50PyBJZiBzbywgcGxlYXNlIHN1bW1hcmlzZSB0aGUgYXJlYXMgb2YgY29u
ZmxpY3QgaW4gDQogICAgICAgIHNlcGFyYXRlIGVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBSZXNwb25z
aWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgDQogICAgICAgIHNob3VsZCBiZSBpbiBhIHNlcGFyYXRl
IGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzIA0KICAgICAgICBlbnRlcmVkIGlu
dG8gdGhlIElEIFRyYWNrZXIuKSANCg0KTm8uDQoNCiAgKDEuZykgSGFzIHRoZSBEb2N1bWVudCBT
aGVwaGVyZCBwZXJzb25hbGx5IHZlcmlmaWVkIHRoYXQgdGhlIA0KICAgICAgICBkb2N1bWVudCBz
YXRpc2ZpZXMgYWxsIElEIG5pdHM/IChTZWUgdGhlIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3Qg
DQogICAgICAgIGFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLykuIEJvaWxl
cnBsYXRlIGNoZWNrcyBhcmUgDQogICAgICAgIG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMg
dG8gYmUgdGhvcm91Z2guIEhhcyB0aGUgZG9jdW1lbnQgDQogICAgICAgIG1ldCBhbGwgZm9ybWFs
IHJldmlldyBjcml0ZXJpYSBpdCBuZWVkcyB0bywgc3VjaCBhcyB0aGUgTUlCIA0KICAgICAgICBE
b2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0eXBlIHJldmlld3M/IA0KDQpZZXMsIEkgaGF2ZSBj
aGVja2VkIGl0LiBUaGVyZSBpcyBvbmUgdW51c2VkIHJlZmVyZW5jZTsgc2VlIDEuaC4NCg0KDQog
ICgxLmgpIEhhcyB0aGUgZG9jdW1lbnQgc3BsaXQgaXRzIHJlZmVyZW5jZXMgaW50byBub3JtYXRp
dmUgYW5kIA0KICAgICAgICBpbmZvcm1hdGl2ZT8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVu
Y2VzIHRvIGRvY3VtZW50cyB0aGF0IA0KICAgICAgICBhcmUgbm90IHJlYWR5IGZvciBhZHZhbmNl
bWVudCBvciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xlYXIgDQogICAgICAgIHN0YXRlPyBJZiBz
dWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSANCiAgICAgICAgc3Ry
YXRlZ3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/IEFyZSB0aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNl
cyANCiAgICAgICAgdGhhdCBhcmUgZG93bndhcmQgcmVmZXJlbmNlcywgYXMgZGVzY3JpYmVkIGlu
IFtSRkMzOTY3XT8gSWYgDQogICAgICAgIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5j
ZXMgdG8gc3VwcG9ydCB0aGUgQXJlYSANCiAgICAgICAgRGlyZWN0b3IgaW4gdGhlIExhc3QgQ2Fs
bCBwcm9jZWR1cmUgZm9yIHRoZW0gW1JGQzM5NjddLiANCg0KVGhlIHJlZmVyZW5jZXMgYXJlIGNv
cnJlY3QuICBUaGVyZSBhcmUgdHdvIHJlZmVyZW5jZXMgdG8gbm9uLUlFVEYNCmRvY3VtZW50cyAo
VW5pY29kZSA1LjIgYW5kIFVuaWNvZGUgNi4wKSwgYW5kIHRob3NlIGFyZSBuZWNlc3NhcnkgYW5k
DQpjb3JyZWN0Lg0KDQoiVW5pY29kZTYiIGlzIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVu
Y2UsIGJ1dA0KaXQgaXMgbmV2ZXIgcmVmZXJlbmNlZCBpbiB0aGUgbWFpbiB0ZXh0IGFsdGhvdWdo
ICJVbmljb2RlIDYuMCIgaXMNCnVzZWQgZXZlcnl3aGVyZS4gIFBsZWFzZSBhZGQgdGhlIGZvbGxv
d2luZyBSRkMgRWRpdG9yIG5vdGU6DQotLS0NCkludHJvZHVjdGlvbiwgZmlyc3QgcGFyYWdyYXBo
Og0KT0xEDQogICBpdCBkZWZpbmVzIGEgZGVyaXZlZCBwcm9wZXJ0eSB2YWx1ZS4gIFVuaWNvZGUg
Ni4wIGhhcyBjaGFuZ2VkDQogICBHZW5lcmFsQ2F0ZWdvcnkgb2YgdGhyZWUgY29kZSBwb2ludHMg
dGhhdCB3aGVyZSBhbGxvY2F0ZWQgaW4gVW5pY29kZQ0KTkVXDQogICBpdCBkZWZpbmVzIGEgZGVy
aXZlZCBwcm9wZXJ0eSB2YWx1ZS4gIFVuaWNvZGUgNi4wIFtVbmljb2RlNl0gaGFzIGNoYW5nZWQN
CiAgIEdlbmVyYWxDYXRlZ29yeSBvZiB0aHJlZSBjb2RlIHBvaW50cyB0aGF0IHdoZXJlIGFsbG9j
YXRlZCBpbiBVbmljb2RlDQotLS0NCg0KICAoMS5pKSBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJk
IHZlcmlmaWVkIHRoYXQgdGhlIGRvY3VtZW50IElBTkEgDQogICAgICAgIGNvbnNpZGVyYXRpb24g
c2VjdGlvbiBleGlzdHMgYW5kIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYm9keSANCiAgICAgICAg
b2YgdGhlIGRvY3VtZW50PyANCg0KWWVzLg0KDQoNCiAgICAgICAgSWYgdGhlIGRvY3VtZW50IHNw
ZWNpZmllcyBwcm90b2NvbCANCiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9ucyBy
ZXF1ZXN0ZWQgaW4gYXBwcm9wcmlhdGUgSUFOQSANCiAgICAgICAgcmVnaXN0cmllcz8gQXJlIHRo
ZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlmaWVkPyBJZiANCiAgICAgICAgdGhlIGRv
Y3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5lIHRoZSANCiAgICAg
ICAgcHJvcG9zZWQgaW5pdGlhbCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9j
YXRpb24gDQogICAgICAgIHByb2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMg
aXQgc3VnZ2VzdCBhIA0KICAgICAgICByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0
cnk/IFNlZSBbUkZDNTIyNl0uIElmIHRoZSANCiAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFu
IEV4cGVydCBSZXZpZXcgcHJvY2VzcyBoYXMgU2hlcGhlcmQgDQogICAgICAgIGNvbmZlcnJlZCB3
aXRoIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cgDQogICAg
ICAgIGNhbiBhcHBvaW50IHRoZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0
aW9uPyANCg0KTi9BLg0KDQoNCiAgKDEuaikgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJp
ZmllZCB0aGF0IHNlY3Rpb25zIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgdGhhdCBhcmUgd3Jp
dHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3VjaCBhcyBYTUwgDQogICAgICAgIGNvZGUsIEJO
RiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuLCB2YWxpZGF0ZSBjb3JyZWN0bHkgaW4gDQog
ICAgICAgIGFuIGF1dG9tYXRlZCBjaGVja2VyPyANCg0KVGhlcmUgaXMgbm8gZm9ybWFsIGxhbmd1
YWdlIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KICAoMS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5v
dW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCANCiAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRl
LVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgDQogICAgICAgIEFubm91bmNlbWVu
dCBXcml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAg
IkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92
YWwgDQogICAgICAgIGFubm91bmNlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25z
OiANCg0KICAgICBUZWNobmljYWwgU3VtbWFyeSANCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg
SUVURiBjb25zZW5zdXMgZm9yIElETkEgZGVyaXZlZCBjaGFyYWN0ZXINCnByb3BlcnRpZXMgcmVs
YXRlZCB0byB0aGUgdGhyZWUgY29kZSBwb2ludHMsIGV4aXN0aW5nIGluIFVuaWNvZGUgNS4yLA0K
dGhhdCBjaGFuZ2VkIHByb3BlcnR5IHZhbHVlcyB3aGVuIHZlcnNpb24gNi4wIHdhcyByZWxlYXNl
ZC4gDQoNCg0KICAgICBXb3JraW5nIEdyb3VwIFN1bW1hcnkgDQogICAgICAgIA0KVGhpcyBkb2N1
bWVudCBoYXMgYmVlbiBkaXNjdXNzZWQgYm90aCBpbiB0aGUgb2xkIElETkFiaXMgV0cgbGlzdCBh
bmQgQVBQU0FXRyBsaXN0LiANClRoZSBXRyBjYW1lIHRvIGNvbnNlbnN1cyBvbiB0aGlzIGRvY3Vt
ZW50Lg0KDQoNCg0KICAgICBEb2N1bWVudCBRdWFsaXR5IA0KDQpUaGlzIGRvY3VtZW50IGlzIGNv
bmNpc2UgYW5kIGNsZWFyLA0KYW5kIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbg0KDQooZW5kKQ0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t


From patrik@frobbit.se  Mon May 16 20:47:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC93CE06B5 for ; Mon, 16 May 2011 20:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.303
X-Spam-Level: 
X-Spam-Status: No, score=-100.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8j0IrtX5678 for ; Mon, 16 May 2011 20:47:05 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E0969E0721 for ; Mon, 16 May 2011 20:47:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 4D13710DAFD2D; Tue, 17 May 2011 05:47:01 +0200 (CEST)
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 DHInmR+MkFT5; Tue, 17 May 2011 05:47:00 +0200 (CEST)
Received: from [78.78.92.224] (host-78-78-92-224.mobileonline.telia.com [78.78.92.224]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id EB86110DAFD22; Tue, 17 May 2011 05:46:58 +0200 (CEST)
References: <505601902.08550@cnnic.cn>
In-Reply-To: <505601902.08550@cnnic.cn>
Mime-Version: 1.0 (iPhone Mail 8J2)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <893263AB-7206-4408-9D5E-2FB149161BC2@frobbit.se>
X-Mailer: iPhone Mail (8J2)
From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= 
Date: Tue, 17 May 2011 05:46:25 +0200
To: Jiankang YAO 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Publication request:draft-faltstrom-5892bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 03:47:06 -0000

Thank you for your work!

   Patrik

On 17 maj 2011, at 05:11, "Jiankang YAO"  wrote:

> Dear ADs,
>=20
> This message is a request to publish
> draft-faltstrom-5892bis-04 on the Standards Track.
> The draft represents the rough consensus of the APPSAWG Working
> Group.
>=20
> As required by RFC 4858, below is the completed current template for
> the Document Shepherd Write-Up.
>=20
>=20
> Best regards,
> Jiankang Yao(as a co-chair of APPSAWG)
>=20
>=20
> --------------------------------------------
>=20
> DRAFT FILENAME:=20
>    draft-faltstrom-5892bis-04
> TITLE:=20
>   The Unicode code points and IDNA - Unicode 6.0
>=20
>=20
>=20
>  (1.a) Who is the Document Shepherd for this document? Has the
>        Document Shepherd personally reviewed this version of the=20
>        document and, in particular, does he or she believe this=20
>        version is ready for forwarding to the IESG for publication?=20
>=20
> Jiankang Yao.  Yes, I believe it is ready.
>=20
>  (1.b) Has the document had adequate review both from key WG members=20
>        and from key non-WG members? Does the Document Shepherd have=20
>        any concerns about the depth or breadth of the reviews that=20
>        have been performed?
>=20
> There has a lot of discussions and an informal last call for comments abou=
t
> this draft in the IDNAbis list idna-update@alvestrand.no. =20
> The APPSAWG has been talking about this draft for some time.  I believe it=

> has had adequate review. =20
>=20
>  (1.c) Does the Document Shepherd have concerns that the document=20
>        needs more review from a particular or broader perspective,=20
>        e.g., security, operational complexity, someone familiar with=20
>        AAA, internationalization or XML?=20
>=20
> No.
>=20
>  (1.d) Does the Document Shepherd have any specific concerns or=20
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of? For example, perhaps he=20
>        or she is uncomfortable with certain parts of the document, or=20
>        has concerns whether there really is a need for it. In any=20
>        event, if the WG has discussed those issues and has indicated=20
>        that it still wishes to advance the document, detail those=20
>        concerns here. Has an IPR disclosure related to this document=20
>        been filed? If so, please include a reference to the=20
>        disclosure and summarize the WG discussion and conclusion on=20
>        this issue.=20
>=20
> This draft is a document that updates RFC 5892 by
> stating nothing is to be changed with respect to Unicode
> version 6. The IESG needs to decide whether this document
> should be marked as "updating" RFC 5892 or not.
>=20
>=20
>=20
>  (1.e) How solid is the WG consensus behind this document? Does it=20
>        represent the strong concurrence of a few individuals, with=20
>        others being silent, or does the WG as a whole understand and=20
>        agree with it?  =20
>=20
> Many WG participants from IDNAbis and APPSAWG have reviewed this document a=
nd
> had reasonably strong WG consensus.
>=20
>  (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20
>        discontent? If so, please summarise the areas of conflict in=20
>        separate email messages to the Responsible Area Director. (It=20
>        should be in a separate email because this questionnaire is=20
>        entered into the ID Tracker.)=20
>=20
> No.
>=20
>  (1.g) Has the Document Shepherd personally verified that the=20
>        document satisfies all ID nits? (See the Internet-Drafts Checklist=20=

>        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20=

>        not enough; this check needs to be thorough. Has the document=20
>        met all formal review criteria it needs to, such as the MIB=20
>        Doctor, media type and URI type reviews?=20
>=20
> Yes, I have checked it. There is one unused reference; see 1.h.
>=20
>=20
>  (1.h) Has the document split its references into normative and=20
>        informative? Are there normative references to documents that=20
>        are not ready for advancement or are otherwise in an unclear=20
>        state? If such normative references exist, what is the=20
>        strategy for their completion? Are there normative references=20
>        that are downward references, as described in [RFC3967]? If=20
>        so, list these downward references to support the Area=20
>        Director in the Last Call procedure for them [RFC3967].=20
>=20
> The references are correct.  There are two references to non-IETF
> documents (Unicode 5.2 and Unicode 6.0), and those are necessary and
> correct.
>=20
> "Unicode6" is listed as a normative reference, but
> it is never referenced in the main text although "Unicode 6.0" is
> used everywhere.  Please add the following RFC Editor note:
> ---
> Introduction, first paragraph:
> OLD
>   it defines a derived property value.  Unicode 6.0 has changed
>   GeneralCategory of three code points that where allocated in Unicode
> NEW
>   it defines a derived property value.  Unicode 6.0 [Unicode6] has changed=

>   GeneralCategory of three code points that where allocated in Unicode
> ---
>=20
>  (1.i) Has the Document Shepherd verified that the document IANA=20
>        consideration section exists and is consistent with the body=20
>        of the document?=20
>=20
> Yes.
>=20
>=20
>        If the document specifies protocol=20
>        extensions, are reservations requested in appropriate IANA=20
>        registries? Are the IANA registries clearly identified? If=20
>        the document creates a new registry, does it define the=20
>        proposed initial contents of the registry and an allocation=20
>        procedure for future registrations? Does it suggest a=20
>        reasonable name for the new registry? See [RFC5226]. If the=20
>        document describes an Expert Review process has Shepherd=20
>        conferred with the Responsible Area Director so that the IESG=20
>        can appoint the needed Expert during the IESG Evaluation?=20
>=20
> N/A.
>=20
>=20
>  (1.j) Has the Document Shepherd verified that sections of the=20
>        document that are written in a formal language, such as XML=20
>        code, BNF rules, MIB definitions, etc., validate correctly in=20
>        an automated checker?=20
>=20
> There is no formal language in this document.
>=20
>=20
>  (1.k) The IESG approval announcement includes a Document=20
>        Announcement Write-Up. Please provide such a Document=20
>        Announcement Write-Up? Recent examples can be found in the
>        "Action" announcements for approved documents. The approval=20
>        announcement contains the following sections:=20
>=20
>     Technical Summary=20
>=20
> This document specifies IETF consensus for IDNA derived character
> properties related to the three code points, existing in Unicode 5.2,
> that changed property values when version 6.0 was released.=20
>=20
>=20
>     Working Group Summary=20
>=20
> This document has been discussed both in the old IDNAbis WG list and APPSA=
WG list.=20
> The WG came to consensus on this document.
>=20
>=20
>=20
>     Document Quality=20
>=20
> This document is concise and clear,
> and is ready for publication
>=20
> (end)
> ---------------------------------------------
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20

From mnot@mnot.net  Mon May 16 21:23:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30B1E07C4 for ; Mon, 16 May 2011 21:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.602
X-Spam-Level: 
X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[AWL=-2.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRehAZv+gWdU for ; Mon, 16 May 2011 21:23:18 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 33A29E07A7 for ; Mon, 16 May 2011 21:23:18 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.62.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A3B1D22E247 for ; Tue, 17 May 2011 00:23:11 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 May 2011 14:23:08 +1000
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com>
To: Apps Discuss 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 04:23:18 -0000

FYI.


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: 17 May 2011 2:21:49 PM AEST
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-nottingham-http-browser-hints-00.txt
> Reply-To: internet-drafts@ietf.org
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
> 	Title           : HTTP Browser Hints
> 	Author(s)       : Mark Nottingham
> 	Filename        : draft-nottingham-http-browser-hints-00.txt
> 	Pages           : 8
> 	Date            : 2011-05-16
>=20
>   Over time, Web browsers have adapted how they use HTTP based upon
>   common server configurations and behaviours.  While this is =
necessary
>   in the common case, it can be detrimental for performance and
>   interoperability.
>=20
>   This document establishes a mechanism whereby origin servers can =
make
>   available hints for browsers about their preferences and
>   capabilities, without imposing overhead on their interactions or
>   requiring support for them.
>=20
>   This is intended to allow browsers to safely optimise connections to
>   servers.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00=
.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00.=
txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham   http://www.mnot.net/




From mnot@mnot.net  Mon May 16 23:17:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50651E07AE for ; Mon, 16 May 2011 23:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.602
X-Spam-Level: 
X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[AWL=-2.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cBC2v7yGmUv for ; Mon, 16 May 2011 23:16:59 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 45AACE0682 for ; Mon, 16 May 2011 23:16:58 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.62.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 900DA22E1F4; Tue, 17 May 2011 02:16:51 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: <20110517053416.GB26443@1wt.eu>
Date: Tue, 17 May 2011 16:16:48 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu>
To: Willy Tarreau 
X-Mailer: Apple Mail (2.1084)
Cc: HTTP Working Group , Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Apps Discuss 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2011 06:17:00 -0000

[ sending replies to apps-discuss ]

Hi Willy,=20


On 17/05/2011, at 3:34 PM, Willy Tarreau wrote:

> Hi Mark,
>=20
> On Tue, May 17, 2011 at 02:23:29PM +1000, Mark Nottingham wrote:
>> A URL for this Internet-Draft is:
>> =
http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00=
.txt
>=20
> While I have still not replied to your previous mail about the =
pipelining
> draft, I must say that I like this new proposal a lot more than the =
old one.

Thanks, but they're orthogonal.

> I think that default values should be indicated for all values there.

The defaults are the current behaviours of implementations; anything =
else would make this mechanism non-optional, and introduce lots of =
problems.

> For
> instance, if a site complies with this draft and delivers a =
browser-hints
> file, it means that it's likely to comply with many of the server
> requirements, so pipelining should be supported for instance.

Pipelining already has to be supported, if it's a HTTP/1.1 server. As =
has been discussed ad nauseum, a "I support pipelining" or even a "I =
really support pipelining" flag doesn't do anyone any good.

> Thus, we
> could reasonably suggest that max-pipeline-depth is non-zero when not
> specified.
>=20
> For "small-hdrs", we should explicitly indicate what Accept* header =
values
> will be used by the server when they are not sent by the browser.

It'll work just like it does when you don't send the Accept-Headers =
values in HTTP today. Anything else would be introducing incompatible =
changes to HTTP.

> Concerning the no-referer, we're risking that people always ask for a
> referer header to be sent because they want to see how they're =
indexed.
> My suggestion would be that we provide the ability not to send a =
referer
> header for requests coming from the same site (eg: fetching images =
from
> a site's page enlarges all requests for nothing). That could probably =
be
> combined with the new Ref header you're proposing with various options =
:
>=20
>   - no referer from the same site
>   - relative referer only without query string
>   - relative referer only with query string
>   - full referer

I suspect that the referer-related mechanisms are going to be refined, =
based on feedback I've already received. Also, see Adam Barth's related =
work on Origin.=20

> I'm seeing a minor issue though : we're mixing there two distinct =
pieces of
> information. We have infrastructure-related information (pipelining, =
concurrent
> persistent connections, etc...) and application informationn (referer, =
...).
>=20
> Some large hosting infrastructures I know will like the connection =
related
> informations to be directly delivered from outer shared reverse =
proxies for all
> hosted sites, while the application-specific information will be =
delivered from
> hosted applications. Eg: one app will want the referer while another =
won't care,
> however neither knows what to announce for pipelining or persistent =
conns.

IME more complex deployments like this tend to develop back-end =
practices and tools to manage those issues.

> Thus we should probably have two distinct well known files. In order =
to
> reduce the number of requests, we could suggest that if the =
browser-hints
> file does not contain any connection information, then the browser is
> invited to get /.well-known/connection-hints too as a complement.

I have a pretty strong suspicion that this will end up being too =
complex, but let's see what others think.

> Anyway I don't think that fetching two files is an issue, considering =
that
> the connection-specific one would be cached much longer.
>=20
> While we're at it, the same file could be used to announce the =
configured
> keep-alive timeout so that browsers don't try to send requests over
> supposedly dead connections.


Possibly, but I'm not sure what that achieves, vs. the Keep-Alive header =
that's already implemented. Some servers also want this to be dynamic. =
See also Martin Thompson et al's work on timeouts.

Cheers,

--
Mark Nottingham   http://www.mnot.net/




From ryan.sleevi@gmail.com  Mon May 16 20:55:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD030E079F for ; Mon, 16 May 2011 20:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+09ciZMBJz2 for ; Mon, 16 May 2011 20:55:23 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC3D8E0721 for ; Mon, 16 May 2011 20:55:22 -0700 (PDT)
Received: by yic13 with SMTP id 13so43901yic.31 for ; Mon, 16 May 2011 20:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=iXPo4Qku0l0kF4EY2mG1Qh/s+0eG35qupGSL57FkliY=; b=DGmTCzTOh9DpVXxD8kN9QgwG+F7LOWjAGycoqjJapVVXcPdp2B0QlX+mTnErm1A9C9 whROycsVCmUgBeTXfQqP9jk5aEKW9+MNeddco2hKmflaK3wlAlivD0kVYXDPR9qmjsXE DhBNie2veBQw/pZgj8nj5YPmbOXmCBDuV3G6s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AfWzZY4Y5Bfj0PrBCVMmyxkRbwhwrCVPMy23mHadrJm157Ai7+kQX1zd4VEKKxdZv+ rbNF6ABLbx9sgpQPLarnZcwMly+O6vhba4e48yXmNT+/Z+Pp4qBlzVfQXb95FNFvP42m 2Y8OX0vwlp6VKViHRGIc2E7BKCGPC9L1UP1iM=
MIME-Version: 1.0
Received: by 10.236.9.99 with SMTP id 63mr145169yhs.25.1305604522051; Mon, 16 May 2011 20:55:22 -0700 (PDT)
Received: by 10.236.208.225 with HTTP; Mon, 16 May 2011 20:55:22 -0700 (PDT)
Date: Mon, 16 May 2011 23:55:22 -0400
Message-ID: 
From: Ryan Sleevi 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Tue, 17 May 2011 06:27:53 -0700
Subject: [apps-discuss] Comments on draft-hammer-oauth-v2-mac-token
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 03:56:07 -0000

These comments apply to the -05 draft,
http://tools.ietf.org/id/draft-hammer-oauth-v2-mac-token-05.txt . As
I'm not subscribed to apps-discuss, please keep me cc'd in replies.

While reviewing a draft implementation of the above, two decisions
stood out to me that seemed odd, both related to the key entropy. It
seems minor to address these, and by doing so, may make it easier for
clients/implementations with different security requirements to
interoperate successfully and behave predictably.


2. Issuing MAC Credentials

Is there a reason that the MAC key is constrained to printable
encoding, as opposed to being Base64-encoded like bodyhash (3.2),
hmac-sha-1 (3.3.2), or hmac-sha-256 (3.3.3)? My concern here is that,
pursuant to RFC 2104, Section 2, HMAC implementations are required to
hash keys longer than B bytes, the length of the underlying hash
algorithm block size, in order to obtain K, the key used for HMAC. As
a result of this requirement, there is a hard upper limit to the
length and possible entropy of a key.

Under the current text, each key byte is limited to roughly 6.55 bits
of entropy, rather than the possible full 8 bits of entropy with no
character restrictions. In practical terms, this means that the
maximum entropy available for a HMAC-SHA-256 key (B=64 bytes) goes
from 512 bits to approximately 419 bits, which equally causes a
corresponding drop in the maximum security strength available.

Updating the MAC key to be Base64-encoded in Section 2, and
Base64-decoded before processing in Sections 3.3.2 and 3.3.3 would be
able to easily resolve this, allowing the server greater control over
the amount of entropy in the key and the strength of the produced
results. Given the threat model previously discussed, this entropy
upper bound is not likely to be a significant practical concern, but
it struck me as odd to impose this limit.


7.5.  Entropy of MAC Keys

Combined with Sections 3.3.2. and 3.3.3., I'm concerned that there may
be a possible interoperability concern, specifically between
implementations that are operating in a FIPS-approved/FIPS-validated
mode of operation and implementations which are not. While FIPS
validation is primarily a US concern, the current language, combined
with the language in RFC 2104, Section 3, give enough flexibility to
run into this issue. Considering that NIST FIPS-180-3 is referenced in
the draft, it seems appropriate to bring up this issue.

Currently, RFC 2104, Section 3 provides guidance that keys should be
between L bytes, which is the size of the output of the underlying
hash algorithm, and B bytes long. Keys less than L bytes are "strongly
discouraged," but that is not an RFC 2119-style imperative, thus keys
of lengths less than L are perfectly acceptable. Meanwhile,
implementations that were validated according to the requirements of
NIST FIPS-198, whether FIPS 198 (released in 2002) or FIPS 198-1
(updated in 2008), have and typically enforce certain minimum key
lengths. This is traditionally L/2, regardless of algorithm, as that
was the requirement in FIPS 198, but may be implemented as a minimum
strength of the key, independent of the algorithm.

As a result of the differing requirements between the two HMAC
documents, it's possible for an interoperability issue to emerge where
a client, with a cryptographic module that is FIPS validated and
configured to operate in a FIPS-approved mode of operation,
communicates with a server that selects a key smaller than L/2 bytes,
selected based on the general security guidance of Section 7.5. When
passing the MAC key in to the cryptographic module, in order to
compute the request "mac", the key will be rejected for not meeting
the FIPS length requirements and the client will be unable to
authenticate. While there are potentially more complexities regarding
FIPS interoperability, this would seem a trivial issue to address in
the current draft.

By adding language, similar to that added in the -04 revision to
Section 2 for unknown algorithms, to handle unsupported/insufficient
key lengths, this issue could be easily addressed, and in a manner
that is suitable for the differing organizational and operational
security requirements. Under the "MAC key" section of Section 2,
adding "If the issued key is not of sufficient strength for the
client's implementation of the chosen MAC algorithm, the client MUST
NOT use the MAC credentials and should continue as if no MAC
credentials were issued." Likewise, either by adopting similar
language to RFC 2104, Section 3, or simply by referencing it, the
security guidance of Section 7.5 could be updated to reflect the
possible interoperability issues related to minimum key sizes.

By adopting Base64-encoding/decoding for the MAC key, as described
above, implementations should be able to easily evaluate security
strength, which will be the length of decoded key in bits, rather than
having to consider the limited keyspace of the printable encoding and
expanding that based upon the length in bytes of the key.

From dzonatas@gmail.com  Tue May 17 07:08:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3ACE081C for ; Tue, 17 May 2011 07:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.837
X-Spam-Level: 
X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-3.532, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Xh8SvPTXsz for ; Tue, 17 May 2011 07:08:02 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id AFA71E0773 for ; Tue, 17 May 2011 07:08:02 -0700 (PDT)
Received: by pxi2 with SMTP id 2so328884pxi.38 for ; Tue, 17 May 2011 07:08:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FNIil18glqG18tIB8Gi0v27xcoGVfKhTSmofeo/Y3ik=; b=CAVG+UX5ecWW77Qy7j7LDfwdokWlnkiVXTOuvcI59xD8XYfqBLuzFSb8v6pbG5EwSc HmzEIXJGTnXtPOHd5E2b3DgABIVB1qvYyVq55WkY1OkJDoiV7Dlh5ojJ0yyY+pU826v/ QC73eAHyNAmEeWAvuL8O+QJ1KXqmavV42ogOM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=EzeTuHf6jEfytS5NAyMSa/c/MP5jiHfJxckfevkb6TviNYByRaFS43slafXZllmlVH wh7KHOvG+Z1nwgbpP2ohJeacBgn2Z3k8Gy4LEcXvmGZzxLvC7fEm+WOD5DVfhZNHJtxn zggxut5T7t/SQdrJRobgV96QnVCXkp+s5W1gU=
Received: by 10.142.61.18 with SMTP id j18mr465668wfa.75.1305641282427; Tue, 17 May 2011 07:08:02 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id t9sm395832pbq.31.2011.05.17.07.08.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 07:08:01 -0700 (PDT)
Message-ID: <4DD28114.7010601@gmail.com>
Date: Tue, 17 May 2011 07:07:16 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 14:08:03 -0000

On 05/16/2011 11:16 PM, Mark Nottingham wrote:
>
>> Thus we should probably have two distinct well known files. In order to
>> reduce the number of requests, we could suggest that if the browser-hints
>> file does not contain any connection information, then the browser is
>> invited to get /.well-known/connection-hints too as a complement.
>>      
> I have a pretty strong suspicion that this will end up being too complex, but let's see what others think.
>
>    

The ReSTful paradigm is useful here such that any specific field in the 
browser-hints file can be found by path.

GET /.well-known/browser-hints/max-conns

I'm sure this leads to PUT, POST, and DELETE methods as well for easier 
connection negotiation, management, and hints of what paths are 
streams/pipelines, or like capabilities.

For example, I use these next two to combine all data into one stream 
that appears like a structure, with the specific path:

GET /.well-known/browser-hint/s   # all hints with data in XML format
GET /.well-known/browser-hint      # list of categories known in XML format

As above:
GET /.well-known/browser-hints    # suggested default for JSON fromat

I suggest this "symbolic" reservation for *explicit* stream methods and 
logical devices  (combined path use-cases from SYSV, VMS, and 
IETF-VWRAP-LLIDL)
GET /.well-known/browser-hint$
GET /.well-known/browser-hint$max-conns

Conservative approach to avoid query arguments or extra headers that 
specify format:
GET /.well-known/browser-hint.xml         # XML alternative
GET /.well-known/browser-hint.json         # JSON alternative
GET /.well-known/browser-hint.json.xml  # json in XML format: 
https://datatracker.ietf.org/doc/draft-rsalz-jsonx

I think XSLT with optional script can be used for further 
transformations of paths and streams.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From rjsparks@nostrum.com  Tue May 17 07:16:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11306E06A7; Tue, 17 May 2011 07:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.4
X-Spam-Level: 
X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQS1HACp7lJc; Tue, 17 May 2011 07:16:36 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA37E0665; Tue, 17 May 2011 07:16:36 -0700 (PDT)
Received: from [192.168.2.105] (pool-173-57-91-217.dllstx.fios.verizon.net [173.57.91.217]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4HEGA3E054289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 May 2011 09:16:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks 
In-Reply-To: 
Date: Tue, 17 May 2011 09:16:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "Henry S. Thompson" 
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.57.91.217 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Tue, 17 May 2011 08:05:40 -0700
Cc: Henning Schulzrinne , Alan Johnston , apps-discuss@ietf.org, Simon Pietro Romano , Chris Boulton , xcon@ietf.org, Richard Barnes , "iesg@ietf.org IESG" 
Subject: Re: [apps-discuss] apps-team review of draft-ietf-xcon-ccmp-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 14:16:38 -0000

Adding the XCON WG list

On May 16, 2011, at 4:04 AM, Henry S. Thompson wrote:

> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
>=20
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>=20
> Document: draft-ietf-xcon-ccmp-13
>=20
> Title: Centralized Conferencing Manipulation Protocol
>=20
> Reviewer: Henry S. Thompson
>=20
> Review Date: 2011-05-13
>=20
> Summary: This draft is almost ready for publication as a Proposed
> Standard but has a few issues that should be fixed before publication
>=20
> Major Issues:=20
>=20
> 4.2 Data Management
>=20
> 1) The approach to detecting competing updates and their consequences
>   specified here seems unnecessarily complex.  Was the alternative of
>   including version numbers in _update_ messages (so that the server
>   could reject any update whose target version had been superseded)
>   considered and rejected?  If so, perhaps a brief explanation of why
>   it was rejected might be helful at this point.
>=20
> 2) In a related point, the statement at the end of this section that
>   "a client subscribed to . . . notifications . . . will always have
>   the most up-to-date version" is clearly false, in-so-far as it
>   implies that such a client is guaranteed success for any update, as
>   there is clearly a race condition here.
>=20
> 4.3 Data Model Compliance
>=20
> 1) Again this approach seems unnecessarily complex -- why does the
>   data model have to constrain the initiation of a conference in this
>   way.  why not simply have messages which request new conference or
>   new user IDs?
>=20
> 2) I'm also confused by the fact that _elements_ described here as
>   "mandatory" are not required by the schema.  Specifically in 5.1 we
>   will see that the 'confUserID' and 'confObjID' elements, which
>   correspond precisely to XCON-USERID and XCON-URI which are
>   described here as mandatory, appear in message type definitions as
>   minOccurs=3D"0", i.e. as optional.  If they are optional, why is the
>   above gensym complexity needed?  If they are not optional, why
>   doesn't the schema say so?
>=20
> 3) It is unusual to refer to aspects of a data model with words such
>   as 'element' and 'attribute', which are better reserved for use
>   with respect to _XML serializations_ of data model instances.  Ah,
>   I see by looking at draft-ietf-xcon-common-data-model that the XCON
>   data model is defined as an XML document.  It's undoubtedly too
>   late to do anything about that, but confounding data models and XML
>   serializations is usually considered to be a mistake. . .
>=20
> 11. XML Schema
>=20
> An http URI should be provided where this schema document can be found
> on its own, and an update policy for it (or, preferably, _two_ URIs,
> one for exactly this schema document, and one which will be updated if
> this document is revised or superseded).  (Likewise for DataModel.xsd
> and rfc4575.xsd.)
>=20
> 12.5 CCMP Protocol Registry
>=20
> Why are these registries needed?  No role is specified for them
> anywhere in the body of the document. Registries are not free, and if
> all the information in the registry is also in the published schemas
> it's not at all clear what purpose they will serve.
>=20
> Minor Issues:=20
>=20
> 6.2. Alice gets detailed information about a specific blueprint
>=20
> The blueprintResponse message is not schema-valid per ccmp.xsd.  On
> lines 32 and 33 of the example read
>                    confirm
>                      
> The problem really lies in DataModel.xsd -- whereas (correctly)
> ccmp.xsd uses xs:token as the base type for enumerated types,
> DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
> and the string value of the above element is "confirm
>                      ", which is not one of the allowed values.  The
> example should be corrected, or, for preference, the schema in
> draft-ietf-xcon-common-data-model should be changed to use xs:token as
> the base type for join-handling-type and all other enumerated types.
>=20
> A similar problem occurs in the response in 6.3
> (floor-request-handling)
>=20
> 6.9 Alice exploits a CCMP server extension
>=20
> For compatibility with the actual response given, the extension schema
> document should have a target namespace, as follows:
>=20
>   
>    	      =
targetNamespace=3D"http://example.com/ccmp-extension-schema.xsd"
> 	      xmlns=3D"http://example.com/ccmp-extension-schema.xsd">
>=20
>     
>=20
>     
>       
> 	 
> 	 
> 	 
> 	 
>       
>     
>=20
>   
>=20
> Or, better, the example _and_ the schema should be changed to read as
> follows:
>=20
>   
>     	   xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp"
> 	   xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-conference-info"
> 	   xmlns:example=3D"http://example.com/ccmp-extension">
>       	  xsi:type=3D"ccmp:ccmp-extended-response-message-type">
> 	  xcon-userid:Alice@example.com
> 	  xcon:8977794@example.com
> 	  retrieve
>=20
>=20
> 	  200
> 	  success
> 	  
> 	     confSummaryRequest
> 	     
> 		  Alice's conference 
> 		  active 
> 		  true 
> 		  audio 
> 	     
> 	  
>      
>    
>=20
>    
>     	       targetNamespace=3D"http://example.com/ccmp-extension"
> 	       xmlns=3D"http://example.com/ccmp-extension">
>=20
>      
>=20
>      
> 	
> 	  
> 	  
> 	  
> 	  
> 	
>      
>=20
>    
>=20
> Otherwise I've checked all the schemas for conformance and the
> examples for schema-validity.
>=20
> 12.2 XML Schema Registration
>=20
> Should include pointers to the RFCs which include the text of the
> schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the
> schema docuemnt given in section 11.
>=20
> 12.3 Media Type Registration
>=20
> It seems unlikely that the proposed extension of 'ccmpxml' will see
> much use---4 characters seems to be the practical limit for
> extensions.
>=20
> Nits: One more proofreading pass over the first three sections would
> be a good idea. . .
>=20
> ht
> --=20
>       Henry S. Thompson, School of Informatics, University of =
Edinburgh
>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 =
650-4440
>                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
>                       URL: http://www.ltg.ed.ac.uk/~ht/
> [mail from me _always_ has a .sig like this -- mail without it is =
forged spam]


From dzonatas@gmail.com  Tue May 17 08:55:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FD4E073D for ; Tue, 17 May 2011 08:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level: 
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-4.486, BAYES_40=-0.185, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUIEAJl95YbG for ; Tue, 17 May 2011 08:55:18 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6814EE073C for ; Tue, 17 May 2011 08:55:18 -0700 (PDT)
Received: by pxi2 with SMTP id 2so392324pxi.38 for ; Tue, 17 May 2011 08:55:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gnDgnHD81C/drxbidghjHhEe3njeHKGs3IFgVKjO6d0=; b=XL5uRyVrKaEP0tQu9CqHHGG++YORBOYfx9B7IMYhKLPyNMSnSCK2eE/Q7M6I4GeFrF itLQqZKjhZh/xeanjdbCjMvUYAhlLGYzjzwTQzaw1PYm1s2ysm15l0AnLp6uVzAbBAiH VKbOxzboAfE1p0Of4/WRHAxaRhCtDGA13Tva4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Q2dkZ+hrhcWQ0DO+XVqSkXIobbQVtHjWW9AJmrdeXltjemyQMi3LTmE7mkU0gPa9vO gzDjOkd2P/9gBKkIBTxtzsYTh39uQO+KuZqOhdc6Udyrm0oKv9DmTMSpG+sZlvjzgfP1 /E/JXShygLYQbU45j2CIh3IlZewK0JJRka5Io=
Received: by 10.68.68.111 with SMTP id v15mr1252270pbt.310.1305647718125; Tue, 17 May 2011 08:55:18 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id q10sm445525pbk.39.2011.05.17.08.55.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 08:55:17 -0700 (PDT)
Message-ID: <4DD29A37.50301@gmail.com>
Date: Tue, 17 May 2011 08:54:31 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu>  <4DD28114.7010601@gmail.com>
In-Reply-To: <4DD28114.7010601@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 15:55:19 -0000

For those interested in interoperability of where I suggested ReSTful 
paradigm, here is one use-case:

Portable web-server in client web-browser, see here for basis without 
network installed:  http://bellard.org/jslinux 

Technicals: http://bellard.org/jslinux/tech.html

Imagine several dozens of those in one web page; then, the gist of how 
all instances can update or save themselves through provider means is 
little more obvious. I thought the above is useful reference to further 
design intermediary states and stateful/stateless implementation, 
especially where each instance/region is thought in terms of IPv4 and 
the outer frame is IPv6.

The complete idea of this use-case includes capabilities that enable 
intermediate systems rather be stuck in monolithic support requirements: 
"How do we save all these great ideas and not need to implement one 
single way?"

On 05/17/2011 07:07 AM, Dzonatas Sol wrote:
> On 05/16/2011 11:16 PM, Mark Nottingham wrote:
>>
>>> Thus we should probably have two distinct well known files. In order to
>>> reduce the number of requests, we could suggest that if the 
>>> browser-hints
>>> file does not contain any connection information, then the browser is
>>> invited to get /.well-known/connection-hints too as a complement.
>> I have a pretty strong suspicion that this will end up being too 
>> complex, but let's see what others think.
>>
>
> The ReSTful paradigm is useful here such that any specific field in 
> the browser-hints file can be found by path.
>
> GET /.well-known/browser-hints/max-conns
>
> I'm sure this leads to PUT, POST, and DELETE methods as well for 
> easier connection negotiation, management, and hints of what paths are 
> streams/pipelines, or like capabilities.
>
> For example, I use these next two to combine all data into one stream 
> that appears like a structure, with the specific path:
>
> GET /.well-known/browser-hint/s   # all hints with data in XML format
> GET /.well-known/browser-hint      # list of categories known in XML 
> format
>
> As above:
> GET /.well-known/browser-hints    # suggested default for JSON fromat
>
> I suggest this "symbolic" reservation for *explicit* stream methods 
> and logical devices  (combined path use-cases from SYSV, VMS, and 
> IETF-VWRAP-LLIDL)
> GET /.well-known/browser-hint$
> GET /.well-known/browser-hint$max-conns
>
> Conservative approach to avoid query arguments or extra headers that 
> specify format:
> GET /.well-known/browser-hint.xml         # XML alternative
> GET /.well-known/browser-hint.json         # JSON alternative
> GET /.well-known/browser-hint.json.xml  # json in XML format: 
> https://datatracker.ietf.org/doc/draft-rsalz-jsonx
>
> I think XSLT with optional script can be used for further 
> transformations of paths and streams.
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From presnick@qualcomm.com  Tue May 17 10:40:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F93E073C for ; Tue, 17 May 2011 10:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.589
X-Spam-Level: 
X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuMsqvd9dl1S for ; Tue, 17 May 2011 10:40:26 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 17EBDE06B0 for ; Tue, 17 May 2011 10:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305654026; x=1337190026; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DD2B306.9060702@qualcomm.com>|Date:=20Tu e,=2017=20May=202011=2012:40:22=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Jiankang=20YAO=20|CC:=20,=20|Subject:=20Re:=20[apps-discuss]=20Publication=20 request:draft-faltstrom-5892bis-04|References:=20|In-Reply-To:=20  |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=zg+JWii6oI5clnJU7fR3Cz30cBs1N57gPq0iYYo0H4E=; b=Kq7jaKPz74gS7/gxjo0w2HdVI6hB9jiAE/JCOHUaIIDXaFLhsdahcrT8 fcxRgunfxW29bGr6DGbdW2jlGWK7OTXLJ9Ke/70inc0iDI119npKuuhxK USOUhC6Tjd/QPhX9C/OyPRO+OamS7+LnyrlnqdclCJCcRBLZqe4+qVcqU Q=;
X-IronPort-AV: E=McAfee;i="5400,1158,6349"; a="91862248"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 17 May 2011 10:40:24 -0700
X-IronPort-AV: E=Sophos;i="4.65,225,1304319600"; d="scan'208";a="105369368"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 17 May 2011 10:40:24 -0700
Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 10:40:24 -0700
Message-ID: <4DD2B306.9060702@qualcomm.com>
Date: Tue, 17 May 2011 12:40:22 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Jiankang YAO 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: appsawg-ads@tools.ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Publication request:draft-faltstrom-5892bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 17:40:26 -0000

On 5/16/11 10:11 PM, Jiankang YAO wrote:
>    (1.e) How solid is the WG consensus behind this document? Does it
>          represent the strong concurrence of a few individuals, with
>          others being silent, or does the WG as a whole understand and
>          agree with it?
>
> Many WG participants from IDNAbis and APPSAWG have reviewed this document and
>   had reasonably strong WG consensus.
>    

I'd like at least some discussion here (and probably in the Technical 
Summary for the announcement) of the issue explained by Simon: There was 
at least some controversy and discussion as to whether U+19DA  should be 
made BackwardCompatible. I agree that eventually both WGs came to 
concensus, but I think you should document the issue and its result, 
since it was pretty central.

Other than that, this looks good. Once I have your update, I'll post the 
Last Call.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From presnick@qualcomm.com  Tue May 17 14:56:42 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DCFE0777 for ; Tue, 17 May 2011 14:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYO4UUqKXJBQ for ; Tue, 17 May 2011 14:56:38 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id BAAF7E0744 for ; Tue, 17 May 2011 14:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305669398; x=1337205398; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DD2EF12.4040602@qualcomm.com>|Date:=20Tu e,=2017=20May=202011=2016:56:34=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20David=20Singer=20|CC:=20Randall=20Gellens=20,=20P er=20Frojdh=0D=0A=09,=20S=20Moon esamy=20,=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20Apps-team=20revi ew=20of=09draft-gellens-mime-bucket-bis-03|References:=20 <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>=09=09<147FB978-70D1-452A-BA 57-6D31EC1B7C43@apple.com>=09<6.2.5.6.2.20110419000054.05 5c8c10@elandnews.com>=09=09=20 |In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-88 59-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207 bit|X-Originating-IP:=20[172.30.48.1]; bh=etmuCDT78sI+CGlJsOh1hy/6qrqLg4O724Cik8W0eno=; b=JuOSHAvzJnR3SHIX8QEvxvaQ6KmJ+eXUvseZDMgBorWNDCgtk5Zo+Y2P N0whVp9IULFhXfDukyws6E1WVk6GaMa6LFe9FIt41HYsnVTcxTkTzxJO8 jsm/QmMuew99g+In98MAJcbxX5x52JsKt6e5PBzYtNfSShDp5sxEvOeoo w=;
X-IronPort-AV: E=McAfee;i="5400,1158,6349"; a="91915625"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 17 May 2011 14:56:38 -0700
X-IronPort-AV: E=Sophos;i="4.65,225,1304319600"; d="scan'208";a="139793746"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 17 May 2011 14:56:38 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 14:56:37 -0700
Message-ID: <4DD2EF12.4040602@qualcomm.com>
Date: Tue, 17 May 2011 16:56:34 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: David Singer 
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>		<147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com>	<6.2.5.6.2.20110419000054.055c8c10@elandnews.com>		 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: Randall Gellens , Per Frojdh , S Moonesamy , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of	draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 21:56:42 -0000

On 5/12/11 6:47 PM, David Singer wrote:

> -04 uploaded. what's next?

Almost time for me to Last Call the document. A few things:

I found one nit in -04 
:

   == Missing Reference: '13k' is mentioned on line 148, but not defined

I see that you used regular BNF and not ABNF. That's OK, but I would 
appreciate you (a) using a tool to syntax check the BNF and (b) pointing 
me to the output of that tool. My BNF is OK, but not great.

I will do a review of the document before sending it for Last Call, but 
I would appreciate if one of you could start writing up the announcement 
text. As it says in RFC 4858:


           The IESG approval announcement includes a Document
           Announcement Write-Up.  Please provide such a Document
           Announcement Write-Up.  Recent examples can be found in the
           "Action" announcements for approved documents.  The approval
           announcement contains the following sections:

           Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

           Working Group Summary
              Was there anything in the WG process that is worth noting?
              For example, was there controversy about particular points
              or were there decisions where the consensus was
              particularly rough?

           Document Quality
              Are there existing implementations of the protocol?  Have a
              significant number of vendors indicated their plan to
              implement the specification?  Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues?  If
              there was a MIB Doctor, Media Type, or other Expert Review,
              what was its course (briefly)?  In the case of a Media Type
              Review, on what date was the request posted?

           Personnel
              Who is the Document Shepherd for this document?  Who is the
              Responsible Area Director?  If the document requires IANA
              experts(s), insert 'The IANA Expert(s) for the registries
              in this document are .'

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From presnick@qualcomm.com  Tue May 17 15:00:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E694E0744 for ; Tue, 17 May 2011 15:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuSGsMBHOPt1 for ; Tue, 17 May 2011 15:00:34 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6BE0674 for ; Tue, 17 May 2011 15:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305669634; x=1337205634; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DD2F000.1030601@qualcomm.com>|Date:=20Tu e,=2017=20May=202011=2017:00:32=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20 |Subject:=20Re:=20[apps-discuss]=20Apps-team=20review=09o f=09draft-gellens-mime-bucket-bis-03|References:=20<6.2.5 .6.2.20110416051507.05ba6868@elandnews.com>=09=09<147FB978-70D1-452A-BA57-6D3 1EC1B7C43@apple.com>=09<6.2.5.6.2.20110419000054.055c8c10 @elandnews.com>=09=09=09=20<4DD2EF1 2.4040602@qualcomm.com>|In-Reply-To:=20<4DD2EF12.4040602@ qualcomm.com>|Content-Type:=20text/plain=3B=20charset=3D" ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=BtppPVDPf0or14Lc6hMcAnZoxgiRFwD1N7LDEASaVa4=; b=ef8riUT/gJPIVPdyCubQtsPqwubUsturjk8bF1LTbc5sOWwoDeS16COj kJ3i5EUbonq2lABqrU4yeNbs7BfkpA97Mx/48KeEN7PnlPKxFU/ydjAZI NJwb+yNB3qUjSTrt7ob+aKpqmfz3tA2Lqeh7fi7TutX2v5KFokh8d1pLF I=;
X-IronPort-AV: E=McAfee;i="5400,1158,6349"; a="91916240"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 17 May 2011 15:00:34 -0700
X-IronPort-AV: E=Sophos;i="4.65,225,1304319600"; d="scan'208";a="139794224"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 17 May 2011 15:00:34 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 15:00:34 -0700
Message-ID: <4DD2F000.1030601@qualcomm.com>
Date: Tue, 17 May 2011 17:00:32 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: 
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>		<147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com>	<6.2.5.6.2.20110419000054.055c8c10@elandnews.com>			 <4DD2EF12.4040602@qualcomm.com>
In-Reply-To: <4DD2EF12.4040602@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Subject: Re: [apps-discuss] Apps-team review	of	draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 22:00:35 -0000

On 5/17/11 4:56 PM, Pete Resnick wrote:
> On 5/12/11 6:47 PM, David Singer wrote:
>
>> -04 uploaded. what's next?
>
> Almost time for me to Last Call the document. A few things:

Sorry, that was meant for the authors. Apps-discuss may ignore.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From presnick@qualcomm.com  Tue May 17 15:48:17 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E633E06F9 for ; Tue, 17 May 2011 15:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FJzrnkr3hL3 for ; Tue, 17 May 2011 15:48:16 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id C89ACE06D8 for ; Tue, 17 May 2011 15:48:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1305672496; x=1337208496; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DD2FAB3.9070308@qualcomm.com>|Date:=20Tu e,=2017=20May=202011=2017:46:11=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Jiankang=20YAO=20|CC:=20,=20|Subject:=20Re:=20[apps-discuss]=20Publication=20 request:draft-faltstrom-5892bis-04|References:=20=20<4DD2B306.906 0702@qualcomm.com>|In-Reply-To:=20<4DD2B306.9060702@qualc omm.com>|Content-Type:=20text/plain=3B=20charset=3D"ISO-8 859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit|X-Originating-IP:=20[172.30.48.1]; bh=nptBL0dR5BkvyoJZN/Gd6OjRY038Xw3YofiKYhirmVQ=; b=cvg3X8cz7nX9epIw6vljLMsEluXr2uqeqeInRl93fm63JdkgWFnKEhyZ Y13dEWlOGTPIaiwkw17pN4lOUScU8WLh6GfXBPairvuI80v1dEInV8mWN wxfCx17Yh17RcUYGPr5tyZlFLRM36qrLWyFDBUohfsl7fW9QFIVEJL/Ig s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6349"; a="91927054"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 17 May 2011 15:48:16 -0700
X-IronPort-AV: E=Sophos;i="4.65,225,1304319600"; d="scan'208";a="139798438"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 17 May 2011 15:48:08 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 15:46:13 -0700
Message-ID: <4DD2FAB3.9070308@qualcomm.com>
Date: Tue, 17 May 2011 17:46:11 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Jiankang YAO 
References:  <4DD2B306.9060702@qualcomm.com>
In-Reply-To: <4DD2B306.9060702@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: appsawg-ads@tools.ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Publication request:draft-faltstrom-5892bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 May 2011 22:48:17 -0000

On 5/17/11 12:40 PM, Pete Resnick wrote:
> I'd like at least some discussion here (and probably in the Technical 
> Summary for the announcement) of the issue explained by Simon:

Correction. I think that probably belongs in the WG Summary, not the 
Technical Summary.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From brianp@brianp.net  Wed May 18 19:04:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B45E06BA for ; Wed, 18 May 2011 19:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.077
X-Spam-Level: 
X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-CmbDX3kt5z for ; Wed, 18 May 2011 19:04:07 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBF04E0684 for ; Wed, 18 May 2011 19:04:06 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1869260vxg.31 for ; Wed, 18 May 2011 19:04:06 -0700 (PDT)
Received: by 10.220.109.227 with SMTP id k35mr787820vcp.64.1305770646156; Wed, 18 May 2011 19:04:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.192.201 with HTTP; Wed, 18 May 2011 19:03:46 -0700 (PDT)
X-Originating-IP: [216.243.35.32]
In-Reply-To: 
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu> 
From: Brian Pane 
Date: Wed, 18 May 2011 19:03:46 -0700
Message-ID: 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 02:11:25 -0000

Reading through the browser hints draft,
http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
first reaction is that it specifies a really arbitrary subset of
request headers that clients can be advised to stop sending.

While there's definitely some benefit to be gained by addressing
special cases like this, I think a general-case solution would be
preferable: a hop-by-hop response header that tells the client that
the server (or intermediary) supports compressed headers.  This would
require the definition of a compressed header standard, of course.

Of the specific headers covered in the draft, many have the same
values on every request: Accept, Accept-Charset, User-Agent.  Header
compression would be very effective for these and for some other
common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
addition, Cookie and Referrer would benefit from compression in a lot
of common cases.

-Brian

From vumip1@gmail.com  Wed May 18 20:20:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAD8E06ED for ; Wed, 18 May 2011 20:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4EZxFMXLKjs for ; Wed, 18 May 2011 20:20:39 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 772B5E0696 for ; Wed, 18 May 2011 20:20:39 -0700 (PDT)
Received: by wwk4 with SMTP id 4so5226563wwk.1 for ; Wed, 18 May 2011 20:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=cS5rNw3AlohjifOQKQrBsAPYH+/tS6F/FxtPAaK7P70=; b=KD5Q2azDBUWD48ZpHEe9A9tSoNdhxyaSD/y94wA/Ny6BUZE/sculfUcdVCEdy+B5A6 7Ub0KPurXOtTqjbaskjdwYU5teoMM5coe7jrh3KKsj8+D4RuRcnKvQB9eeqTY9lPb8+R +EfEa2cJ0UJNZiUmOfxVCHzxNAGPqaTqzIkRw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=J662sNIwYqZdGmIFZDcVptW7UQErp4DO2BNEMJQhA66hv7/MZ/BX+lVKXMnPupUC+L vyga2B5EiK+k63MComfYWJE10icjKi0MS8ewx9NsGTePoxMgVecZbjAHiyVHy4iPmKpB P3GUEbjH8WhSfAruH+KC8iM1U4dU1UwdIDA0M=
MIME-Version: 1.0
Received: by 10.216.237.155 with SMTP id y27mr5124327weq.82.1305775238276; Wed, 18 May 2011 20:20:38 -0700 (PDT)
Received: by 10.216.52.75 with HTTP; Wed, 18 May 2011 20:20:38 -0700 (PDT)
Date: Wed, 18 May 2011 23:20:38 -0400
Message-ID: 
From: Bhumip Khasnabish 
To: Apps Discuss 
Content-Type: multipart/alternative; boundary=0015175dda023be60d04a3987d33
Subject: [apps-discuss] Fwd: VDI discussion mtg notes, pls review. thanks.
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 03:20:41 -0000

--0015175dda023be60d04a3987d33
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Below pls find the notes from the last two VDI discussion conf calls.
Thanks.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++
*10 AM ET, Friday, 06 May, 2011.*

Attendees: Viswas, YingZhe, Paul, Gene, Spencer, Tom, Liang, and Bhumip

Bhumip opened the mtg. by mentioning that in future, we=92ll use the
apps-discuss@ietf.org,  for discussing VDI works/drafts/progress, so
everyone should register into this list (if interested in updates on VDI).
Similarly, we plan to use opsawg@ietf.org for discussion and distribution o=
f
Datacenter Operations and Management (DCOPS) related drafts and works, so
PLEASE register to opsawg@ietf.org by sending an email to
opsawg-request@ietf.org if you have not done so already.

Gene mentioned that he is looking for inputs related to VDI to update the
CloudLog draft (http://tools.ietf.org/id/draft-cloud-log-01.txt) and that
his new email address is golov@swbell.net (or ggolovinsky@gmail.com).
Paul wants to see a real need (use cases) for API/interop between opensoure
VDC and other options in mixed vendors environment via comments from the
attendees and participants of the mtgs.

Tom may contribute on use cases and testability (related to
interoperability) for VDI.

Spencer was requested to bring in use cases and the requirements of
interoperability for various scenarios.

Bhumip suggested that API/interop may be required for (a) seamless session
transfer, (b) support of private and business (Enterprise) profiles in the
same device, (c) Effortless customization of services, and (d) Seamless
add/move/upgrade/change management of VDC and services.

Liang reviewed a multi-layer (Applications, Virtual channel, Session
control, Transport) model for VDI protocol stack, and plan to work on a
draft describing the details.

Bhumip polled all of the announced attendees for closing comments and
suggestions. Hearing none, the mtg was adjourned with a wish for everyone t=
o
have a great weekend.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++

*10 AM ET, Friday, 22 April, 2011.
*
Attendees: Ning, Suren, Mr. Shima, Carl, Marco, Liang, Joe Lin, and Bhumip

Bhumip opened the mtg. by mentioning that in future, we=92ll use the
apps-discuss@ietf.org,  for discussing VDI works/drafts/progress, so
everyone should register into this list (if interested in updates on VDI).
Similarly, we plan to use opsawg@ietf.org for discussion and distribution o=
f
Datacenter Operations and Management (DCOPS) related drafts and works, so
PLEASE register to opsawg@ietf.org by sending an email to
opsawg-request@ietf.org if you have not done so already.

Ning discussed that VDI may be useful for shared applications over a common
system, and that the current focus of VDI may be only consumer oriented
services.
Marco suggested VDI use cases currently exist for Enterprise, Residential
(consumer) and machine-to-machine services.  We need to develop drafts
summarizing these use cases.

Bhumip described that we need to work on architecture and functional
requirements for VDI first and these can be used for developing network and
protocol requirements, and API development.

Laing suggested that we need to scope the VDI works first and then develop
basic and enhanced requirements. Liang will present his thoughts on how
these can be achieved during the next conf call.

Suren mentioned that he is creating VDI security requirements draft based o=
n
the cloud security framework (CSF) that he has been working on since last
year. He plans to review that draft in a future conf call.

Bhumip polled all of the announced attendees for closing comments and
suggestions. Hearing none, the mtg was adjourned with a wish for everyone t=
o
have a great weekend.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++

--0015175dda023be60d04a3987d33
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Below pls find the notes from the last two VDI discussion conf calls. =
Thanks.


=A0


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++


10 AM ET, Friday, 06 May, 2011.
=A0
Attendees: =
Viswas, YingZhe, Paul, Gene, Spencer, Tom, Liang, and Bhumip
=A0
Bhum=
ip opened the mtg. by mentioning that in future, we=92ll use the apps-discuss@ietf.org,=
=A0 for discussing VDI works/drafts/progress, so everyone should register i=
nto this list (if interested in updates on VDI). Similarly, we plan to use =
opsawg@ietf.org fo=
r discussion and distribution of Datacenter Operations and Management (DCOP=
S) related drafts and works, so PLEASE register to opsawg@ietf.org by sending an email to opsawg-request@ie=
tf.org if you have not done so already.

=A0
Gene mentioned that he is looking for inputs related to VDI to updat=
e the CloudLog draft (http://tools.ietf.org/id/draft-cloud-log-01.txt) and that his new email address is golov@swbell.net (or ggolovinsky@gmail.com).=A0=A0=A0=A0 




Paul wants to see a real need (use cases) for API/interop between open=
soure VDC and other options in mixed vendors environment via comments from =
the attendees and participants of the mtgs.
=A0
Tom may contribute on=
 use cases and testability (related to interoperability) for VDI. 

=A0
Spencer was requested to bring in use cases and the requirements of =
interoperability for various scenarios. 
=A0
Bhumip suggested that AP=
I/interop may be required for (a) seamless session transfer, (b) support of=
 private and business (Enterprise) profiles in the same device, (c) Effortl=
ess customization of services, and (d) Seamless add/move/upgrade/change man=
agement of VDC and services. 

=A0
Liang reviewed a multi-layer (Applications, Virtual channel, Session=
 control, Transport) model for VDI protocol stack, and plan to work on a dr=
aft describing the details.
=A0
Bhumip polled all of the announced at=
tendees for closing comments and suggestions. Hearing none, the mtg was adj=
ourned with a wish for everyone to have a great weekend.

=A0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++
=A0
10 AM ET, Friday, 22 April, 2011.
=A0
Attendees: Ning, Suren, Mr. Shima, Carl, Marco, Liang, Joe Lin=
, and Bhumip

=A0
Bhumip opened the mtg. by mentioning that in future, we=92ll use the=
 apps-discuss@ie=
tf.org,=A0 for discussing VDI works/drafts/progress, so everyone should=
 register into this list (if interested in updates on VDI). Similarly, we p=
lan to use opsawg@ietf=
.org for discussion and distribution of Datacenter Operations and Manag=
ement (DCOPS) related drafts and works, so PLEASE register to opsawg@ietf.org by sending an e=
mail to opsawg=
-request@ietf.org if you have not done so already.

=A0
Ning discussed that VDI may be useful for shared applications over a=
 common system, and that the current focus of VDI may be only consumer orie=
nted services. 


Marco suggested VDI use cases currently exist for Enterprise, Resident=
ial (consumer) and machine-to-machine services.=A0 We need to develop draft=
s summarizing these use cases. 


=A0


Bhumip described that we need to work on architecture and functional r=
equirements for VDI first and these can be used for developing network and =
protocol requirements, and API development. 


=A0


Laing suggested that we need to scope the VDI works first and then dev=
elop basic and enhanced requirements. Liang will present his thoughts on ho=
w these can be achieved during the next conf call.


=A0


Suren mentioned that he is creating VDI security requirements draft ba=
sed on the cloud security framework (CSF) that he has been working on since=
 last year. He plans to review that draft in a future conf call.



=A0


Bhumip polled all of the announced attendees for closing comments and =
suggestions. Hearing none, the mtg was adjourned with a wish for everyone t=
o have a great weekend.
=A0
+++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++


--0015175dda023be60d04a3987d33--

From dzonatas@gmail.com  Wed May 18 22:47:36 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC3BE070A for ; Wed, 18 May 2011 22:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.932
X-Spam-Level: 
X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts-fn2CRVbye for ; Wed, 18 May 2011 22:47:35 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 01063E06F6 for ; Wed, 18 May 2011 22:47:34 -0700 (PDT)
Received: by pxi2 with SMTP id 2so1401261pxi.38 for ; Wed, 18 May 2011 22:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nfD7k/3pfnL9/Qr4fenOkIivXCP+h8WF0DvwU9EGWZY=; b=BfY7fzzSXMvwr2mcjFLpQFy56ICZmu3Hw+++XKgXzk5e61nIei7KW9M9aAYEBW+faS fVcM5HL8/4lg9wedmJYWKUinqsCBwVxmKaLrOylRgB7zcnNipgj4TU4xE9yePjkjj07o fLBOh2us2xAPDwhHhOhpSEPyP7coxkDwYcgfo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=VVgdy6k19mclG16GglJ/E3V+7BpxOPoPKcHj0cHQ778H1fbAzMQvH4t36MN4KnY1u+ mFdui/YT0NrNhVVidv/oa9Da4ejONoEuEk3E+qZ6GumtitHo5ucZtmW+5/ImbQByZ006 oV4e9tlrY/e4r/2SfTulWyFLfK/wwY+TGoFmI=
Received: by 10.68.15.196 with SMTP id z4mr4340029pbc.59.1305784054630; Wed, 18 May 2011 22:47:34 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id l7sm1528906pbs.55.2011.05.18.22.47.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 22:47:33 -0700 (PDT)
Message-ID: <4DD4AE87.6050501@gmail.com>
Date: Wed, 18 May 2011 22:45:43 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com>	<1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net>	<20110517053416.GB26443@1wt.eu>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action:	draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:47:36 -0000

#!twitter.com/Dzonatas_Sol/status/71018131946082304

Proven standard and extensible with channel persist objects; it works in 
less than #140.

On 05/18/2011 07:03 PM, Brian Pane wrote:
> Reading through the browser hints draft,
> http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
> first reaction is that it specifies a really arbitrary subset of
> request headers that clients can be advised to stop sending.
>
> While there's definitely some benefit to be gained by addressing
> special cases like this, I think a general-case solution would be
> preferable: a hop-by-hop response header that tells the client that
> the server (or intermediary) supports compressed headers.  This would
> require the definition of a compressed header standard, of course.
>
> Of the specific headers covered in the draft, many have the same
> values on every request: Accept, Accept-Charset, User-Agent.  Header
> compression would be very effective for these and for some other
> common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
> addition, Cookie and Referrer would benefit from compression in a lot
> of common cases.
>
> -Brian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>    


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From dzonatas@gmail.com  Thu May 19 10:43:32 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29C7E06AE for ; Thu, 19 May 2011 10:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level: 
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21+mHYSl63VL for ; Thu, 19 May 2011 10:43:29 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id E116EE0665 for ; Thu, 19 May 2011 10:43:29 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1759765pvh.31 for ; Thu, 19 May 2011 10:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GMuGurYrgmjuo9UGsio97nLSVouoPkVhW9Ki0KudagE=; b=Ptmzd94LrlHwV0dYfhUyl2zEy0G5ZYZ3HZjFaSiBDHtrtPWfUwVzJOZZy1GvU936RO 7zSeFfqOtV/KZFLIjvlA8BArNfskvDJjR9Ty8+/+jBTMZWTp02HZ/ZQNlc8aRHgWJqp2 6Jm0RIRWGja4ghM54FpA/47BqzCD9yldbpjGU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sbttn1JDk6+Vp5+A9Hvz1b64BlfOsCBGyhv2Dc7ofYTcmtdz/Z0GCcj1lNYAi9jB1w rvWg95s5RD93SVdsCkCbA2y7jacDSC2hT8wZEt5KHPCtATE6Sgiz56/uUjo+OrN7AiGI +zmtyzGaQuzg4Z1g3EJJK81IrVT5bFo7Io/o8=
Received: by 10.68.59.227 with SMTP id c3mr4074739pbr.380.1305827009584; Thu, 19 May 2011 10:43:29 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id k10sm1875048pbl.76.2011.05.19.10.43.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 10:43:28 -0700 (PDT)
Message-ID: <4DD55654.9080805@gmail.com>
Date: Thu, 19 May 2011 10:41:40 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com>	<1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net>	<20110517053416.GB26443@1wt.eu>	  <4DD4AE87.6050501@gmail.com>
In-Reply-To: <4DD4AE87.6050501@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action:	draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:43:32 -0000

For those that are new to such concept, or can't make heads or tails out 
of "the content", I explained the basics of the code here:

http://icyspherical.blogspot.com/2011/05/unix-in-xml.html

And, why we do not put the spin on hypermedia: 
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0240.html

We did our homework (for Science of the Letters).

On 05/18/2011 10:45 PM, Dzonatas Sol wrote:
> #!twitter.com/Dzonatas_Sol/status/71018131946082304
>
> Proven standard and extensible with channel persist objects; it works 
> in less than #140.
>
> On 05/18/2011 07:03 PM, Brian Pane wrote:
>> Reading through the browser hints draft,
>> http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
>> first reaction is that it specifies a really arbitrary subset of
>> request headers that clients can be advised to stop sending.
>>
>> While there's definitely some benefit to be gained by addressing
>> special cases like this, I think a general-case solution would be
>> preferable: a hop-by-hop response header that tells the client that
>> the server (or intermediary) supports compressed headers.  This would
>> require the definition of a compressed header standard, of course.
>>
>> Of the specific headers covered in the draft, many have the same
>> values on every request: Accept, Accept-Charset, User-Agent.  Header
>> compression would be very effective for these and for some other
>> common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
>> addition, Cookie and Referrer would benefit from compression in a lot
>> of common cases.
>>
>> -Brian
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From vumip1@gmail.com  Thu May 19 15:16:38 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04258E06A2 for ; Thu, 19 May 2011 15:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0EOvvYlsv3t for ; Thu, 19 May 2011 15:16:36 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7148E068B for ; Thu, 19 May 2011 15:16:36 -0700 (PDT)
Received: by yic13 with SMTP id 13so1348974yic.31 for ; Thu, 19 May 2011 15:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=nMn1xsjFK/MsIHvrfQ2us21x6e6qXFBqLT3q1K+/wRI=; b=IoRQ6N0/XqupzpyUgekvzgMs16T3eCqgHkf/7yx/LHhi+sUCpdJDuEuCOs3oSOGbvr ZrUx9uC+09JVkvyVtTlOHBqnIrUMiZch4OyoaurSATTxQGeOUYUEWxU0T+chaqs/iCOD z+UVO3aLmVVjbV2O2oAWAIdWhffr6trsU5wHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LbwR4cKjmK/4X4GfLlhiDWLMFDe1T36IVwejPNyVBu9KtR4AFg2Tt3/SaF+8i7To0A b0OE9g580whk1I2cjEi9BTF6WeiAQKlpkUCOBmFymufplvBdmGt6PuDlDUx98MoSYOhi NzB9TLiIapqOCcP5K2Z59jAZjvnMq0UsDfBu0=
MIME-Version: 1.0
Received: by 10.236.180.231 with SMTP id j67mr3947104yhm.68.1305843395928; Thu, 19 May 2011 15:16:35 -0700 (PDT)
Received: by 10.236.105.238 with HTTP; Thu, 19 May 2011 15:16:35 -0700 (PDT)
Date: Thu, 19 May 2011 18:16:35 -0400
Message-ID: 
From: Bhumip Khasnabish 
To: Apps Discuss 
Content-Type: multipart/alternative; boundary=20cf30563f5dbf23ea04a3a85b83
Subject: [apps-discuss] Conf call [10 AM ET/USA, 20May2011] for VDI discussion
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 22:16:38 -0000

--20cf30563f5dbf23ea04a3a85b83
Content-Type: text/plain; charset=ISO-8859-1

Based on our previous discussion on virtual desktop infrastructure (VDI) in
this list
(see e.g.,
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02310.html),
subsequent presentation during IETF-80 (
http://www.ietf.org/proceedings/80/minutes/apparea.txt),
and  conf call (
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02688.html)
we are planning to continue work on
developing the required architecture and requirements for VDI protocol and
API.
We are also looking for reports on VDI implementation experiences.



*Start Time:* 10 AM ET (NY/USA time), Friday 20 May 2011

*Conf bridge:* US Toll-free +1-866-710-5490

If the toll-free number does not work, pls use +001-203-875-8973,

*Passcode:* 204 1744#



General Agenda
VDI topics:
- Use cases, implementation experiences (to determine gaps)

- Protocol requirements, and APIs

- Others: Architecture, Security framework, ...

(problem statement draft is at
http://trac.tools.ietf.org/area/app/trac/attachment/wiki/Clouds/draft-wang-appsawg-vdi-problem-statement-01minus.txt
 )


Note: All of the drafts and presentations are available at the following
Website:
http://trac.tools.ietf.org/area/app/trac/wiki/Clouds

--20cf30563f5dbf23ea04a3a85b83
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




Based on our previou=
s discussion on virtual desktop infrastructure (VDI) in this list 

(see e.g., http://www.ietf.org/mail-archive/web/app=
s-discuss/current/msg02310.html),=A0 



subsequent presentation during IETF-80 (http://www.ietf.org/proceedi=
ngs/80/minutes/apparea.txt),=A0 



and=A0 =
conf call (http://www.ietf.org/mail-archive/web/=
apps-discuss/current/msg02688.html)



we are planning to continue work on 


developing the required architecture and requirements for VDI=
 protocol and API. 


We are also looking for reports on VDI implementation experie=
nces.


=A0


Start Time: 10 AM ET (NY/USA time), Frida=
y 20 May 2011



Conf bridge: US Toll-free +1-866-710-5490 



If the toll-free number does not work, pls use +001-203-875-=
8973, 



Passcode: 204 1744#


=A0


General Agenda


VDI topics:


- Use cases, implementation experiences (to determine gaps) <=
/font>


- Protocol requirements, and APIs


- Others: Architecture, Security framework, ...


=A0


(problem statement draft is at http://trac.tools.ietf.org/=
area/app/trac/attachment/wiki/Clouds/draft-wang-appsawg-vdi-problem-stateme=
nt-01minus.txt=A0)



=A0


Note: All of the drafts and presentations are available at the=
 following Website:


http://trac.tools.ietf.org/area/app/=
trac/wiki/Clouds 



=A0


=A0


=A0


--20cf30563f5dbf23ea04a3a85b83--

From mnot@mnot.net  Thu May 19 17:51:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED0DE06D8 for ; Thu, 19 May 2011 17:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.601
X-Spam-Level: 
X-Spam-Status: No, score=-104.601 tagged_above=-999 required=5 tests=[AWL=-2.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KT1AIL391uD for ; Thu, 19 May 2011 17:51:40 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A9E4CE0658 for ; Thu, 19 May 2011 17:51:40 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.62.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2948922E257; Thu, 19 May 2011 20:51:32 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Fri, 20 May 2011 10:51:30 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu>  
To: Brian Pane 
X-Mailer: Apple Mail (2.1084)
Cc: Apps Discuss 
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 00:51:41 -0000

Hi Brian,

I've been thinking about HTTP compression schemes too, but IMO the =
barrier to entry for hop-by-hop is probably too high, as that's getting =
perilously close to HTTP 2.0, and if we're going to go that far, we =
might as well go the whole hog (a la SPDY, WAKA, etc.). Also, header =
compression only works well if you have many requests on a connection; =
IME we're not there yet.

Rather, I'm seeing this draft as a mechanism for backing away from the =
spiral of unfortunate behaviours that the browsers have to implement to =
interoperate with really broken sites. My site doesn't need convoluted =
Accept-* headers, nor does it need a painfully wordy User-Agent, but the =
browsers still send the because some other broken sites do require this. =
Likewise, my site doesn't need browsers to be careful about pipelining.

Also, there is more in the draft than just reducing request header =
sizes; while that might be the most beneficial case for you, I actually =
started the draft for the pconn-ip behaviour.=20

Regards,


On 19/05/2011, at 12:03 PM, Brian Pane wrote:

> Reading through the browser hints draft,
> http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
> first reaction is that it specifies a really arbitrary subset of
> request headers that clients can be advised to stop sending.
>=20
> While there's definitely some benefit to be gained by addressing
> special cases like this, I think a general-case solution would be
> preferable: a hop-by-hop response header that tells the client that
> the server (or intermediary) supports compressed headers.  This would
> require the definition of a compressed header standard, of course.
>=20
> Of the specific headers covered in the draft, many have the same
> values on every request: Accept, Accept-Charset, User-Agent.  Header
> compression would be very effective for these and for some other
> common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
> addition, Cookie and Referrer would benefit from compression in a lot
> of common cases.
>=20
> -Brian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




From brianp@brianp.net  Fri May 20 02:52:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB80E074E for ; Fri, 20 May 2011 02:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.527
X-Spam-Level: 
X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C1++ahWaJSf for ; Fri, 20 May 2011 02:52:35 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26A96E070C for ; Fri, 20 May 2011 02:52:34 -0700 (PDT)
Received: by vws12 with SMTP id 12so3055674vws.31 for ; Fri, 20 May 2011 02:52:34 -0700 (PDT)
Received: by 10.220.198.198 with SMTP id ep6mr1273281vcb.29.1305885153067; Fri, 20 May 2011 02:52:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.192.201 with HTTP; Fri, 20 May 2011 02:52:12 -0700 (PDT)
X-Originating-IP: [216.243.35.32]
In-Reply-To: 
References: <20110517042149.2176.20778.idtracker@ietfa.amsl.com> <1603FA8A-5BBC-4574-815A-2E13850F1D52@mnot.net> <20110517053416.GB26443@1wt.eu>   
From: Brian Pane 
Date: Fri, 20 May 2011 02:52:12 -0700
Message-ID: 
To: Apps Discuss 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 09:52:35 -0000

On Thu, May 19, 2011 at 5:51 PM, Mark Nottingham  wrote:

> Also, header compression only works well if you have many requests
> on a connection; IME we're not there yet.

My experience has been that the number of requests per site (scheme+authority)
often is large enough to make header compression interesting, but that number
divided by ~6 (a modern browser's connection parallelism) usually isn't.  Thus I
see header compression being viable in combination with another change: hinting
to the client that it should use pipelining and a smaller number of connections.
But yes, at that point we're halfway to reinventing SPDY.

> Also, there is more in the draft than just reducing request header sizes; while
> that might be the most beneficial case for you, I actually started the draft for
> the pconn-ip behaviour.

The pconn-ip hint looks good.  The only complication I can think of is that the
client implementer will have to decide whether to manage the maximum size
of its persistent connection pool on a per-IP-addr or per-site basis.  E.g., if
static.example.com and images.example.com resolve to the same address,
a typical browser today might open N concurrent connections to static and
another N connections to images.  If the client honors the pconn-ip hint for
both those sites, it needs to decide on a suitable number of concurrent
connections.  Some possibilities that come to mind are:
  N (may reduce concurrency)
  Some fixed number P > N
  M*N, where M is the number of sites that resolve to the same addr
        (that the client knows about)
None of those is really ideal, though.

Finally, some notes on max-conns: I think it's a good hint, as it leads server
side applications away from having to use tricks like domain sharding.  And
for servers that can handle a lot of concurrent connections, the ability to tell
the client that it's okay to open some very large number of persistent
connections
reduces the need to come up with a pipeline hinting standard.  The catch, I
think, is that the clients most in need of a hint to increase their connection
limit are specific old browser versions, still in widespread use, that
aren't likely
to ever be updated with support for a new browser hint standard.

-Brian

From stpeter@stpeter.im  Fri May 20 08:41:03 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEFFE0722 for ; Fri, 20 May 2011 08:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.567
X-Spam-Level: 
X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIC9PD3BXm+Y for ; Fri, 20 May 2011 08:41:03 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1CE0713 for ; Fri, 20 May 2011 08:41:03 -0700 (PDT)
Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3DBF940046; Fri, 20 May 2011 09:41:02 -0600 (MDT)
Message-ID: <4DD68B8D.9090405@stpeter.im>
Date: Fri, 20 May 2011 09:41:01 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bhumip Khasnabish 
References: <095c01cc0b51$e005ba30$a0112e90$@olddog.co.uk> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010508040000090009010203"
Cc: "So, Ning" , Apps Discuss 
Subject: Re: [apps-discuss] pls note that invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only.
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:41:03 -0000

This is a cryptographically signed message in MIME format.

--------------ms010508040000090009010203
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Bhumip, if you are holding closed design team calls then do not
advertise them on this list. I strongly suggest that you create your own
dedicated list for the design team, e.g. using one of the free
discussion list services on the Internet. Notices and minutes of closed
design team calls are not appropriate for open IETF discussion lists.

On 5/5/11 7:27 PM, Bhumip Khasnabish wrote:
> For tomorrow's mtg., we plan to hold a discussion among the VDI related=

> drafts' (existing/proposed) authors/contributors. Thanks.
> On Thu, May 5, 2011 at 2:25 PM, Adrian Farrel  > wrote:
>=20
>     What is the status of this call?
>=20
>     Is it a closed Design Team call, or an open call for any IETF
>     participant?
>=20
>     =20
>=20
>     Thanks,
>=20
>     Adrian




--------------ms010508040000090009010203
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy
MDE1NDEwMVowIwYJKoZIhvcNAQkEMRYEFGrp3D/IfiOz2cxRcYtJi270ZFSwMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBR1Tp4sLogaPUfK0TQAxCQDl+1+C7LM5a4xkp8ggYVGaeyicu2/klhAyPb
JvaKYqhSZgozx2YppHsJWOxe0oinYr8/rSmqbrmn4+lvtIkv6/td+kY/Wyl9X5t0nouoPhyi
qqhhkKHUqV11kO4c0z6GW2YjOlTCsaiOVnHdQXVS7sa/4OIAtQUt3yGJPz4wrUo5PLZEVNBp
X5M8/kpq6usPwg9wCtJbevEat0UfT8KQCaMNwLyV3Ox0yYnISkQxQTQ+5WJomnp9nDEW8E94
MYbKk9fIyFO/CMeaHFU5gXHiOdov1iTs1KU1/HgSNPkZ0A9ipbfKHo2eXWJnBsEt8YGaAAAA
AAAA
--------------ms010508040000090009010203--

From vumip1@gmail.com  Fri May 20 08:46:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FE1E0739 for ; Fri, 20 May 2011 08:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnoKi7YvaJzC for ; Fri, 20 May 2011 08:46:27 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB6E072A for ; Fri, 20 May 2011 08:46:27 -0700 (PDT)
Received: by ywp31 with SMTP id 31so1625975ywp.31 for ; Fri, 20 May 2011 08:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gblDi9MDQ5GlabfNH53SD/Kbg1oBAqRi14TFJXlibUY=; b=TUaxsKikeviRgztn2VktyNgFTNw1qspsLaLhAs+5usgvCEz6XggffamgvbnzUFpnTp KQ1gxjnjm5TGUSda9yt7Bx86bIcK2bJRK+9O9EpuQjI9yUEwon6xNFT1vXc6qMWHnHzt 4RNq5nkTLdRHGFtMJyx126x5RdIrjiC6KtA/I=
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=Zb3gIyqAQyURX3vWho5xLzmjCemEG3W7RC6a/vsH6A1fVs6B72y0vnFzgpaJ/cv5CC HOb3JsChqfqAjkJOU0Q1ypGKOIlF0xgYN6mdDlPMi6uDqXBaxOtpeqeHGiXbuaHma0mY 1nuGaL0nrYioN7gMZlJO23PZHpYjXU1CJEyTg=
MIME-Version: 1.0
Received: by 10.236.201.193 with SMTP id b41mr4965510yho.1.1305906386574; Fri, 20 May 2011 08:46:26 -0700 (PDT)
Received: by 10.236.105.238 with HTTP; Fri, 20 May 2011 08:46:26 -0700 (PDT)
In-Reply-To: <4DD68B8D.9090405@stpeter.im>
References: <095c01cc0b51$e005ba30$a0112e90$@olddog.co.uk>  <4DD68B8D.9090405@stpeter.im>
Date: Fri, 20 May 2011 11:46:26 -0400
Message-ID: 
From: Bhumip Khasnabish 
To: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=20cf305e2553481d8c04a3b706c5
Cc: "So, Ning" , Apps Discuss 
Subject: Re: [apps-discuss] pls note that invitation for tomorrow's VDI call will be announced to apps-discuss@ietf.org only.
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:46:28 -0000

--20cf305e2553481d8c04a3b706c5
Content-Type: text/plain; charset=ISO-8859-1

All right Peter, and will do. Thanks for the updated guidance.
On Fri, May 20, 2011 at 11:41 AM, Peter Saint-Andre wrote:

> 
>
> Bhumip, if you are holding closed design team calls then do not
> advertise them on this list. I strongly suggest that you create your own
> dedicated list for the design team, e.g. using one of the free
> discussion list services on the Internet. Notices and minutes of closed
> design team calls are not appropriate for open IETF discussion lists.
>
> On 5/5/11 7:27 PM, Bhumip Khasnabish wrote:
> > For tomorrow's mtg., we plan to hold a discussion among the VDI related
> > drafts' (existing/proposed) authors/contributors. Thanks.
> > On Thu, May 5, 2011 at 2:25 PM, Adrian Farrel   > > wrote:
> >
> >     What is the status of this call?
> >
> >     Is it a closed Design Team call, or an open call for any IETF
> >     participant?
> >
> >
> >
> >     Thanks,
> >
> >     Adrian
>
>
>
>

--20cf305e2553481d8c04a3b706c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


All right Peter, and will do. Thanks for the updated guidance.


On Fri, May 20, 2011 at 11:41 AM, Peter Saint-An=
dre <stpeter@stp=
eter.im> wrote:


<hat type=3D'AD'/>=


Bhumip, if you are holding closed design team calls then do not
=
advertise them on this list. I strongly suggest that you create your own
dedicated list for the design team, e.g. using one of the free
discussio=
n list services on the Internet. Notices and minutes of closed
design te=
am calls are not appropriate for open IETF discussion lists.



On 5/5/11 7:27 PM, Bhumip Khasnabish wrote:
> F=
or tomorrow's mtg., we plan to hold a discussion among the VDI related<=
br>> drafts' (existing/proposed) authors/contributors. Thanks.

> On Thu, May 5, 2011 at 2:25 PM, Adrian Farrel <adrian@olddog.co.uk






> <mailto:ad=
rian@olddog.co.uk>> wrote:
>
> =A0 =A0 What is the st=
atus of this call?
>
> =A0 =A0 Is it a closed Design Team call,=
 or an open call for any IETF

> =A0 =A0 participant?
>
>
>
> =A0 =A0 Thanks,>
> =A0 =A0 Adrian




=A0

--20cf305e2553481d8c04a3b706c5--

From john-ietf@jck.com  Fri May 20 08:59:41 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F4E071C for ; Fri, 20 May 2011 08:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level: 
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uksl6m950Hww for ; Fri, 20 May 2011 08:59:41 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id DB21FE0710 for ; Fri, 20 May 2011 08:59:40 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QNS6x-0004YJ-Dx; Fri, 20 May 2011 11:59:39 -0400
Date: Fri, 20 May 2011 11:59:30 -0400
From: John C Klensin 
To: "J-F C. Morfin" 
Message-ID: <1D8C60E204C582795721FBE7@PST.JCK.COM>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Internationalization Terminlogy
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:59:41 -0000

--On Monday, May 16, 2011 01:27 +0200 "J-F C. Morfin"
 wrote:

> John,
> Good work. I have just searched the text for some words.

Thanks.  And thanks for the review.  Some of the omissions that
you note below are deliberate, so let me comment on those at
least.

> I note that:
> 
> - "globalization" is missing which is embarrassing as Unicode
> uses to say (if I am correct) globalization =
> internationalization  + localization + language tagging.

As we have explained to others (mostly off-list), our criterion,
as indicated by the title, is terms used, and found useful, in
the IETF.  The definition or use of a term in Unicode (or
elsewhere) does not justify inclusion.  When we've concluded
that a term should be included, we have tried to either make our
definition consistent with the definition elsewhere (often by
copying) or we have tried to comment on the differences between
IETF usage and usage elsewhere along with any issues those
differences raise.

As I am sure you know, "globalization" is used heavily in
international political and economic contexts with meanings
quite different from the one you describe above.  Inconsistent
definitions of a term are probably a good reason to avoid
recommending it.  The term is not, as far as I know, used
significantly in the IETF.  And, as far as I can tell after a
quick inspection, Unicode does not, in fact, define it (it at
least doesn't appear in their index, which I've found to be
pretty good).  Any of "no use in the IETF", "ambiguity of
meaning", and "no strong requirement in the IETF" would be
grounds for excluding it; all three seem to apply in this case.


> - "langtag" term is missing, so is their IANA table (largest
> by far IANA file). RFC 5646 is named. RFC 4647 is  quoted, but
> not explained, so  "language filtering" is not alluded to.

I've done a quick search, and I don't see "langtag" as a common
term in the IETF.  "Language tag" is usually spelled out
instead.  As with our decision to send readers directly to RFC
5890 for IDNA terminology, I think that anyone who really needs
to understand the terminology for language tagging and
associated issues and actions is better off looking at the
relevant documents (which are referenced for a reason).  If you
have suggested text for clarifying that, or a good selection of
counterexamples in which "langtag" is used in IETF documents,
please send them along. 

> - "linguistic diversity" is missing. Not an IETF word but the
> IETF targets its support?

It seems to me that this is a term about which many people have
good (but not necessarily consistent) intuitions but for which
there is no generally-accepted definition that would stand any
sort of precise test.  How would you recommend defining it using
plain English?  

> - "majuscules" are named, but uncorrectly explained: in latin
> languages, at least, an upper case may be a majuscule, but a
> majuscule may not be printed as an upper case, or stays a
> majuscule even if incorrectly printed as a lower case.

The definition given is attributed to Unicode and accurately
copied.  It is certainly a correct definition in a typography
context and probably a correct one in character set coding or
internationalization ones.  It seems to me that what you are
after is a definition appropriate to some localization contexts.
That has, so far, been out of the scope of this document
(although certainly within scope of some of your other work).
I'd rather keep it out of scope for this document, if only
because I think the definition you propose would be very
controversial, even for Latin-based writing systems in general.

> - "plurilingual" is not quoted which is different from
> multilingual?
> - "linguistic independence" is not alluded to - ex. using
> digital codes.
> - "orthotypograpy" is missing in IETF

As far as I know, neither of those two terms have been used in
any IETF document or discussion except by you and your group(s).


   best,
    john


From internet-drafts@ietf.org  Fri May 20 09:37:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA994E0789; Fri, 20 May 2011 09:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFP+QS8wNsRa; Fri, 20 May 2011 09:37:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF77E0797; Fri, 20 May 2011 09:37:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.54
Message-ID: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 09:37:16 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 16:37:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Applications Area Working Group Worki=
ng Group of the IETF.

	Title           : Terminology Used in Internationalization in the IETF
	Author(s)       : Paul Hoffman
                          John C Klensin
	Filename        : draft-ietf-appsawg-rfc3536bis-01.txt
	Pages           : 46
	Date            : 2011-05-20

   This document provides a glossary of terms used in the IETF when
   discussing internationalization.  The purpose is to help frame
   discussions of internationalization in the various areas of the IETF
   and to help introduce the main concepts to IETF participants.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.txt

From nico@cryptonector.com  Fri May 20 13:24:48 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105AE0758; Fri, 20 May 2011 13:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.29
X-Spam-Level: 
X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.313,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2xdwSpYUxo9; Fri, 20 May 2011 13:24:47 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E0E80E0710; Fri, 20 May 2011 13:24:47 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 55579594062; Fri, 20 May 2011 13:24:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=FQiafcjE6EoaINb7Dsj8n v+KqFhBY8X72n8fK2nfhbGqzZGubVW1S3UwIZZoH36V1/vH1BHIHQj3eeWC1Nup0 Jlg30DU1ZSXffceNHXdIVBzJbcI+hcIiD1/A8g1i+uJtvTP9OiAgl145JFvK2xTb xnB8Bj0XrApwp0kqDTQ0zE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ddX2s1YSRTkvGEZDzUsZ YMot7Bc=; b=SrpcK3ylsHGwZk+G8TER0bxRPcYZHJB1ORjYiXDCitosE5zCyQx1 9pa8dEOI75yusp6GxBt21VKCkLCA9VBSvFwxzzzlfFx0+xKjOcehgm/Oe8tbk8XP l79IIqsjEhCVY8UelMDIgJT6hdLrzhOJi61zqxWtyL9iN6HzvhMODGc=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 04575594058;  Fri, 20 May 2011 13:24:42 -0700 (PDT)
Received: by vws12 with SMTP id 12so3526669vws.31 for ; Fri, 20 May 2011 13:24:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.106 with SMTP id cp10mr56945vdc.199.1305923082438; Fri, 20 May 2011 13:24:42 -0700 (PDT)
Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 13:24:42 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 20 May 2011 15:24:42 -0500
Message-ID: 
From: Nico Williams 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" , Ben Adida , "Adam Barth \(adam@adambarth.com\)" , "http-state@ietf.org" , HTTP Working Group , OAuth WG 
Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 20:24:48 -0000

Additional comments:

 - Using nonces for replay protection is heavy-duty.  It is difficult
to implement a reliable, secure, high-performance replay cache.  (It
is easy to implement just a high-performance replay cache: use
memcache.)

   I recommend an option to use sequence numbers at the server's
choice, understanding, of course, that requests will not be received
in sequence.  The use of a sliding sequence number window makes it
possible to do at least as well as when using nonce, and probably
faster while still being secure.

 - In an open wifi environment active attacks may not be very
difficult, thus an option to secure more than just a handful of bits
from the request, would be nice (all of the request and all of the
response, say).  The hard part is how to decide when to use one or the
other.  Ideally browsers can request more protection when the network
is reconfigured such that there's one or more clear wifi interfaces.

Nico
--

From eran@hueniverse.com  Fri May 20 14:25:18 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636DCE0714 for ; Fri, 20 May 2011 14:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+tV4ahfnpyI for ; Fri, 20 May 2011 14:25:18 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2A8CFE06CF for ; Fri, 20 May 2011 14:25:18 -0700 (PDT)
Received: (qmail 23941 invoked from network); 20 May 2011 21:18:38 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 May 2011 21:18:38 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 20 May 2011 14:18:29 -0700
From: Eran Hammer-Lahav 
To: Nico Williams 
Date: Fri, 20 May 2011 14:18:21 -0700
Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme
Thread-Index: AcwXK/Tq8zux+2NhRMyGj/1LRzJuvgABvy4g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" , Ben Adida , "Adam Barth \(adam@adambarth.com\)" , "http-state@ietf.org" , HTTP Working Group , OAuth WG 
Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:25:18 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmljbyBXaWxsaWFtcyBb
bWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0NCj4gU2VudDogRnJpZGF5LCBNYXkgMjAsIDIw
MTEgMToyNSBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IGFwcHMtZGlzY3Vzc0Bp
ZXRmLm9yZzsgQmVuIEFkaWRhOyBodHRwLXN0YXRlQGlldGYub3JnOyBPQXV0aCBXRzsgQWRhbQ0K
PiBCYXJ0aCAoYWRhbUBhZGFtYmFydGguY29tKTsgSFRUUCBXb3JraW5nIEdyb3VwDQo+IFN1Ympl
Y3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBIVFRQIE1BQyBBdXRoZW50aWNhdGlvbiBTY2hlbWUNCj4g
DQo+IEFkZGl0aW9uYWwgY29tbWVudHM6DQo+IA0KPiAgLSBVc2luZyBub25jZXMgZm9yIHJlcGxh
eSBwcm90ZWN0aW9uIGlzIGhlYXZ5LWR1dHkuICBJdCBpcyBkaWZmaWN1bHQgdG8NCj4gaW1wbGVt
ZW50IGEgcmVsaWFibGUsIHNlY3VyZSwgaGlnaC1wZXJmb3JtYW5jZSByZXBsYXkgY2FjaGUuICAo
SXQgaXMgZWFzeSB0bw0KPiBpbXBsZW1lbnQganVzdCBhIGhpZ2gtcGVyZm9ybWFuY2UgcmVwbGF5
IGNhY2hlOiB1c2UNCj4gbWVtY2FjaGUuKQ0KPiANCj4gICAgSSByZWNvbW1lbmQgYW4gb3B0aW9u
IHRvIHVzZSBzZXF1ZW5jZSBudW1iZXJzIGF0IHRoZSBzZXJ2ZXIncyBjaG9pY2UsDQo+IHVuZGVy
c3RhbmRpbmcsIG9mIGNvdXJzZSwgdGhhdCByZXF1ZXN0cyB3aWxsIG5vdCBiZSByZWNlaXZlZCBp
biBzZXF1ZW5jZS4NCj4gVGhlIHVzZSBvZiBhIHNsaWRpbmcgc2VxdWVuY2UgbnVtYmVyIHdpbmRv
dyBtYWtlcyBpdCBwb3NzaWJsZSB0byBkbyBhdA0KPiBsZWFzdCBhcyB3ZWxsIGFzIHdoZW4gdXNp
bmcgbm9uY2UsIGFuZCBwcm9iYWJseSBmYXN0ZXIgd2hpbGUgc3RpbGwgYmVpbmcNCj4gc2VjdXJl
Lg0KDQpXZSBzd2l0Y2hlZCB0byB1c2UgdGltZSBzaW5jZSBjcmVkZW50aWFscyB3ZXJlIGlzc3Vl
ZC4gVGhpcyBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gaW1wbGVtZW50IGlmIHlvdSByZWFsbHkg
bmVlZCByZXBseSBwcm90ZWN0aW9uIGJ5IHVzaW5nIGEgc21hbGwgd2luZG93IChjbG9jayBzeW5j
IGlzIG5vIGxvbmdlciBhIHByb2JsZW0sIGp1c3QgdGhlIGRlbGF5IGluIGdldHRpbmcgdGhlIGNy
ZWRlbnRpYWxzIHRvIHRoZSBjbGllbnQsIHdoaWNoIHNob3VsZCBiZSBhIHNtYWxsIHdpbmRvdyku
DQoNCj4gIC0gSW4gYW4gb3BlbiB3aWZpIGVudmlyb25tZW50IGFjdGl2ZSBhdHRhY2tzIG1heSBu
b3QgYmUgdmVyeSBkaWZmaWN1bHQsIHRodXMNCj4gYW4gb3B0aW9uIHRvIHNlY3VyZSBtb3JlIHRo
YW4ganVzdCBhIGhhbmRmdWwgb2YgYml0cyBmcm9tIHRoZSByZXF1ZXN0LCB3b3VsZA0KPiBiZSBu
aWNlIChhbGwgb2YgdGhlIHJlcXVlc3QgYW5kIGFsbCBvZiB0aGUgcmVzcG9uc2UsIHNheSkuICBU
aGUgaGFyZCBwYXJ0IGlzIGhvdw0KPiB0byBkZWNpZGUgd2hlbiB0byB1c2Ugb25lIG9yIHRoZSBv
dGhlci4gIElkZWFsbHkgYnJvd3NlcnMgY2FuIHJlcXVlc3QgbW9yZQ0KPiBwcm90ZWN0aW9uIHdo
ZW4gdGhlIG5ldHdvcmsgaXMgcmVjb25maWd1cmVkIHN1Y2ggdGhhdCB0aGVyZSdzIG9uZSBvciBt
b3JlDQo+IGNsZWFyIHdpZmkgaW50ZXJmYWNlcy4NCg0KVGhlcmUgaXMganVzdCBubyBlYXN5IHdh
eSB0byBkbyB0aGF0LiBJZiB5b3UgbmVlZCBtb3JlLCB1c2UgVExTLg0KDQpFSEwNCg0K

From nico@cryptonector.com  Fri May 20 14:31:55 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F52E06CD; Fri, 20 May 2011 14:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxbVXMBeC4C3; Fri, 20 May 2011 14:31:54 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 54A13E06AD; Fri, 20 May 2011 14:31:54 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id ABE045406F; Fri, 20 May 2011 14:31:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=HbUh7udovQq+tRDqIt4xyHJwdFdJnh0hgbSUdAYXG933 +pvqZetq4T0/VBbFCbfcOPtedQem4ONpMc7iDRtrl38CSouoMAVQlBQMlHVw/2fA Al71SJDj6efTHVNQg6CFGf+E7wHK6KqYvWqXd2TrCKDd27tu+3fW+yGMtGx+guo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wRXDvM0zQrr3JzT7Xuq7tUvW91Q=; b=F/55JvrnwNI 4xHL4O+WKGEwjX8NcGgriBYxgAcbReEAG/x63bbH7Q/YYnbSJNF46i/C1H3zpyM+ Dt0yhCEeKIZKmtoXifnfvxO3de1uDy3ITTp+Xe6EtYENcqq9wiwUq1uAIiZZZnVE ZyOWMqjCeeFeeSWnGJXaMMLEKRHSsCF4=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 4EDC054057;  Fri, 20 May 2011 14:31:53 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3540948vxg.31 for ; Fri, 20 May 2011 14:31:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.196 with SMTP id cs4mr117174vdc.279.1305927112714; Fri, 20 May 2011 14:31:52 -0700 (PDT)
Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 14:31:52 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>  <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 20 May 2011 16:31:52 -0500
Message-ID: 
From: Nico Williams 
To: Eran Hammer-Lahav 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" , Ben Adida , "Adam Barth \(adam@adambarth.com\)" , "http-state@ietf.org" , HTTP Working Group , OAuth WG 
Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 21:31:55 -0000

On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav  wr=
ote:
>> Additional comments:
>>
>> =C2=A0- Using nonces for replay protection is heavy-duty. =C2=A0It is di=
fficult to
>> implement a reliable, secure, high-performance replay cache. =C2=A0(It i=
s easy to
>> implement just a high-performance replay cache: use
>> memcache.)
>>
>> =C2=A0 =C2=A0I recommend an option to use sequence numbers at the server=
's choice,
>> understanding, of course, that requests will not be received in sequence=
.
>> The use of a sliding sequence number window makes it possible to do at
>> least as well as when using nonce, and probably faster while still being
>> secure.
>
> We switched to use time since credentials were issued. This should be pre=
tty easy to implement if you really need reply protection by using a small =
window (clock sync is no longer a problem, just the delay in getting the cr=
edentials to the client, which should be a small window).

Kerberos has had an option to use time or sequence numbers for a long
time.  We've learned a few things from this experience.

For a memcache-type implementation, timestamps are probably best
because maintaining a sequence number window in memcache,
synchronized, would be a pain, if not impossible.

Other replay cache implementations would likely do better using
sequence numbers, especially when they have a small sequence number
window per-session.

And, of course, memcache isn't going to be durable (but probably it
will be good enough in many cases).  If you set a skew window to be
tight on the future side, then you can compensate for this if you can
detect loss of replay data (hmmm, not likely with memcache, eh?).

One big gotcha to be aware of:

 - Some clocks have lousy resolution, leading to easily repeated
values in high-rate environments.  One fix is to add resolution on the
wire and use random numbers for the unused precision bits.  Another
solution is to not use time.

My advice is that you allow the server to select which of timestamps
or sequence numbers to use.

Also, I strongly recommend that you specify replay cache semantics in
some detail.  Think of the Kerberos V5 replay cache semantics.

>> =C2=A0- In an open wifi environment active attacks may not be very diffi=
cult, thus
>> an option to secure more than just a handful of bits from the request, w=
ould
>> be nice (all of the request and all of the response, say). =C2=A0The har=
d part is how
>> to decide when to use one or the other. =C2=A0Ideally browsers can reque=
st more
>> protection when the network is reconfigured such that there's one or mor=
e
>> clear wifi interfaces.
>
> There is just no easy way to do that. If you need more, use TLS.

But even then you need to know when to use TLS.  TLS doesn't solve the
problem when you're trying to solve problems without introducing TLS
in the first place.  This is a serious problem.  You think you're
fixing one problem (cookie theft by passive attackers on open
networks) and you're very likely only making things somewhat harder
for the attacker -- we need to be very careful that the attacker can't
just automate active attacks and still win.

Nico
--

From singer@apple.com  Fri May 20 16:40:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B64E07F6 for ; Fri, 20 May 2011 16:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level: 
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjgE39qB7kmu for ; Fri, 20 May 2011 16:40:14 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id DECB2E07F1 for ; Fri, 20 May 2011 16:40:13 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_/guJrl2EN1DsMopgvYEySQ)"
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LLI00EFSPQUB651@mail-out.apple.com> for apps-discuss@ietf.org; Fri, 20 May 2011 16:40:13 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-86-4dd6fbdc9fa6
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay11.apple.com (Apple SCV relay) with SMTP id 08.A3.23242.CDBF6DD4; Fri, 20 May 2011 16:40:12 -0700 (PDT)
From: David Singer 
In-reply-to: <4DD2EF12.4040602@qualcomm.com>
Date: Fri, 20 May 2011 16:40:12 -0700
Message-id: <5F5C6DDF-A7C3-4E3B-8DF9-8F57F6AFC519@apple.com>
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com>  <147FB978-70D1-452A-BA57-6D31EC1B7C43@apple.com> <6.2.5.6.2.20110419000054.055c8c10@elandnews.com>    <4DD2EF12.4040602@qualcomm.com>
To: Pete Resnick 
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
Cc: Randall Gellens , Per Frojdh , S Moonesamy , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of	draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 23:40:17 -0000

--Boundary_(ID_/guJrl2EN1DsMopgvYEySQ)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

Pete

the [13k] was an editing error, should have been an RFC reference, I didn't catch it when fixing up after rfc2xml.  Thanks for catching it.

I can't find a perfect checker online, but Bill's ABNF checker  says, after changing := to =

-  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ -  +|+ 

Bill's ABNF Parser

No errors during parsing.

so I *think* we're OK


--Boundary_(ID_/guJrl2EN1DsMopgvYEySQ)
Content-type: text/plain; name=draft-gellens-mime-bucket-bis-05.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=draft-gellens-mime-bucket-bis-05.txt




Network Working Group                                         R. Gellens
Internet-Draft                                     QUALCOMM Incorporated
Obsoletes: 4281 (if approved)                                  D. Singer
Intended status: Standards Track                              Apple Inc.
Expires: November 21, 2011                                     P. Frojdh
                                                       Ericsson Research
                                                            May 20, 2011


      The Codecs and Profiles Parameters for "Bucket" Media Types
                  draft-gellens-mime-bucket-bis-05.txt

Abstract

   Several MIME type/subtype combinations exist that can contain
   different media formats.  A receiving agent thus needs to examine the
   details of such media content to determine if the specific elements
   can be rendered given an available set of codecs.  Especially when
   the end system has limited resources, or the connection to the end
   system has limited bandwidth, it is helpful to know from the Content-
   Type alone if the content can be rendered.

   This document specifies two parameters, "codecs" and "profiles",
   which are used with various MIME types or type/subtype combinations
   to allow for unambiguous specification of the codecs and/or profiles
   employed by the media formats contained within.  This document
   obsoletes RFC 4281; RFC 4281 defines the "codecs" parameter, which
   this document retains in a backwards compatible manner with minor
   clarifications; the "profiles" parameter is added by this document.

   By labeling content with the specific codecs indicated to render the
   contained media, receiving systems can determine if the codecs are
   supported by the end system, and if not, can take appropriate action
   (such as rejecting the content, sending notification of the
   situation, transcoding the content to a supported type, fetching and
   installing the required codecs, further inspection to determine if it
   will be sufficient to support a subset of the indicated codecs, etc.)

   Similarly, the profiles can provide an overall indication, to the
   receiver, of the specifications with which the content complies.  The
   receiver may be able to work out the extent to which it can handle
   and render the content by examining to see which of the declared
   profiles it supports, and what they mean.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.



Gellens, et al.         Expires November 21, 2011               [Page 1]

Internet-Draft          MIME codecs and profiles                May 2011


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 21, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

























Gellens, et al.         Expires November 21, 2011               [Page 2]

Internet-Draft          MIME codecs and profiles                May 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
   3.  The Codecs Parameter . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Generic Syntax . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  ISO File Format Name Space . . . . . . . . . . . . . . . . 10
     3.4.  ISO Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.5.  Use in Additional Media Types  . . . . . . . . . . . . . . 12
     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.7.  Additional Media Feature Details . . . . . . . . . . . . . 13
   4.  The Profiles Parameter . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Formal Declaration . . . . . . . . . . . . . . . . . . . . 14
     4.3.  Profiles Parameter Definition  . . . . . . . . . . . . . . 15
     4.4.  Profiles for files carrying registered brands  . . . . . . 15
     4.5.  Profiles Parameter BNF Definition  . . . . . . . . . . . . 16
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Registration . . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

























Gellens, et al.         Expires November 21, 2011               [Page 3]

Internet-Draft          MIME codecs and profiles                May 2011


1.  Introduction

   One of the original motivations for MIME is the ability to identify
   the specific media type of a message part.  However, due to various
   factors, it is not always possible from looking at the MIME type and
   subtype to know which specific media formats are contained in the
   body part, or which codecs are indicated in order to render the
   content.

   There are several media type/subtypes (either currently registered or
   deployed with registration pending) that contain codecs chosen from a
   set.  In the absence of the parameters described here, it is
   necessary to examine each media element in order to determine the
   codecs or other features required to render the content.  For
   example, video/3gpp may contain any of the video formats H.263
   Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any
   of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate -
   WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or
   Enhanced aacPlus, as specified in [3GPP-Formats].

   In some cases, the specific codecs can be determined by examining the
   header information of the media content.  While this isn't as bad as
   examining the entire content, it still requires specialized knowledge
   of each format and is resource consumptive.

   This ambiguity can be a problem for various clients and servers.  For
   example, it presents a significant burden to Multimedia Messaging
   (MMS) servers, which must examine the media sent in each message in
   order to determine which codecs are required to render the content.
   Only then can such a server determine if the content requires
   transcoding or specialized handling prior to being transmitted to the
   handset.

   Additionally, it presents a challenge to smart clients on devices
   with constrained memory, processing power, or transmission bandwidth
   (such as cellular telephones and PDAs).  Such clients often need to
   determine in advance if they are currently capable of rendering the
   content contained in an MMS or email message.

   Ambiguity:

   o  audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or
      Enhanced aacPlus contents as specified in [3GPP-Formats].

   o  audio/3gpp2 can contain AMR, AAC, 13K (as per [RFC3625]), Enhanced
      Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or
      VMR-WB, as specified in [3GPP2-Formats].




Gellens, et al.         Expires November 21, 2011               [Page 4]

Internet-Draft          MIME codecs and profiles                May 2011


   o  video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264,
      MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC,
      or Enhanced aacPlus, as specified in [3GPP-Formats].

   o  video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264,
      MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]),
      EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats].

   o  audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4
      or registered at the MP4 registration authority [MP4RA].

   o  video/mp4 has the same issues as audio/mp4, and in addition many
      video codecs, and especially the MPEG codecs, have a variety of
      profiles and levels, not all of which are supported by every
      implementation.

   Note that there are additional media types that are ambiguous, but
   are outside the scope of this document, including:

   o  video/mpeg4-generic, which can contain anything allowed by the
      MPEG-4 specification, or any codec registered with the MP4
      registration authority [MP4RA];

   With each "bucket" type, a receiving agent only knows that it has a
   container format.  It doesn't even know whether content labeled
   video/3gpp or video/3gpp2 contains video; it might be audio only,
   audio and video, or video only.

   A solution that permits a receiving agent to determine the specific
   codecs or profiles required to render media content would help
   provide efficient and scalable servers, especially for Multimedia
   Messaging (MMS), and aid the growth of multimedia services in
   wireless networks.


















Gellens, et al.         Expires November 21, 2011               [Page 5]

Internet-Draft          MIME codecs and profiles                May 2011


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119] .

   The syntax in this document uses the BNF rules specified in [RFC2045]
   and [RFC2231].










































Gellens, et al.         Expires November 21, 2011               [Page 6]

Internet-Draft          MIME codecs and profiles                May 2011


3.  The Codecs Parameter

3.1.  Introduction

   This section adds a parameter to allow unambiguous specification of
   all codecs indicated to render the content in the MIME part.  This
   parameter is optional in all current types to which it is added.
   Future types that contain ambiguity are strongly encouraged to
   include this parameter.

   This parameter applies to:

   1.  Files in the family based on the ISO Base Media File Format
       [ISO14496-12].

   2.  The QuickTime file format, owned by Apple Inc.

   This includes the media types:

   1.  audio/3gpp, video/3gpp

   2.  audio/3gpp2, video/3gpp2

   3.  audio/mp4, video/mp4, application/mp4

   4.  video/quicktime

   5.  application/mp21 (see note below)

   Note that MPEG-21 files under the type application/mp21 may, but are
   not required to, contain a top-level 'moov' atom providing a timed,
   coded, resource.  The codecs parameter SHOULD only be used for
   MPEG-21 files when this timed material is also present in the file.

   Parameter name: codecs

   Parameter value: A single value, or a comma-separated list of values
   identifying the codec(s) indicated to render the content in the body
   part.

   Each value consists of one or more dot-separated elements.  The name
   space for the first element is determined by the MIME type.  The name
   space for each subsequent element is determined by the preceding
   element.  The precise syntax is given below in the Generic Syntax
   (Section 3.2).

   Note that, per [RFC2045], some characters (including the comma used
   to separate multiple values) require that the entire parameter value



Gellens, et al.         Expires November 21, 2011               [Page 7]

Internet-Draft          MIME codecs and profiles                May 2011


   be enclosed in quotes.

   An element MAY include an octet that [RFC2045] REQUIRES to be
   encoded.  In this case, [RFC2231] is used: an asterisk ("*") is
   placed at the end of the parameter name (becoming "codecs*" instead
   of "codecs"), the parameter value usually starts with two single
   quote ("'") characters (indicating that neither character set nor
   language is specified), and each octet that requires encoding is
   represented as a percent sign ("%") followed by two hexadecimal
   digits.  Note that, when the [RFC2231] form is used, the percent
   sign, asterisk, and single quote characters have special meaning and
   so MUST themselves be encoded.


           Examples of Generic Syntax:
               codecs=a.bb.ccc.d
               codecs="a.bb.ccc.d, e.fff"
               codecs*=''fo%2e
               codecs*="''%25%20xz, gork"

   When the codecs parameter is used, it MUST contain all codecs
   indicated by the content present in the body part.  The codecs
   parameter MUST NOT include any codecs that are not indicated by any
   media elements in the body part.

   In some cases, not all indicated codecs are absolutely required in
   order to render the content.  Therefore, when a receiver does not
   support all listed codecs, special handling MAY be required.  For
   example, the media element(s) MAY need to be examined in order to
   determine if an unsupported codec is actually required (e.g., there
   may be alternative tracks (such as English and Spanish audio), there
   may be timed text that can be dropped, etc.)

   NOTE: Although the parameter value MUST be complete and accurate in
   'breadth' (that is, it MUST report all four-character codes used in
   all tracks for ISO-family files, for example) systems MUST NOT rely
   on it being complete in 'depth'.  If the hierarchical rules for a
   given code (e.g., 'qvxy') were written after a server was
   implemented, for example, that server will not know what elements to
   place after 'qvxy'.

   If a receiver encounters a body part whose codecs parameter contains
   codecs that are not indicated by any media elements, then the
   receiver SHOULD process the body part by discarding the information
   in the codecs parameter.

   If a receiver encounters a body part whose codecs parameter does not
   contain all codecs indicated by the media elements, then the receiver



Gellens, et al.         Expires November 21, 2011               [Page 8]

Internet-Draft          MIME codecs and profiles                May 2011


   MAY process the body part by discarding the information in the codecs
   parameter.

3.2.  Generic Syntax

   The codecs parameter takes either of two forms.  The first form is
   used when the value does not contain any octets that require
   encoding.  The second form uses [RFC2231] to allow arbitrary octets
   to be encoded.  With either form, quotes allow for commas and other
   characters in  (quotes MAY be used even when not
   required).

   This BNF uses the rules specified in [RFC2045] and [RFC2231] .

   Implementations MUST NOT add CFWS between the tokens except after
   ",".  TOKEN is defined in [RFC2045], and  and  are defined in [RFC2231].

   The BNF syntax is as follows:


      codecs      := cod-simple / cod-fancy
      cod-simple  := "codecs" "=" unencodedv
      unencodedv  := id-simple / simp-list
      simp-list   := DQUOTE id-simple *( "," id-simple ) DQUOTE
      id-simple   := element
                  ; "." reserved as hierarchy delimiter
      element     := 1*octet-sim
      octet-sim   := 

                  ; Within a codecs parameter value, "." is reserved
                  ; as a hierarchy delimiter
      cod-fancy   := "codecs*" ":=" encodedv
      encodedv    := fancy-sing / fancy-list
      fancy-sing  := [charset] "'" [language] "'" id-encoded
                  ; Parsers MAY ignore 
                  ; Parsers MAY support only US-ASCII and UTF-8
      fancy-list  := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
                  ; Parsers MAY ignore 
                  ; Parsers MAY support only US-ASCII and UTF-8
      id-list     := id-encoded *( "," id-encoded )
      id-encoded  := encoded-elm *( "." encoded-elm )
                  ; "." reserved as hierarchy delimiter
      encoded-elm := 1*octet-fancy
      octet-fancy := ext-octet / attribute-char

      DQUOTE      := %x22 ; " (double quote)




Gellens, et al.         Expires November 21, 2011               [Page 9]

Internet-Draft          MIME codecs and profiles                May 2011


   Initial name space: This document only defines values for files in
   the ISO Base Media File Format, and QuickTime, families.  Other file
   formats may also define codec naming.

3.3.  ISO File Format Name Space

   For the ISO Base Media File Format, and the QuickTime movie file
   format, the first element of a codecs parameter value is a sample
   description entry four-character code as registered by the MP4
   Registration Authority [MP4RA].  Values are case sensitive.

   Note that there are potentially multiple tracks in a file, each
   potentially carrying multiple sample entries (some but not all uses
   of the ISO File Format restrict the number of sample entries in a
   track to one).

   When the first element of a value is 'mp4a' (indicating some kind of
   MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2
   video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams
   such as MPEG-4 BIFS), the second element is the hexadecimal
   representation of the MP4 Registration Authority ObjectTypeIndication
   (OTI), as specified in [MP4RA] and [MP41] (including amendments).
   Note that [MP4RA] uses a leading "0x" with these values, which is
   omitted here and hence implied.

   One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio).
   For this value, the third element identifies the audio
   ObjectTypeIndication (OTI) as defined in [MP4A] (including
   amendments), expressed as a decimal number.

   For example, AAC low complexity has the value 2, so a complete string
   for AAC-LC would be "mp4a.40.2".

   One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2
   video).  For this value, the third element identifies the video
   ProfileLevelIndication as defined in [MP4V] (including amendments),
   expressed as a decimal number.

   For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so
   a complete string for MPEG-4 Visual Simple Profile Level 0 would be
   "mp4v.20.9".

   When the first element of a value is a code indicating a codec from
   the Advanced Video Coding specification [AVC], specifically one of
   the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2',
   'svc1', 'mvc1' and 'mvc2') - indicating AVC (H.264), Scalable Video
   Coding (SVC) or Multiview Video Coding (MVC), the second element
   (referred to as 'avcoti' in the formal syntax) is the hexadecimal



Gellens, et al.         Expires November 21, 2011              [Page 10]

Internet-Draft          MIME codecs and profiles                May 2011


   representation of the following three bytes in the (subset) sequence
   parameter set NAL unit specified in [AVC]:

   (1)  profile_idc,

   (2)  the byte containing the constraint_set flags (currently
        constraint_set0_flag through constraint_set5_flag, and the
        reserved_zero_2bits) and

   (3)  level_idc.

   Note that the sample entries 'avc1' and 'avc2' do not necessarily
   indicate that the media only contains AVC NAL units.  In fact, the
   media may be encoded as an SVC or MVC profile and thus contain SVC or
   MVC NAL units.  In order to be able to determine which codec is used
   further information is necessary (profile_idc).  Note also that
   reserved_zero_2bits is required to be equal to 0 in [AVC], but other
   values for it may be specified in the future by ITU-T or ISO/IEC.

   This is as previously defined in the 3GPP File Format specification
   3GPP TS 26.244 [3GPP-Formats], section A.2.2.

   When SVC or MVC content is coded in an AVC-compatible fashion, the
   sample description may include both an AVC configuration record and
   an SVC or MVC configuration record.  Under those circumstances, it is
   recommended that the two configuration records both be reported as
   they may contain different AVC profile, level, and compatibility
   indicator values.  Thus the codecs reported would include the sample
   description code (e.g. 'avc1') twice, with the values from one of the
   configuration records forming the 'avcoti' information in each.





















Gellens, et al.         Expires November 21, 2011              [Page 11]

Internet-Draft          MIME codecs and profiles                May 2011


3.4.  ISO Syntax

      id-simple   :=/ id-iso
      id-encoded  :=/ id-iso
      id-iso      := iso-gen / iso-mpega / iso-mpegv / iso-avc
      iso-gen     := cpid *( element / encoded-elm )
                  ;  used with 
                  ;  used with 
                  ;
                  ; Note that the BNF permits "." within 
                  ; and  but "." is reserved as the
                  ; hierarchy delimiter
      iso-mpega   := mp4a "." oti [ "." aud-oti ]
      iso-mpegv   := mp4v "." oti [ "." vid-pli ]
      iso-avc     := avc1  / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti  ]
      cpid        := 4(octet-simple / octet-fancy)
                  ;  used with 
                  ;  used with 
      mp4a        := %x6d.70.34.61 ; 'mp4a'
      oti         := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
                  ; leading "0x" omitted
      avc1        := %x61.76.63.31 ; 'avc1'
      avc2        := %x61.76.63.32 ; 'avc2'
      svc1        := %x73.76.63.31 ; 'svc1'
      mvc1        := %x6d.76.63.31 ; 'mvc1'
      mvc2        := %x6d.76.63.32 ; 'mvc2'
      avcoti      := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
                  ; leading "0x" omitted
      aud-oti     := 1*DIGIT
      mp4v        := %x6d.70.34.76 ; 'mp4v'
      vid-pli     := 1*DIGIT

3.5.  Use in Additional Media Types

   This parameter MAY be specified for use with additional MIME media
   types.

   For ISO file formats where the name space as defined here is
   sufficient, all that needs to be done is to update the media type
   registration to specify the codecs parameter with a reference to this
   document.  For existing media types, it is generally advisable for
   the parameter to be optional; for new media types, the parameter MAY
   be optional or required, as appropriate.

   For ISO file formats where the name space as defined here needs to be
   expanded, a new document MAY update this one by specifying the
   additional detail.




Gellens, et al.         Expires November 21, 2011              [Page 12]

Internet-Draft          MIME codecs and profiles                May 2011


   For non-ISO formats, a new document MAY update this one by specifying
   the name space for the media type(s).

3.6.  Examples


      Content-Type: video/3gpp2; codecs="sevc, s263"
          (EVRC audio plus H.263 video)
      Content-Type: audio/3gpp; codecs=samr
          (AMR audio)
      Content-Type: video/3gpp; codecs="s263, samr"
          (H.263 video plus AMR audio)
      Content-Type: audio/3gpp2; codecs=mp4a.E1
          (13k audio)
      Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
          (MPEG-4 Visual Simple Profile Level 0 plus 13K voice)
      Content-Type: video/mp4; codecs="avc1.640028"
           (H.264/AVC video, High Profile, Level 40,
            e.g. DVB 720p 50Hz HDTV)
      Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E"
           (SVC video, Scalable High Profile, Level 30,
            with a Main Profile AVC base layer, e.g. DVB 25 Hz SDTV)
       Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030"
           (MVC video, Stereo High Profile, Level 42,
            with a High Profile base layer, e.g. as adopted in Blu-ray)

   Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated
   Amendment(s) and Corrigendum(a).  The actual object types are defined
   in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in
   [MP4V], Annex K."  (references adjusted).

3.7.  Additional Media Feature Details

   It is sometimes helpful to provide additional details for a media
   element (e.g., the number of X and Y pixels, the color depth, etc.).
   These details are sometimes called "media features" or "media
   characteristics".

   When such additional features are included, the content-features
   [RFC2912] header provides a handy way to do so.











Gellens, et al.         Expires November 21, 2011              [Page 13]

Internet-Draft          MIME codecs and profiles                May 2011


4.  The Profiles Parameter

4.1.  Introduction

   Just as some codecs have a variety of profiles (subsets of their
   functionality within which a bitstream can be coded), so also some
   media files can be profiled, and be associated with one or more
   profile identifiers of the profiles to which they conform.  These
   profiles can indicate features of the file format itself, which
   codecs may be present, the profiles of those codecs, and so on.  It
   can be advantageous to a receiving system to know the overall file
   profile(s) of a file; indeed, under these circumstances it may not be
   necessary to know the codecs themselves if they are implied by the
   profile.

4.2.  Formal Declaration

   This section adds a parameter to allow unambiguous specification of
   the profiles to which a file claims conformance.  This parameter is
   optional in all current types to which it is added.

   This parameter applies to:

   1.  Box-structured (also known as atom-structured) files that have an
       initial box containing compatibility brands, as registered at the
       MP4 Registration Authority [MP4RA], such as a filetype or
       segment-type box.  This includes principally files in the family
       based on the ISO Base Media File Format [ISO14496-12].

   2.  The QuickTime file format, owned by Apple Inc.

   This includes the media types:

   1.  audio/3gpp, video/3gpp

   2.  audio/3gpp2, video/3gpp2

   3.  audio/mp4, video/mp4

   4.  video/quicktime

   5.  application/mp21

   Parameter name: profiles

   Parameter value: A single value, or a comma-separated list of values
   identifying the profiles(s) to which the file claims conformance.




Gellens, et al.         Expires November 21, 2011              [Page 14]

Internet-Draft          MIME codecs and profiles                May 2011


   The name space is determined by the MIME type.

   Note that, per [RFC2045], some characters (including the comma used
   to separate multiple values) require that the entire parameter value
   be enclosed in quotes.

   An element MAY include an octet that [RFC2045] REQUIRES to be
   encoded.  In this case, [RFC2231] is used: an asterisk ("*") is
   placed at the end of the parameter name (becoming "profiles*" instead
   of "profiles"), the parameter value usually starts with two single
   quote ("'") characters(indicating that neither character set nor
   language is specified), and each octet that requires encoding is
   represented as a percent sign ("%") followed by two hexadecimal
   digits.  Note that, when the [RFC2231] form is used, the percent
   sign, asterisk, and single quote characters have special meaning and
   so MUST themselves be encoded.


           Examples of Generic Syntax:
               profiles="isom,mp41,qvXt"
               profiles*="''%25%20xz, gork"

4.3.  Profiles Parameter Definition

   The 'profiles' parameter is an optional parameter that indicates one
   or more profiles to which the file claims conformance.  Like the
   'codecs' parameter described above, it may occur as either 'profiles'
   or 'profiles*', with the same encoding rules.  The value is, as for
   the codecs parameter, a comma-separated list of profile identifiers.

4.4.  Profiles for files carrying registered brands

   For any file format carrying a brand registered at the MP4
   Registration Authority [MP4RA], notably files based on the ISO Base
   Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie
   files, the profiles parameter MUST list exactly the major brand,
   followed by the compatible-brands, as listed in the filetype box
   ('ftyp') or segment-type box ('styp').  The major-brand MUST be
   first, and MAY be removed from the compatible-brands list.  (The file
   format requires that it be repeated in the compatible brands, but
   this requirement is relaxed here for compactness.)

   An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4
   version 1 is the major brand and preferred use, that the file is
   compatible with the version of the base file format identified by
   'isom', and that it is also compatible with the specification/profile
   'qvXt' (whatever that may be).




Gellens, et al.         Expires November 21, 2011              [Page 15]

Internet-Draft          MIME codecs and profiles                May 2011


4.5.  Profiles Parameter BNF Definition


      profil      := pro-simple / pro-fancy
      pro-simple  := "profiles" "=" unencodedv

                  ; Within a codecs parameter value, "." is reserved
                  ; as a hierarchy delimiter
      pro-fancy   := "profiles*" ":=" encodedv










































Gellens, et al.         Expires November 21, 2011              [Page 16]

Internet-Draft          MIME codecs and profiles                May 2011


5.  IANA Considerations

   The IANA has added "codecs" and "profiles" as optional parameters to
   the media types as listed in Sections 3 and 4, with a reference to
   this document.














































Gellens, et al.         Expires November 21, 2011              [Page 17]

Internet-Draft          MIME codecs and profiles                May 2011


6.  Registration

   The MPEG4 Registration Authority can be consulted for the most up-to-
   date registration of sub-parameters for the codecs type, for specific
   codecs.














































Gellens, et al.         Expires November 21, 2011              [Page 18]

Internet-Draft          MIME codecs and profiles                May 2011


7.  Security Considerations

   The codecs parameter itself does not alter the security
   considerations of any of the media types with which it is used.  Each
   audio and video media type has its own set of security considerations
   that continue to apply, regardless of the use of the codecs
   parameter.

   An incorrect codecs parameter might cause media content to be
   received by a device that is not capable of rendering it, or might
   cause media content to not be sent to a device that is capable of

   receiving it.  An incorrect codecs parameter is therefore capable of
   some types of denial-of-service attacks.  However, this is most
   likely to arise by accident, as an attacker capable of altering media
   data in transit could cause more harm by altering the media format
   itself, or even the content type header, rather than just the codecs
   parameter of the content type header.

































Gellens, et al.         Expires November 21, 2011              [Page 19]

Internet-Draft          MIME codecs and profiles                May 2011


8.  Acknowledgements

   Harinath Garudadri provided a great deal of help, which is very much
   appreciated.  Mary Barnes and Bruce Lilly provided detailed and
   helpful comments.  Reviews and comments by Sam Hartman, Russ Housley,
   and Bert Wijnen were much appreciated.  Chris Newman carefully
   reviewed and improved the BNF.

   Christian Timmerer helped with the MPEG-21 material, and Thomas
   Schierl and Yago Sanchez helped with SVC and MVC.









































Gellens, et al.         Expires November 21, 2011              [Page 20]

Internet-Draft          MIME codecs and profiles                May 2011


9.  References

9.1.  Normative References

   [3GPP-Formats]
              3rd Generation Partnership Project, "Technical
              Specification Group Services and System Aspects;
              Transparent end-to-end packet switched streaming service
              (PSS); 3GPP file format (3GP)", 3GPP TS 26.244.

   [AVC]      "Advanced video coding for generic audiovisual services",
              ITU-T Recommendation H.264, ISO/IEC 14496-10:2009.

   [AVC-Formats]
              "Information technology -- Coding of audio-visual objects
              -- Part 15: Advanced Video Coding (AVC) file format", ISO/
              IEC 14496-15:2010.

   [ISO14496-12]
              "Information technology -- Coding of audio-visual objects
              -- Part 12: ISO base media file format", ISO/
              IEC 14496-12:2008.

   [MP4RA]    "MP4REG, The MPEG-4 Registration Authority",
              .

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions:
              Character Sets, Languages, and Continuations", RFC 2231,
              November 1997.

   [RFC2912]  Klyne, G., "Indicating Media Features for MIME Content",
              RFC 2912, September 2000.

9.2.  Informative References

   [3GPP2-Formats]
              Third Generation Partnership Project 2, "3GPP2 File
              Formats for Multimedia Service", .




Gellens, et al.         Expires November 21, 2011              [Page 21]

Internet-Draft          MIME codecs and profiles                May 2011


   [MP41]     "Information technology--Coding of audio-visual objects--
              Part 1:  Systems", ISO/IEC 14496-1:2010.

   [MP4A]     "Information technology--Coding of audio-visual
              objects--3:  Audio", ISO/IEC 14496-3:2009.

   [MP4V]     "Information technology--Coding of audio-visual objects--
              Part 2:  Visual", ISO/IEC 14496-2:2004.

   [RFC3625]  Gellens, R. and H. Garudadri, "The QCP File Format and
              Media Types for Speech Data", RFC 3625, September 2003.








































Gellens, et al.         Expires November 21, 2011              [Page 22]

Internet-Draft          MIME codecs and profiles                May 2011


Authors' Addresses

   Randall Gellens
   QUALCOMM Incorporated
   5775 Morehouse Drive
   San Diego, CA  92121
   US

   Email: randy@qualcomm.com


   David Singer
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   US

   Phone: +1 408 996 1010
   Email: singer@apple.com


   Per Frojdh
   Ericsson Research
   Multimedia Technologies SE-164
   Stockholm  80
   Sweden

   Phone: +46 8 7190000
   Email: Per.Frojdh@ericsson.com






















Gellens, et al.         Expires November 21, 2011              [Page 23]


--Boundary_(ID_/guJrl2EN1DsMopgvYEySQ)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT



On May 17, 2011, at 14:56 , Pete Resnick wrote:

> On 5/12/11 6:47 PM, David Singer wrote:
> 
>> -04 uploaded. what's next?
> 
> Almost time for me to Last Call the document. A few things:
> 
> I found one nit in -04 :
> 
>  == Missing Reference: '13k' is mentioned on line 148, but not defined
> 
> I see that you used regular BNF and not ABNF. That's OK, but I would appreciate you (a) using a tool to syntax check the BNF and (b) pointing me to the output of that tool. My BNF is OK, but not great.
> 
> I will do a review of the document before sending it for Last Call, but I would appreciate if one of you could start writing up the announcement text. As it says in RFC 4858:
> 
> 
>          The IESG approval announcement includes a Document
>          Announcement Write-Up.  Please provide such a Document
>          Announcement Write-Up.  Recent examples can be found in the
>          "Action" announcements for approved documents.  The approval
>          announcement contains the following sections:
> 
>          Technical Summary
>             Relevant content can frequently be found in the abstract
>             and/or introduction of the document.  If not, this may be
>             an indication that there are deficiencies in the abstract
>             or introduction.

I think the document abstract should meet this need.

> 
>          Working Group Summary
>             Was there anything in the WG process that is worth noting?
>             For example, was there controversy about particular points
>             or were there decisions where the consensus was
>             particularly rough?

It's worth noting that it was uncontroversial enough to elicit very few comments.

> 
>          Document Quality
>             Are there existing implementations of the protocol?  Have a
>             significant number of vendors indicated their plan to
>             implement the specification?  Are there any reviewers that
>             merit special mention as having done a thorough review,
>             e.g., one that resulted in important changes or a
>             conclusion that the document had no substantive issues?  If
>             there was a MIB Doctor, Media Type, or other Expert Review,
>             what was its course (briefly)?  In the case of a Media Type
>             Review, on what date was the request posted?

The codecs parameter is getting increasingly popular, and the MPEG/3G DASH specifications would like to have a stable reference for the 'profiles' parameter.

> 
>          Personnel
>             Who is the Document Shepherd for this document?  Who is the
>             Responsible Area Director?  If the document requires IANA
>             experts(s), insert 'The IANA Expert(s) for the registries
>             in this document are .'
> 
> -- 
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> 

David Singer
Multimedia and Software Standards, Apple Inc.


--Boundary_(ID_/guJrl2EN1DsMopgvYEySQ)--

From barryleiba.mailing.lists@gmail.com  Fri May 20 19:32:24 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE914E068E for ; Fri, 20 May 2011 19:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.279
X-Spam-Level: 
X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMFZ-jSiBd3S for ; Fri, 20 May 2011 19:32:21 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5402E06AF for ; Fri, 20 May 2011 19:32:20 -0700 (PDT)
Received: by yxk30 with SMTP id 30so1872637yxk.31 for ; Fri, 20 May 2011 19:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uomgMBsqYYQYJcWK9EGFSCJAY+1hHuEUqIPRpdmKKTA=; b=aI3YIQXO8+QwQPCb6CDIgoSIBcVY5WZey9aHpmfTEsuMWBXRShhiwjwwUOKrIok2pz sefmhT3LFgD38t0xlMJj0rzMRXOQZQqlKks+3/2Mn1oPpLvbkUMBbN6XqOCkcdafHaAn RDHVgX0gBWZHS4p2NNZ2Tob4xhfOgKI4H9sZs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Pqhj1qIL0sSmRITBZBBpMD/BmOGnn1Z4NakG5WXibu/d/3CZZhP6L5o5OtLqBoMONV 6lk34UjavUh/jC2qWYBYJr/OgLM6tRKNprc05mkDoaNGERcz1FOjmwLwyuI/ypicepWu caSD4O6AbQaSdTMhUP2E81BgZKYtARay9RqeA=
MIME-Version: 1.0
Received: by 10.236.116.73 with SMTP id f49mr361516yhh.211.1305945139200; Fri, 20 May 2011 19:32:19 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.169.14 with HTTP; Fri, 20 May 2011 19:32:19 -0700 (PDT)
In-Reply-To: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 22:32:19 -0400
X-Google-Sender-Auth: aCESg6LYszyVB7ZK3QTeR_pDzxo
Message-ID: 
From: Barry Leiba 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 02:32:24 -0000

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area
> Working Group Working Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Terminology Used in Internatio=
nalization in the IETF
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Paul Hoffman
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John C Klensin
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rfc3536bis-01=
.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 46
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-20
>
> =A0 This document provides a glossary of terms used in the IETF when
> =A0 discussing internationalization. =A0The purpose is to help frame
> =A0 discussions of internationalization in the various areas of the IETF
> =A0 and to help introduce the main concepts to IETF participants.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.txt

This version of the internationalization terminology draft
incorporates all the accepted suggestions and comments, and is ready
for working group last call.  Please review this version and post any
pressing issues to  by 3 June, 2011.

Note that not all suggestions were accepted, and in that case the
editors should have responded to that effect.  We're looking for new
issues, here, and not repetitions of old discussions.  If there have
already been multiple rounds of discussion and consensus didn't
support the change, that's why it's not in there.

Again, being issues to  by 3 June.

Barry, appsawg chair

From stpeter@stpeter.im  Fri May 20 19:58:33 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A343E068E for ; Fri, 20 May 2011 19:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.237
X-Spam-Level: 
X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgfexG7VGH98 for ; Fri, 20 May 2011 19:58:32 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E1E0658 for ; Fri, 20 May 2011 19:58:31 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC45840046 for ; Fri, 20 May 2011 20:58:29 -0600 (MDT)
Message-ID: <4DD72A53.1080606@stpeter.im>
Date: Fri, 20 May 2011 20:58:27 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070306050805090806010608"
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 02:58:33 -0000

This is a cryptographically signed message in MIME format.

--------------ms070306050805090806010608
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On 5/20/11 8:32 PM, Barry Leiba wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Applications Area
>> Working Group Working Group of the IETF.
>>
>>        Title           : Terminology Used in Internationalization in t=
he IETF
>>        Author(s)       : Paul Hoffman
>>                          John C Klensin
>>        Filename        : draft-ietf-appsawg-rfc3536bis-01.txt
>>        Pages           : 46
>>        Date            : 2011-05-20
>>
>>   This document provides a glossary of terms used in the IETF when
>>   discussing internationalization.  The purpose is to help frame
>>   discussions of internationalization in the various areas of the IETF=

>>   and to help introduce the main concepts to IETF participants.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.t=
xt
>=20
> This version of the internationalization terminology draft
> incorporates all the accepted suggestions and comments, and is ready
> for working group last call.  Please review this version and post any
> pressing issues to  by 3 June, 2011.

"A language is a way that humans interact"? I'd substitute "communicate"
for "interact" (humans also interact by trading things, playing games,
fighting, sharing meals, etc.).

Peter

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




--------------ms070306050805090806010608
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy
MTAyNTgyN1owIwYJKoZIhvcNAQkEMRYEFGynXIFUQutheON4a9bWFnBpUS+fMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBDfJkgXBsrbCb6BIbJnkxHWpD0HviyQ5aJG5tvmXrXWINVZdAwpPGkOfWD
9ptv6NdaUoo/4FPeDld9T35uLooMJd5oQIGguPh5iFZ6eDCxi1FUDkI03e2y5F10xQxQt3cO
7pWHNLyUFgdyi+ZKxuKjJenYD9+iXFntfvIwj7FlYDmcp232k5ZJjhiqQx1SzvmdJiaYlNoR
4z/FngYZtW+MGxMT8TCq1QYF3dh4PVtpHV4LuV25wreXpRJKSpRMXQG2qrM/A1+dz+kSeGps
DO1psTxOsMvZO5lq8WZowZgCNjkOw6jJgTnwYjOjGelFZS6Uw+xbUyvkMRbC4WjZ8pn+AAAA
AAAA
--------------ms070306050805090806010608--

From evnikita2@gmail.com  Fri May 20 21:45:53 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2CAE0662 for ; Fri, 20 May 2011 21:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.509
X-Spam-Level: 
X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTIsksXggMBM for ; Fri, 20 May 2011 21:45:52 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEC41E0658 for ; Fri, 20 May 2011 21:45:51 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4014843bwz.31 for ; Fri, 20 May 2011 21:45:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=rWQgoPVp5MYq9s/n8bqfGBwOfI+/u0MR/4I8K+ABaus=; b=m/s9rMJOXfxeL6rUMjE/aUJktGmkgRWninXGl7lLH5CNa1TmPPwucEIeWPdZcez4OV /r1Bld3+iHLE8AUNw21WbMKmNwy6roefiQoJ4VSZXh7fO1PT9PSEZEXjnILW7XNL9ScC 9nuM5CvhzBJXIsji97ULUkBzDG0IYsMdBLPuo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=U0pT5zHORXsREfh24LyQrDCVVFZaAH/YSEi4qinRhqkzAPlZB2CcdrXIEzJkA2pc05 htUzcv7OafDuzNVUsdYWYZjA+r1R5sJPX8K0Q72RwfLY6mDXEaBGB/Efgm1PHu0YLZcp rswrOh3PIUI5vBK+H+xctd/OL3whGCcldXvjo=
Received: by 10.204.7.88 with SMTP id c24mr290510bkc.61.1305953150823; Fri, 20 May 2011 21:45:50 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d10sm2512809bkw.11.2011.05.20.21.45.49 (version=SSLv3 cipher=OTHER); Fri, 20 May 2011 21:45:49 -0700 (PDT)
Message-ID: <4DD743AB.8050603@gmail.com>
Date: Sat, 21 May 2011 07:46:35 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>	 <4DD72A53.1080606@stpeter.im>
In-Reply-To: <4DD72A53.1080606@stpeter.im>
Content-Type: multipart/alternative; boundary="------------030701000004010403020906"
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 04:45:53 -0000

This is a multi-part message in MIME format.
--------------030701000004010403020906
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

21.05.2011 5:58, Peter Saint-Andre wrote:
> 
>
> On 5/20/11 8:32 PM, Barry Leiba wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Applications Area
>>> Working Group Working Group of the IETF.
>>>
>>>         Title           : Terminology Used in Internationalization in the IETF
>>>         Author(s)       : Paul Hoffman
>>>                           John C Klensin
>>>         Filename        : draft-ietf-appsawg-rfc3536bis-01.txt
>>>         Pages           : 46
>>>         Date            : 2011-05-20
>>>
>>>    This document provides a glossary of terms used in the IETF when
>>>    discussing internationalization.  The purpose is to help frame
>>>    discussions of internationalization in the various areas of the IETF
>>>    and to help introduce the main concepts to IETF participants.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.txt
>> This version of the internationalization terminology draft
>> incorporates all the accepted suggestions and comments, and is ready
>> for working group last call.  Please review this version and post any
>> pressing issues to  by 3 June, 2011.
> "A language is a way that humans interact"? I'd substitute "communicate"
> for "interact" (humans also interact by trading things, playing games,
> fighting, sharing meals, etc.).
Thanks for the new revision.  It addresses many of my comments.

I agree with Peter's comment above.  I was trying to submit a very 
similar proposal to -00 and I'll try once more now, for -01.

The language term definition is a bit obscure in the current revision of 
the document.  Therefore, I propose the following clarification, 
considering the comment from Peter above.

>   language
>
>        A language is a form of communication between humans using
>        words, which might be either spoken, written or gestured
>        and is a subject to a particular grammar and other rules.
>        
>
>        [as in current draft]
Please, also re-consider my proposal to control character definition I 
posted in 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02589.html.

Another minor editorial comment on -01.  Shouldn't the entries in the 
document be formed as in RFC 4949 (http://tools.ietf.org/html/rfc4949)?

Mykyta Yevstifeyev
> Peter
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--------------030701000004010403020906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
    
  
  
    21.05.2011 5:58, Peter Saint-Andre wrote:
    

      
<hat type='individual'/>

On 5/20/11 8:32 PM, Barry Leiba wrote:


      

        

          
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Applications Area
Working Group Working Group of the IETF.

       Title           : Terminology Used in Internationalization in the IETF
       Author(s)       : Paul Hoffman
                         John C Klensin
       Filename        : draft-ietf-appsawg-rfc3536bis-01.txt
       Pages           : 46
       Date            : 2011-05-20

  This document provides a glossary of terms used in the IETF when
  discussing internationalization.  The purpose is to help frame
  discussions of internationalization in the various areas of the IETF
  and to help introduce the main concepts to IETF participants.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3536bis-01.txt


        

        
This version of the internationalization terminology draft
incorporates all the accepted suggestions and comments, and is ready
for working group last call.  Please review this version and post any
pressing issues to <apps-discuss@ietf.org> by 3 June, 2011.


      

      
"A language is a way that humans interact"? I'd substitute "communicate"
for "interact" (humans also interact by trading things, playing games,
fighting, sharing meals, etc.).


    

    Thanks for the new revision.  It addresses many of my comments.

    

    I agree with Peter's comment above.  I was trying to submit a very
    similar proposal to -00 and I'll try once more now, for -01.

    

    The language term definition is a bit obscure in the current
    revision of the document.  Therefore, I propose the following
    clarification, considering the comment from Peter above.

    

    

      
 language

      A language is a form of communication between humans using
      words, which might be either spoken, written or gestured
      and is a subject to a particular grammar and other rules.
      <NONE>

      [as in current draft]


    

    Please, also re-consider my proposal to control character definition
    I posted in
    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02589.html.

    

    Another minor editorial comment on -01.  Shouldn't the entries in
    the document be formed as in RFC 4949
    (http://tools.ietf.org/html/rfc4949)?

    

    Mykyta Yevstifeyev

    

      
Peter



      

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


    

    

  


--------------030701000004010403020906--

From john@jck.com  Sat May 21 00:50:35 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABFDE06C7 for ; Sat, 21 May 2011 00:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ieBxHhpczv for ; Sat, 21 May 2011 00:50:34 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7255FE0697 for ; Sat, 21 May 2011 00:50:33 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QNgxE-0001Vt-3B; Sat, 21 May 2011 03:50:32 -0400
Date: Sat, 21 May 2011 03:50:31 -0400
From: John C Klensin 
To: Peter Saint-Andre , apps-discuss@ietf.org
Message-ID: <98A1FE2EF9918513D6F490C8@PST.JCK.COM>
In-Reply-To: <4DD72A53.1080606@stpeter.im>
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>  <4DD72A53.1080606@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 07:50:35 -0000

--On Friday, May 20, 2011 20:58 -0600 Peter Saint-Andre
 wrote:

>...
> "A language is a way that humans interact"? I'd substitute
> "communicate" for "interact" (humans also interact by trading
> things, playing games, fighting, sharing meals, etc.).

Sorry.  Meant to pick this up in this (-01) iteration.  It
slipped through the cracks.  Now changed in the working version
of -02 -- it won't get lost again.

   john





From john-ietf@jck.com  Sat May 21 01:22:01 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CEE06D7 for ; Sat, 21 May 2011 01:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj2+c8JJBNFT for ; Sat, 21 May 2011 01:22:00 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id BDA44E0697 for ; Sat, 21 May 2011 01:21:58 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QNhRd-0002X7-Hl; Sat, 21 May 2011 04:21:57 -0400
Date: Sat, 21 May 2011 04:21:56 -0400
From: John C Klensin 
To: Mykyta Yevstifeyev , apps-discuss@ietf.org
Message-ID: 
In-Reply-To: <4DD743AB.8050603@gmail.com>
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>  <4DD72A53.1080606@stpeter.im> <4DD743AB.8050603@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 08:22:01 -0000

--On Saturday, May 21, 2011 07:46 +0300 Mykyta Yevstifeyev
 wrote:

>...
> I agree with Peter's comment above.  I was trying to submit a
> very similar proposal to -00 and I'll try once more now, for
> -01.
> 
> The language term definition is a bit obscure in the current
> revision of the document.  Therefore, I propose the following
> clarification, considering the comment from Peter above.
> 
>>   language
>> 
>>        A language is a form of communication between humans
>>        using words, which might be either spoken, written or
>>        gestured and is a subject to a particular grammar and
>>        other rules. 

As I think was explained to you earlier, the assumption that
languages are bound to, or defined by, "a particular grammar and
other rules" has become wildly controversial.  From some
perspectives and lines of reasoning or research, it is also flat
wrong.  If you are interested in that set of arguments and where
they lead, I think some of us could recommend some things for
you to read.  But, unless you can offer a persuasive reason why
a definition that embroils use in the arguments about grammars
and transformations as the defining properties of a language
would make a significant difference in the IETF
internationalization context, I think we should leave the
definition alone (corrected as per Peter's note and my response).

>>        [as in current draft]
> Please, also re-consider my proposal to control character
> definition I posted in
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg0
> 2589.html.

The new text about control characters in -01 was intended to
address your concerns, including your suggestion to point to
ISO/IEC 6429.  Please read that new paragraph (starting
"Occasionally, in other vocabularies,").  We see considerable
advantage in using the Unicode definition rather than making one
up.  Even if we were to make one up, your definition is
questionable because the first paragraph would classify many
characters (code points) as control characters that many
standards, including Unicode, assign to other categories.
Similarly, in some real sense, any character "control[s]
handling of data; they can be considered to be and in-band
signaling in the context of character encoding" because
traditional graphical characters simply control their own
representations.  Or, if you want it the other way around, the
format effector control characters (e.g., VT, HT, and often BEL)
control page/display layout but not handling of data in the
usual sense; others, either particular control characters in
selected applications or others, notably ESC followed by a
graphic character in a particular range, form CSI sequences that
were traditionally used for terminal control, not handling of
the graphical character data themselves.

We have tried to accommodate your concerns by putting in the new
paragraph but the bottom line remains that control characters
(using the narrow definition)  are largely irrelevant to
internationalization.  Trying to provide an explanation here
that is both accurate and comprehensive would add a great deal
of clutter with little benefit.   We can try to do so if the WG
concludes that a more comprehensive definition is appropriate,
but I'd hope people would consider the question of how much such
a definition would contribute to an understanding of
internationalization (rather than an understanding of coded
character set terminology) before recommending that.

> Another minor editorial comment on -01.  Shouldn't the entries
> in the document be formed as in RFC 4949
> (http://tools.ietf.org/html/rfc4949)?

No.  The RFC Editor is free to reformat as they think
appropriate.  But, with all of the definitions sections in
Standards-Track documents that one could look at, why do you
believe that the entries here should be structured to conform to
an Informational document that was not even processed through
the IETF stream?

    john


From evnikita2@gmail.com  Sat May 21 08:18:08 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9137E06CF for ; Sat, 21 May 2011 08:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level: 
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLzbbNF4OVmU for ; Sat, 21 May 2011 08:18:07 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE6E0657 for ; Sat, 21 May 2011 08:18:07 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4262959bwz.31 for ; Sat, 21 May 2011 08:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rUej6csvuXEm6dbIyf1l/NpAYJfhYtCxEMFMvM2T/AI=; b=W9ffM+BwnGHFaA26tNJs34b1HJHe6dBEVJSqh8oJCO//RxuOrNhfW+GbrCYbbJlHoG ym9/Ajfjs1qVBnq6BoF0nTeFCCf3abDcszFgac3vqEq2EuFqAClnK9eEWVyWkweeNUL8 /0pW3bh97WELNXOuT5qdCLNHgaR2ryard07Fg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EdCzq5dSdIrSCGvCn8wwON4VojSgDiCXGHccavKEO5z6ZG0M/nZS5Su+TnhkZzUhYI /h+maGof/HVbsjUCXtZVBH2IHUK1aK608y8/apYPiVHmD1nRTEcqpgFWkZJyvLP11nWQ wRdlU6ZERYZPJDNlX/FNQpF5s6aKvcjRp1ePw=
Received: by 10.204.19.10 with SMTP id y10mr601053bka.190.1305991085931; Sat, 21 May 2011 08:18:05 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x6sm2779874bkv.0.2011.05.21.08.18.04 (version=SSLv3 cipher=OTHER); Sat, 21 May 2011 08:18:04 -0700 (PDT)
Message-ID: <4DD7D7DA.5060508@gmail.com>
Date: Sat, 21 May 2011 18:18:50 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John C Klensin 
References: <20110520163716.15875.86296.idtracker@ietfa.amsl.com>  <4DD72A53.1080606@stpeter.im> <4DD743AB.8050603@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3536bis-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 May 2011 15:18:08 -0000

21.05.2011 11:21, John C Klensin wrote:
>
> --On Saturday, May 21, 2011 07:46 +0300 Mykyta Yevstifeyev
>   wrote:
>
>> ...
>> I agree with Peter's comment above.  I was trying to submit a
>> very similar proposal to -00 and I'll try once more now, for
>> -01.
>>
>> The language term definition is a bit obscure in the current
>> revision of the document.  Therefore, I propose the following
>> clarification, considering the comment from Peter above.
>>
>>>    language
>>>
>>>         A language is a form of communication between humans
>>>         using words, which might be either spoken, written or
>>>         gestured and is a subject to a particular grammar and
>>>         other rules.
> As I think was explained to you earlier, the assumption that
> languages are bound to, or defined by, "a particular grammar and
> other rules" has become wildly controversial.  From some
> perspectives and lines of reasoning or research, it is also flat
> wrong.  If you are interested in that set of arguments and where
> they lead, I think some of us could recommend some things for
> you to read.  But, unless you can offer a persuasive reason why
> a definition that embroils use in the arguments about grammars
> and transformations as the defining properties of a language
> would make a significant difference in the IETF
> internationalization context, I think we should leave the
> definition alone (corrected as per Peter's note and my response).
Considering the issue to be really controversial, I won't insist on 
putting my text and won't object to leaving the existing one.  I 
understand there is no support of such idea so it makes no sense for me 
to continue pushing it forward.
>>>         [as in current draft]
>> Please, also re-consider my proposal to control character
>> definition I posted in
>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg0
>> 2589.html.
> The new text about control characters in -01 was intended to
> address your concerns, including your suggestion to point to
> ISO/IEC 6429.  Please read that new paragraph (starting
> "Occasionally, in other vocabularies,").  We see considerable
> advantage in using the Unicode definition rather than making one
> up.  Even if we were to make one up, your definition is
> questionable because the first paragraph would classify many
> characters (code points) as control characters that many
> standards, including Unicode, assign to other categories.
> Similarly, in some real sense, any character "control[s]
> handling of data; they can be considered to be and in-band
> signaling in the context of character encoding" because
> traditional graphical characters simply control their own
> representations.  Or, if you want it the other way around, the
> format effector control characters (e.g., VT, HT, and often BEL)
> control page/display layout but not handling of data in the
> usual sense; others, either particular control characters in
> selected applications or others, notably ESC followed by a
> graphic character in a particular range, form CSI sequences that
> were traditionally used for terminal control, not handling of
> the graphical character data themselves.
I see the current definition should probably go to the "narrative" part 
(after mentioning the source) since it is concerned to Unicode's 
understanding of what the control char is.  If we decide to put the 
definition of "control character" in this document at all, just 
mentioning some examples of them isn't enough.  Otherwise, if the 
control character is hardly related to internalization, it shouldn't be 
mentioned in the document at all.  Let's not have double standards.
> We have tried to accommodate your concerns by putting in the new
> paragraph but the bottom line remains that control characters
> (using the narrow definition)  are largely irrelevant to
> internationalization.  Trying to provide an explanation here
> that is both accurate and comprehensive would add a great deal
> of clutter with little benefit.   We can try to do so if the WG
> concludes that a more comprehensive definition is appropriate,
> but I'd hope people would consider the question of how much such
> a definition would contribute to an understanding of
> internationalization (rather than an understanding of coded
> character set terminology) before recommending that.
>
>> Another minor editorial comment on -01.  Shouldn't the entries
>> in the document be formed as in RFC 4949
>> (http://tools.ietf.org/html/rfc4949)?
> No.  The RFC Editor is free to reformat as they think
> appropriate.  But, with all of the definitions sections in
> Standards-Track documents that one could look at, why do you
> believe that the entries here should be structured to conform to
> an Informational document that was not even processed through
> the IETF stream?
I believe so because this will make seeking the definition easier.  I 
was trying to find the definition of "coded character set" (as I 
remember) in your document, and bumped into a dozen of occasions of this 
term in the text.  Having "$ term" is better for such purposes.

.Mykyta Yevstifeyev
>      john
>
>


From masinter@adobe.com  Sun May 22 16:50:05 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC0E06D9; Sun, 22 May 2011 16:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level: 
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LixLbTdxctJC; Sun, 22 May 2011 16:50:03 -0700 (PDT)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA02E06A6; Sun, 22 May 2011 16:50:01 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTdmhKX7Z5E79uLdCd/wu83IxsxJjQaqK@postini.com; Sun, 22 May 2011 16:50:02 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p4MNMLFu012813; Sun, 22 May 2011 16:22:21 -0700 (PDT)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p4MNMGqK008238; Sun, 22 May 2011 16:22:16 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 22 May 2011 16:22:15 -0700
From: Larry Masinter 
To: "eburger@standardstrack.com" , "draft-ietf-speechsc-mrcpv2@tools.ietf.org" , "dburnett@voxeo.com" , "sarvi@cisco.com" , "rjsparks@nostrum.com" , "speechsc@ietf.org" , "apps-review@ietf.org" , "apps-discuss@ietf.org" , "iesg@ietf.org" 
Date: Sun, 22 May 2011 16:22:13 -0700
Thread-Topic: apps-team review of draft-ietf-speechsc-mrcpv2-24
Thread-Index: Acv+H96fCgdiI14BSGyp2vy2TwDXaQatfj3Q
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] apps-team review of draft-ietf-speechsc-mrcpv2-24
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 22 May 2011 23:50:05 -0000

(Sorry for delay in sending this)

I was selected as the Applications Area Review Team reviewer for this draft=
 (for background on apps-review, please see http://www.apps.ietf.org/conten=
t/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you m=
ay receive. Please wait for direction from your document shepherd or AD bef=
ore posting a new version of the draft.

Document: apps-team review of draft-ietf-speechsc-mrcpv2-24
Title: Media Resource Control Protocol Version 2 (MRCPv2)
Reviewer:  Larry Masinter
Review Date: 4/25/2011

IETF Last Call Date: (unknown)
IESG Telechat Date: (unknown)

Summary:  I'm very reluctant to recommend this document for publication as =
an RFC as standards track or even informational.  The document is in need o=
f significant editorial work to make it technically reviewable. The most se=
rious technical problems I noted are in what seem like untestable normative=
 requirements (MUST).

I have a lot of sympathy for the editors of this document. It has been unde=
r development for many years (it is version -24 and version -00 was publish=
ed in 2004, 7 years ago), and I know that many of the difficulties of the d=
ocument come from trying to address hard fought contentious issues.  The do=
cument is over 221 pages long.... nearly impossible for anyone to get their=
 head around.  And given how difficult it must have been to come to agreeme=
nt on many issues, I'm sure there is a great reluctance to engage in a heav=
y massive editing job.

I also understand that the protocol described here is widely implemented wi=
th several interoperable implementations deployed. As a measure of protocol=
 quality, then, implementations should attest to the value of the document.

I confess to have only spent 6-8 hours trying to review the document before=
 giving up, and I really only tried to carefully review the first 20 pages;=
 perhaps the remaining 191 pages are of far superior quality to the first 2=
0 or so I was able to review in detail. However, a scan of the reest isn't =
encouraging.

EDITORIAL

The context and operation of this protocol in the space of other protocols =
is really unclear. The relationship between MRCPv2, MRCP, SPEECHSC, RFC4313=
, VoiceXML, RTSP,  SIP, SDP, SSML, and other protocols and formats cannot b=
e teased out from the introductory material.  The relationship to HTTP vs. =
SIP is really unclear.

The simple requirement that terms be defined on first use, and be given ref=
erences as either normative or informative ... is not met. Many of the refe=
renced items are mysterious or are not defined. "SIP URI", "re-INVITE", "ch=
annel identifier".

Many technical terms are mis-named, e.g., "HTTP" and "HTTPS" are not URI sc=
hemes.

While essential information is missing, there seem to be many instances of =
redundant information, explained slightly differently, and perhaps inconsis=
tently.

While the RFC editor might normally be expected to fix up some of the refer=
ences, I think doing so here would be nearly impossible without significant=
 work from the editors.


NORMATIVE REQUIREMENTS

The document seems to be full of MUST and MAY requirements which do not mak=
e sense, are missing essential context, or are provided with preconditions =
which cannot be readily computed or known.

   The client MAY
   then open a new TCP connection with the server on this port number.

which client, which server, under what circumstances?

                   A recorder MUST provide
                  some endpointing capabilities for suppressing silence
                  at the beginning and end of a recording,

What are "some" endpointing capabilities? Which roles of participants in th=
is protocol are not in conformance with the specification if the recorder's=
 endpointing capabilities are poor? Is this really a normative requirement?

                   and MAY also
                  suppress silence in the middle of a recording.  If
                  such suppression is done, the recorder MUST maintain
                  timing metadata to indicate the actual time stamps of
                  the recorded media.

How does the maintenance of timing metadata manifest itself in any visible =
effect in the protocol?
Examples are called "architectural diagrams".

                 (DTMF Recorder)
                  could also do a semantic interpretation based on
                  semantic tags in the grammar.

Is this a normative requirement? Just a description?

>     MRCPv2 employs a session establishment and management protocol such
>     as SIP in conjunction with SDP.

Is this a "such as" or in fact that SIP and SDP are mandatory and other pro=
tocols are allowed?


>   The client needs a separate MRCPv2 resource control channel to
>   control each media processing resource under the SIP dialog.

The concept of 'channel' isn't clear, where is it defined? What does
it entail?

....

   All servers MUST support TLS.  Servers MAY support TCP without TLS in
   physically secure environments.

Is it really "physically" secure that is the requirement? How does
the server know that it is in a "secure" environment? Are there other
situations where TCP without TLS MAY be supported?
...


SUMMARY


I've really been unable to do an extensive review of the actual protocol, b=
ecause of what I think is a problem with the document quality.  I'm confide=
nt that a careful overview plus removal of redundant or misleading material=
 would make the document shorter and clearer, and that a very careful revie=
w of the language describing normative requirements would improve implement=
ability and interoperability.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
(original review, more details than above but more tentative)

This protocol references RFC 2616. But the convention of references
[HX.Y] to reference sections of RFC 2616 seems problematic.
I will try to review where RFC2616's definitions have been changed
or obsoleted.

The RFC editor will probably fix up the references style and minor
editorial details, but they're annoying.

2.2: I think you mean that the "State-Machine Diagrams" are not
normative but are there for illustrative purposes only? Otherwise why
are they incomplete?

2.3.  URI Schemes:

"HTTP" and "HTTPS" are protocols, not URI schemes. You mean the
"http" and "https" scheme name. I don't understand the MAY
supporting other schemes... either they are allowed or not.
What are the "provided they have addressed any security
considerations" doesn't seem like a reasonable requiest for
conformance.

3.  Architecture
Maybe this belongs earlier? Or in the introduction?
With references to SIP and SDP? Do these requirements appear
in any other document?

SIP URIs needs reference.

   The server, through the SDP exchange, provides the client with an
   unambiguous channel identifier and a TCP port number.

What is a "channel identifier"?


   The client MAY
   then open a new TCP connection with the server on this port number.

This doesn't make too much sense, it's missing some context.
When MAY the client open a new connection?

   Multiple MRCPv2 channels can share a TCP connection between the
   client and the server.

How does this work... aren't they asynchronous?

    All MRCPv2 messages exchanged between the
   client and the server carry the specified channel identifier that the
   server MUST ensure is unambiguous among all MRCPv2 control channels
   that are active on that server.

   The client uses this channel
   identifier to indicate the media processing resource associated with
   that channel.  For information on message framing, see Section 5.

Still not clear what a channel identifier is.

   The session initiation protocol (SIP) also establishes the media
   sessions between the client (or other source/sink of media) and the
   MRCPv2 server using SDP m-lines.  One or more media processing
   resources may share a media session under a SIP session, or each
   media processing resource may have its own media session.

   The following diagram shows the general architecture of a system that
   uses MRCPv2.  To simplify the diagram only a few resources are shown.

How is this a symplification? Is this a "general architecture" or
is it an example diagram?



Figure 1:
Where did RTP come in? Why is the TCP/IP stack even shown?


3.1.  MRCPv2 Media Resource Types

Are these examples? Exhaustive? Normative requirements? Are these
resource types actually named?

"Basic Synthesizer". This is the first mention of "SSML". Is
"full SSML support" actually defined? (Haven't cross-checked
the W3C reference.)

   Recorder
                  A resource capable of recording audio and providing a
                  URI pointer to the recording.

Any other requirements, like access control?

                   A recorder MUST provide
                  some endpointing capabilities for suppressing silence
                  at the beginning and end of a recording,

Doesn't make sense for a "MUST" requirement to be described as "some".

                   and MAY also
                  suppress silence in the middle of a recording.  If
                  such suppression is done, the recorder MUST maintain
                  timing metadata to indicate the actual time stamps of
                  the recorded media.

Unclear why this is a normative requirement at all.


   DTMF Recognizer
                  A recognition resource capable of extracting and
                  interpreting DTMF digits in a media stream and
                  matching them against a supplied digit grammar It
                  could also do a semantic interpretation based on
                  semantic tags in the grammar.

Unclear what "could" means here. Allowed? How would it do this?

   Speech Recognizer
                  A full speech recognition resource that is capable of
                  receiving a media stream containing audio and
                  interpreting it to recognition results.  It also has a
                  natural language semantic interpreter to post-process
                  the recognized data according to the semantic data in
                  the grammar and provide semantic results along with
                  the recognized input.  The recognizer may also support
                  enrolled grammars, where the client can enroll and
                  create new personal grammars for use in future
                  recognition operations.

Is this a normative requirement, a description of a typical Speech
Recognizer, or just an example?

   Speaker Verifier
                  A resource capable of verifying the authenticity of a
                  claimed identity by matching a media stream containing
                  spoken input to a pre-existing voiceprint.  This may
                  also involve matching the caller's voice against more
                  than one voiceprint, also called multi-verification or
                  speaker identification.

Does it matter how this works? Whether it does matching against
voiceprints or something else?

   The MRCPv2 server is a generic SIP server, and is thus addressed by a
   SIP URI.

I think you mean "A" and not "The" MRCPv2 server. What does it mean
"addressed by"? In what context?

4.  MRCPv2 Protocol Basics

   MRCPv2 requires a connection-oriented transport layer protocol such
   as TCP or SCTP to guarantee reliable sequencing and delivery of
   MRCPv2 control messages between the client and the server.  In order
   to meet the requirements for security enumerated in SpeechSC
   Requirements [RFC4313], clients and servers MUST implement TLS as
   well.

RFC 4313 now has  a different name again.
Normative requirements should have references. Need reference for "TLS"?

   One or more connections between the client and the server can
   be shared among different MRCPv2 channels to the server.  The
   individual messages carry the channel identifier to differentiate
   messages on different channels.  MRCPv2 protocol encoding is text
   based with mechanisms to carry embedded binary data.  This allows
   arbitrary data like recognition grammars, recognition results,
   synthesizer speech markup etc. to be carried in MRCPv2 messages.  For
   information on message framing, see Section 5.

Doesn't feel like 'protocol basics' to me.

4.1.  Connecting to the Server
   MRCPv2 employs a session establishment and management protocol such
   as SIP in conjunction with SDP.

Is this really "such as"? Maybe you want to allow for some
extensibility with other possibilities, but really, is that
necessary? Especially since you make reference to SIP-specific
operations and not arbitrary "session establishment" protocols?

I don't understand the overall flow which makes reference to
4.1.

4.2.  Managing Resource Control Channels

    A
   unique channel identifier string identifies these resource control
   channels.  The channel identifier is an unambiguous, opaque string
   followed by an "@", then by a string token specifying the type of
   resource.

So I guess the resource types listed before are exhaustive?

    The server generates the channel identifier and MUST make
   sure it does not clash with the identifier of any other MRCP channel
   currently allocated by that server.

Are they globally unique or just relative to a server? Is it clear
what a "server" is?


  MRCPv2 defines the following
   IANA-registered types of media processing resources.  Additional
   resource types, their associated methods/events and state machines
   may be added as described below in Section 13.

          +---------------+----------------------+--------------+
          | Resource Type | Resource Description | Described in |
          +---------------+----------------------+--------------+
          | speechrecog   | Speech Recognizer    | Section 9    |
          | dtmfrecog     | DTMF Recognizer      | Section 9    |
          | speechsynth   | Speech Synthesizer   | Section 8    |
          | basicsynth    | Basic Synthesizer    | Section 8    |
          | speakverify   | Speaker Verification | Section 11   |
          | recorder      | Speech Recorder      | Section 10   |
          +---------------+----------------------+--------------+

Looks like these *are* exhaustive, describes in a previous section, and
then updated.

                              Resource Types

   The SIP INVITE or re-INVITE transaction and the SDP offer/answer
   exchange it carries contain m-lines describing the resource control
   channel to be allocated.

What's a "m-line"?


   There MUST be one SDP m-line for each
   MRCPv2 resource to be used in the session.

Where must there be an SDP m-line? In what ocntext?

   This m-line MUST have a
   media type field of "application" and a transport type field of
   either "TCP/MRCPv2" or "TCP/TLS/MRCPv2".


Where is the "media type field" ? The "transport type field"?

  (The usage of SCTP with
   MRCPv2 may be addressed in a future specification).

Future specification of what? What does SCTP have to do with anything?

  The port number
   field of the m-line MUST contain the "discard" port of the transport
   protocol (port 9 for TCP) in the SDP offer from the client and MUST
   contain the TCP listen port on the server in the SDP answer.

This confuses me a lot? Why should the port be 9? For what?


  The
   client may then either set up a TCP or TLS connection to that server
   port or share an already established connection to that port.

When MAY the client do this? Are these the only two options? When
is this behavior mandated?


   Since
   MRCPv2 allows multiple sessions to share the same TCP connection,
   multiple m-lines in a single SDP document may share the same port
   field value;

"document"? Where do documents come from?

   MRCPv2 servers MUST NOT assume any relationship between
   resources using the same port other than the sharing of the
   communication channel.

What does it mean to "assume"? How could it assume something that
this "MUST NOT" do? How would you know, even?

   MRCPv2 resources do not use the port or format field of the m-line to
   distinguish themselves from other resources using the same channel.

This discussion of m-lines is just confusing, then.


   The client MUST specify the resource type identifier in the resource
   attribute associated with the control m-line of the SDP offer.  The
   server MUST respond with the full Channel-Identifier (which includes
   the resource type identifier and an unambiguous string) in the
   "channel" attribute associated with the control m-line of the SDP
   answer.  To remain backwards compatible with conventional SDP usage,
   the format field of the m-line MUST have the arbitrarily-selected
   value of "1".

Is the resource type identifier the same in the offer & response, then?
Why is it important to "remain backward compatible with conventional
SDP usage"?  If the value is "1", how is it "arbitrarily-selected"?

   When the client wants to add a media processing resource to the
   session, it issues a SIP re-INVITE transaction.

Is this clear? Is re-INVITE a SIP operation? Or does this just mean
repeating the SIP INVITE.

  The SDP offer/answer

Looks like this uses SIP or SDP in a stylized way.

   The a=3Dsetup attribute, as described in RFC4145 [RFC4145], MUST be
   "active" for the offer from the client and MUST be "passive" for the
   answer from the MRCPv2 server.  The a=3Dconnection attribute MUST have
   a value of "new" on the very first control m-line offer from the
   client to an MRCPv2 server.  Subsequent control m-line offers from
   the client to the MRCP server MAY contain "new" or "existing",
   depending on whether the client wants to set up a new connection or
   share an existing connection, respectively.  If the client specifies
   a value of "new", the server MUST respond with a value of "new".  If
   the client specifies a value of "existing", the server MAY respond
   with a value of "existing" if it prefers to share an existing
   connection or can answer with a value of "new", in which case the
   client MUST initiate a new transport connection.

   When the client wants to de-allocate the resource from this session,
   it issues a SIP re-INVITE transaction with the server.  The SDP MUST
   offer the control m-line with port 0.  The server MUST then answer
   the control m-line with a response of port 0.  This de-allocates the
   associated MRCPv2 identifier and resource.  The server MUST NOT close
   the TCP, SCTP or TLS connection if it is currently being shared among
   multiple MRCP channels.  When all MRCP channels that may be sharing
   the connection are released and/or the associated SIP dialog is
   terminated, the client or server terminates the connection.

   All servers MUST support TLS.  Servers MAY support TCP without TLS in
   physically secure environments.

Is it really "physically" secure that is the requirement? How does
the server know that it is in a "secure" environment?



From mary.ietf.barnes@gmail.com  Mon May 23 11:57:54 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB4E06AB; Mon, 23 May 2011 11:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+Syylq3mkSr; Mon, 23 May 2011 11:57:52 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 897DBE06A5; Mon, 23 May 2011 11:57:51 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5195053vxg.31 for ; Mon, 23 May 2011 11:57:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vl7lqRdBB2D0aBlrzA9jY/Q+EIqimhaJqrbe5qysKDU=; b=OtMi5eqL5SlZPyNHLtY1VKkJM27yG2l+FaXOnTvcw/hCrWnI1gMBRHdvfErXotdffn VQWJ6EA3p7nZOON8+RJp61pYrHUTKpO1fH6uyQnexmGeH+D6MO1UShIO/zEQOfjkogpq rlPu/8REuuA6xDi9eIzl2seezbaU2MyoHhqQM=
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=P2QXOrLoLLrGPRnYIVlQUwKWInSBLjqIyczpIx7XM9L2X6R7VERHxmpQg92yTdeoqc j0GtQhNU6xmDtWpwVuL3Yq2QP6BjKyJZCayuE8RaHIbE3bq78QKDCtsp3mQ1kQJA7Fcr UdzF2Qw/A82YKhfIzSRDEv62RuPPo8a8fd6m0=
MIME-Version: 1.0
Received: by 10.52.110.234 with SMTP id id10mr3962231vdb.303.1306177070779; Mon, 23 May 2011 11:57:50 -0700 (PDT)
Received: by 10.52.160.132 with HTTP; Mon, 23 May 2011 11:57:50 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 23 May 2011 13:57:50 -0500
Message-ID: 
From: Mary Barnes 
To: "Henry S. Thompson" 
Content-Type: multipart/alternative; boundary=bcaec548a2e9514f4104a3f60cc7
Cc: Alan Johnston , apps-discuss@ietf.org, Simon Pietro Romano , Chris Boulton , xcon@ietf.org, Richard Barnes , iesg@ietf.org, Henning Schulzrinne 
Subject: Re: [apps-discuss] apps-team review of draft-ietf-xcon-ccmp-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 May 2011 18:57:54 -0000

--bcaec548a2e9514f4104a3f60cc7
Content-Type: text/plain; charset=ISO-8859-1

Hi Henry,

Thank you for your detailed review.  Responses are inline below [MB].

Regards,
Mary.

On Mon, May 16, 2011 at 4:04 AM, Henry S. Thompson  wrote:

> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-xcon-ccmp-13
>
> Title: Centralized Conferencing Manipulation Protocol
>
> Reviewer: Henry S. Thompson
>
> Review Date: 2011-05-13
>
> Summary: This draft is almost ready for publication as a Proposed
> Standard but has a few issues that should be fixed before publication
>
> Major Issues:
>
> 4.2 Data Management
>
> 1) The approach to detecting competing updates and their consequences
>   specified here seems unnecessarily complex.  Was the alternative of
>   including version numbers in _update_ messages (so that the server
>   could reject any update whose target version had been superseded)
>   considered and rejected?  If so, perhaps a brief explanation of why
>   it was rejected might be helful at this point.
>
[MB]   The alternative was considered, however, with the XCON model, the
server is the only entity that "centralizes" information (in this case, the
available conference objects). A client might not have the very last version
of a conference object, due to the potential for concurrent operations
amongst independent client participants. However, an operation can still
succeed if there is no overlap amongst the data that is manipulated.  Thus,
the server-side mechanism is what guarantees coherence in the data stored.
 We can add some more text around that.  Perhaps, prefacing the paragraph
with a statement about the model. [/MB]

>
> 2) In a related point, the statement at the end of this section that
>   "a client subscribed to . . . notifications . . . will always have
>   the most up-to-date version" is clearly false, in-so-far as it
>   implies that such a client is guaranteed success for any update, as
>   there is clearly a race condition here.
>
[MB] Yes, I can see that it's really not properly stated. The statement is
intending to say that the client will "get" the most up-to-date version with
the next notification - i.e., there is a way to recover in the case that the
update was either on an earlier version or no response received.  [/MB]

>
> 4.3 Data Model Compliance
>
> 1) Again this approach seems unnecessarily complex -- why does the
>   data model have to constrain the initiation of a conference in this
>   way.  why not simply have messages which request new conference or
>   new user IDs?
>
[MB] We do have messages for a new conference and new user IDs. The intent
here, was to eliminate the step of requesting those and thus have multiple
operations as a result of one request.  We can add text around that. [/MB]

>
> 2) I'm also confused by the fact that _elements_ described here as
>   "mandatory" are not required by the schema.  Specifically in 5.1 we
>   will see that the 'confUserID' and 'confObjID' elements, which
>   correspond precisely to XCON-USERID and XCON-URI which are
>   described here as mandatory, appear in message type definitions as
>   minOccurs="0", i.e. as optional.  If they are optional, why is the
>   above gensym complexity needed?  If they are not optional, why
>   doesn't the schema say so?
>
[MB] This is a common practice from what I have seen. This is because the
base request type is being reused, thus the elements are not mandatory for
each operation that uses the request type.  So, the expectation is that it's
mandatory for the protocol for specific operations, but not mandatory in the
schema for all operations.

There may also be confusion in that the mandatory elements being referenced
are those in the *body* of the CCMP messages (the elements as defined in the
data model document) as opposed to the IDs in the *header* of the CCMP
messages defined in this document (confUserID and confObjID).

Perhaps this clarification would help?
OLD:
 Since the XML documents carried in the CCMP need to be compliant with the
XCON data model...
NEW:
 Since the XML documents carried in the body of CCMP requests/responses need
to be compliant with the XCON data model..."

 [/MB]

>
> 3) It is unusual to refer to aspects of a data model with words such
>   as 'element' and 'attribute', which are better reserved for use
>   with respect to _XML serializations_ of data model instances.  Ah,
>   I see by looking at draft-ietf-xcon-common-data-model that the XCON
>   data model is defined as an XML document.  It's undoubtedly too
>   late to do anything about that, but confounding data models and XML
>   serializations is usually considered to be a mistake. . .
>
[MB] Can you characterize in what sense it is a mistake and what problems it
might cause?  Or is it purely a nomenclature  issue that is inaccurate?  I
agree that resolving this concern would impact the data model. [/MB]

>
> 11. XML Schema
>
> An http URI should be provided where this schema document can be found
> on its own, and an update policy for it (or, preferably, _two_ URIs,
> one for exactly this schema document, and one which will be updated if
> this document is revised or superseded).  (Likewise for DataModel.xsd
> and rfc4575.xsd.)
>
[MB] Agreed. [/MB]

>
> 12.5 CCMP Protocol Registry
>
> Why are these registries needed?  No role is specified for them
> anywhere in the body of the document. Registries are not free, and if
> all the information in the registry is also in the published schemas
> it's not at all clear what purpose they will serve.
>
[MB] We define the registries as the protocol is extensible and does require
specification.  The registries also allow a reference to the appropriate
document that defines the normative behavior for the new operations and new
error codes.  This is a standard procedure for RAI area protocols - c.f.,
HELD (RFC 5985), SIP (RFC 3261), Registry for SIP header field parameters
(RFC 3698)...
I will note that we don't typically add a reference in the document that we
are defining the IANA registries.  Is there a particular place you suggest
we add such a reference?
[/MB]

> Minor Issues:
>
> 6.2. Alice gets detailed information about a specific blueprint
>
> The blueprintResponse message is not schema-valid per ccmp.xsd.  On
> lines 32 and 33 of the example read
>                    confirm
>                      
> The problem really lies in DataModel.xsd -- whereas (correctly)
> ccmp.xsd uses xs:token as the base type for enumerated types,
> DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
> and the string value of the above element is "confirm
>                      ", which is not one of the allowed values.  The
> example should be corrected, or, for preference, the schema in
> draft-ietf-xcon-common-data-model should be changed to use xs:token as
> the base type for join-handling-type and all other enumerated types.
>
> [MB]
 Agree that the schema in the data model draft could be improved, by
changing definitions of the enumberated types.  Did you send the authors of
that document this comment?  Or has that been covered by another apps-team
review?

"confirm" is one of the allowed tokens in the 
element (at least in the latest version -- 27 -- of the  data model draft.):


      
        
        
        
      

The "newline" character was introduced for proper formatting of the
document, but we agree that is  not allowed per the definition above
(). So, we should remove the newline. This
change likely needs to be done elsewhere in the document.

[/MB]


A similar problem occurs in the response in 6.3
(floor-request-handling)
[MB] Yep. [/MB]

>
> 6.9 Alice exploits a CCMP server extension
>
> For compatibility with the actual response given, the extension schema
> document should have a target namespace, as follows:
>
>   
>                 targetNamespace="http://example.com/ccmp-extension-schema.xsd
> "
>              xmlns="http://example.com/ccmp-extension-schema.xsd">
>
>     
>
>     
>       
>         
>         
>         
>         
>       
>     
>
>   
>
> Or, better, the example _and_ the schema should be changed to read as
> follows:
>
[MB] Yes, the suggested change below is better. [/MB]

>
>   
>               xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
>           xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"
>           xmlns:example="http://example.com/ccmp-extension">
>                xsi:type="ccmp:ccmp-extended-response-message-type">
>          xcon-userid:Alice@example.com
>          xcon:8977794@example.com
>          retrieve
>
>
>          200
>          success
>          
>             confSummaryRequest
>             
>                  Alice's conference 
>                  active 
>                  true 
>                  audio 
>             
>          
>      
>    
>
>    
>                   targetNamespace="http://example.com/ccmp-extension"
>               xmlns="http://example.com/ccmp-extension">
>
>      
>
>      
>        
>          
>          
>          
>          
>        
>      
>
>    
>
> Otherwise I've checked all the schemas for conformance and the
> examples for schema-validity.
>
> 12.2 XML Schema Registration
>
> Should include pointers to the RFCs which include the text of the
> schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the
> schema docuemnt given in section 11.
>
[MB] Okay. [/MB]

>
> 12.3 Media Type Registration
>
> It seems unlikely that the proposed extension of 'ccmpxml' will see
> much use---4 characters seems to be the practical limit for
> extensions.
>
[MB] How about 'ccmp'?

>
> Nits: One more proofreading pass over the first three sections would
> be a good idea. . .
>
[MB] I'll give it a go, but it appears that it's section 3 that needs some
tidying. [/MB]

>
> ht
> --
>       Henry S. Thompson, School of Informatics, University of Edinburgh
>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
>                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
>                       URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail from me _always_ has a .sig like this -- mail without it is forged
> spam]
>

--bcaec548a2e9514f4104a3f60cc7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Henry,=A0

Thank you for your detailed review. =A0Resp=
onses are inline below [MB].

Regards,
Ma=
ry.

On Mon, May 16, 2011 at 4:04 AM, Henr=
y S. Thompson <ht@inf.ed.ac.uk> wrote:








I have been selected as the Applications Are=
a Review Team reviewer for

this draft (for background on apps-review, please see

http://www.apps.ietf.org/content/applications-area-review=
-team).



Please resolve these comments along with any other Last Call comments

you may receive. Please wait for direction from your document shepherd

or AD before posting a new version of the draft.



Document: draft-ietf-xcon-ccmp-13



Title: Centralized Conferencing Manipulation Protocol



Reviewer: Henry S. Thompson



Review Date: 2011-05-13



Summary: This draft is almost ready for publication as a Proposed

Standard but has a few issues that should be fixed before publication



Major Issues:



4.2 Data Management



1) The approach to detecting competing updates and their consequences

 =A0 specified here seems unnecessarily complex. =A0Was the alternative of<=
br>
 =A0 including version numbers in _update_ messages (so that the server

 =A0 could reject any update whose target version had been superseded)

 =A0 considered and rejected? =A0If so, perhaps a brief explanation of why<=
br>
 =A0 it was rejected might be helful at this point.
[M=
B] =A0=A0The alternative was c=
onsidered, however, with the XCON model, the server is the only entity that=
 "centralizes" information (in this case, the available conferenc=
e objects). A client might not have the very last version of a conference o=
bject, due to the potential for concurrent operations amongst independent c=
lient participants. However, an operation can still succeed if there is no =
overlap amongst the data that is manipulated. =A0Thus, the server-side mech=
anism is what guarantees coherence in the data stored. =A0We can add some m=
ore text around that. =A0Perhaps, prefacing the paragraph with a statement =
about the model. [/MB]





2) In a related point, the statement at the end of this section that

 =A0 "a client subscribed to . . . notifications . . . will always hav=
e

 =A0 the most up-to-date version" is clearly false, in-so-far as it
 =A0 implies that such a client is guaranteed success for any update, as
 =A0 there is clearly a race condition here.
[MB] Yes,=
 I can see that it's really not properly stated. The statement is inten=
ding to say that the client will "get" the most up-to-date versio=
n with the next notification - i.e., there is a way to recover in the case =
that the update was either on an earlier version or no response received. =
=A0[/MB]=A0











4.3 Data Model Compliance



1) Again this approach seems unnecessarily complex -- why does the

 =A0 data model have to constrain the initiation of a conference in this
 =A0 way. =A0why not simply have messages which request new conference or
 =A0 new user IDs?
[MB] We do have messages for a new =
conference and new user IDs. The intent here, was to eliminate the step of =
requesting those and thus have multiple operations as a result of one reque=
st. =A0We can add text around that. [/MB]=A0











2) I'm also confused by the fact that _elements_ described here as

 =A0 "mandatory" are not required by the schema. =A0Specifically =
in 5.1 we

 =A0 will see that the 'confUserID' and 'confObjID' element=
s, which

 =A0 correspond precisely to XCON-USERID and XCON-URI which are

 =A0 described here as mandatory, appear in message type definitions as

 =A0 minOccurs=3D"0", i.e. as optional. =A0If they are optional, =
why is the

 =A0 above gensym complexity needed? =A0If they are not optional, why

 =A0 doesn't the schema say so?
[MB] This is a com=
mon practice from what I have seen. This is because the base request type i=
s being reused, thus the elements are not mandatory for each operation that=
 uses the request type. =A0So, the expectation is that it's mandatory f=
or the protocol for specific operations, but not mandatory in the schema fo=
r all operations. =A0=A0



There may also be confusion in that the mandatory eleme=
nts being referenced are those in the *body* of the CCMP messages (the elem=
ents as defined in the data model document) as opposed to the IDs in the *h=
eader* of the CCMP messages defined in this document (confUserID and confObjID). =A0



Perhaps this clarification would help?=A0
OLD:
=A0Since the XML documents carried in the=
 CCMP need to be compliant with the XCON data model...

NEW:
=A0Since=
 the XML documents carried in the body of CCMP requests/responses need to b=
e compliant with the XCON data model..."



=A0[/MB]=A0










3) It is unusual to refer to aspects of a data model with words such

 =A0 as 'element' and 'attribute', which are better reserve=
d for use

 =A0 with respect to _XML serializations_ of data model instances. =A0Ah,
 =A0 I see by looking at draft-ietf-xcon-common-data-model that the XCON
 =A0 data model is defined as an XML document. =A0It's undoubtedly too<=
br>
 =A0 late to do anything about that, but confounding data models and XML
 =A0 serializations is usually considered to be a mistake. . .
[MB] Can you characterize in what sense it is a mistake and what p=
roblems it might cause? =A0Or is it purely a nomenclature =A0issue that is =
inaccurate? =A0I agree that resolving this concern would impact the data mo=
del. [/MB]











11. XML Schema



An http URI should be provided where this schema document can be found

on its own, and an update policy for it (or, preferably, _two_ URIs,

one for exactly this schema document, and one which will be updated if

this document is revised or superseded). =A0(Likewise for DataModel.xsd

and rfc4575.xsd.)
[MB] Agreed. [/MB]=A0



12.5 CCMP Protocol Registry



Why are these registries needed? =A0No role is specified for them

anywhere in the body of the document. Registries are not free, and if

all the information in the registry is also in the published schemas

it's not at all clear what purpose they will serve.
[MB] We define the registries as the protocol is extensible and does requ=
ire specification. =A0The registries also allow a reference to the appropri=
ate document that defines the normative behavior for the new operations and=
 new error codes. =A0This is a standard procedure for RAI area protocols - =
c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP header field parame=
ters (RFC 3698)...








I will note that we don't typically add a reference in the documen=
t that we are defining the IANA registries. =A0Is there a particular place =
you suggest we add such a reference?=A0
[/MB]








Minor Issues:



6.2. Alice gets detailed information about a specific blueprint



The blueprintResponse message is not schema-valid per ccmp.xsd. =A0On

lines 32 and 33 of the example read

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xcon:floor-request-handling>=
confirm

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</xcon:floor-request-handlin=
g>

The problem really lies in DataModel.xsd -- whereas (correctly)

ccmp.xsd uses xs:token as the base type for enumerated types,

DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,

and the string value of the above element is "confirm

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0", which is not one of the=
 allowed values. =A0The

example should be corrected, or, for preference, the schema in

draft-ietf-xcon-common-data-model should be changed to use xs:token as

the base type for join-handling-type and all other enumerated types.
[MB]=A0
=A0Agree that the schema in the data model draft could be improved, =
by changing definitions of the enumberated types. =A0Did you send the autho=
rs of that document this comment? =A0Or has that been covered by another ap=
ps-team review? =A0



"confirm" is one of the=
 allowed tokens in the <xcon:floor-request-handling> element (at leas=
t in the latest version -- 27 -- of the =A0data model draft.):


<xs:simpleType name=3D"floor=
-request-handling-type">
      <xs:restriction base=3D"xs:string">
        <xs:pattern value=3D"block"/>
        <xs:pattern value=3D"confirm"/>
        <xs:pattern value=3D".+"/>
      </xs:restriction>
</xs:simpleType>

The =
"newline" character was introduced for proper formatting of the d=
ocument, but we agree that is  not allowed per the definition above (<xs=
:pattern value=3D".+"/>). So, we should remove the newline. Th=
is change likely needs to be done elsewhere in the document.=20

[/MB]=A0




A similar problem o=
ccurs in the response in 6.3
(floor-request-handling)
<=
span class=3D"Apple-style-span" style=3D"border-collapse: separate; font-fa=
mily: arial; font-size: small; ">[MB] Yep. [/MB]





6.9 Alice exploits a CCMP server extension



For compatibility with the actual response given, the extension schema

document should have a target namespace, as follows:



 =A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
 =A0 <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0targetNamespace=3D"http://example.com/ccmp=
-extension-schema.xsd"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"http://example.com/ccmp-extension=
-schema.xsd">



 =A0 =A0 <xs:element name=3D"confSummary" type=3D"conf-su=
mmary-type"/>



 =A0 =A0 <xs:complexType name=3D"conf-summary-type">

 =A0 =A0 =A0 <xs:sequence>

 =A0 =A0 =A0 =A0 <xs:element name=3D"title" type=3D"xs:st=
ring"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"status" type=3D"xs:s=
tring"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"public" type=3D"xs:b=
oolean"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"media" type=3D"xs:st=
ring"/>

 =A0 =A0 =A0 </xs:sequence>

 =A0 =A0 </xs:complexType>



 =A0 </xs:schema>



Or, better, the example _and_ the schema should be changed to read as

follows:
[MB] Yes, the suggested change below is bette=
r. [/MB]=A0



 =A0 <?xml version=3D"1.0" encoding=3D"UTF-8" standa=
lone=3D"yes"?>

 =A0 =A0<ccmp:ccmpResponse xmlns:info=3D"urn:ietf:params:xml:ns:con=
ference-info"

 =A0 =A0 =A0 =A0 =A0 xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp&qu=
ot;

 =A0 =A0 =A0 =A0 =A0 xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-confere=
nce-info"

 =A0 =A0 =A0 =A0 =A0 xmlns:example=3D"http://example.com/ccmp-extension"=
>

 =A0 =A0 =A0<ccmpResponse xmlns:xsi=3D"http://www.w3.org/2001/XMLSchem=
a-instance"

 =A0 =A0 =A0 =A0 =A0xsi:type=3D"ccmp:ccmp-extended-response-message-ty=
pe">

 =A0 =A0 =A0 =A0 =A0<confUserID>xcon-userid:Alice@example.com</confU=
serID>

 =A0 =A0 =A0 =A0 =A0<confObjID>xcon:8977794@example.com</confObjID>
 =A0 =A0 =A0 =A0 =A0<operation>retrieve</operation>





 =A0 =A0 =A0 =A0 =A0<response-code>200</response-code>

 =A0 =A0 =A0 =A0 =A0<response-string>success</response-string><=
br>
 =A0 =A0 =A0 =A0 =A0<ccmp:extendedResponse>

 =A0 =A0 =A0 =A0 =A0 =A0 <extensionName>confSummaryRequest</extens=
ionName>

 =A0 =A0 =A0 =A0 =A0 =A0 <example:confSummary>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <title> Alice's conference </=
title>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <status> active </status>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <public> true </public>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <media> audio </media>

 =A0 =A0 =A0 =A0 =A0 =A0 </example:confSummary>

 =A0 =A0 =A0 =A0 =A0</ccmp:extendedResponse>

 =A0 =A0 =A0</ccmpResponse>

 =A0 =A0</ccmp:ccmpResponse>



 =A0 =A0<?xml version=3D"1.0" encoding=3D"UTF-8"?>=
;

 =A0 =A0<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 targetNamespace=3D"http://example.com/ccmp-extension=
"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xmlns=3D"http://example.com/ccmp-extension"=
>



 =A0 =A0 =A0<xs:element name=3D"confSummary" type=3D"conf=
-summary-type"/>



 =A0 =A0 =A0<xs:complexType name=3D"conf-summary-type">

 =A0 =A0 =A0 =A0<xs:sequence>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"title" type=3D"xs=
:string"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"status" type=3D"x=
s:string"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"public" type=3D"x=
s:boolean"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"media" type=3D"xs=
:string"/>

 =A0 =A0 =A0 =A0</xs:sequence>

 =A0 =A0 =A0</xs:complexType>



 =A0 =A0</xs:schema>



Otherwise I've checked all the schemas for conformance and the

examples for schema-validity.



12.2 XML Schema Registration



Should include pointers to the RFCs which include the text of the

schema documents named as "DataModel.xsd" and "rfc4575.xsd&q=
uot; in the

schema docuemnt given in section 11.
[MB] Okay. [/MB]=
=A0



12.3 Media Type Registration



It seems unlikely that the proposed extension of 'ccmpxml' will see=


much use---4 characters seems to be the practical limit for

extensions.
[MB] How about 'ccmp'? =A0



Nits: One more proofreading pass over the first three sections would

be a good idea. . .
[MB] I'll give it a go, but it=
 appears that it's section 3 that needs some tidying. [/MB]=A0




ht

--

 =A0 =A0 =A0 Henry S. Thompson, School of Informatics, University of Edinbu=
rgh

 =A0 =A0 =A010 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650=
-4440

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: http://www.ltg.ed.ac.uk/~ht/

=A0[mail from me _always_ has a .sig like this -- mail without it is forged=
 spam]





--bcaec548a2e9514f4104a3f60cc7--

From mary.ietf.barnes@gmail.com  Mon May 23 11:59:28 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D652DE06D1; Mon, 23 May 2011 11:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.369
X-Spam-Level: 
X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjNAxPAWpBWu; Mon, 23 May 2011 11:59:27 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF0E06AB; Mon, 23 May 2011 11:59:26 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5196316vxg.31 for ; Mon, 23 May 2011 11:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8CnjjX8xsrxwUJ871/ag5b79cO1bkpe0czS6d+sndN8=; b=QGa+pr4hiTeXsBCoo4n+ScBsViwtRPbBjgXhHE4BmuG+jZFeR2hVFEkAIEFx24hS06 IchX7p+A6gnpP0Pludq9aDe4ew9lTv1HoMC/vkHK8o643PskGKWsovj1M4Odldb/dp00 Gnp8Z86Xai/Um6y7ZEqSUE7SGNU1MhNsLUoxc=
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=DX8ENW8BvePIWbgGO3B4WC+kAj8TNzT/V60/N1k+QyWJ3beTOsz/0b/2k7vQu3/alx fHwNo+5+p5pXWnKQ4Bug4xLc8+3IGMK3Tzwaz26RIkzK1iyE3X7VmSK6HSmE+lU3boa4 TFFRIVVul/Ijhix9ji7EYK8k/MZH2hMVm8PI8=
MIME-Version: 1.0
Received: by 10.52.97.10 with SMTP id dw10mr276529vdb.23.1306177165912; Mon, 23 May 2011 11:59:25 -0700 (PDT)
Received: by 10.52.160.132 with HTTP; Mon, 23 May 2011 11:59:25 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 23 May 2011 13:59:25 -0500
Message-ID: 
From: Mary Barnes 
To: "Henry S. Thompson" 
Content-Type: multipart/alternative; boundary=20cf307d01eefceb6c04a3f6119f
Cc: Alan Johnston , apps-discuss@ietf.org, Richard Barnes , Simon Pietro Romano , Chris Boulton , xcon@ietf.org, iesg@ietf.org, Henning Schulzrinne 
Subject: Re: [apps-discuss] apps-team review of draft-ietf-xcon-ccmp-13
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 May 2011 18:59:29 -0000

--20cf307d01eefceb6c04a3f6119f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm resending as Richard Barnes (XCON WG co-chair) email was incorrect and =
I
want to make sure he's included in any follow-up.

On Mon, May 23, 2011 at 1:57 PM, Mary Barnes wr=
ote:

> Hi Henry,
>
> Thank you for your detailed review.  Responses are inline below [MB].
>
> Regards,
> Mary.
>
> On Mon, May 16, 2011 at 4:04 AM, Henry S. Thompson wrote=
:
>
>> I have been selected as the Applications Area Review Team reviewer for
>> this draft (for background on apps-review, please see
>> http://www.apps.ietf.org/content/applications-area-review-team).
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive. Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>> Document: draft-ietf-xcon-ccmp-13
>>
>> Title: Centralized Conferencing Manipulation Protocol
>>
>> Reviewer: Henry S. Thompson
>>
>> Review Date: 2011-05-13
>>
>> Summary: This draft is almost ready for publication as a Proposed
>> Standard but has a few issues that should be fixed before publication
>>
>> Major Issues:
>>
>> 4.2 Data Management
>>
>> 1) The approach to detecting competing updates and their consequences
>>   specified here seems unnecessarily complex.  Was the alternative of
>>   including version numbers in _update_ messages (so that the server
>>   could reject any update whose target version had been superseded)
>>   considered and rejected?  If so, perhaps a brief explanation of why
>>   it was rejected might be helful at this point.
>>
> [MB]   The alternative was considered, however, with the XCON model, the
> server is the only entity that "centralizes" information (in this case, t=
he
> available conference objects). A client might not have the very last vers=
ion
> of a conference object, due to the potential for concurrent operations
> amongst independent client participants. However, an operation can still
> succeed if there is no overlap amongst the data that is manipulated.  Thu=
s,
> the server-side mechanism is what guarantees coherence in the data stored=
.
>  We can add some more text around that.  Perhaps, prefacing the paragraph
> with a statement about the model. [/MB]
>
>>
>> 2) In a related point, the statement at the end of this section that
>>   "a client subscribed to . . . notifications . . . will always have
>>   the most up-to-date version" is clearly false, in-so-far as it
>>   implies that such a client is guaranteed success for any update, as
>>   there is clearly a race condition here.
>>
> [MB] Yes, I can see that it's really not properly stated. The statement i=
s
> intending to say that the client will "get" the most up-to-date version w=
ith
> the next notification - i.e., there is a way to recover in the case that =
the
> update was either on an earlier version or no response received.  [/MB]
>
>>
>> 4.3 Data Model Compliance
>>
>> 1) Again this approach seems unnecessarily complex -- why does the
>>   data model have to constrain the initiation of a conference in this
>>   way.  why not simply have messages which request new conference or
>>   new user IDs?
>>
> [MB] We do have messages for a new conference and new user IDs. The inten=
t
> here, was to eliminate the step of requesting those and thus have multipl=
e
> operations as a result of one request.  We can add text around that. [/MB=
]
>
>>
>> 2) I'm also confused by the fact that _elements_ described here as
>>   "mandatory" are not required by the schema.  Specifically in 5.1 we
>>   will see that the 'confUserID' and 'confObjID' elements, which
>>   correspond precisely to XCON-USERID and XCON-URI which are
>>   described here as mandatory, appear in message type definitions as
>>   minOccurs=3D"0", i.e. as optional.  If they are optional, why is the
>>   above gensym complexity needed?  If they are not optional, why
>>   doesn't the schema say so?
>>
> [MB] This is a common practice from what I have seen. This is because the
> base request type is being reused, thus the elements are not mandatory fo=
r
> each operation that uses the request type.  So, the expectation is that i=
t's
> mandatory for the protocol for specific operations, but not mandatory in =
the
> schema for all operations.
>
> There may also be confusion in that the mandatory elements being referenc=
ed
> are those in the *body* of the CCMP messages (the elements as defined in =
the
> data model document) as opposed to the IDs in the *header* of the CCMP
> messages defined in this document (confUserID and confObjID).
>
> Perhaps this clarification would help?
> OLD:
>  Since the XML documents carried in the CCMP need to be compliant with th=
e
> XCON data model...
> NEW:
>  Since the XML documents carried in the body of CCMP requests/responses
> need to be compliant with the XCON data model..."
>
>  [/MB]
>
>>
>> 3) It is unusual to refer to aspects of a data model with words such
>>   as 'element' and 'attribute', which are better reserved for use
>>   with respect to _XML serializations_ of data model instances.  Ah,
>>   I see by looking at draft-ietf-xcon-common-data-model that the XCON
>>   data model is defined as an XML document.  It's undoubtedly too
>>   late to do anything about that, but confounding data models and XML
>>   serializations is usually considered to be a mistake. . .
>>
> [MB] Can you characterize in what sense it is a mistake and what problems
> it might cause?  Or is it purely a nomenclature  issue that is inaccurate=
?
>  I agree that resolving this concern would impact the data model. [/MB]
>
>>
>> 11. XML Schema
>>
>> An http URI should be provided where this schema document can be found
>> on its own, and an update policy for it (or, preferably, _two_ URIs,
>> one for exactly this schema document, and one which will be updated if
>> this document is revised or superseded).  (Likewise for DataModel.xsd
>> and rfc4575.xsd.)
>>
> [MB] Agreed. [/MB]
>
>>
>> 12.5 CCMP Protocol Registry
>>
>> Why are these registries needed?  No role is specified for them
>> anywhere in the body of the document. Registries are not free, and if
>> all the information in the registry is also in the published schemas
>> it's not at all clear what purpose they will serve.
>>
> [MB] We define the registries as the protocol is extensible and does
> require specification.  The registries also allow a reference to the
> appropriate document that defines the normative behavior for the new
> operations and new error codes.  This is a standard procedure for RAI are=
a
> protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for SIP heade=
r
> field parameters (RFC 3698)...
> I will note that we don't typically add a reference in the document that =
we
> are defining the IANA registries.  Is there a particular place you sugges=
t
> we add such a reference?
> [/MB]
>
>> Minor Issues:
>>
>>
>> 6.2. Alice gets detailed information about a specific blueprint
>>
>> The blueprintResponse message is not schema-valid per ccmp.xsd.  On
>> lines 32 and 33 of the example read
>>                    confirm
>>                      
>> The problem really lies in DataModel.xsd -- whereas (correctly)
>> ccmp.xsd uses xs:token as the base type for enumerated types,
>> DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,
>> and the string value of the above element is "confirm
>>                      ", which is not one of the allowed values.  The
>> example should be corrected, or, for preference, the schema in
>> draft-ietf-xcon-common-data-model should be changed to use xs:token as
>> the base type for join-handling-type and all other enumerated types.
>>
>> [MB]
>  Agree that the schema in the data model draft could be improved, by
> changing definitions of the enumberated types.  Did you send the authors =
of
> that document this comment?  Or has that been covered by another apps-tea=
m
> review?
>
> "confirm" is one of the allowed tokens in the 
> element (at least in the latest version -- 27 -- of the  data model draft=
.):
>
> 
>       
>         
>         
>         
>       
> 
>
> The "newline" character was introduced for proper formatting of the docum=
ent, but we agree that is  not allowed per the definition above (). So, we should remove the newline. This change likely nee=
ds to be done elsewhere in the document.
>
> [/MB]
>
>
> A similar problem occurs in the response in 6.3
> (floor-request-handling)
> [MB] Yep. [/MB]
>
>>
>> 6.9 Alice exploits a CCMP server extension
>>
>> For compatibility with the actual response given, the extension schema
>> document should have a target namespace, as follows:
>>
>>   
>>   >              targetNamespace=3D"
>> http://example.com/ccmp-extension-schema.xsd"
>>              xmlns=3D"http://example.com/ccmp-extension-schema.xsd">
>>
>>     
>>
>>     
>>       
>>         
>>         
>>         
>>         
>>       
>>     
>>
>>   
>>
>> Or, better, the example _and_ the schema should be changed to read as
>> follows:
>>
> [MB] Yes, the suggested change below is better. [/MB]
>
>>
>>   
>>    >           xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp"
>>           xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-conference-info"
>>           xmlns:example=3D"http://example.com/ccmp-extension">
>>      >          xsi:type=3D"ccmp:ccmp-extended-response-message-type">
>>          xcon-userid:Alice@example.com
>>          xcon:8977794@example.com
>>          retrieve
>>
>>
>>          200
>>          success
>>          
>>             confSummaryRequest
>>             
>>                  Alice's conference 
>>                  active 
>>                  true 
>>                  audio 
>>             
>>          
>>      
>>    
>>
>>    
>>    >               targetNamespace=3D"http://example.com/ccmp-extension"
>>               xmlns=3D"http://example.com/ccmp-extension">
>>
>>      
>>
>>      
>>        
>>          
>>          
>>          
>>          
>>        
>>      
>>
>>    
>>
>> Otherwise I've checked all the schemas for conformance and the
>> examples for schema-validity.
>>
>> 12.2 XML Schema Registration
>>
>> Should include pointers to the RFCs which include the text of the
>> schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the
>> schema docuemnt given in section 11.
>>
> [MB] Okay. [/MB]
>
>>
>> 12.3 Media Type Registration
>>
>> It seems unlikely that the proposed extension of 'ccmpxml' will see
>> much use---4 characters seems to be the practical limit for
>> extensions.
>>
> [MB] How about 'ccmp'?
>
>>
>> Nits: One more proofreading pass over the first three sections would
>> be a good idea. . .
>>
> [MB] I'll give it a go, but it appears that it's section 3 that needs som=
e
> tidying. [/MB]
>
>>
>> ht
>> --
>>       Henry S. Thompson, School of Informatics, University of Edinburgh
>>      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444=
0
>>                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
>>                       URL: http://www.ltg.ed.ac.uk/~ht/
>>  [mail from me _always_ has a .sig like this -- mail without it is forge=
d
>> spam]
>>
>
>

--20cf307d01eefceb6c04a3f6119f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm resending as Richard Barnes (XCON WG co-chair) email was incorrect =
and I want to make sure he's included in any follow-up.

On Mon, May 23, 2011 at 1:57 PM, Mary Barnes <mary.ietf.barnes=
@gmail.com> wrote:


Hi Henry,=A0

Thank you for your detailed review. =A0Responses are inline below [M=
B].



Regards,
Mary.

On Mon, May 16, 2011 at 4:04 AM, Henry S. Thomp=
son <ht@inf.ed.ac.uk> wrote:









I have been selected as the Applications Are=
a Review Team reviewer for

this draft (for background on apps-review, please see

http://www.apps.ietf.org/content/applications-area-review=
-team).



Please resolve these comments along with any other Last Call comments

you may receive. Please wait for direction from your document shepherd

or AD before posting a new version of the draft.



Document: draft-ietf-xcon-ccmp-13



Title: Centralized Conferencing Manipulation Protocol



Reviewer: Henry S. Thompson



Review Date: 2011-05-13



Summary: This draft is almost ready for publication as a Proposed

Standard but has a few issues that should be fixed before publication



Major Issues:



4.2 Data Management



1) The approach to detecting competing updates and their consequences

 =A0 specified here seems unnecessarily complex. =A0Was the alternative of<=
br>
 =A0 including version numbers in _update_ messages (so that the server

 =A0 could reject any update whose target version had been superseded)

 =A0 considered and rejected? =A0If so, perhaps a brief explanation of why<=
br>
 =A0 it was rejected might be helful at this point.
<=
div>[MB] =A0=A0The alternative was considered, however, with the=
 XCON model, the server is the only entity that "centralizes" inf=
ormation (in this case, the available conference objects). A client might n=
ot have the very last version of a conference object, due to the potential =
for concurrent operations amongst independent client participants. However,=
 an operation can still succeed if there is no overlap amongst the data tha=
t is manipulated. =A0Thus, the server-side mechanism is what guarantees coh=
erence in the data stored. =A0We can add some more text around that. =A0Per=
haps, prefacing the paragraph with a statement about the model. [/MB]







2) In a related point, the statement at the end of this section that

 =A0 "a client subscribed to . . . notifications . . . will always hav=
e

 =A0 the most up-to-date version" is clearly false, in-so-far as it
 =A0 implies that such a client is guaranteed success for any update, as
 =A0 there is clearly a race condition here.
[MB] Yes, I can see that it's really not properly stated=
. The statement is intending to say that the client will "get" th=
e most up-to-date version with the next notification - i.e., there is a way=
 to recover in the case that the update was either on an earlier version or=
 no response received. =A0[/MB]=A0












4.3 Data Model Compliance



1) Again this approach seems unnecessarily complex -- why does the

 =A0 data model have to constrain the initiation of a conference in this
 =A0 way. =A0why not simply have messages which request new conference or
 =A0 new user IDs?
[MB] We do =
have messages for a new conference and new user IDs. The intent here, was t=
o eliminate the step of requesting those and thus have multiple operations =
as a result of one request. =A0We can add text around that. [/MB]=A0












2) I'm also confused by the fact that _elements_ described here as

 =A0 "mandatory" are not required by the schema. =A0Specifically =
in 5.1 we

 =A0 will see that the 'confUserID' and 'confObjID' element=
s, which

 =A0 correspond precisely to XCON-USERID and XCON-URI which are

 =A0 described here as mandatory, appear in message type definitions as

 =A0 minOccurs=3D"0", i.e. as optional. =A0If they are optional, =
why is the

 =A0 above gensym complexity needed? =A0If they are not optional, why

 =A0 doesn't the schema say so?
[MB] This is a common practice from what I have seen. This is because=
 the base request type is being reused, thus the elements are not mandatory=
 for each operation that uses the request type. =A0So, the expectation is t=
hat it's mandatory for the protocol for specific operations, but not ma=
ndatory in the schema for all operations. =A0=A0




There may also be confusion in that the mandatory=
 elements being referenced are those in the *body* of the CCMP messages (th=
e elements as defined in the data model document) as opposed to the IDs in =
the *header* of the CCMP messages defined in this document (conf=
UserID and confObjID). =A0




Perhaps this clarification would help?=A0
OLD:

=A0Since the XML documents carried in the CCMP need to be compliant with th=
e XCON data model...

NEW:
=A0Since the XML documen=
ts carried in the body of CCMP requests/responses need to be compliant with=
 the XCON data model..."




=A0[/MB]=A0










3) It is unusual to refer to aspects of a data model with words such

 =A0 as 'element' and 'attribute', which are better reserve=
d for use

 =A0 with respect to _XML serializations_ of data model instances. =A0Ah,
 =A0 I see by looking at draft-ietf-xcon-common-data-model that the XCON
 =A0 data model is defined as an XML document. =A0It's undoubtedly too<=
br>
 =A0 late to do anything about that, but confounding data models and XML
 =A0 serializations is usually considered to be a mistake. . .
[MB] Can you characterize in what sense it is a mistake and =
what problems it might cause? =A0Or is it purely a nomenclature =A0issue th=
at is inaccurate? =A0I agree that resolving this concern would impact the d=
ata model. [/MB]













11. XML Schema



An http URI should be provided where this schema document can be found

on its own, and an update policy for it (or, preferably, _two_ URIs,

one for exactly this schema document, and one which will be updated if

this document is revised or superseded). =A0(Likewise for DataModel.xsd

and rfc4575.xsd.)
[MB] Agreed. [/MB]=A0



12.5 CCMP Protocol Registry



Why are these registries needed? =A0No role is specified for them

anywhere in the body of the document. Registries are not free, and if

all the information in the registry is also in the published schemas

it's not at all clear what purpose they will serve.
[MB] We define the registries as the protocol is =
extensible and does require specification. =A0The registries also allow a r=
eference to the appropriate document that defines the normative behavior fo=
r the new operations and new error codes. =A0This is a standard procedure f=
or RAI area protocols - c.f., HELD (RFC 5985), SIP (RFC 3261), Registry for=
 SIP header field parameters (RFC 3698)...









I will note that we don't typically add a reference in the documen=
t that we are defining the IANA registries. =A0Is there a particular place =
you suggest we add such a reference?=A0
[/MB]









Minor Issues:




6.2. Alice gets detailed information about a specific blueprint



The blueprintResponse message is not schema-valid per ccmp.xsd. =A0On

lines 32 and 33 of the example read

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xcon:floor-request-handling>=
confirm

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</xcon:floor-request-handlin=
g>

The problem really lies in DataModel.xsd -- whereas (correctly)

ccmp.xsd uses xs:token as the base type for enumerated types,

DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string,

and the string value of the above element is "confirm

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0", which is not one of the=
 allowed values. =A0The

example should be corrected, or, for preference, the schema in

draft-ietf-xcon-common-data-model should be changed to use xs:token as

the base type for join-handling-type and all other enumerated types.
[MB]=A0
=A0Agree that the sch=
ema in the data model draft could be improved, by changing definitions of t=
he enumberated types. =A0Did you send the authors of that document this com=
ment? =A0Or has that been covered by another apps-team review? =A0



"confirm" is one=
 of the allowed tokens in the <xcon:floor-request-handling> element (=
at least in the latest version -- 27 -- of the =A0data model draft.):



<xs:simpleType nam=
e=3D"floor-request-handling-type">
      <xs:restriction base=3D"xs:string">
        <xs:pattern value=3D"block"/>
        <xs:pattern value=3D"confirm"/>
        <xs:pattern value=3D".+"/>
      </xs:restriction>
</xs:simpleType>


The "newline" c=
haracter was introduced for proper formatting of the document, but we agree=
 that is  not allowed per the definition above (<xs:pattern value=3D&quo=
t;.+"/>). So, we should remove the newline. This change likely need=
s to be done elsewhere in the document.=20

[/MB]=A0





A similar problem occurs in the response in 6.3
(f=
loor-request-handling)
[MB] Yep. [/MB]






6.9 Alice exploits a CCMP server extension



For compatibility with the actual response given, the extension schema

document should have a target namespace, as follows:



 =A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
 =A0 <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0targetNamespace=3D"http://example.com/ccmp=
-extension-schema.xsd"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0xmlns=3D"http://example.com/ccmp-extension=
-schema.xsd">



 =A0 =A0 <xs:element name=3D"confSummary" type=3D"conf-su=
mmary-type"/>



 =A0 =A0 <xs:complexType name=3D"conf-summary-type">

 =A0 =A0 =A0 <xs:sequence>

 =A0 =A0 =A0 =A0 <xs:element name=3D"title" type=3D"xs:st=
ring"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"status" type=3D"xs:s=
tring"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"public" type=3D"xs:b=
oolean"/>

 =A0 =A0 =A0 =A0 <xs:element name=3D"media" type=3D"xs:st=
ring"/>

 =A0 =A0 =A0 </xs:sequence>

 =A0 =A0 </xs:complexType>



 =A0 </xs:schema>



Or, better, the example _and_ the schema should be changed to read as

follows:
[MB] Yes, the suggested change below is=
 better. [/MB]=A0




 =A0 <?xml version=3D"1.0" encoding=3D"UTF-8" standa=
lone=3D"yes"?>

 =A0 =A0<ccmp:ccmpResponse xmlns:info=3D"urn:ietf:params:xml:ns:con=
ference-info"

 =A0 =A0 =A0 =A0 =A0 xmlns:ccmp=3D"urn:ietf:params:xml:ns:xcon:ccmp&qu=
ot;

 =A0 =A0 =A0 =A0 =A0 xmlns:xcon=3D"urn:ietf:params:xml:ns:xcon-confere=
nce-info"

 =A0 =A0 =A0 =A0 =A0 xmlns:example=3D"http://example.com/ccmp-extension"=
>

 =A0 =A0 =A0<ccmpResponse xmlns:xsi=3D"http://www.w3.org/2001/XMLSchem=
a-instance"

 =A0 =A0 =A0 =A0 =A0xsi:type=3D"ccmp:ccmp-extended-response-message-ty=
pe">

 =A0 =A0 =A0 =A0 =A0<confUserID>xcon-userid:Alice@example.com</confU=
serID>

 =A0 =A0 =A0 =A0 =A0<confObjID>xcon:8977794@example.com</confObjID>
 =A0 =A0 =A0 =A0 =A0<operation>retrieve</operation>





 =A0 =A0 =A0 =A0 =A0<response-code>200</response-code>

 =A0 =A0 =A0 =A0 =A0<response-string>success</response-string><=
br>
 =A0 =A0 =A0 =A0 =A0<ccmp:extendedResponse>

 =A0 =A0 =A0 =A0 =A0 =A0 <extensionName>confSummaryRequest</extens=
ionName>

 =A0 =A0 =A0 =A0 =A0 =A0 <example:confSummary>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <title> Alice's conference </=
title>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <status> active </status>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <public> true </public>

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <media> audio </media>

 =A0 =A0 =A0 =A0 =A0 =A0 </example:confSummary>

 =A0 =A0 =A0 =A0 =A0</ccmp:extendedResponse>

 =A0 =A0 =A0</ccmpResponse>

 =A0 =A0</ccmp:ccmpResponse>



 =A0 =A0<?xml version=3D"1.0" encoding=3D"UTF-8"?>=
;

 =A0 =A0<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 targetNamespace=3D"http://example.com/ccmp-extension=
"

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xmlns=3D"http://example.com/ccmp-extension"=
>



 =A0 =A0 =A0<xs:element name=3D"confSummary" type=3D"conf=
-summary-type"/>



 =A0 =A0 =A0<xs:complexType name=3D"conf-summary-type">

 =A0 =A0 =A0 =A0<xs:sequence>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"title" type=3D"xs=
:string"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"status" type=3D"x=
s:string"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"public" type=3D"x=
s:boolean"/>

 =A0 =A0 =A0 =A0 =A0<xs:element name=3D"media" type=3D"xs=
:string"/>

 =A0 =A0 =A0 =A0</xs:sequence>

 =A0 =A0 =A0</xs:complexType>



 =A0 =A0</xs:schema>



Otherwise I've checked all the schemas for conformance and the

examples for schema-validity.



12.2 XML Schema Registration



Should include pointers to the RFCs which include the text of the

schema documents named as "DataModel.xsd" and "rfc4575.xsd&q=
uot; in the

schema docuemnt given in section 11.
[MB] =
Okay. [/MB]=A0



12.3 Media Type Registration



It seems unlikely that the proposed extension of 'ccmpxml' will see=


much use---4 characters seems to be the practical limit for

extensions.
[MB] How about 'ccmp'? =A0



Nits: One more proofreading pass over the first three sections would

be a good idea. . .
[MB] I'll give it a go, =
but it appears that it's section 3 that needs some tidying. [/MB]=A0





ht

--

 =A0 =A0 =A0 Henry S. Thompson, School of Informatics, University of Edinbu=
rgh

 =A0 =A0 =A010 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650=
-4440

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk

 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: http://www.ltg.ed.ac.uk/~ht/

=A0[mail from me _always_ has a .sig like this -- mail without it is forged=
 spam]








--20cf307d01eefceb6c04a3f6119f--

From iesg-secretary@ietf.org  Mon May 23 15:19:04 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74641E0821; Mon, 23 May 2011 15:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdAFU39Dz-yj; Mon, 23 May 2011 15:19:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5374E067B; Mon, 23 May 2011 15:19:03 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.54
Message-ID: <20110523221903.11394.18650.idtracker@ietfa.amsl.com>
Date: Mon, 23 May 2011 15:19:03 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2011 22:19:04 -0000

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'The Unicode code points and IDNA - Unicode 6.0'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document specifies IETF consensus for IDNA derived character
properties related to the three code points, existing in Unicode 5.2,
that changed property values when version 6.0 was released.  The
consensus is that no update is needed to RFC 5892 based on the
changes made in Unicode 6.0.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-faltstrom-5892bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-faltstrom-5892bis/


No IPR declarations have been submitted directly on this I-D.



From stpeter@stpeter.im  Mon May 23 15:26:44 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B22E0818 for ; Mon, 23 May 2011 15:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.615
X-Spam-Level: 
X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leUdhtTDZ2um for ; Mon, 23 May 2011 15:26:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8F076E067B for ; Mon, 23 May 2011 15:26:43 -0700 (PDT)
Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D2CF140046 for ; Mon, 23 May 2011 16:26:42 -0600 (MDT)
Message-ID: <4DDADF21.108@stpeter.im>
Date: Mon, 23 May 2011 16:26:41 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com>
In-Reply-To: <20110523221903.11394.18650.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030700060600000506000508"
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 May 2011 22:26:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms030700060600000506000508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The first paragraph of the Introduction contains a few infelicities and
grammatical errors. I suggest modifying it as follows:

   RFC 5892 [RFC5892] specifies an algorithm that was defined when
   the current version of The Unicode Standard was Unicode 5.2
   [Unicode5.2], and also defines a derived property value based on
   that algorithm.  Unicode 6.0 has changed the GeneralCategory of
   three code points that were allocated in Unicode 5.2 or earlier.
   This implies that the derived property value differs depending on
   whether the property definitions used are from Unicode 5.2 or
   Unicode 6.0.

On 5/23/11 4:19 PM, The IESG wrote:
>=20
> The IESG has received a request from the Applications Area Working Grou=
p
> WG (appsawg) to consider the following document:
> - 'The Unicode code points and IDNA - Unicode 6.0'
>    as a Proposed Standard
>=20
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-06-06. Exceptionally, comments may =
be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>=20
> Abstract
>=20
>=20
> This document specifies IETF consensus for IDNA derived character
> properties related to the three code points, existing in Unicode 5.2,
> that changed property values when version 6.0 was released.  The
> consensus is that no update is needed to RFC 5892 based on the
> changes made in Unicode 6.0.
>=20
>=20
>=20
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-faltstrom-5892bis/
>=20
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-faltstrom-5892bis/
>=20
>=20
> No IPR declarations have been submitted directly on this I-D.
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


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




--------------ms030700060600000506000508
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy
MzIyMjY0MVowIwYJKoZIhvcNAQkEMRYEFM96rXrKHqLtgKYeEcBwO02ia6WxMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQB/Sw7Jv79o2xu8qTi0kdHIyMV1mppu/ey0LpkYs6xyP729pWQojt/YaaoI
e/A0XGWYXv78EcPGywfD5pK1hFqqUSfU/edvmx1Uy6B/L31QYqEkO84vGsXJfsEj8DYjFhsY
VZmixgnFgC2QAwlUUO2jGhvy3pn0rX01J3fCiApRHclm1s0IVck1DJ31FzR73HcTYDsBoYLC
C1CCzVtQZ7b5cEtkOEugOuyVqW9bClwEEVBXwkg+KPSyzKIua126NNebCq5cz8WGpsPt0a9/
he7rqmwTkRgDfAoV/53GW2Yja+j0eawQhuF7OWYPSr9r7uFw2AyStHc8I/Zbh510V7n4AAAA
AAAA
--------------ms030700060600000506000508--

From john-ietf@jck.com  Mon May 23 19:22:21 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00722E068F for ; Mon, 23 May 2011 19:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level: 
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LF5dZGgXjHW for ; Mon, 23 May 2011 19:22:20 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id E050AE0682 for ; Mon, 23 May 2011 19:22:19 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOhG9-000MQB-Pj; Mon, 23 May 2011 22:22:13 -0400
Date: Mon, 23 May 2011 22:22:13 -0400
From: John C Klensin 
To: Peter Saint-Andre , apps-discuss@ietf.org
Message-ID: <1E0BD491A5C0210B48BA7043@PST.JCK.COM>
In-Reply-To: <4DDADF21.108@stpeter.im>
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <4DDADF21.108@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 24 May 2011 02:22:21 -0000

Peter,

Personally, I think it would be a big mistake to spend a lot
more time on this.  It just isn't worth it.  And I continue to
object to the IESG -- or even responsible ADs -- doing
copy-editing.  We pay the highly qualified RFC Editor staff for
doing that and should let them do their jobs.  That said, if
this is worth fussing with...

--On Monday, May 23, 2011 16:26 -0600 Peter Saint-Andre
 wrote:

> The first paragraph of the Introduction contains a few
> infelicities and grammatical errors. I suggest modifying it as
> follows:
> 
>    RFC 5892 [RFC5892] specifies an algorithm that was defined
> when    the current version of The Unicode Standard was
> Unicode 5.2    [Unicode5.2], and also defines a derived
> property value based on    that algorithm.  Unicode 6.0 has
> changed the GeneralCategory of    three code points that were
> allocated in Unicode 5.2 or earlier.    This implies that the
> derived property value differs depending on    whether the
> property definitions used are from Unicode 5.2 or    Unicode
> 6.0.

Strictly speaking, IDNA2008 (including RFC 5890 and 5892) were
defined when the current version of the Unicode Standard was
5.0.  It was then verified (and would have been modified if
needed, but it wasn't) for Unicode 5.2.  The table-generating
algorithm was rerun for 5.2, producing new non-normative
reference tables.  Because of the General Category changes that
were part of Unicode 6.0, the IDNA category values for those
code points changed and rerunning the table-generating algorithm
produces different results.

     john


From john-ietf@jck.com  Wed May 25 10:37:11 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D975AE074E; Wed, 25 May 2011 10:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.213
X-Spam-Level: 
X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liJUBoY45qBV; Wed, 25 May 2011 10:37:11 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id CC38C130067; Wed, 25 May 2011 10:37:10 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QPI17-0009ZZ-At; Wed, 25 May 2011 13:37:10 -0400
Date: Wed, 25 May 2011 13:32:22 -0400
From: John C Klensin 
To: ietf@ietf.org
Message-ID: <0F3D97B3473D57F7B652AC03@[10.100.3.199]>
In-Reply-To: <20110523221903.11394.18650.idtracker@ietfa.amsl.com>
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 May 2011 17:37:12 -0000

Just for the record,..

I favor the publication of this document with a minimum of
further fuss.

I read and studied this document before the first I-D was
published, participated in discussion of it on the IDNABIS WG
list and again on the APPSAWG list.  In each case, essentially
the same arguments were repeated and the same conclusion
reached.  While the consensus is definitely rough, we are
putting a tremendous amount of of review cycles and energy into
a document whose essence is "we have agreed to do nothing".  We
rarely publish documentation of a decision to do nothing in the
RFC Series.  Instead, we simply do nothing and move on.

   john


_Background and Reprise (in case needed or wanted)_

The argument for doing something --that this document makes and
describes the wrong decision-- is rooted in a set of decisions
the IDNABIS WG made (also with rough, rather than perfect,
consensus) a rather long time ago.  One of the key differences
between IDNA2003 and IDNA2008 was the decision to try to be
independent of Unicode versions rather than tied to a specific
one.  That decision, in turn, required that the IDNA properties
of characters -- whether they are Protocol-VALID in IDNs,
DISALLOWED, or valid only in particular contexts -- became a
matter of rules that, in turn, utilize the values of selected
Unicode properties.  If Unicode never changed the properties for
a particular character once it was allocated (and avoided
introducing new characters that required contextual evaluation),
the rule-set would never need to be changed and we would never
have to debate, and write, documents keyed to those property
changes: new versions of Unicode would add new characters but
not change the IDNA properties of previously-assigned ones.

The world is not that perfect: Unicode does change properties of
already-assigned characters.  It is rare (how rare depends a bit
on perspective), but it does happen.  The reason is typically to
correct errors made in earlier property assignments, but other
reasons are possible (or one could have a
philosophically-interesting, but otherwise useless, debate about
how far the concept of "error" can extend).  IDNA2008 recognized
that such changes might occur and might be disruptive, so
provided for a special "exception" rule that could be used to
list characters that needed special treatment because of changes
in Unicode properties.  

The WG discussed the question of how to fill the table
associated with that rule in, a discussion that included the
realization that having the  having the table become large would
simply create a new, and hard-to-explain, Unicode-version
dependence.  One option was to populate it automatically: if
Unicode made changes, the table would be filled in to preserve
the behavior at the time the character was first allocated or
that appeared in Unicode 5.2, whichever came later, whatever
that was.  Another was to turn the decision-making over to the
Unicode consortium, which might have resulted in either that
same rule or a rule that treated changes from DISALLOWED to
PVALID differently from changes from PVALID to DISALLOWED.  The
WG rejected both of those ideas as well as the idea that some
changes were inherently more attractive than others.

Instead, the WG concluded that Unicode changes of character
properties that affected IDNA needed to be evaluated in the IETF
on a case-by-case basis as to whether they were important enough
to justify an addition to that exceptions table or whether the
balance fell on the side of keeping the table small (and IDNA
reflecting as short and obvious an exception list as possible).  

In this particular instance, rough consensus has been reached in
multiple groups that it is better to keep the rules (including
that exception table stable and compact than to change the rules
in the interest of preserving the character classification
associated with Unicode 5.2.  Had the characters involved been
less obscure, or more obviously used in domain names for other
than demonstrations and equivalent purposes, perhaps the
decision would have been different (or, if they were less
obscure, perhaps Unicode either would not have made the mistake
in the first place or would have decided to not correct it).

But wanting to consider the tradeoffs and balance between those
alternatives, probably with a slight bias toward not making
changes in the rules,a is precisely why the WG decided that
Unicode property changes needed to be considered by the IETF and
on a case-by-case basis.   

There is no perfect answer to the tradeoff involved unless
Unicode never makes an error and concludes that a correction is
needed.  Because no perfect answer exists, it is possible to
reopen the issue, bring up variations on the same old arguments,
and debate them endlessly.  In that case, we've done that at
least twice, and, depending on how one counts, probably several
more times.  We've decided.  Let's get the document published
rather than seeing how many words and person-hours we can devote
to saying "we considered the issue and decided to do nothing".

     john

--On Monday, 23 May, 2011 15:19 -0700 The IESG
 wrote:

> 
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'The Unicode code points and IDNA - Unicode 6.0'
>    as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@ietf.org mailing lists by
> 2011-06-06.





From mark.edward.davis@gmail.com  Wed May 25 10:54:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2BE0726; Wed, 25 May 2011 10:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.076
X-Spam-Level: 
X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b64sqEGJBQ8Y; Wed, 25 May 2011 10:54:22 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1013EE06E0; Wed, 25 May 2011 10:54:20 -0700 (PDT)
Received: by yic13 with SMTP id 13so4024346yic.31 for ; Wed, 25 May 2011 10:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0OgZxKokXSWCC4A7qdz2e5h6mXwXuyc132MFPEX631w=; b=NPLkr416WrqqFsU+TleE/ABiVYe/VEF64EcIBHKBMW3drZodBa4vc8JKMP2JLuS7k1 KPDvmA50PNZ5m00zcGzEjRjDuMBWLPFUjMZZrCeWKqEIk3TBsKyQy1fwgrEtovRAThHj 9kG1N0ssgkdUnfnqyEb2TDC8iqs4K5K2Ju3dg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ObLXeNBiTu31C1/QU7ddhsM9Z8jztN7RLpdK5mVpUmX7LJy5zNA5ANC2OXaQHdxdcj ZVuzzWzBMHCYUVw1E1OUCG8BsoostRjEvBfSLvRE4USNWeH914lHnP3Eg4lyaFO1CKTD 2UTQvm+LqftWWVrGv9AGrp0Ll+x1dgUEZxGHQ=
MIME-Version: 1.0
Received: by 10.151.92.10 with SMTP id u10mr6043564ybl.72.1306346060565; Wed, 25 May 2011 10:54:20 -0700 (PDT)
Sender: mark.edward.davis@gmail.com
Received: by 10.150.228.1 with HTTP; Wed, 25 May 2011 10:54:20 -0700 (PDT)
In-Reply-To: <0F3D97B3473D57F7B652AC03@10.100.3.199>
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <0F3D97B3473D57F7B652AC03@10.100.3.199>
Date: Wed, 25 May 2011 10:54:20 -0700
X-Google-Sender-Auth: E2W71QUlYg0krjab5uvkFomruEI
Message-ID: 
From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= 
To: John C Klensin 
Content-Type: multipart/alternative; boundary=000e0cd359dee4ce4704a41d64d4
X-Mailman-Approved-At: Thu, 26 May 2011 15:32:48 -0700
Cc: ietf@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 May 2011 17:54:23 -0000

--000e0cd359dee4ce4704a41d64d4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I also favor publication of the document with a minimum of further fuss.

[For a somewhat different reason. I do believe that
draft-faltstrom-5892bis-04.txt
makes an incorrect choice, breaking compatibility when that isn't at all
necessary. However, I don't think that any further discussion will change
the decision-maker's minds. Since further discussion appears to just be a
waste of everyone's time,  the document might as well just get issued.]

Mark

*=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94*


On Wed, May 25, 2011 at 10:32, John C Klensin  wrote:

> Just for the record,..
>
> I favor the publication of this document with a minimum of
> further fuss.
>
> I read and studied this document before the first I-D was
> published, participated in discussion of it on the IDNABIS WG
> list and again on the APPSAWG list.  In each case, essentially
> the same arguments were repeated and the same conclusion
> reached.  While the consensus is definitely rough, we are
> putting a tremendous amount of of review cycles and energy into
> a document whose essence is "we have agreed to do nothing".  We
> rarely publish documentation of a decision to do nothing in the
> RFC Series.  Instead, we simply do nothing and move on.
>
>   john
>
>
> _Background and Reprise (in case needed or wanted)_
>
> The argument for doing something --that this document makes and
> describes the wrong decision-- is rooted in a set of decisions
> the IDNABIS WG made (also with rough, rather than perfect,
> consensus) a rather long time ago.  One of the key differences
> between IDNA2003 and IDNA2008 was the decision to try to be
> independent of Unicode versions rather than tied to a specific
> one.  That decision, in turn, required that the IDNA properties
> of characters -- whether they are Protocol-VALID in IDNs,
> DISALLOWED, or valid only in particular contexts -- became a
> matter of rules that, in turn, utilize the values of selected
> Unicode properties.  If Unicode never changed the properties for
> a particular character once it was allocated (and avoided
> introducing new characters that required contextual evaluation),
> the rule-set would never need to be changed and we would never
> have to debate, and write, documents keyed to those property
> changes: new versions of Unicode would add new characters but
> not change the IDNA properties of previously-assigned ones.
>
> The world is not that perfect: Unicode does change properties of
> already-assigned characters.  It is rare (how rare depends a bit
> on perspective), but it does happen.  The reason is typically to
> correct errors made in earlier property assignments, but other
> reasons are possible (or one could have a
> philosophically-interesting, but otherwise useless, debate about
> how far the concept of "error" can extend).  IDNA2008 recognized
> that such changes might occur and might be disruptive, so
> provided for a special "exception" rule that could be used to
> list characters that needed special treatment because of changes
> in Unicode properties.
>
> The WG discussed the question of how to fill the table
> associated with that rule in, a discussion that included the
> realization that having the  having the table become large would
> simply create a new, and hard-to-explain, Unicode-version
> dependence.  One option was to populate it automatically: if
> Unicode made changes, the table would be filled in to preserve
> the behavior at the time the character was first allocated or
> that appeared in Unicode 5.2, whichever came later, whatever
> that was.  Another was to turn the decision-making over to the
> Unicode consortium, which might have resulted in either that
> same rule or a rule that treated changes from DISALLOWED to
> PVALID differently from changes from PVALID to DISALLOWED.  The
> WG rejected both of those ideas as well as the idea that some
> changes were inherently more attractive than others.
>
> Instead, the WG concluded that Unicode changes of character
> properties that affected IDNA needed to be evaluated in the IETF
> on a case-by-case basis as to whether they were important enough
> to justify an addition to that exceptions table or whether the
> balance fell on the side of keeping the table small (and IDNA
> reflecting as short and obvious an exception list as possible).
>
> In this particular instance, rough consensus has been reached in
> multiple groups that it is better to keep the rules (including
> that exception table stable and compact than to change the rules
> in the interest of preserving the character classification
> associated with Unicode 5.2.  Had the characters involved been
> less obscure, or more obviously used in domain names for other
> than demonstrations and equivalent purposes, perhaps the
> decision would have been different (or, if they were less
> obscure, perhaps Unicode either would not have made the mistake
> in the first place or would have decided to not correct it).
>
> But wanting to consider the tradeoffs and balance between those
> alternatives, probably with a slight bias toward not making
> changes in the rules,a is precisely why the WG decided that
> Unicode property changes needed to be considered by the IETF and
> on a case-by-case basis.
>
> There is no perfect answer to the tradeoff involved unless
> Unicode never makes an error and concludes that a correction is
> needed.  Because no perfect answer exists, it is possible to
> reopen the issue, bring up variations on the same old arguments,
> and debate them endlessly.  In that case, we've done that at
> least twice, and, depending on how one counts, probably several
> more times.  We've decided.  Let's get the document published
> rather than seeing how many words and person-hours we can devote
> to saying "we considered the issue and decided to do nothing".
>
>     john
>
> --On Monday, 23 May, 2011 15:19 -0700 The IESG
>  wrote:
>
> >
> > The IESG has received a request from the Applications Area
> > Working Group WG (appsawg) to consider the following document:
> > - 'The Unicode code points and IDNA - Unicode 6.0'
> >    as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> > solicits final comments on this action. Please send
> > substantive comments to the ietf@ietf.org mailing lists by
> > 2011-06-06.
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>

--000e0cd359dee4ce4704a41d64d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I also favor publ=
ication of the document with a minimum of further fuss.

[For a somewhat diff=
erent reason. I do believe that=C2=A0draft-faltstrom-58=
92bis-04.txt makes an incorrect choice, breaking compatibility when that is=
n't at all necessary. However, I don't think that any further discu=
ssion will change the decision-maker's minds. Since further discussion =
appears to just be a waste of everyone's time, =C2=A0the document might=
 as well just get issued.]



Mark

=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =
=E2=80=94



On Wed, May 25, 2011 at 10:32, John C Klensin <john-ietf@jck.com> wrote:


Just for the record,..



I favor the publication of this document with a minimum of

further fuss.



I read and studied this document before the first I-D was

published, participated in discussion of it on the IDNABIS WG

list and again on the APPSAWG list. =C2=A0In each case, essentially

the same arguments were repeated and the same conclusion

reached. =C2=A0While the consensus is definitely rough, we are

putting a tremendous amount of of review cycles and energy into

a document whose essence is "we have agreed to do nothing". =C2=
=A0We

rarely publish documentation of a decision to do nothing in the

RFC Series. =C2=A0Instead, we simply do nothing and move on.



 =C2=A0 john





_Background and Reprise (in case needed or wanted)_



The argument for doing something --that this document makes and

describes the wrong decision-- is rooted in a set of decisions

the IDNABIS WG made (also with rough, rather than perfect,

consensus) a rather long time ago. =C2=A0One of the key differences

between IDNA2003 and IDNA2008 was the decision to try to be

independent of Unicode versions rather than tied to a specific

one. =C2=A0That decision, in turn, required that the IDNA properties

of characters -- whether they are Protocol-VALID in IDNs,

DISALLOWED, or valid only in particular contexts -- became a

matter of rules that, in turn, utilize the values of selected

Unicode properties. =C2=A0If Unicode never changed the properties for

a particular character once it was allocated (and avoided

introducing new characters that required contextual evaluation),

the rule-set would never need to be changed and we would never

have to debate, and write, documents keyed to those property

changes: new versions of Unicode would add new characters but

not change the IDNA properties of previously-assigned ones.



The world is not that perfect: Unicode does change properties of

already-assigned characters. =C2=A0It is rare (how rare depends a bit

on perspective), but it does happen. =C2=A0The reason is typically to

correct errors made in earlier property assignments, but other

reasons are possible (or one could have a

philosophically-interesting, but otherwise useless, debate about

how far the concept of "error" can extend). =C2=A0IDNA2008 recogn=
ized

that such changes might occur and might be disruptive, so

provided for a special "exception" rule that could be used to

list characters that needed special treatment because of changes

in Unicode properties.



The WG discussed the question of how to fill the table

associated with that rule in, a discussion that included the

realization that having the =C2=A0having the table become large would

simply create a new, and hard-to-explain, Unicode-version

dependence. =C2=A0One option was to populate it automatically: if

Unicode made changes, the table would be filled in to preserve

the behavior at the time the character was first allocated or

that appeared in Unicode 5.2, whichever came later, whatever

that was. =C2=A0Another was to turn the decision-making over to the

Unicode consortium, which might have resulted in either that

same rule or a rule that treated changes from DISALLOWED to

PVALID differently from changes from PVALID to DISALLOWED. =C2=A0The

WG rejected both of those ideas as well as the idea that some

changes were inherently more attractive than others.



Instead, the WG concluded that Unicode changes of character

properties that affected IDNA needed to be evaluated in the IETF

on a case-by-case basis as to whether they were important enough

to justify an addition to that exceptions table or whether the

balance fell on the side of keeping the table small (and IDNA

reflecting as short and obvious an exception list as possible).



In this particular instance, rough consensus has been reached in

multiple groups that it is better to keep the rules (including

that exception table stable and compact than to change the rules

in the interest of preserving the character classification

associated with Unicode 5.2. =C2=A0Had the characters involved been

less obscure, or more obviously used in domain names for other

than demonstrations and equivalent purposes, perhaps the

decision would have been different (or, if they were less

obscure, perhaps Unicode either would not have made the mistake

in the first place or would have decided to not correct it).



But wanting to consider the tradeoffs and balance between those

alternatives, probably with a slight bias toward not making

changes in the rules,a is precisely why the WG decided that

Unicode property changes needed to be considered by the IETF and

on a case-by-case basis.



There is no perfect answer to the tradeoff involved unless

Unicode never makes an error and concludes that a correction is

needed. =C2=A0Because no perfect answer exists, it is possible to

reopen the issue, bring up variations on the same old arguments,

and debate them endlessly. =C2=A0In that case, we've done that at

least twice, and, depending on how one counts, probably several

more times. =C2=A0We've decided. =C2=A0Let's get the document publi=
shed

rather than seeing how many words and person-hours we can devote

to saying "we considered the issue and decided to do nothing".


 =C2=A0 =C2=A0 john



--On Monday, 23 May, 2011 15:19 -0700 The IESG


<iesg-secretary@ietf.=
org> wrote:



>

> The IESG has received a request from the Applications Area

> Working Group WG (appsawg) to consider the following document:

> - 'The Unicode code points and IDNA - Unicode 6.0'

> =C2=A0 <draft-faltstrom-5892bis-04.txt> as a Proposed Standard
>

> The IESG plans to make a decision in the next few weeks, and

> solicits final comments on this action. Please send

> substantive comments to the ietf@ietf=
.org mailing lists by

> 2011-06-06.










____=
___________________________________________

Ietf mailing list

Ietf@ietf.org





--000e0cd359dee4ce4704a41d64d4--

From mnot@mnot.net  Thu May 26 22:07:49 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F3E06AF for ; Thu, 26 May 2011 22:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.139
X-Spam-Level: 
X-Spam-Status: No, score=-105.139 tagged_above=-999 required=5 tests=[AWL=-2.540, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWzvySGEsrZt for ; Thu, 26 May 2011 22:07:48 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD32E07A2 for ; Thu, 26 May 2011 22:07:48 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.214.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D28C6509EB for ; Fri, 27 May 2011 01:07:41 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 May 2011 15:07:38 +1000
References: <20110527050308.5589.11486.idtracker@ietfa.amsl.com>
To: Apps Discuss 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 05:07:49 -0000

FYI.

This draft adds two new hints: chunk-req-bodies and omit-cookies, at the =
suggestion of Patrick McManus and Poul-Henning Kamp respectively =
(thanks).

Another question Poul brought up was making it possible to have some =
hints be more fine-grained. omit-cookies would be a good example for =
this; instead of applying to the entire server, it could look something =
like:

'omit-cookies': {'/images/': true, '/images/user_special': false}

I'm a bit wary of making the file too verbose or complex, but the =
specific use case seems attractive. It could also be useful for the =
referer-related directives.

Thoughts? One approach to this would be to make the entire file some =
sort of map to the site, but my initial reaction is that this raises the =
bar for parsing too high.

Cheers,



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: 27 May 2011 3:03:08 PM AEST
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-nottingham-http-browser-hints-01.txt
> Reply-To: internet-drafts@ietf.org
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
> 	Title           : HTTP Browser Hints
> 	Author(s)       : Mark Nottingham
> 	Filename        : draft-nottingham-http-browser-hints-01.txt
> 	Pages           : 8
> 	Date            : 2011-05-26
>=20
>   Over time, Web browsers have adapted how they use HTTP based upon
>   common server configurations and behaviours.  While this is =
necessary
>   in the common case, it can be detrimental for performance and
>   interoperability.
>=20
>   This document establishes a mechanism whereby origin servers can =
make
>   available hints for browsers about their preferences and
>   capabilities, without imposing overhead on their interactions or
>   requiring support for them.
>=20
>   This is intended to allow browsers to safely optimise connections to
>   servers.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-01=
.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-01.=
txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham   http://www.mnot.net/




From dzonatas@gmail.com  Fri May 27 01:11:26 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02BBE07B1 for ; Fri, 27 May 2011 01:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.834
X-Spam-Level: 
X-Spam-Status: No, score=-4.834 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axv46wyyTmNu for ; Fri, 27 May 2011 01:11:25 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 881F3E069A for ; Fri, 27 May 2011 01:11:24 -0700 (PDT)
Received: by pxi2 with SMTP id 2so908673pxi.38 for ; Fri, 27 May 2011 01:11:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5GTYtEtfBlQXfyy6CcB3SrQ+q831+UiqaSF8hFZZLBM=; b=qgjT6ksrJ2sKt9SSgRiEyJSob2qGz8rBPoW34TKS0F9zUWTRSzSSTqEH1WadzYPnvB /D9TOKAytlEtg+tSQQfT+5hinKCF/qSF2tk9jglzVSlMuL7Q2zYGwFC1Bhg3ujc71d4l PGqu3ZN5wpzYt3V8IwEpcxNDUgJaqeoiBCMFA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=njKVzlFDQ0tnMForz62m9HABldkR1dI3XB0NJ/mQW0BUJ6kQue2eGZ7Xs3/otGFfjd r9n7dxXyOr6WowFKrqQ5CBukCXFs8oHZLdAvHpB+E1gAA2rTpyeyZZ25cI7eOCyS1XSu ZUy3CBjakC25hRpcRDa/H/mVP1BhCDnHAa4H0=
Received: by 10.143.68.4 with SMTP id v4mr300477wfk.168.1306483884017; Fri, 27 May 2011 01:11:24 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id w5sm330666pbh.61.2011.05.27.01.11.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 01:11:23 -0700 (PDT)
Message-ID: <4DDF5C55.9030900@gmail.com>
Date: Fri, 27 May 2011 01:09:57 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20110527050308.5589.11486.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 08:11:26 -0000

If the values for "omit-cookies" are (already) of environmental scope 
then I think CSS is the solution. One use-case is the web-browser scans 
the CSS for elements and namespaces that relate or are relative to the 
context (cookies can further be enabled/disabled/sent/not-sent in 
content sensitive manner in optimization). That avoids unintentional 
redundancy. If there is intentional difference in scope between global 
and environmental access then that is what I think "raises the bar". We 
can assume one intentional use-case of global access with URL fragments:

'omit-cookies': {'/images/': true, '/images/#!/user_special': false }

...begs the question on who processes.

On 05/26/2011 10:07 PM, Mark Nottingham wrote:
> FYI.
>
> This draft adds two new hints: chunk-req-bodies and omit-cookies, at the suggestion of Patrick McManus and Poul-Henning Kamp respectively (thanks).
>
> Another question Poul brought up was making it possible to have some hints be more fine-grained. omit-cookies would be a good example for this; instead of applying to the entire server, it could look something like:
>
> 'omit-cookies': {'/images/': true, '/images/user_special': false}
>
> I'm a bit wary of making the file too verbose or complex, but the specific use case seems attractive. It could also be useful for the referer-related directives.
>
> Thoughts? One approach to this would be to make the entire file some sort of map to the site, but my initial reaction is that this raises the bar for parsing too high.
>
> Cheers,
>
>
>
> Begin forwarded message:
>
>    
>> From: internet-drafts@ietf.org
>> Date: 27 May 2011 3:03:08 PM AEST
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-nottingham-http-browser-hints-01.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : HTTP Browser Hints
>> 	Author(s)       : Mark Nottingham
>> 	Filename        : draft-nottingham-http-browser-hints-01.txt
>> 	Pages           : 8
>> 	Date            : 2011-05-26
>>
>>    Over time, Web browsers have adapted how they use HTTP based upon
>>    common server configurations and behaviours.  While this is necessary
>>    in the common case, it can be detrimental for performance and
>>    interoperability.
>>
>>    This document establishes a mechanism whereby origin servers can make
>>    available hints for browsers about their preferences and
>>    capabilities, without imposing overhead on their interactions or
>>    requiring support for them.
>>
>>    This is intended to allow browsers to safely optimise connections to
>>    servers.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-01.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>      
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>    


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From patrik@frobbit.se  Sun May 29 08:50:23 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F19E06F2 for ; Sun, 29 May 2011 08:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1TXu0MGanae for ; Sun, 29 May 2011 08:50:22 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 21388E0662 for ; Sun, 29 May 2011 08:50:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 93804110A2C29; Sun, 29 May 2011 17:50:17 +0200 (CEST)
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 nEFoVEiZhDtm; Sun, 29 May 2011 17:50:17 +0200 (CEST)
Received: from dhcp-10-61-97-71.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id BE1F0110A2C21; Sun, 29 May 2011 17:50:16 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <1E0BD491A5C0210B48BA7043@PST.JCK.COM>
Date: Sun, 29 May 2011 13:25:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <4DDADF21.108@stpeter.im> <1E0BD491A5C0210B48BA7043@PST.JCK.COM>
To: John C Klensin 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 May 2011 15:50:23 -0000

FWIW, although I agree with John and expect me getting a fair number of =
editorial corrections because of English not being my native language =
when this document hit the RFC editor, I have slightly changed the first =
paragraph in the upcoming new version to the following:

(sorry, can not generate TXT now, but you get the point...)

If you have other suggested changes, let me know.

RFC 5892 specifies an algorithm that
   was defined when version 5.0 (later
   updated to version 5.2) was the current version of Unicode,
   and it also defines a derived property value based on that algorithm.
   Unicode 6.0 has changed GeneralCategory of three code points that
   where allocated in Unicode 5.2 or earlier. This imply the derived
   property value differs depending on whether the property definitions
   used are from Unicode 5.2 or 6.0.


   Patrik

On 24 maj 2011, at 04.22, John C Klensin wrote:

> Peter,
>=20
> Personally, I think it would be a big mistake to spend a lot
> more time on this.  It just isn't worth it.  And I continue to
> object to the IESG -- or even responsible ADs -- doing
> copy-editing.  We pay the highly qualified RFC Editor staff for
> doing that and should let them do their jobs.  That said, if
> this is worth fussing with...
>=20
> --On Monday, May 23, 2011 16:26 -0600 Peter Saint-Andre
>  wrote:
>=20
>> The first paragraph of the Introduction contains a few
>> infelicities and grammatical errors. I suggest modifying it as
>> follows:
>>=20
>>   RFC 5892 [RFC5892] specifies an algorithm that was defined
>> when    the current version of The Unicode Standard was
>> Unicode 5.2    [Unicode5.2], and also defines a derived
>> property value based on    that algorithm.  Unicode 6.0 has
>> changed the GeneralCategory of    three code points that were
>> allocated in Unicode 5.2 or earlier.    This implies that the
>> derived property value differs depending on    whether the
>> property definitions used are from Unicode 5.2 or    Unicode
>> 6.0.
>=20
> Strictly speaking, IDNA2008 (including RFC 5890 and 5892) were
> defined when the current version of the Unicode Standard was
> 5.0.  It was then verified (and would have been modified if
> needed, but it wasn't) for Unicode 5.2.  The table-generating
> algorithm was rerun for 5.2, producing new non-normative
> reference tables.  Because of the General Category changes that
> were part of Unicode 6.0, the IDNA category values for those
> code points changed and rerunning the table-generating algorithm
> produces different results.
>=20
>     john
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20


From john-ietf@jck.com  Sun May 29 12:14:16 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD58E06FC for ; Sun, 29 May 2011 12:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.358
X-Spam-Level: 
X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsaeE1YRD1Ax for ; Sun, 29 May 2011 12:14:10 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id D960FE0655 for ; Sun, 29 May 2011 12:14:09 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QQlR3-000J1X-Mv; Sun, 29 May 2011 15:14:01 -0400
Date: Sun, 29 May 2011 15:14:00 -0400
From: John C Klensin 
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= 
Message-ID: <62BF38B4A0358DF278AC5678@PST.JCK.COM>
In-Reply-To: 
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <4DDADF21.108@stpeter.im> <1E0BD491A5C0210B48BA7043@PST.JCK.COM> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 May 2011 19:14:16 -0000

--On Sunday, May 29, 2011 13:25 +0200 Patrik F=C3=A4ltstr=C3=B6m
 wrote:

> FWIW, although I agree with John and expect me getting a fair
> number of editorial corrections because of English not being
> my native language when this document hit the RFC editor, I
> have slightly changed the first paragraph in the upcoming new
> version to the following:
>=20
> (sorry, can not generate TXT now, but you get the point...)
>=20
> If you have other suggested changes, let me know.
>=20
> RFC 5892 specifies an
> algorithm that    was defined when=20

Please say "rule set" or something like that, not "algorithm".
While "algorithm" is strictly correct, some people will read it
as pseudo-code, and our principle should remain that anything
that produces the save results is correct.

>   target=3D"Unicode5.2">version 5.0 (later=20
> updated to version 5.2)=20
> was the current version of Unicode, and it also
> defines a derived property value based on that algorithm.

Again, "rule set" or some such thing.   In addition, IMO, I
think that, if you are going to make that change, you should add
an extra sentence that says something like "That derived
property value is, in turn, used to generate the tables shown in
Appendix B and their successors".   Neither the derived property
value nor the tables are themselves normative: they depend on a
particular version of Unicode, which the rules do not."

> Unicode 6.0 has changed GeneralCategory of three code points
> that    where allocated in Unicode 5.2 or earlier. This imply
> the derived    property value differs depending on whether the
> property definitions    used are from Unicode 5.2 or 6.0.
> 

Editorial recommendation (no change in meaning):

Unicode 6.0 changed the GeneralCategory of three code points
that had been allocated in Unicode 5.2 or earlier. The
consequence of that change is that the derived property value
for those code points differs depending on whether the property
definitions used are from Unicode 5.2 or 6.0. 

  --john


From paul.hoffman@vpnc.org  Sun May 29 12:24:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83643E0756 for ; Sun, 29 May 2011 12:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89aPuPLYbQIm for ; Sun, 29 May 2011 12:24:47 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36DE0755 for ; Sun, 29 May 2011 12:24:45 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4TJOc71029569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 May 2011 12:24:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Paul Hoffman 
In-Reply-To: <62BF38B4A0358DF278AC5678@PST.JCK.COM>
Date: Sun, 29 May 2011 12:24:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <4DDADF21.108@stpeter.im> <1E0BD491A5C0210B48BA7043@PST.JCK.COM>  <62BF38B4A0358DF278AC5678@PST.JCK.COM>
To: John C Klensin 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 May 2011 19:24:52 -0000

On May 29, 2011, at 12:14 PM, John C Klensin wrote:

>=20
>=20
> --On Sunday, May 29, 2011 13:25 +0200 Patrik F=E4ltstr=F6m
>  wrote:
>=20
>> FWIW, although I agree with John and expect me getting a fair
>> number of editorial corrections because of English not being
>> my native language when this document hit the RFC editor, I
>> have slightly changed the first paragraph in the upcoming new
>> version to the following:
>>=20
>> (sorry, can not generate TXT now, but you get the point...)
>>=20
>> If you have other suggested changes, let me know.
>>=20
>> RFC 5892 specifies an
>> algorithm that    was defined when=20
>=20
> Please say "rule set" or something like that, not "algorithm".
> While "algorithm" is strictly correct, some people will read it
> as pseudo-code, and our principle should remain that anything
> that produces the save results is correct.

Do you think this change follows the definition of "rule set" in RFC =
5892? To me, "algorithm" seems much better. =46rom the introduction to =
5892:
   This document reviews and classifies the collections of code points
   in the Unicode character set by examining various properties of the
   code points.  It then defines an algorithm for determining a derived
   property value.  It specifies a procedure, and not a table, of code
   points so that the algorithm can be used to determine code point sets
   independent of the version of Unicode that is in use.
The term "rule set" is used specifically as part of the context =
registry, and not at all what we are discussing here.

>> Unicode 6.0 has changed GeneralCategory of three code points
>> that    where allocated in Unicode 5.2 or earlier. This imply
>> the derived    property value differs depending on whether the
>> property definitions    used are from Unicode 5.2 or 6.0.
>> 
>=20
> Editorial recommendation (no change in meaning):
>=20
> Unicode 6.0 changed the GeneralCategory of three code points
> that had been allocated in Unicode 5.2 or earlier. The
> consequence of that change is that the derived property value
> for those code points differs depending on whether the property
> definitions used are from Unicode 5.2 or 6.0. 


Seems like a good change to me.

--Paul Hoffman


From john-ietf@jck.com  Sun May 29 12:50:43 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C50E075E for ; Sun, 29 May 2011 12:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Level: 
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKy4UN-uzpkf for ; Sun, 29 May 2011 12:50:42 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3292EE0750 for ; Sun, 29 May 2011 12:50:42 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QQm0P-000Jmi-4n; Sun, 29 May 2011 15:50:33 -0400
Date: Sun, 29 May 2011 15:50:32 -0400
From: John C Klensin 
To: Paul Hoffman 
Message-ID: <82F537AF2A1B70A69E256960@PST.JCK.COM>
In-Reply-To: 
References: <20110523221903.11394.18650.idtracker@ietfa.amsl.com> <4DDADF21.108@stpeter.im> <1E0BD491A5C0210B48BA7043@PST.JCK.COM>  <62BF38B4A0358DF278AC5678@PST.JCK.COM> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call:  (The Unicode code points	and IDNA - Unicode 6.0) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 May 2011 19:50:43 -0000

--On Sunday, May 29, 2011 12:24 -0700 Paul Hoffman
 wrote:

> On May 29, 2011, at 12:14 PM, John C Klensin wrote:
>...
>>> RFC 5892 specifies an
>>> algorithm that    was defined when 
>> 
>> Please say "rule set" or something like that, not "algorithm".
>> While "algorithm" is strictly correct, some people will read
>> it as pseudo-code, and our principle should remain that
>> anything that produces the save results is correct.
> 
> Do you think this change follows the definition of "rule set"
> in RFC 5892? To me, "algorithm" seems much better. From the
> introduction to 5892:    This document reviews and classifies
> the collections of code points    in the Unicode character set
>...

Sorry, had forgotten that sentence in the Introduction.   Given
that, you are right: "algorithm" is better and we should stick
with it.

    john


From svartman95@gmail.com  Sun May 29 15:48:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2019BE0700 for ; Sun, 29 May 2011 15:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2KupsJyBqCE for ; Sun, 29 May 2011 15:48:51 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAEAE06FE for ; Sun, 29 May 2011 15:48:51 -0700 (PDT)
Received: by yic13 with SMTP id 13so1798094yic.31 for ; Sun, 29 May 2011 15:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=rXijujTDe6T0vr7l51dYEUyJdOJyzQMK/SBUF7EiZj0=; b=q7Iv0h1qHYGnM8hPEfiBYSMP1TCqDj1/iO4zktmrGr+DK1/QZlHBZh2o5PXf4b5m5F JNnC+P5J0jgYqRt4x/yhI0Vx3aPqli/OdV60XfFRFks3TW0KrkhFRoVoEsPUR2CxCv2h xwUb2EX49vJtyobdoFqRmBDeUJ/r5dhJ766oI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cml60du/2i/K9LmA0JMaS+HmoEwqc09bzpOEWhdPHGChBfR4B8ksCV+QIB26TuvvM1 xJuj3FOyTbcx8f2L8BF0LaaHloV77K/PaeX8LDvnNHlE3/e6kLLe9dbDBsBJLLWkj5tr 4woCHi79KGYp8uQ1vVhawBPaBsPl/D7wex+7g=
MIME-Version: 1.0
Received: by 10.236.76.197 with SMTP id b45mr5301422yhe.147.1306709330800; Sun, 29 May 2011 15:48:50 -0700 (PDT)
Received: by 10.236.47.228 with HTTP; Sun, 29 May 2011 15:48:50 -0700 (PDT)
Date: Sun, 29 May 2011 22:48:50 +0000
Message-ID: 
From: Bjartur Thorlacius 
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 12:37:33 -0000

The current draft specifies that browser hints are a resource
identified by the URI "/.well-known/browser-hints" resolved relative
to an URI scheme, an authority section, and an empty path (assuming I
understand the draft correctly). I believe this to be harmful, as the
URI shares the authority section with other URIs, but is in fact named
by IETF (even though IETF doesn't maintain the resource).
Have you considered the possibility of passing this information as a
response to another method than GET, e.g. OPTIONS?
If creating a new method or reusing OPTIONS isn't an option (no pun
intended), could a new URI scheme be used, so that the hints are still
assigned an URI, without polluting the namespace supposedly given to
domain name registrants, and potentially clashing with existing or
future URIs.

From mnot@mnot.net  Mon May 30 05:57:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817D0E06F7 for ; Mon, 30 May 2011 05:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.286
X-Spam-Level: 
X-Spam-Status: No, score=-105.286 tagged_above=-999 required=5 tests=[AWL=-2.687, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miWHYtO-lm5k for ; Mon, 30 May 2011 05:57:51 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEA6E0651 for ; Mon, 30 May 2011 05:57:51 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.214.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A6134509E2; Mon, 30 May 2011 08:57:44 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 30 May 2011 22:57:41 +1000
Content-Transfer-Encoding: 7bit
Message-Id: <70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>
References: 
To: Bjartur Thorlacius 
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 12:57:52 -0000

Bjartur,

See RFC 5785.

Cheers,


On 30/05/2011, at 8:48 AM, Bjartur Thorlacius wrote:

> The current draft specifies that browser hints are a resource
> identified by the URI "/.well-known/browser-hints" resolved relative
> to an URI scheme, an authority section, and an empty path (assuming I
> understand the draft correctly). I believe this to be harmful, as the
> URI shares the authority section with other URIs, but is in fact named
> by IETF (even though IETF doesn't maintain the resource).
> Have you considered the possibility of passing this information as a
> response to another method than GET, e.g. OPTIONS?
> If creating a new method or reusing OPTIONS isn't an option (no pun
> intended), could a new URI scheme be used, so that the hints are still
> assigned an URI, without polluting the namespace supposedly given to
> domain name registrants, and potentially clashing with existing or
> future URIs.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




From svartman95@gmail.com  Mon May 30 06:49:51 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47CBE07CB for ; Mon, 30 May 2011 06:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.208
X-Spam-Level: 
X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=1.391,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVO1tH2Qjx1U for ; Mon, 30 May 2011 06:49:49 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 39429E07D6 for ; Mon, 30 May 2011 06:49:29 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2689871wwa.13 for ; Mon, 30 May 2011 06:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oBr+YVIVVVJX4kMTf8NrChGRr8uMbra3AzdI/acL77k=; b=eNl//s99SVejatTajBo2z0OqzTbFtKhY5Zl3+LbWsB8aW6HRxtb1w+thKJZgUhMy+w D1mUYNWqsFnNYn74f073J+fdZ61BvTDqQI0dgtCC8SzhMEqMntGTu9bfieVjuxKmbM5W csQcCXltF8vQL/AWyhbm0IKCck2EwI871rPYQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=u95stlME+SIa1RYQVr3LOL3kQ1gwMI8qz6z94A2SUWFvWiJwf8zw+CX6TQfG2IhakH AkS6fvwgqL+iOwG9H+JkALIyln2x3mWyT8JWLdo6k5htV3OlURh/psby2zgpBJg6qWsW lRIWOH8Q9y8sQ2rjvRHTrgNPiWR018lNni7ME=
Received: by 10.227.170.74 with SMTP id c10mr4939517wbz.104.1306763368257; Mon, 30 May 2011 06:49:28 -0700 (PDT)
Received: from [192.168.1.100] (dsl-ls-104-143.du.vortex.is [213.190.104.143]) by mx.google.com with ESMTPS id p21sm3061749wbh.40.2011.05.30.06.49.26 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 06:49:27 -0700 (PDT)
Message-ID: <4DE3A064.8010404@gmail.com>
Date: Mon, 30 May 2011 13:49:24 +0000
From: Bjartur Thorlacius 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Mark Nottingham 
References:  <70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>
In-Reply-To: <70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 13:49:51 -0000

Şann mán 30.maí 2011 12:57, skrifaği Mark Nottingham:
> Bjartur,
>
> See RFC 5785.
>
>    
RFC 5785 is fine when you're limited to GET and PUT, which is often the 
case. This is not one of them.

 > RFCXXXX * HTTP/1.1
 > Host: example.net
 >

< 200 OK
< Content-Type: example/example
< Content-Location: http://etc.example.net/hints
<
 > {....}

It is also possible to use the authority instead of the asterisk (as per 
RFC 2616). This would have the minor security benefit of not allowing 
users who can register arbitrary path components below the root, as in a 
user registering as ".well-known" and uploading a maliciously named file 
to make clients open insane amounts of connections to the host.
What use cases does this method not fulfill?

From julian.reschke@gmx.de  Mon May 30 07:58:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E26E068F for ; Mon, 30 May 2011 07:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.969
X-Spam-Level: 
X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDL2tVnTdIE6 for ; Mon, 30 May 2011 07:58:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4D407E0677 for ; Mon, 30 May 2011 07:58:17 -0700 (PDT)
Received: (qmail invoked by alias); 30 May 2011 14:58:16 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 30 May 2011 16:58:16 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18LBbIuB9gLIQlYgt8FooiV6TijQk+3dmEayu9dNm yWwKxvxkn84Vf2
Message-ID: <4DE3B07F.9030407@gmx.de>
Date: Mon, 30 May 2011 16:58:07 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bjartur Thorlacius 
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net> <4DE3A064.8010404@gmail.com>
In-Reply-To: <4DE3A064.8010404@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 14:58:19 -0000

On 2011-05-30 15:49, Bjartur Thorlacius wrote:
> Şann mán 30.maí 2011 12:57, skrifaği Mark Nottingham:
>> Bjartur,
>>
>> See RFC 5785.
>>
> RFC 5785 is fine when you're limited to GET and PUT, which is often the
> case. This is not one of them.

How is this limited to specific methods?

>  > RFCXXXX * HTTP/1.1
>  > Host: example.net
>  >
>
> < 200 OK
> < Content-Type: example/example
> < Content-Location: http://etc.example.net/hints
> <
>  > {....}
>
> It is also possible to use the authority instead of the asterisk (as per
> RFC 2616). This would have the minor security benefit of not allowing
> users who can register arbitrary path components below the root, as in a
> user registering as ".well-known" and uploading a maliciously named file
> to make clients open insane amounts of connections to the host.
> What use cases does this method not fulfill?

It appears you're trying to re-open an old discussion about how to 
expose server-wide metadata. Been there, done that. RFC 5785 is what 
came out of it.

Best regards, Julian

From evnikita2@gmail.com  Mon May 30 08:03:39 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A01E079D for ; Mon, 30 May 2011 08:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9q2IGfww9CI for ; Mon, 30 May 2011 08:03:36 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 158EFE06A2 for ; Mon, 30 May 2011 08:03:35 -0700 (PDT)
Received: by bwz13 with SMTP id 13so3404965bwz.31 for ; Mon, 30 May 2011 08:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uCZD+UUCkogkBZyXXcaMYiGxnhWEQGPb38pTe3vTMT0=; b=xLydr53Ltk1d7XYNYrRjn/QVq+3wLZtQVLbD7vEvUJH33v/CE8qVBFDfCQYWba2cHI vAS5OqwL/mELi6DjHPiUdSbcCHka5BBuOsvV2pF6iLt1aBsfqV+M4i4jyo15HWSYb+Te Zwl/fI8DEWc2R5rObgygseWWnQ0JpzWrwtASk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YJaaBX/m1c/RsdQPTZH2RbJ9aQjqmnxEFnGczP9PcEMNgTSrN3mBi75XlxCPOjNfzD 9Jf/chc/mfEdWTTVVVgLX2pbG7+Ma9q1/v3zN6tfb09ox3HR50IH5u461GXbe7I2jmbt Rb5nKlmHG4jfdBeH9ulnUvMUQ1qG1BeBhKgxU=
Received: by 10.204.47.18 with SMTP id l18mr4662317bkf.31.1306767813217; Mon, 30 May 2011 08:03:33 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id ag6sm3487197bkc.6.2011.05.30.08.03.30 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 08:03:31 -0700 (PDT)
Message-ID: <4DE3B1F0.4090306@gmail.com>
Date: Mon, 30 May 2011 18:04:16 +0300
From: Mykyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bjartur Thorlacius 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 15:03:39 -0000

30.05.2011 1:48, Bjartur Thorlacius wrote:
> The current draft specifies that browser hints are a resource
> identified by the URI "/.well-known/browser-hints" resolved relative
> to an URI scheme, an authority section, and an empty path (assuming I
> understand the draft correctly). I believe this to be harmful, as the
> URI shares the authority section with other URIs, but is in fact named
> by IETF (even though IETF doesn't maintain the resource).
> Have you considered the possibility of passing this information as a
> response to another method than GET, e.g. OPTIONS?
> If creating a new method or reusing OPTIONS isn't an option (no pun
> intended), could a new URI scheme be used, so that the hints are still
> assigned an URI, without polluting the namespace supposedly given to
> domain name registrants, and potentially clashing with existing or
> future URIs.
Bjartur, just my personal opinion.

/.well-known/ has been designed specially to allow everybody and 
everything (meaning applications) to know that something is exactly 
there, and not anywhere else.  Using GET with the definite well-known 
path, denoted as defined in RFC 5785, is probably the easiest way to 
provide a means of access to some particular pre-defined resource in 
HTTP.  I don't understand why we should create a new HTTP method (as you 
proposed in your subsequent message) or a new URI scheme (as you propose 
above) and, in this way, complicate the "protocol", if it may be called so.

What is currently proposed by Mark is fine and needs no further 
improvements (with respect to how the hints are discovered).

Mykyta Yevstifeyev
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From svartman95@gmail.com  Mon May 30 09:25:19 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849CE06A2 for ; Mon, 30 May 2011 09:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.904
X-Spam-Level: 
X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.695,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbEq1+SmPHV3 for ; Mon, 30 May 2011 09:25:18 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3644BE0678 for ; Mon, 30 May 2011 09:25:18 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2784254wwa.13 for ; Mon, 30 May 2011 09:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cD4bSgPjWS2mYUFn2mTuKPrCGoCQ4AF9KlY2ZcOw3K8=; b=LT3OT8oLdwZhF9pdVh3x9xnHlsm+xN3yQbCSsnSkrteMBPAmEh2t/9GYeCTALtzNAd N1hZg8p3NWYNyeCeSdu4ozOVMDvniRVl8WbJuVkgGUnGta50PGqwKhsNWwXf7rL5n88i ggX7YGTGTJeF7euhPavyO91hsK3+ldS1EZjj4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MeZEWq1aHPfGuDAFOEV+NOQMwWugOFs3JKw8PSaz6ITWlfgZ2XJHD8p8ZxFua/oQJM tJ2WM3S1O0f1i76EPT5mS7aj5FvOkyW8zlPte0NUdyQgHbb+3rfthdkSc4Al18MpyN1f N6ZsngKEr0N1GXuPdToicePV/zDqF2JVICuIU=
Received: by 10.227.167.129 with SMTP id q1mr5030194wby.101.1306772717308; Mon, 30 May 2011 09:25:17 -0700 (PDT)
Received: from [192.168.1.100] (dsl-ls-104-143.du.vortex.is [213.190.104.143]) by mx.google.com with ESMTPS id m8sm3159557wbh.62.2011.05.30.09.25.15 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 09:25:16 -0700 (PDT)
Message-ID: <4DE3C4E8.4000900@gmail.com>
Date: Mon, 30 May 2011 16:25:12 +0000
From: Bjartur Thorlacius 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Julian Reschke 
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net> <4DE3A064.8010404@gmail.com> <4DE3B07F.9030407@gmx.de>
In-Reply-To: <4DE3B07F.9030407@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Mark Nottingham , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 16:25:19 -0000

Şann mán 30.maí 2011 14:58, skrifaği Julian Reschke:
> On 2011-05-30 15:49, Bjartur Thorlacius wrote:
>> Şann mán 30.maí 2011 12:57, skrifaği Mark Nottingham:
>>> Bjartur,
>>>
>>> See RFC 5785.
>>>
>> RFC 5785 is fine when you're limited to GET and PUT, which is often the
>> case. This is not one of them.
>
> How is this limited to specific methods?
It isn't. Well known locations are simply the best way to discover 
server-wide metadata when all you have is GET.
>> > RFCXXXX * HTTP/1.1
>> > Host: example.net
>> >
>>
>> < 200 OK
>> < Content-Type: example/example
>> < Content-Location: http://etc.example.net/hints
>> <
>> > {....}
>>
>> It is also possible to use the authority instead of the asterisk (as per
>> RFC 2616). This would have the minor security benefit of not allowing
>> users who can register arbitrary path components below the root, as in a
>> user registering as ".well-known" and uploading a maliciously named file
>> to make clients open insane amounts of connections to the host.
>> What use cases does this method not fulfill?
>
> It appears you're trying to re-open an old discussion about how to 
> expose server-wide metadata. Been there, done that. RFC 5785 is what 
> came out of it.
>
I'll have to read the discussions behind RFC 5785. I seem to vastly 
underestimate the deployment difficulties of a new method.
> Rather, they are designed to facilitate
>     discovery of information on a site when it isn't practical to use
>     other mechanisms;
In other words well known locations are a hack. RFC 5785 mitigates most 
of the drawbacks of the hack, by providing a common prefix for future 
well known locations, but it's still misusing GET. It breaks breaks the 
hierarchical nature of the hierarchical part of URIs. This problem gets 
worse for every new well known location. What are the implications of an 
attacker forging max-conns? The value of the property would be lessened 
if user agents imposed strict limits on the value.

> and attacks where limited access to a server grants the ability to
>     affect how well-known URIs are served.



From evnikita2@gmail.com  Mon May 30 10:57:52 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30DCE06BC for ; Mon, 30 May 2011 10:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.527
X-Spam-Level: 
X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0AFf3jcnfGb for ; Mon, 30 May 2011 10:57:51 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 888F9E0719 for ; Mon, 30 May 2011 10:57:51 -0700 (PDT)
Received: by bwz13 with SMTP id 13so3522804bwz.31 for ; Mon, 30 May 2011 10:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2O6ZBtpr4w28Kyctf3kvhQfAeS3joK539oj7G3CevI8=; b=uG7fiSxutnoPHbQVdFhDmPRWVo3XmNuYeqsYA6kIpgWDJOn5pdOVz5eFxaAGNE2GCk OrzIWsnVu1uMu7KYGOQr3jSYwwPekwk6g86RsvJfUMIhMGP+sNH1eNymUUX6vGZ1tbU/ fhVCJ3RmUSJ6Tw24IOT0We9LE2qQlfeVG3L2M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=lXv0PqOcB+h0RTbA2R9QaSyQ1U6ynyVpfGgaTAhbfxlECEKINxkFbpY0bxelutku1V pDfbfdix1lUpuPMNZt9gDmXlqnbJ3Xs9eY0m9Rr8XdX78QivOc2FijllLhG98U8CsL2Y Fza7+1aWLNDXf3o7DNjJBtMTSbVXfzwRG4w1o=
Received: by 10.204.8.141 with SMTP id h13mr2018455bkh.64.1306778270141; Mon, 30 May 2011 10:57:50 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id k16sm3592927bks.13.2011.05.30.10.57.48 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 10:57:49 -0700 (PDT)
Message-ID: <4DE3DACA.5030707@gmail.com>
Date: Mon, 30 May 2011 20:58:34 +0300
From: MyKyta Yevstifeyev 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net> <4DE3A064.8010404@gmail.com>
In-Reply-To: <4DE3A064.8010404@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] Fwd: I-D Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 17:57:52 -0000

30.05.2011 16:49, Bjartur Thorlacius wrote:
> Şann mán 30.maí 2011 12:57, skrifaği Mark Nottingham:
>> Bjartur,
>>
>> See RFC 5785.
>>
> RFC 5785 is fine when you're limited to GET and PUT, which is often 
> the case. This is not one of them.
BTW, RFC 5785 works with standard 'http' URIs which imply the GET 
method, not PUT or anything else.  Unless we decide to use other method 
(which is very unlikely to happen), well-known URIs are fine.

Mykyta Yevstifeyev
>
> [ . . . ]
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From dzonatas@gmail.com  Mon May 30 11:02:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C7E0723 for ; Mon, 30 May 2011 11:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8YPR3Hpoo7B for ; Mon, 30 May 2011 11:02:59 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id EBA46E06AB for ; Mon, 30 May 2011 11:02:58 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2621773pxi.27 for ; Mon, 30 May 2011 11:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RpqazD0Vqd9oAoUZN5h2Q90/USNbHl2w/1gTGtem0Xk=; b=ibc2d0CMUrz2EslIZs/hwqYxzN9wiwdcD3ixat7Y6LQjBwdRyBU48tDAwpIAL0oxMT tph/rD2AR4sKE8Aj9YM/SeF2SYsdksPxepObzLmVzTcfmIJwHQgjeFkYLljGQEy7+Ilr ZUjnagNqGetBDl2EhV8sMPDvafDou9Yx9n7/E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=r3Rosk825QMTxyDuzLtnllRRPTHuv1+2inseYVbGVc0qIWP2x7PoB+FR3/WLzpE1G8 jhea9ofao2WZFHb7SqwezraF325n0MY7SEZk6/saYaI2wP+qZr8/zJy4bOutAebRB60G Pzls9nOShli6C+3nwsFOJwY+QhRtX1eoasNkw=
Received: by 10.142.215.18 with SMTP id n18mr726029wfg.332.1306778578569; Mon, 30 May 2011 11:02:58 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id w5sm3035074pbh.29.2011.05.30.11.02.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 11:02:57 -0700 (PDT)
Message-ID: <4DE3DB86.8000505@gmail.com>
Date: Mon, 30 May 2011 11:01:42 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>	<4DE3A064.8010404@gmail.com> <4DE3B07F.9030407@gmx.de> <4DE3C4E8.4000900@gmail.com>
In-Reply-To: <4DE3C4E8.4000900@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: I-D	Action:	draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 18:02:59 -0000

On 05/30/2011 09:25 AM, Bjartur Thorlacius wrote:
> In other words well known locations are a hack. RFC 5785 mitigates 
> most of the drawbacks of the hack, by providing a common prefix for 
> future well known locations, but it's still misusing GET. It breaks 
> breaks the hierarchical nature of the hierarchical part of URIs. This 
> problem gets worse for every new well known location. What are the 
> implications of an attacker forging max-conns? The value of the 
> property would be lessened if user agents imposed strict limits on the 
> value.

People often implement the ReSTful paradigm based only on these four 
http methods: POST, GET, PUT, DELETE. I hardly consider usage of those 
to the fullest means as any hack. (In my book. they each are subclasses 
of TASKs on the queue.)

Any implication of an attacker... questionable on why would one stop 
there, specifically, even if we assume "they're inside".

Personally, I see /.well-known/ as simple as file based implementation, 
yet obviously much more can be done with the flexibility of logical 
devices. In the simple form GET is available. With logical devices (or 
permissions) one can implement the other 3 methods and negotiate options.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From svartman95@gmail.com  Mon May 30 16:25:47 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04281E0754 for ; Mon, 30 May 2011 16:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHHloGer56P for ; Mon, 30 May 2011 16:25:45 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42389E0741 for ; Mon, 30 May 2011 16:25:45 -0700 (PDT)
Received: by yic13 with SMTP id 13so2204633yic.31 for ; Mon, 30 May 2011 16:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SnBOipFA/YFxXk8xvdzpMxWBr67t1+19mPU4i198+FU=; b=DjJRHBbdWyEyvTj17JtDBGkIqrlRgJLK2AYkijIJFeHzhZAIx4/cJaSDK/w6bViR7f PQ2MZIw5ozA2AaaTZ1FhyZp0XwyrUO7ux/WcaOVH7JWRHr/mQRZqgFqzTVWI0QLVh5/S SrvfExWdLFh+QF+DzyagqSHrvEEGGI3GeLkgU=
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=jvrL44GLo1Pi8BSk1drH3vjdagIXPh1LCFMvAr4i4A3yi6Ux+MgUdeKhOUwjazlGKA Jjf5hwidxmkxSNMsymL4C8LGbtu2BOMkDTXZjOd6irWHMtibHMkZ2z6UKrD/WefAE5uR 8ivYOS3hIZKh9edWSdr0SHpX4Qn4Vfsmf/eWw=
MIME-Version: 1.0
Received: by 10.236.92.116 with SMTP id i80mr6558114yhf.348.1306797942342; Mon, 30 May 2011 16:25:42 -0700 (PDT)
Received: by 10.236.47.228 with HTTP; Mon, 30 May 2011 16:25:42 -0700 (PDT)
In-Reply-To: <4DE3DB86.8000505@gmail.com>
References:  <70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net> <4DE3A064.8010404@gmail.com> <4DE3B07F.9030407@gmx.de> <4DE3C4E8.4000900@gmail.com> <4DE3DB86.8000505@gmail.com>
Date: Mon, 30 May 2011 23:25:42 +0000
Message-ID: 
From: Bjartur Thorlacius 
To: Dzonatas Sol 
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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 May 2011 23:25:47 -0000

On 5/30/11, Dzonatas Sol  wrote:
> People often implement the ReSTful paradigm based only on these four
> http methods: POST, GET, PUT, DELETE. I hardly consider usage of those
> to the fullest means as any hack. (In my book. they each are subclasses
> of TASKs on the queue.)
>
I consider creating URIs under all URI authorities (as in the
authority section of the hierarchical part) questionable, not the
usage of an existing method. Why should the IETF construct URIs such
as  and
. There's no image
board named ".well-known". It's /possible/ to use RFC 5785 for _all_
site-wide metadata, no matter what, just as it's /possible/ to use
POST to it's fullest, and POST exclusively, embedding the action and
entity-body in the message-body.
What queue? Most (but not all) HTTP methods operate on resources
identified by URIs.

> Any implication of an attacker... questionable on why would one stop
> there, specifically, even if we assume "they're inside".
>
You don't necessarily have to be "inside" to be able to upload files.
I'm thinking of a user registering as ".well-known" and uploading
maliciously named and crafted files. *All* HTTP servers out there will
have to reserve the "/.well-known" prefix, if only to avoid serving a
dangerous value of the max-conns property in the browser-hints file
(and thereby values of other properties such as max-pipeline-depth).

Note that I don't disagree with RFC 5785. It's the right mechanism for
certain tasks. I disagree with the apparent group consensus that
discovery of browser hints are one of these tasks.

From dzonatas@gmail.com  Mon May 30 17:29:00 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA466E075A for ; Mon, 30 May 2011 17:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.121
X-Spam-Level: 
X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjUJBOi5FwY8 for ; Mon, 30 May 2011 17:28:59 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id F128FE074C for ; Mon, 30 May 2011 17:28:58 -0700 (PDT)
Received: by pzk5 with SMTP id 5so1985727pzk.31 for ; Mon, 30 May 2011 17:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AGdymeMnqpJ4o0H7p3wMfv7Dw2Qg+PRqIz51fhVixGQ=; b=KHH10HTcwh5tG52hNxtd997+Gw1LDjkRmGLvDar/SymUHHgssaDFkDmVQPgNhrLtiF 14IV3EsiKssTQbdDGAohBuNpIzQzjHmIFYCNo0EqTyvR6nSYg6XBpOdkyHtBzv5ILgvh 2H1zorW4JglwIGAOe40v5bloP8glUnU9fmuJ8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=T6X7e/egYchJk/zrFIqFTqJwYN/qig6fApdw0HUmBZNCwvTSnDMHRvar8zFETYjM87 OP4iT0KzNiYrHIW681tTbhTgj6rk2xLBZBWfhv+MZ2pZz+7N7WkhLnJsGLiPYcL6IpJ3 WoYRElt4Cjp519K4QuSjIt+cZ4muZbJh8TpKk=
Received: by 10.68.69.43 with SMTP id b11mr2222803pbu.18.1306801738522; Mon, 30 May 2011 17:28:58 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id m9sm3239082pbd.71.2011.05.30.17.28.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 17:28:57 -0700 (PDT)
Message-ID: <4DE435FE.2050201@gmail.com>
Date: Mon, 30 May 2011 17:27:42 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Bjartur Thorlacius 
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>	<4DE3A064.8010404@gmail.com>	<4DE3B07F.9030407@gmx.de>	<4DE3C4E8.4000900@gmail.com>	<4DE3DB86.8000505@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 May 2011 00:29:00 -0000

On 05/30/2011 04:25 PM, Bjartur Thorlacius wrote:
>
> What queue? Most (but not all) HTTP methods operate on resources
> identified by URIs.
>    

We don't inline any of the http method calls, so they are all queued 
asynchronously. Programs, then, can easily examine the queue for 
optimizations, especially to stream them all together. That's the 
ReSTful queue. That's works well and simply quicker when there hundreds 
of queries between two end points.


>    
>> Any implication of an attacker... questionable on why would one stop
>> there, specifically, even if we assume "they're inside".
>>
>>      
> You don't necessarily have to be "inside" to be able to upload files.
> I'm thinking of a user registering as ".well-known" and uploading
> maliciously named and crafted files.

If someone is not logged in, for example, then one could issue one of 
the 3xx codes and possibly issue some private URL. I don't see the 
conflict there.

>   *All* HTTP servers out there will
> have to reserve the "/.well-known" prefix, if only to avoid serving a
> dangerous value of the max-conns property in the browser-hints file
> (and thereby values of other properties such as max-pipeline-depth).
>    

"have-to"?

The example uses the full path for simple conveyance, yet there could be 
 in container setups that implement RFC5785 and 
, especially when 
restricted to no nested directories. If there is no  then 
most likely fallback to the "User-Agent:" header if that exists; 
otherwise, eventually assume some past http provider on one end.


> Note that I don't disagree with RFC 5785. It's the right mechanism for
> certain tasks. I disagree with the apparent group consensus that
> discovery of browser hints are one of these tasks.
>
>    

Do you think that information should exist in the "User-Agent:" header 
and have everybody upgrade their browser together as one group? Maybe 
some rather use 'cloud' containers with restricted data driven flow, but 
I can think of too many other examples, and the 'cloud' idea is actually 
useful for an example as one step beyond as site (i.e. containers) on 
demand despite paths based on URIs in individual queries and synchronous 
end-to-end flow.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


From mnot@mnot.net  Mon May 30 23:28:59 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C60E06E1 for ; Mon, 30 May 2011 23:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.284
X-Spam-Level: 
X-Spam-Status: No, score=-105.284 tagged_above=-999 required=5 tests=[AWL=-2.685, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXEehbc6FJ5k for ; Mon, 30 May 2011 23:28:57 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 82BDCE06D4 for ; Mon, 30 May 2011 23:28:57 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.214.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 17389509DB for ; Tue, 31 May 2011 02:28:50 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 May 2011 16:28:48 +1000
References: <20110531062229.28776.82429.idtracker@ietfa.amsl.com>
To: Apps Discuss 
Message-Id: <0CE9268E-5802-4B0A-B643-F580E7F048B5@mnot.net>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 May 2011 06:28:59 -0000

FYI. Diffs at:
  =
http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-browser-hints-0=
2

Changelog:
  - removed Ref header and rearranged referer-based hints
  - added 'prefixlist' value type
  - changed omit-cookies from list of cookie names to prefixlist
  - added caching advice for 404s

Feedback appreciated, as always.



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: 31 May 2011 4:22:29 PM AEST
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt
> Reply-To: internet-drafts@ietf.org
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
> 	Title           : HTTP Browser Hints
> 	Author(s)       : Mark Nottingham
> 	Filename        : draft-nottingham-http-browser-hints-02.txt
> 	Pages           : 9
> 	Date            : 2011-05-30
>=20
>   Over time, Web browsers have adapted how they use HTTP based upon
>   common server configurations and behaviours.  While this is =
necessary
>   in the common case, it can be detrimental for performance and
>   interoperability.
>=20
>   This document establishes a mechanism whereby origin servers can =
make
>   available hints for browsers about their preferences and
>   capabilities, without imposing overhead on their interactions or
>   requiring support for them.
>=20
>   This is intended to allow browsers to safely optimise connections to
>   servers.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02=
.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.=
txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham   http://www.mnot.net/




From mnot@mnot.net  Tue May 31 16:57:30 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC96CE06E6; Tue, 31 May 2011 16:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.283
X-Spam-Level: 
X-Spam-Status: No, score=-105.283 tagged_above=-999 required=5 tests=[AWL=-2.684, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ7Ti+QZDZ6F; Tue, 31 May 2011 16:57:29 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B361CE06A0; Tue, 31 May 2011 16:57:29 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown [118.209.19.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6CD2D509DB; Tue, 31 May 2011 19:57:22 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Mark Nottingham 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 09:57:19 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav 
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org" , Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" , "http-state@ietf.org" , HTTP Working Group , OAuth WG 
Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 31 May 2011 23:57:30 -0000

Hi,

Reading draft -05.

The "normalized request string" contains the request-URI and values =
extracted from the Host header. Be aware that intermediaries can and do =
change these; e.g., they may change an absolute URI to a relative URI in =
the request-line, without affecting the semantics of the request. See =
[1] for details (it covers other problematic conditions too).

It would be more robust to calculate an effective request URI, as in =
[2].

Also, if you include a hash of the request body, you really need to =
include a hash of the body media type.

Generally, I think that people can and will want to include other =
headers; just because *some* developers can't get this right doesn't =
mean we should preclude *all* developers from doing it. It'd be really =
nice to see this either leverage DOSETA [3][4], or at least offer a =
clean transition path to it.

Regards,

1. =
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.=
2
2. =
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3
3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00
4. http://tools.ietf.org/html/draft-crocker-doseta-base-02


On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote:

> (Please discuss this draft on the Apps-Discuss  =
mailing list)
> =20
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
> =20
> The draft includes:
> =20
> * An HTTP authentication scheme using a MAC algorithm to authenticate =
requests (via a pre-arranged MAC key).
> * An extension to the Set-Cookie header, providing a method for =
associating a MAC key with a session cookie.
> * An OAuth 2.0 binding, providing a method of returning MAC =
credentials as an access token.
> =20
> Some background: OAuth 1.0 introduced an HTTP authentication scheme =
using HMAC for authenticating an HTTP request with partial cryptographic =
protection of the HTTP request (namely, the request URI, host, and =
port). The OAuth 1.0 scheme was designed for delegation-based use cases, =
but is widely =93abused=94 for simple client-server authentication (the =
poorly named =91two-legged=92 use case). This functionality has been =
separated from OAuth 2.0 and has been reintroduced as a standalone, =
generally applicable HTTP authentication scheme called MAC.
> =20
> Comments and feedback is greatly appreciated.
> =20
> EHL
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




From svartman95@gmail.com  Tue May 31 19:44:22 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4F9E078B for ; Tue, 31 May 2011 19:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkG-5qkslTbO for ; Tue, 31 May 2011 19:44:21 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A120E068F for ; Tue, 31 May 2011 19:44:21 -0700 (PDT)
Received: by gyf3 with SMTP id 3so2788089gyf.31 for ; Tue, 31 May 2011 19:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n18IRQfIis2fDJvvYlpzMo9eVZQqIEpg5Kf0+BxX6Kw=; b=aCadbJ2DGqySuGntfG5xJl9LZhV1cHdGy/e1HWmOgyPk6PemKVs3IFyjXv5sdqI3EA aybE/SgoGetDuyv/UejVcuFsDu3EKsuZ+KRcHb01OVdsesFinepJttaSCq/WVycfD1QI pOEk5XPtDfV1nWPJ3wmFLQiwjRH6e6ol160To=
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=fltmw0DC2Nzff7T9N7JRo3Deu2Xzm3QBsYQQwiWSim55Qnl8NJQaKH6RCrgJuXTxj7 C6sqWcKZH1YyYhht1sOPEHnoj8DxbMwQYMiFm6vX26VvCG/T8IPBktTKnUZbzF9V9ZOj OkuxMdj2kMHfMxmvw8TreNMuXvLDNprPtkl70=
MIME-Version: 1.0
Received: by 10.236.192.230 with SMTP id i66mr7813393yhn.482.1306896260569; Tue, 31 May 2011 19:44:20 -0700 (PDT)
Received: by 10.236.47.228 with HTTP; Tue, 31 May 2011 19:44:20 -0700 (PDT)
In-Reply-To: <4DE435FE.2050201@gmail.com>
References:  <70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net> <4DE3A064.8010404@gmail.com> <4DE3B07F.9030407@gmx.de> <4DE3C4E8.4000900@gmail.com> <4DE3DB86.8000505@gmail.com>  <4DE435FE.2050201@gmail.com>
Date: Wed, 1 Jun 2011 02:44:20 +0000
Message-ID: 
From: Bjartur Thorlacius 
To: Dzonatas Sol 
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Jun 2011 02:44:22 -0000

On 5/31/11, Dzonatas Sol  wrote:
> We don't inline any of the http method calls, so they are all queued
> asynchronously. Programs, then, can easily examine the queue for
> optimizations, especially to stream them all together. That's the
> ReSTful queue. That's works well and simply quicker when there hundreds
> of queries between two end points.
>
I thought responses to pipelined requests had to be returned in order,
breaking most optimization opportunities. I seam to be
misunderstanding something.

>> You don't necessarily have to be "inside" to be able to upload files.
>> I'm thinking of a user registering as ".well-known" and uploading
>> maliciously named and crafted files.
>
> If someone is not logged in, for example, then one could issue one of
> the 3xx codes and possibly issue some private URL. I don't see the
> conflict there.
>
We seem to misunderstand each other. I'm thinking of a hypothetical
server set up prior to RFC 5785 that allows users to choose the path
component of URIs for files they upload. On that server
/.well-known/browser-hints could refer to user content, yielding
terror.

>>   *All* HTTP servers out there will
>> have to reserve the "/.well-known" prefix, if only to avoid serving a
>> dangerous value of the max-conns property in the browser-hints file
>> (and thereby values of other properties such as max-pipeline-depth).
>>
>
> "have-to"?
>
Yes, so they don't let /.well-known/browser-hints refer to anything
else. There's hardly any risk of that happening accidentally, but it's
uncomfortably easy to plant a malicious browser-hints file at the
right location. It's common for multiple users to share a domain by
allocating one path component directly below root to each user as a
prefix. I can't think of a registry that accepts registrations from
untrusted users, but they surely exisy. Information under one prefix
shouldn't affect the server's stability.
Maybe this'll be less dangerous when I've slept some.

> The example uses the full path for simple conveyance, yet there could be
>  in container setups that implement RFC5785 and
> , especially when
> restricted to no nested directories. If there is no  then
> most likely fallback to the "User-Agent:" header if that exists;
> otherwise, eventually assume some past http provider on one end.
>
If there is no /.well-known/* then there's no problem. But as soon as
there is, browser may start interpreting it. I don't see what the
User-Agent header has to do with anything; User-Agent provides
information to servers, while browser-hints provide recommendations to
browsers.

> Do you think that information should exist in the "User-Agent:" header
> and have everybody upgrade their browser together as one group? Maybe
> some rather use 'cloud' containers with restricted data driven flow, but
> I can think of too many other examples, and the 'cloud' idea is actually
> useful for an example as one step beyond as site (i.e. containers) on
> demand despite paths based on URIs in individual queries and synchronous
> end-to-end flow.
>
You've lost me; there too many ideas in this paragraph for me to
comprehend at once. I'm not proposing adding any information to the
User-Agent header. From my point of view User-Agent is motly there for
backwards compatibility and telling the world how esotoric software
you use. There isn't any useful information therein.

From dzonatas@gmail.com  Tue May 31 22:29:27 2011
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB98E06DD for ; Tue, 31 May 2011 22:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.304
X-Spam-Level: 
X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=-2.665, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJvfvNCcKawh for ; Tue, 31 May 2011 22:29:25 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46E11E06E7 for ; Tue, 31 May 2011 22:29:25 -0700 (PDT)
Received: by pwi5 with SMTP id 5so2661333pwi.31 for ; Tue, 31 May 2011 22:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F/EWcgs3eIxiCln9X3gtLlt5x5FE34vQMWDk9/xnoi0=; b=rzNteVpdGojbGgaSPdi9+I1yn43eo3jTzpJpaR6F5tfFqirZD7Oqpa5dU1p+i/i23x Kl+d2joe1ySHqfcpJm8q326LoXBO/d1F5/cjkdkC4Go2GlkpxX5A1AeqdN9LbgSlEgbG z4xyljGBSILBggQIQHAd+dzIQRIRzJlCAHA50=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=C8srgm6yGr7WUwVtJvaceYYLfgMV0jRVGBwzwZIYPn6xIrhQEQBaDvzv1GJWjq/ku6 dEkrTCxJ+LgYn4cu/lZ+oaj6UXGAJ0dvnv9S0G/81A74IXGUtbePyMvpS+eMkE5xG0E3 pEu1VgFjLv4zvD6uK+8b3kR3y0Xdn+Yi5R49Q=
Received: by 10.68.5.234 with SMTP id v10mr945893pbv.132.1306906164824; Tue, 31 May 2011 22:29:24 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id c3sm715028pbk.93.2011.05.31.22.29.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 22:29:23 -0700 (PDT)
Message-ID: <4DE5CDEC.7040209@gmail.com>
Date: Tue, 31 May 2011 22:28:12 -0700
From: Dzonatas Sol 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Bjartur Thorlacius 
References: 	<70A19350-4EA8-4FB4-89CF-B6D4E7FA456B@mnot.net>	<4DE3A064.8010404@gmail.com>	<4DE3B07F.9030407@gmx.de>	<4DE3C4E8.4000900@gmail.com>	<4DE3DB86.8000505@gmail.com>		<4DE435FE.2050201@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Jun 2011 05:29:27 -0000

The existence of the "User-Agent:" proves that someone wanted that 
there, so from backwards compatibility, the process flow I wrote with 
the two "CONNECT /000" happens before any "User-Agent:" field exists.

first-hand: the state does not exist.
second-hand: the state existed or exists.

One intent is for stateful transfers with the ReSTful paradigm (this is 
simpler). The HTTP is there in the hypermedia (the two "CONNECT /000" 
given) in stream mode by "Content-Type:" multi-parts. We found we can't 
do stateful transfers with SSL without consistent major 
reimplementation, over and over through the years. I proved earlier (the 
flow format) how S/MIME can help solve that (if my expression is seen as 
one template of stateful transfers).

I'm just one scientist with lots of results. Some are useful and some 
are useless, and we don't have ordinary time to explain them all. I 
think you found something useful (to solve this further) even if neither 
of us has stated such specifically.

On 05/31/2011 07:44 PM, Bjartur Thorlacius wrote:
>
> You've lost me; there too many ideas in this paragraph for me to
> comprehend at once. I'm not proposing adding any information to the
> User-Agent header. From my point of view User-Agent is motly there for
> backwards compatibility and telling the world how esotoric software
> you use. There isn't any useful information therein.
>
>    


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant