From Claudio.Allocchio@garr.it Wed Dec 1 01:25:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE7728C0E9 for ; Wed, 1 Dec 2010 01:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JgnuYNQOB-M for ; Wed, 1 Dec 2010 01:25:27 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id A4EF728C0E3 for ; Wed, 1 Dec 2010 01:25:21 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oB19QQHN079475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 10:26:26 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB19QQHN079475 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=L6JoTctj9ApaD/fY600acTk3kcEWpJ11AshtdsiCjQMprvNSNYN2z1WGfQ9vLBkQJ s94HHAT3Z00JYXcfNhaVMkamuEIrs8FlMZTdHY8DiTOzGMKbA7hU5/AGtxmYIASM/zT xk/1OcQT2BTbZVGvBDP7dZi9rlpfUPSqjcmSSnk= Date: Wed, 1 Dec 2010 10:26:25 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: apps-discuss@ietf.org, jmpolk@cisco.com, john@schnizlein.org, marc.linsner@cisco.com, martin.thomson@andrew.com, bernarda@microsoft.com, iesg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [apps-discuss] apps-team review of draft-ietf-geopriv-rfc3825bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 09:25:32 -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-geopriv-rfc3825bis Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network) Review Date: 2010-11-30 IETF Last Call Date: 2010-10-11 IESG Telechat Date: 2010-12-02 Summary: This draft specifies quite well and clearly the problem to solve, and all its impications and scenarios. Examples in appendixes are useful to understand real cases and help implementors to avoid misunderstandings (even if at first sight the lenght balance of "normative text section" vs "appendix/examples sections" might look unfair). It looks ok for publication and it seems to clarfy all points raised. Just see the Minor issues and Nits below. Major Issues: None. Minor Issues: Section 2.2.1.2. Server Version Selection The sentence "A DHCPv4 server that provides location information cannot provide options with both version 0 and version 1 formats in the same response." does not use a normative language... it says "cannot"... Given also the explanation in the following of the text, I would suggest using normative language here, to avoid implementation problems, e.g.: "A DHCPv4 server that provides location information MUST NOT provide options with both version 0 and version 1 formats in the same response." Section 2.4.3. Altitude in Floors (AType = 2) The Altitude value is a 30bits fixed point, thus it can have a negative value. However in thr "AType = 2" (Floors) section I would suggest adding a sentence also to cover clearly "undel Ground Level" floors (... my main GigaPop is at -2 ... for example). "For instance, and undeground Servers room could be represented as -2.0" Nits: Boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) :-) go ahead! best regards, ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From Claudio.Allocchio@garr.it Wed Dec 1 01:29:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17E93A69DA; Wed, 1 Dec 2010 01:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJydduIOb-0q; Wed, 1 Dec 2010 01:29:26 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 9BC3C28B23E; Wed, 1 Dec 2010 01:29:25 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oB19UQdU079550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 10:30:27 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB19UQdU079550 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=jPkhRnR5aaZTXlAol0ujcRKt8V22QP2nro7zPZZ2AW92W9e/M3xl6SSWo0gFli1a8 YB3znOBBncgull99yTySAvPOdJJ5N4jwScH5YDYSglF1f1leCr2wZLiZ5EBAykv1JbA e/CK7rbplVjYlbMgWINNySfk9dsPwMYc3pUYVgY= Date: Wed, 1 Dec 2010 10:30:26 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Claudio Allocchio In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marc.linsner@cisco.com, apps-discuss@ietf.org, john@schnizlein.org, bernarda@microsoft.com, iesg@ietf.org, jmpolk@cisco.com Subject: Re: [apps-discuss] apps-team review of draft-ietf-geopriv-rfc3825bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 09:29:27 -0000 ANOTHER NIT: The Postfix program : host winse-6216-mail6.customer.frontbridge.com[131.107.115.215] said: 550 5.1.1 User unknown (in reply to RCPT TO command) you should Fix the Author's Addresses section, too. On Wed, 1 Dec 2010, Claudio Allocchio 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-geopriv-rfc3825bis > Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network) > Review Date: 2010-11-30 > IETF Last Call Date: 2010-10-11 > IESG Telechat Date: 2010-12-02 > > Summary: This draft specifies quite well and clearly the problem to solve, > and all its impications and scenarios. Examples in appendixes are useful to > understand real cases and help implementors to avoid misunderstandings (even > if at first sight the lenght balance of "normative text section" vs > "appendix/examples sections" might look unfair). It looks ok for publication > and it seems to clarfy all points raised. Just see the Minor issues and Nits > below. > > Major Issues: None. > > Minor Issues: > > > Section 2.2.1.2. Server Version Selection > > The sentence > > "A DHCPv4 server that provides location > information cannot provide options with both version 0 and version 1 > formats in the same response." > > does not use a normative language... it says "cannot"... Given also the > explanation in the following of the text, I would suggest using normative > language here, to avoid implementation problems, e.g.: > > "A DHCPv4 server that provides location > information MUST NOT provide options with both version 0 and version 1 > formats in the same response." > > Section 2.4.3. Altitude in Floors (AType = 2) > > The Altitude value is a 30bits fixed point, thus it can have a negative > value. However in thr "AType = 2" (Floors) section I would suggest adding a > sentence also to cover clearly "undel Ground Level" floors (... my main > GigaPop is at -2 ... for example). > > "For instance, and undeground Servers room could be represented as -2.0" > > Nits: > > Boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > > You're using the IETF Trust Provisions' Section 6.b License Notice > from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/) > > :-) > > go ahead! > > best regards, > > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R > Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From vkg@bell-labs.com Wed Dec 1 14:17:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F743A67E5 for ; Wed, 1 Dec 2010 14:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PadweByKS1es for ; Wed, 1 Dec 2010 14:17:50 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C290C3A67DF for ; Wed, 1 Dec 2010 14:17:49 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id oB1MJ1iJ012350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 16:19:01 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oB1MJ1Wo016767; Wed, 1 Dec 2010 16:19:01 -0600 (CST) Message-ID: <4CF6CA50.6000005@bell-labs.com> Date: Wed, 01 Dec 2010 16:21:04 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: draft-ietf-geopriv-rfc3825bis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Apps area review: draft-ietf-geopriv-rfc3825bis-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 22:17:51 -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-geopriv-rfc3825bis-14 Title: Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information Reviewer: Vijay K. Gurbani Review Date: Dec-1-2010 IETF Last Call Date: Not known IESG Telechat Date: Dec-2-2010 Summary: This draft is ready for publication as a Proposed Standard. I have some nits that could possibly be addressed. Nits: 1) S1: s/has a range of/is useful for a range of/ 2) In S1, the phrase "where retrieving it might be difficult in practice" --- what is it qualifying? The fact that the information is stored on the end device? or the fact that location information is stored somewhere else on the network? I suspect it is the latter, but just wanted to make sure. It could possibly be reworded as: OLD: An important feature of this specification is that after the relevant DHCP exchanges have taken place, the location information is stored on the end device rather than somewhere else, where retrieving it might be difficult in practice. NEW: An important feature of this specification is that after the relevant DHCP exchanges have taken place, the location information is stored on the end device rather than somewhere else. Storing this information at a place other than the end device makes retrieving it difficult in practice. 3) S1.2, suggested re-write: s/In this document, each of the three axes can be/In this document, each of the three axes --- Latitude, Longitude and Altitude --- can be/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From sm@elandsys.com Wed Dec 1 15:35:50 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056EC3A6821 for ; Wed, 1 Dec 2010 15:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB1Ae-MUZggo for ; Wed, 1 Dec 2010 15:35:24 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 040B13A681A for ; Wed, 1 Dec 2010 15:35:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.135]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB1NaBpV024389 for ; Wed, 1 Dec 2010 15:36:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291246578; bh=NIAwOduLD+gl6N6YwttSB4+3myc=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=adorN2q4i7E/T3lMBjlL/O2kF35ZnYAxRXhbElP8cUv1SOp6uVpbgdrjMdwlXjAPD GPEPfduQNUluIYLYSGggao4/Tq2FIxku4WZJy0s6OwclVOUsqQdpWTsOKeY+dav0qk JhsqFdExQv25dP6O34v0VyRTR8xgJisz2zrE/Zpk= Message-Id: <6.2.5.6.2.20101201152834.0e4b63f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Dec 2010 15:35:04 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Review Team Report for November 2010 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 23:35:51 -0000 Hello, The Applications Area Review Team provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The members of the team are selected from the IETF community, especially from among active participants and recognized experts in the Applications Area. The following reviews have been performed in November 2010: Reviewer I-D Ted Hardie draft-ietf-martini-gin-10 Claudio Allocchio draft-ietf-geopriv-rfc3825bis-14 Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From Claudio.Allocchio@garr.it Wed Dec 1 23:59:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FF03A6860 for ; Wed, 1 Dec 2010 23:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKwek6u324q1 for ; Wed, 1 Dec 2010 23:59:57 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 3DF763A6818 for ; Wed, 1 Dec 2010 23:59:56 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oB280u1u038410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Dec 2010 09:00:57 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB280u1u038410 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=k+zbTgvMDvHqCGqpf+pih/w+Q+XfehbZ1Ux0hTDlLFuQ0KidPAVvdArkHzHieAZVB RVY4m5t4BcqqhKxnn75fSaY0FWsGafPVEaG4BGN43AyVKu9dKhf0dqY02Mwleep/+Gh MdSw3LOrCqZBUYGqjnrbNcB53p1rD9mxK+G1SOM= Date: Thu, 2 Dec 2010 09:00:56 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: "Vijay K. Gurbani" In-Reply-To: <4CF6CA50.6000005@bell-labs.com> Message-ID: References: <4CF6CA50.6000005@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: draft-ietf-geopriv-rfc3825bis@tools.ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Apps area review: draft-ietf-geopriv-rfc3825bis-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 07:59:58 -0000 On Wed, 1 Dec 2010, Vijay K. Gurbani 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). ?? some misreading of assignment? I did the review of draft-ietf-geopriv-rfc3825bis-14 yesterday. :-) you were suppoused to review this one: 1. : Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Assigned to Vijay Gurbani Anyhow... additional nits also for draft-ietf-geopriv-rfc3825bis-14 are always welcome... but now draft-ietf-sipcore-event-rate-control needs a review. ;-) Claudio > 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-geopriv-rfc3825bis-14 > Title: Dynamic Host Configuration Protocol Options for > Coordinate-based Location Configuration Information > Reviewer: Vijay K. Gurbani > Review Date: Dec-1-2010 > IETF Last Call Date: Not known > IESG Telechat Date: Dec-2-2010 > Summary: This draft is ready for publication as a Proposed Standard. > I have some nits that could possibly be addressed. > > Nits: > > 1) S1: s/has a range of/is useful for a range of/ > > 2) In S1, the phrase "where retrieving it might be difficult > in practice" --- what is it qualifying? The fact that the > information is stored on the end device? or the fact that > location information is stored somewhere else on the network? > I suspect it is the latter, but just wanted to make sure. > > It could possibly be reworded as: > > OLD: > An important feature of this specification is that after the relevant > DHCP exchanges have taken place, the location information is stored > on the end device rather than somewhere else, where retrieving it > might be difficult in practice. > NEW: > An important feature of this specification is that after the relevant > DHCP exchanges have taken place, the location information is stored > on the end device rather than somewhere else. Storing this > information at a place other than the end device makes retrieving it > difficult in practice. > > 3) S1.2, suggested re-write: > s/In this document, each of the three axes can be/In this document, > each of the three axes --- Latitude, Longitude and Altitude --- can be/ > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From jyee@ca.afilias.info Fri Dec 3 12:57:13 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D99128C136 for ; Fri, 3 Dec 2010 12:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.265 X-Spam-Level: X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IUZKwjfwR8q for ; Fri, 3 Dec 2010 12:57:12 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 67B173A69A5 for ; Fri, 3 Dec 2010 12:57:09 -0800 (PST) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1POci2-0005hQ-4e; Fri, 03 Dec 2010 20:58:26 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1POci2-000633-3w; Fri, 03 Dec 2010 20:58:26 +0000 From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Dec 2010 15:58:25 -0500 Message-Id: To: Apps-Discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: cheshire@apple.com, marc@apple.com Subject: [apps-discuss] Apps-Review Team Review: draft-cheshire-dnsext-dns-sd-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 20:57: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 may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-cheshire-dnsext-dns-sd-07 Title: DNS-Based Service Discovery Reviewer: Joseph Yee Review Date: Dec 2, 2010 Summary: The draft is almost ready for publication as Standard Track but = has few issues that should be fixed before publication. I have a = "Question" section after the Nits section. They are merely questions = about this draft in general. No blocking issues there. ------------------ Major Issues:=20 1) Section 4.1, last paragraph, need update on terminologies The paragraph use terminologies from IDNA2003 (ie. UTF-8 NFC, punycode), = and best to update it to IDNA2008 (U-label, A-label, etc). The = paragraph needs to cite RFC5890 instead of RFC3492/3490. The = references, whether it's RFC 3490/3492/5980, are missing in both = normative and informative reference section. Note: Two issues mentioned here. Update of terminologies is Major. = The lack of reference is Minor (no repeat in Minor section).=20 ---- 2) Concerns on key/value pair in TXT Section 6.3, 2nd paragraph Section 6.4, 1st paragraph section 6.3: If an implementation sees unknown keys in a service TXT record, it MUST silently ignore them. section 6.4: The "Key" MUST be at least one character. Strings = beginning with an '=3D' character (i.e. the key is missing) SHOULD be silently ignored. If unknown-key (6.3) MUST be ignored, undefined-key (6.4) is more of = a configuration error than unknown-key. Undefined-key needs to have = same level of ignores in unknown-key. SHOULD gives the dangerous = "freedom". =20 Recommendation (Section 6.4, 1st paragraph) The "Key" MUST be at least one character. Strings beginning with an '=3D' character (i.e. the key is missing) MUST be silently ignored. ---- 3) Section 6.7 (1st paragraph), version tag being 1st key/value pair in = TXT records=20 The first paragraph mentioned if using version tag, it "require it = to be the first key/value pair in the TXT records" to help client to = determine if there's any compatibility concerns. In regular DNS, when = there are multiple TXT records, the order is giving out in "pseudo = random" order (some rotate the order in predictable manner). The first = order appearance can't be guarantee in regular DNS even version tag is = the first inserted/defined TXT into configuration. My recommendation is to update the paragraph to have client to = inspect version value after capturing all key/value pairs, and proceed = only after checking the compatibility concerns. =20 Note 1: I interpret the "require it to be the first key/value pair = in the TXT record" as equivalent to "MUST be the first pair for client = to receive". =20 ---- 4) Mandatory of TXT record (Section 6, general, interoperability) There are many SRV records deployed without the associated TXT. = With this draft trying to "merge" 2 sides of the world, this draft needs = to address the potential lack of TXT RR in some services. =20 The draft needs to bring up the following: - New services need to have TXT record, even it's empty (this was = addressed) - Client implementations need to be robust to expect TXT RR may not = be there - In absence of TXT, client implementations MAY - treat the service has empty parameter=20 OR - treat the service as not serviceable at the moment =20 NOTE: What's saying at client implementations are suggestion. I would = leave it to authors to determine the scenarios, but I believe the need = to expand the text (no pun intended). The current draft had gone in = great details to explain many issues (they are great), I believed this = draft is the right place to address it. ------------------ Minor Issues: 1) Section 4.1, 2nd paragraph on page 7 "However, the Unicode characters with longer UTF-8 encodings tend to be the more rarely- used ones, and tend to be the ones that convey greater meaning per character." recommendation "However, the Unicode characters with longer octet length under UTF-8 encoding tend to be = the more rarely- used ones, and tend to be the ones that convey greater meaning per character." ---- 2) Section 4.3, 2nd paragraph, first sentence original "Any dots in the portion should be escaped by preceding them = with a backslash" recommendation "Any dots in the portion MUST be escaped by preceding them = with a backslash" ---- 3) Section 7, 3rd paragraph, first sentence original "Application Protocol Names may be no more than fifteen characters (not counting the mandatory underscore)" recommendation "Application Protocol Names RECOMMENDED be no more than fifteen = characters (not counting the mandatory underscore)" This is a soft (recommendation) limit rather than hard limit. ----------------- Nits:=20 1) Status of this Memo, Last paragraph, the sole sentence. "This Internet-Draft will expire on 8th September 2010." Wrong date and not necessary. Boilerplate issue? ----------------- Questions 1. Ever thought of creating an ABNF for the whole service name? 2. What will the IANA Consideration section like after = draft-ietf-tsvwg-iana-ports published (what part will get deleted)? Is = DNS-SD draft depend on draft-ietf-tsvwg-iana-ports to publish first? = Wouldn't the suggestions of how IANA to manage service name be better = suggest in draft-ietf-tsvwg-iana-ports (and discuss there) instead? ----------------- Best Joseph= From brian.e.carpenter@gmail.com Fri Dec 3 19:46:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5223A69FC for ; Fri, 3 Dec 2010 19:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.278 X-Spam-Level: X-Spam-Status: No, score=-103.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxsLFCj2+2BW for ; Fri, 3 Dec 2010 19:46:45 -0800 (PST) Received: from mail-gy0-f177.google.com (mail-gy0-f177.google.com [209.85.160.177]) by core3.amsl.com (Postfix) with ESMTP id 596393A681D for ; Fri, 3 Dec 2010 19:46:45 -0800 (PST) Received: by gyg4 with SMTP id 4so6826243gyg.22 for ; Fri, 03 Dec 2010 19:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type; bh=LSg1emlMFbD6rXaxrmfjkR2JdRssYQ71Ka59lGpV4s0=; b=fuKrPsozoN0Rz/H85lLRA5EZEc2zhIWoByUDAp3eW8Z7xK6J38UgFyZLG2SHgU0l7Q +LHeu3OUbzJWA0f6+dAmANESH7Rcbpv+4aBgVSlEBpFRveHFYpJCmAhlGx9gmHIpFREr zx4HJlj4OugzswKu+f5kZMmTh+juk09NFqs2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; b=EEGdq1/36DTKKzamq7aSHhgoThtb69t/LIzb8q7bEt2fiV3Dfl7W8IxnIljyprWVX4 pvPJGyJyZbJjqA5mQgnUFtuTsj5k4WgMJhnSOUxljElE78gZiH1bmnF5Iwf5I2ykQwNI 9yDtLB8dUCK20OeylxRzJW7zGtsHrr96rcTpU= Received: by 10.90.24.10 with SMTP id 10mr4173491agx.179.1291434482358; Fri, 03 Dec 2010 19:48:02 -0800 (PST) Received: from [10.1.1.6] ([121.98.190.33]) by mx.google.com with ESMTPS id 26sm1542025yhl.23.2010.12.03.19.48.00 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Dec 2010 19:48:01 -0800 (PST) Message-ID: <4CF9B9EC.20409@gmail.com> Date: Sat, 04 Dec 2010 16:47:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Discuss Apps Content-Type: multipart/mixed; boundary="------------050206020502030402050703" Subject: [apps-discuss] [Fwd: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 03:46:46 -0000 This is a multi-part message in MIME format. --------------050206020502030402050703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I thought I should forward my Gen-ART review here, since it contains an opinion statement. See attachment. Brian -------- Original Message -------- Subject: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt Date: Sat, 04 Dec 2010 16:44:06 +1300 From: Brian E Carpenter Organization: University of Auckland To: draft-loreto-http-bidirectional.all@tools.ietf.org, General Area Review Team --------------050206020502030402050703 Content-Type: text/plain; name="draft-loreto-http-bidirectional-05-carpenter.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-loreto-http-bidirectional-05-carpenter.txt" SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gRm9y IGJhY2tncm91bmQgb24NCkdlbi1BUlQsIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0K DQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBM YXN0IENhbGwgY29tbWVudHMNCnlvdSBtYXkgcmVjZWl2ZS4NCg0KRG9jdW1lbnQ6IGRyYWZ0 LWxvcmV0by1odHRwLWJpZGlyZWN0aW9uYWwtMDUudHh0DQpSZXZpZXdlcjogQnJpYW4gQ2Fy cGVudGVyDQpSZXZpZXcgRGF0ZTogMjAxMC0xMi0wNA0KSUVURiBMQyBFbmQgRGF0ZTogMjAx MC0xMi0yMQ0KSUVTRyBUZWxlY2hhdCBkYXRlOiANCg0KU3VtbWFyeTogUmVhZHkgKHNhaWQg Z3J1ZGdpbmdseSkNCi0tLS0tLS0tDQoNCkNvbW1lbnQ6DQotLS0tLS0tLQ0KDQpUaGlzIGlz IHJlYWwgZXhhbXBsZSBvZiBwcm90b2NvbCBhYnVzZS4gSFRUUCB3YXNuJ3QgZGVzaWduZWQg Zm9yIHRoaXMgYW5kIGRvZXNuJ3QNCmRvIHRoaXMgcHJvcGVybHkuIFRoZSBkcmFmdCBpcyBu b24tanVkZ21lbnRhbCwgYW5kIHRoYXQgbWlnaHQgYmUgYSBtaXN0YWtlLg0KUGVyc29uYWxs eSwgaWYgSSB3YXMgaW4gdGhlIElFU0csIEknZCBiZSBjb25zaWRlcmluZyBhICJob2xkaW5n IG15IG5vc2UiIEFCU1RBSU4NCmJhbGxvdCB1bmxlc3Mgc29tZSB0ZXh0IHN0YXRpbmcgdGhh dCB0aGUgbWV0aG9kcyBkZXNjcmliZWQgYXJlIHJlYWxseSBiYWQgaWRlYXMgDQp3YXMgYWRk ZWQuDQoNCk1pbm9yIGlzc3VlOg0KLS0tLS0tLS0tLS0tDQoNCj4gMi4yLiAgSFRUUCBMb25n IFBvbGxpbmcgSXNzdWVzDQouLi4NCj4gICBBbGxvY2F0ZWQgUmVzb3VyY2VzOiAgT3BlcmF0 aW5nIHN5c3RlbXMgd2lsbCBhbGxvY2F0ZSByZXNvdXJjZXMgdG8NCj4gICAgICAgVENQL0lQ IGNvbm5lY3Rpb25zIA0KDQpOb3QganVzdCBvcGVyYXRpbmcgc3lzdGVtcy4gQXJlIHRoZXJl IGFueSBpbXBsaWNhdGlvbnMgZm9yIE5BVCByZXNvdXJjZXMgYW5kIHBvc3NpYmxlDQpsb3Nz IG9mIE5BVCBzdGF0ZSwgY2F1c2luZyBzb21lIGtpbmQgb2YgaGFuZ3VwLCBvciBhdCBsZWFz dCBsb3NzIG9mIHBvbGwgcmVzcG9uc2VzPw0KDQo= --------------050206020502030402050703-- From sm@resistor.net Sun Dec 5 01:29:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D833A6A56 for ; Sun, 5 Dec 2010 01:29:26 -0800 (PST) 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.416, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvJ18lKjC3Ur for ; Sun, 5 Dec 2010 01:29:24 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 87E693A69B9 for ; Sun, 5 Dec 2010 01:29:24 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oB59UYvR009138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Dec 2010 01:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1291541444; x=1291627844; bh=L574tvWsJc6veSbdksHy6VL8XoPJ/4zTe7GcYT0vu2s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=qKCW8fWDd9zHlUGdcVvlFgN3+q/FQI7b9uEa5sihk79hLGfmWSVYks5RUNUMVha95 X2LfQIXg/77hjOIW/noz70Z0x4NMgIywYMQ1rj583p581XdKHO0s8cppnoaJ0fKGa5 WVJPAOtNi3XuTChFj++2NE8SfAmlyEPKnn4l7hIM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1291541444; x=1291627844; bh=L574tvWsJc6veSbdksHy6VL8XoPJ/4zTe7GcYT0vu2s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=KiwQKn3CW6k2OgeJJlgoxTuEgAHahJ+8t7TJIcpfNKiEXi45IvCcKElUJL7Xtsrv/ 11iylwnK1TDlsKTEgxb/E4cmN/D/OCnj6gB6axg1AuRc5ouwv5pe8o71zwehr2iMM1 +i8kziMCg5eXpqPNTFiDUybHDrcEs9t5kQgO93FU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=X7ifxR5UgJoRFmomVoFqIpWPWO0QNUwlmV8RtzLSfpmOFIZ5tNevsn1FNJJXveLlO n5fUhjgB02IniRNtb0wpc/FIF6HrqWmo28iT4PCw5C678llDo3iUJOSl7qdUKbTL9VU z1T1Aqs7ckaH6p3Vbxp6+nQRqlY6t6ZNqWykN34= Message-Id: <6.2.5.6.2.20101204230117.0b7c3c80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Dec 2010 01:30:15 -0800 To: Brian E Carpenter From: SM In-Reply-To: <4CF9B9EC.20409@gmail.com> References: <4CF9B9EC.20409@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Discuss Apps Subject: [apps-discuss] HTTP wasn't designed for this (was: [Fwd: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt]) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 09:29:26 -0000 Hi Brain, This comment is not about the draft. At 19:47 03-12-10, Brian E Carpenter wrote: >I thought I should forward my Gen-ART review here, since it >contains an opinion statement. See attachment. Quoting the opinion statement and adding another draft to the mix: >This is real example of protocol abuse. HTTP wasn't designed for >this and doesn't >do this properly. The draft is non-judgmental, and that might be a mistake. draft-iab-ip-model-evolution-02 "attempts to document the properties of the IP layer as they are seen by upper-layer protocols and applications, and especially properties which were (and at times still are) incorrectly perceived to exist, as well as properties that would cause problems if changed." "With the advent of technologies such as Network Address Translators (NATs) and firewalls", ports 80 and 443 are frequently abused. Saying that "HTTP wasn't designed to do this" would probably fall into deaf ears. After all, TCP/IP over HTTP (RFC 3093) has been around for over ten years. >Personally, if I was in the IESG, I'd be considering a "holding my >nose" ABSTAIN >ballot unless some text stating that the methods described are >really bad ideas >was added. :-) Regards, -sm From lisa.dusseault@gmail.com Sun Dec 5 10:04:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78AEF28C115; Sun, 5 Dec 2010 10:04:12 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpwh8YDRZzJG; Sun, 5 Dec 2010 10:04:11 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 29AFF28C0E3; Sun, 5 Dec 2010 10:04:11 -0800 (PST) Received: by wyf23 with SMTP id 23so10463965wyf.31 for ; Sun, 05 Dec 2010 10:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=xkXrm0yuB0mnL9fKcGExgQaj7eEMf+A6rVsqxfkY3c4=; b=pkOquRYJ0tadtPOk8DIxcm6Om3Dta8X5s47i6Yuqwg8Q6sr+timtMyufuAUUKAA9QJ NnEgpyE+KVz2eBJbU+rqZVcODhNRbi50s1ffOOI9AIZ0GlWT5JGb/i93E4H3rfAxb9hp lkB1SGD6t+qR85hPNxYmJylkPFRkV35YzQKfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FHjqKBqYTVDwYCBXcLzfclB1Y7EPMv6zqmy39ZzGmQo+4YW8e8FckBt543DBEqs6u0 uqIC2sb9Dmq3qjZRt+HHzGAsf811O1wRLDhD17cig3XQPq5go2xr2w1dEFqy9fapaWka gdQTm8yHKxicuY18ato6eM1Ffv2I8EcCPmvME= MIME-Version: 1.0 Received: by 10.216.231.160 with SMTP id l32mr1647171weq.98.1291572330371; Sun, 05 Dec 2010 10:05:30 -0800 (PST) Received: by 10.216.30.131 with HTTP; Sun, 5 Dec 2010 10:05:30 -0800 (PST) Date: Sun, 5 Dec 2010 10:05:30 -0800 Message-ID: From: Lisa Dusseault To: Alexey Melnikov , SM , Peter Saint-Andre , apps-discuss@ietf.org, ietf@adambarth.com, http-state@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Apps area review of draft-ietf-httpstate-cookie-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 18:04:12 -0000 Hi Adam and others, 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). Document: draft-ietf-httpstate-cookie-19 Title: HTTP State Management Mechanism Reviewer: Lisa Dusseault Review Date: Dec 5, 2010 IETF Last Call Date: 2010-11-29 IESG Telechat Date: 2010-12-16] Summary: I recommend this document for publication. The document alone is quite valuable, and the actions to register headers and mark other documents as historic makes it even more useful to the Internet community. I also found this document had strong investigation, discussion and reviews in its history. Major Issues: None Minor Issues: Section 3. "Origin servers can send a Set-Cookie response header with any response.". Do we happen to know if it's more common for user agents to handle, or ignore Set-Cookie response headers on error responses? I'd be surprised if user-agents do handle them including on 500-level, 400-level and particularly on a 100 Continue response, but I haven't tested it. Is it part of your tests? So while this statement is factual, it might not help servers much. If my assumption about some clients ignoring the header on some classes of responses is correct, I would add that information to the document in a non-normative sentence. Section 4. As a matter of taste, my choice would be to make it even more clear that third-party cookie protections erected by user agents cannot provide the desired protection from cooperating servers. E.g. "No limitations on cookie use can prevent cooperating servers from injecting identifying information in dynamic URLs." Thank-you, Lisa Dusseault From ietf@adambarth.com Sun Dec 5 12:50:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A163A6B1F; Sun, 5 Dec 2010 12:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK5rZ1RDKdBu; Sun, 5 Dec 2010 12:50:02 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id C3EE43A6B1E; Sun, 5 Dec 2010 12:50:01 -0800 (PST) Received: by qyk34 with SMTP id 34so2807531qyk.10 for ; Sun, 05 Dec 2010 12:51:23 -0800 (PST) Received: by 10.224.60.198 with SMTP id q6mr3743279qah.273.1291582283490; Sun, 05 Dec 2010 12:51:23 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx.google.com with ESMTPS id nb14sm2993160qcb.0.2010.12.05.12.51.21 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Dec 2010 12:51:22 -0800 (PST) Received: by vws7 with SMTP id 7so4562320vws.31 for ; Sun, 05 Dec 2010 12:51:21 -0800 (PST) Received: by 10.220.189.138 with SMTP id de10mr1145400vcb.169.1291582281074; Sun, 05 Dec 2010 12:51:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.123.142 with HTTP; Sun, 5 Dec 2010 12:50:50 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Sun, 5 Dec 2010 12:50:50 -0800 Message-ID: To: Lisa Dusseault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Saint-Andre , SM , apps-discuss@ietf.org, http-state@ietf.org Subject: Re: [apps-discuss] Apps area review of draft-ietf-httpstate-cookie-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 20:50:03 -0000 On Sun, Dec 5, 2010 at 10:05 AM, Lisa Dusseault wrote: > Hi Adam and others, > > 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). > > Document: draft-ietf-httpstate-cookie-19 > Title: HTTP State Management Mechanism > Reviewer: Lisa Dusseault > Review Date: Dec 5, 2010 > IETF Last Call Date: 2010-11-29 > IESG Telechat Date: 2010-12-16] > Summary: I recommend this document for publication. =A0The document > alone is quite valuable, and the actions to register headers and mark > other documents as historic makes it even more useful to the Internet > community. I also found this document had strong investigation, > discussion and reviews in its history. > > Major Issues: None > Minor Issues: > Section 3. "Origin servers can send a Set-Cookie response header with > any response.". =A0Do we happen to know if it's more common for user > agents to handle, or ignore Set-Cookie response headers on error > responses? =A0I'd be surprised if user-agents do handle them including > on 500-level, 400-level and particularly on a 100 Continue response, > but I haven't tested it. =A0Is it part of your tests? I haven't tested those cases specifically. I suspect user agents process Set-Cookie headers for 500-level and 400-level responses. I'm less sure about 100-level responses. >=A0So while this > statement is factual, it might not help servers much. =A0If my > assumption about some clients ignoring the header on some classes of > responses is correct, I would add that information to the document in > a non-normative sentence. I'll test this and update the document accordingly. > Section 4. =A0As a matter of taste, my choice would be to make it even > more clear that third-party cookie protections erected by user agents > cannot provide the desired protection from cooperating servers. =A0E.g. > "No limitations on cookie use can prevent cooperating servers from > injecting identifying information in dynamic URLs." Sure. I wasn't exactly sure where you'd like this text to appear. We don't seem to mention third-party cookies in Section 4. In Section 5, we mention them three times. We also discuss them in the privacy considerations. We now have the following text in the Privacy Considerations section: In particular, two collaborating servers can often track users without using cookies at all by injecting identifying information into dynamic URLs. Thanks, Adam From evnikita2@gmail.com Mon Dec 6 01:21:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1CE3A6A25 for ; Mon, 6 Dec 2010 01:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.877 X-Spam-Level: X-Spam-Status: No, score=-3.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6xulhN6D-ga for ; Mon, 6 Dec 2010 01:21:42 -0800 (PST) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id A74233A6A00 for ; Mon, 6 Dec 2010 01:21:42 -0800 (PST) Received: by gxk8 with SMTP id 8so33200776gxk.27 for ; Mon, 06 Dec 2010 01:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=gXwVHf9aXDEpdFuEURGmXcex+XgImFzEzMOmTmWTQfI=; b=SGVcjsIl7Oh203yNvuqQEnJlVgdjif2qD/mIvaWo8WHjk1Y8exvZ+Hp4XlYZDDSBSZ PXMB80mUIuF+5f5Ap7DU6zCekfoAAV5zJdlzCr6OY4pmaxkIKeuDD6kpDwVF/E1X7thw Bq61sUNOZ6OJ9XSbhidLa8ugTj+j98eh1/2mA= 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; b=kn2jAODA0vHOl+LCX29qd8V94LNzDXPvjn1ik9+ydvAfvitRBS4MGXffSvyQ/s8zzw 8aWKn93wcG3hBRIaODjhj4oidl+RGcvykn9rnmQT1Lf454E6Pi+pW4pJHttiOb5jjxe2 qeYZb5EL84CsMOpcVpwzerZR+x0EJq87AyujM= MIME-Version: 1.0 Received: by 10.150.158.15 with SMTP id g15mr1379675ybe.57.1291627383945; Mon, 06 Dec 2010 01:23:03 -0800 (PST) Received: by 10.150.52.19 with HTTP; Mon, 6 Dec 2010 01:23:03 -0800 (PST) In-Reply-To: <4CFBB951.3040602@vigilsec.com> References: <4CFB5F77.9030603@gmail.com> <4CFBB951.3040602@vigilsec.com> Date: Mon, 6 Dec 2010 11:23:03 +0200 Message-ID: From: Mykyta Yevstifeyev To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Fwd: Draft Review Request X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 09:21:43 -0000 Hello all, I am writing to reuqest the review of my draft folowing the advice of Russ Housley (see below). All the best, Mykyta Yevstifeyev ---------- Forwarded message ---------- From: Russ Housley Date: Sun, 05 Dec 2010 11:09:53 -0500 Subject: Re: Draft Review Request To: Mykyta Yevstifeyev Dave Crocker has agreed to review the document. I also suggested a discussion on the Applications Area mail list. Russ On 12/5/2010 4:46 AM, Mykyta Yevstifeyev wrote: > Russ, > > I am writing to request the review of my draft. I think > that it concerns to General Area - so I ask you for the > review. Anyway I did not find a the corresponding > WG or even mailing list for it. > > You are able to find it here: > > https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1 > > > Could you please review it? > > Thank you for your time, > Mykyta Yevstifeyev > > From enrico.marocco@telecomitalia.it Mon Dec 6 06:35:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722FD3A67F9 for ; Mon, 6 Dec 2010 06:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.223 X-Spam-Level: X-Spam-Status: No, score=-100.223 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT9FuN6fdQgq for ; Mon, 6 Dec 2010 06:35:41 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 26AC63A67B4 for ; Mon, 6 Dec 2010 06:35:41 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Dec 2010 15:37:01 +0100 Received: from pc-moris.cselt.it (163.162.173.6) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Dec 2010 15:36:58 +0100 Message-ID: <4CFCF509.4000607@telecomitalia.it> Date: Mon, 6 Dec 2010 15:36:57 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080605030105000708070809" Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Apps-team review of draft-ietf-sipcore-reinvite-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 14:35:42 -0000 --------------ms080605030105000708070809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-sipcore-reinvite-07 Title: Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Reviewer: Enrico Marocco Review Date: Dec 6, 2010 Summary: This draft is basically ready for publication as an Informational RFC. A few clarifications suggested as minor issues. Major Issues: none. Minor Issues: In S. 4.1., the definition of local target is formally correct, but quite hard to parse. A simpler wording or maybe an example could save several brain cycles. In S. 4.4., last paragraph mixes normative and non-normative terminology and does not provide enough information for determining when mixing target refresh and media session changes may be considered acceptable. Nits: no typos found. --------------ms080605030105000708070809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITpDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGsjCCBZqgAwIBAgIDAZXQMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAwOTAyMjE0NjQ5 WhcNMTEwOTA0MDczNDM2WjCBnTEgMB4GA1UEDRMXMjUxNDUwLTVBOWo3QUhXTXgzNkVHa2Qx HjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRDb20gRnJl ZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVq5Ial9/2 azyFbgXY2+yMbEwHjhOWlXcwa7sdnRZ6BUXjusppAmshM1SPz+IZYfLdqancntuhkG/YKR4T Mg0SzWz3bDtCQjga0FSBQ5v2Up8kT/Q0F4/hkYrsTaKfL+WA2cjQtn8+K0fD3t/1tcuTuIHw fesN6w1VDn4HhFj3WGSXok9Zxk7609/Z4ZBqr3trmQ5Dl6pwb8pO1kE/ggH7qCx537ybIByS dxzcPNzbryGJiCfy4iXaws0xsl4xEQXDJFixLjgJm+AOTXb37AAgwKq+v9t3qIH6AHAbPBO6 I/qpoQ/zYMs1s9CoKkNDa9DsJlgyZdPH/vyFvCi/dDJ7AgMBAAGjggMIMIIDBDAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFCTMmq/In1ufC0+wdpHdBvezAYWcMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCoGA1UdEQQjMCGBH2Vucmljby5tYXJvY2NvQHRlbGVjb21pdGFsaWEuaXQwggFCBgNV HSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20g THRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNV HR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADWaaCjv4EfYGz4rrds8wLUpSPTi1tnO3hIm /Hg0SHqDRWRv3AG/OjUKYj+UKKAzhhEoYYrYCxhQfO3uEAC4Mez+DWDsBymKHsRkpf/0efoh mDe60HN81V6jB7hSB+FHaJ5QCBhJ/yasltL7HMl92dpRHYlnKXoXAiIoZUY54eYh09Gyk8su xgaiAwWtn4NnTqnQTjYOOly+WOZ/M6AlmkTErzjliIyAJOIceWzByJs6iIvLXzqpdoZ1+BzE TvoyaVidF13Xc8opUGSqYTyaVKwumrA5eUOZrLzdunkT8JuWgAx81syHYjSeD4ae+EoMFRJ8 gVm6vGPNETTSbFjGM38wggayMIIFmqADAgECAgMBldAwDQYJKoZIhvcNAQEFBQAwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDA5MDIyMTQ2NDlaFw0xMTA5MDQw NzM0MzZaMIGdMSAwHgYDVQQNExcyNTE0NTAtNUE5ajdBSFdNeDM2RUdrZDEeMBwGA1UEChMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRpZmlj YXRlIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxp YS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJWrkhqX3/ZrPIVuBdjb7Ixs TAeOE5aVdzBrux2dFnoFReO6ymkCayEzVI/P4hlh8t2pqdye26GQb9gpHhMyDRLNbPdsO0JC OBrQVIFDm/ZSnyRP9DQXj+GRiuxNop8v5YDZyNC2fz4rR8Pe3/W1y5O4gfB96w3rDVUOfgeE WPdYZJeiT1nGTvrT39nhkGqve2uZDkOXqnBvyk7WQT+CAfuoLHnfvJsgHJJ3HNw83NuvIYmI J/LiJdrCzTGyXjERBcMkWLEuOAmb4A5NdvfsACDAqr6/23eogfoAcBs8E7oj+qmhD/NgyzWz 0KgqQ0Nr0OwmWDJl08f+/IW8KL90MnsCAwEAAaOCAwgwggMEMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUJMyar8if W58LT7B2kd0G97MBhZwwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0R BCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCAUIGA1UdIASCATkwggE1 MIIBMQYLKwYBBAGBtTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEa gZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBv ZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJs ZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6Ap oCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz MS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEANZpoKO/gR9gbPiut2zzAtSlI9OLW2c7eEib8eDRIeoNFZG/c Ab86NQpiP5QooDOGEShhitgLGFB87e4QALgx7P4NYOwHKYoexGSl//R5+iGYN7rQc3zVXqMH uFIH4UdonlAIGEn/JqyW0vscyX3Z2lEdiWcpehcCIihlRjnh5iHT0bKTyy7GBqIDBa2fg2dO qdBONg46XL5Y5n8zoCWaRMSvOOWIjIAk4hx5bMHImzqIi8tfOql2hnX4HMRO+jJpWJ0XXddz yilQZKphPJpUrC6asDl5Q5msvN26eRPwm5aADHzWzIdiNJ4Php74SgwVEnyBWbq8Y80RNNJs WMYzfzGCA9AwggPMAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC AwGV0DAJBgUrDgMCGgUAoIICEDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xMDEyMDYxNDM2NTdaMCMGCSqGSIb3DQEJBDEWBBQ9t1R5/5/HKvYYoL9nk/LM hq9IxDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsG AQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMBldAw gacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwGV0DANBgkqhkiG9w0BAQEFAASCAQAtccIiFl+wrYF1+jzHVhchpfr6EcjbS95SpYpp IQmRpRmBwLfGL/qLfquaNKOQ97PbfhdXKK6kq88RZ6tMTLO/hp1Vg4G7MaJ6ZDN5JfKeuytK lKANhvCVNYmjmx+fAke/hHjxvpHi4OFYn4RNbr1MACyKVJXe6g6CWAj/ZPV/gTelzOeOLLFo ndK54bRWJwgAZGw4Q+mK9GIAffsWOOmffrDrAkpwzvt7TheDVCoimiLQsZnun4JoVqgfGuVF mDDs46/OjcsouaQHzL0Es2UE8R97jv9nwI5Yo0cMhCAUrooD2UuE9qP+6/Vb2Vy/JGiryFzk /dISGLqyFrVBVT20AAAAAAAA --------------ms080605030105000708070809-- From barryleiba.mailing.lists@gmail.com Mon Dec 6 07:00:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4633A6826 for ; Mon, 6 Dec 2010 07:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.414, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTs29pSsHkAb for ; Mon, 6 Dec 2010 07:00:21 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 37F6A3A6825 for ; Mon, 6 Dec 2010 07:00:21 -0800 (PST) Received: by gyb13 with SMTP id 13so6708299gyb.31 for ; Mon, 06 Dec 2010 07:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hibe28BluOo/pa7sHDmMaKakiBW2/4bYxSVj7r1TCPI=; b=E1a3OnuY+aMOhfEXCMd1TTJLJkBtl5t8JzTGh6VAZkZ30M3J+ymzuDFI+GYxk0kMLN j5lY3JkWxk83zkemTpV9x9xT3JTPITmWsmMFoKLJ4gib20gp0d9WMWsXqZiSweFsTNwu xqLPtDIMZRixXShafTxzKzmS/SUv+EGM68lSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=FmogyrF7xaphosM/YUi4gLK2OPTyOIzT43txKHToo4ZdSAjOUO8QKVgBvdXqAqO13V 7HJHBuo7DsOcwYbO6FXXmLVNVKLNNgQyo7+uiAWcYfGrEFwiaz110lsoANX/6arOP4HK CpkKzUKKm3dGOUDWAqFU4QV6aILF/oAYjzYxA= MIME-Version: 1.0 Received: by 10.42.240.2 with SMTP id ky2mr405207icb.529.1291647704374; Mon, 06 Dec 2010 07:01:44 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.225.4 with HTTP; Mon, 6 Dec 2010 07:01:44 -0800 (PST) Date: Mon, 6 Dec 2010 10:01:44 -0500 X-Google-Sender-Auth: kAqCoqoVtrvkJxykKhhMDinp5zs Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave CROCKER , apps-discuss@ietf.org Subject: [apps-discuss] Draft Review Request of draft-yevstifeyev-abnf-separated-lists-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 15:00:22 -0000 On Mon, Dec 6, 2010 at 4:23 AM, Mykyta Yevstifeyev wrote: > I am writing to reuqest the review of my draft folowing the advice of > Russ Housley ... > You are able to find it here: > > https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1 It's short; I'll give it a review for form here. I'll leave it to Dave to discuss why such list constructs aren't in 5234. Starting with a nit: How did you create this draft? The abstract is in the "wrong" place (I initially thought it was missing), so it seems you're not using the latest tools. The abstract is too brief. How about this?: OLD This document specifies Augmented Backus-Naur Form (ABNF) notation for separated lists. It updates RFC 5234. NEW This document defines Augmented Backus-Naur Form (ABNF) notation for representing lists separated by any specified character. It updates RFC 5234. Introduction: ABNF provides a possibility to express lists of elements, separated by commas (",") via the construction #element. Where is that documented? It's not in RFC 5234. Section 2: The ABNF isn't right. You don't show that and are optional, and you define them as having at least one digit each... and then you say that either or both can be omitted in some cases. Also, "" as an arithmetic difference isn't meaningful in ABNF. Perhaps the text that's there is sufficient to make it clear, but I think it won't pass automated processing. I'm not sure what the best way to handle that is. A section with a few examples would be helpful. Barry From evnikita2@gmail.com Mon Dec 6 08:10:09 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66F63A681F for ; Mon, 6 Dec 2010 08:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO5iFcAghVAU for ; Mon, 6 Dec 2010 08:10:07 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7A0A33A6813 for ; Mon, 6 Dec 2010 08:10:06 -0800 (PST) Received: by fxm9 with SMTP id 9so10216351fxm.31 for ; Mon, 06 Dec 2010 08:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=qpuumVHO1ITDAPQ8A2uZ1eU/hQPWWaLHYyBpbrO7+Cw=; b=AV26DqYoHoymCddIzJu4qEVfvelO/2PRZhVcpe+QPJ++UHw/BTGEYwNa0YFewigkRS 9izPJXWr7JR0T0aO4hO9TZHz4VKHtkuKW2fMgmPW3W5bkuIEQLQvoSXpx5UD9fzWWGbe uUPVoqZYX5YKZN8LhB/2DhFoH1/8GMpLKnGLQ= 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=qbgPkc8FaC7YY0xpjUm0H4qY3NQ/UIgEtrCmgLZaVpuk6Mj0gGVFkFN1KIhjUfTqmp s02t2XSw46Rh3hTz9N/HEd8N/bK4PoVNzgkdwA79SU/EmY3Ahf+mm+PSEUhTgRL53bvL eONE5qOjbTfCTHCi3GJ331QvM+zx39rKe3oWU= Received: by 10.223.126.5 with SMTP id a5mr5735550fas.47.1291651889652; Mon, 06 Dec 2010 08:11:29 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id d27sm2577886bkw.14.2010.12.06.08.11.27 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 08:11:28 -0800 (PST) Message-ID: <4CFD0B37.7010601@gmail.com> Date: Mon, 06 Dec 2010 18:11:35 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tony Hansen , Dave CROCKER , apps-discuss@ietf.org, Barry Leiba References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> In-Reply-To: <4CFCF71C.4050908@att.com> Content-Type: multipart/alternative; boundary="------------010201000700000009040401" Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 16:10:09 -0000 This is a multi-part message in MIME format. --------------010201000700000009040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Some answers: 06.12.2010 16:45, Tony Hansen wrote: > On 12/6/2010 2:36 AM, Mykyta Yevstifeyev wrote: >> 2010/12/6, Tony Hansen: >>> n = 0*DIGIT ;minimum amount of elements >>> m = 0*DIGIT ;maximum amount of elements >> Will be taken into consideration. >> Or, maybe, just *DIGIT . > > *DIGIT is fine Will be corrected in the next version of the draft. > >>> Your draft is inconsistent. In one place, you use "m" and another place >>> you use "o". >>> >>> I don't see why you use "o" at all -- I recommend you just use "m". >> o = m-n as m is maximum and n we have already used as it is mimimum. >> So we can use only he differebce between them. > > We *can*, but that doesn't mean we *should*. > > Other ABNF constructs use "m" and "n" directly -- they do *not* use > the difference. > > I think using the difference for this case is just asking for trouble > and will introduce subtle errors in future protocols that use this > construct. > > Consider the normal 5234 ABNF rule *element. is the minimum > and is the maximum. It is *not* *element. > > The 822 ABNF rule #element, which your rule is updating, also > used the same minimum and maximum values -- it did *not* use the > difference. However we MUST use *n* elements and MAY use all more *(m-n)*. If we say that we use the we MAY use more *m*, it is possible that we use *(m+n)* togetger, but we MUST use at most *m* while *m+n is not m* > > Note also: your introduction is incorrect. It talks about ABNF having > the # rule. However, it does not. The original 822 ABNF had the # > rule, but it was dropped when ABNF was extracted for the *234 series. Maybe I meant the construction form RFC 2616. > >>> It would be useful to have examples of where this production would have >>> been useful, such as some RFCs or I-Ds that have been written using the >>> "old way" and how they would be better written using the "new way". >> At the moment there are no acceptable examples - however I think the >> construction will be useful in future. > > Two points: Examples of future use would still be useful. > > And not having examples of places where this would have been useful in > the past is going to make it a very hard sell. > > There was a reason the #rule was dropped from the *234 series of RFCs > -- it wasn't found to be useful enough to keep for a general purpose > ABNF rule. > > Tony Hansen > tony@att.com > 06.12.2010 17:01, Barry Leiba wrote: > On Mon, Dec 6, 2010 at 4:23 AM, Mykyta Yevstifeyev wrote: >> I am writing to reuqest the review of my draft folowing the advice of >> Russ Housley > ... >> You are able to find it here: >> >> https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1 > It's short; I'll give it a review for form here. I'll leave it to > Dave to discuss why such list constructs aren't in 5234. > > Starting with a nit: How did you create this draft? The abstract is > in the "wrong" place (I initially thought it was missing), so it seems > you're not using the latest tools. > > The abstract is too brief. How about this?: > > OLD > This document specifies Augmented Backus-Naur Form (ABNF) notation > for separated lists. It updates RFC 5234. > > NEW > This document defines Augmented Backus-Naur Form (ABNF) notation > for representing lists separated by any specified character. It > updates RFC 5234. > Will be taken into consideration. > Introduction: > ABNF provides a possibility to express lists of elements, separated > by commas (",") via the construction#element. > > Where is that documented? It's not in RFC 5234. See above - in RFC2616 (however it is not a specification of ABNF). > > Section 2: > The ABNF isn't right. You don't show that and are optional, > and you define them as having at least one digit each... and then you > say that either or both can be omitted in some cases. > > Also, "" as an arithmetic difference isn't meaningful in ABNF. > Perhaps the text that's there is sufficient to make it clear, but I > think it won't pass automated processing. I'm not sure what the best > way to handle that is. > See above. > A section with a few examples would be helpful. Will be added. > Barry > Mykyta Yevstifeyev --------------010201000700000009040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Some answers:

06.12.2010 16:45, Tony Hansen wrote: Will be corrected in the next version of the draft.

Your draft is inconsistent. In one place, you use "m" and another place
you use "o".

I don't see why you use "o" at all -- I recommend you just use "m".
o = m-n as m is maximum and n we have already used as it is mimimum.
So we can use only he differebce between them.

We *can*, but that doesn't mean we *should*.

Other ABNF constructs use "m" and "n" directly -- they do *not* use the difference.

I think using the difference for this case is just asking for trouble and will introduce subtle errors in future protocols that use this construct.

Consider the normal 5234 ABNF rule <a>*<b>element. <a> is the minimum and <b> is the maximum. It is *not* <a>*<b-a>element.

The 822 ABNF rule <a>#<b>element, which your rule is updating, also used the same minimum and maximum values -- it did *not* use the difference.
However we MUST use *n* elements and MAY use all more *(m-n)*. If we say that we use the we MAY use more *m*, it is possible that we use *(m+n)* togetger, but we MUST use at most *m* while
m+n is not m

Note also: your introduction is incorrect. It talks about ABNF having the # rule. However, it does not. The original 822 ABNF had the # rule, but it was dropped when ABNF was extracted for the *234 series.
Maybe I meant the construction form RFC 2616.

It would be useful to have examples of where this production would have
been useful, such as some RFCs or I-Ds that have been written using the
"old way" and how they would be better written using the "new way".
At the moment there are no acceptable examples - however I think the
construction will be useful in future.

Two points: Examples of future use would still be useful.

And not having examples of places where this would have been useful in the past is going to make it a very hard sell.

There was a reason the #rule was dropped from the *234 series of RFCs -- it wasn't found to be useful enough to keep for a general purpose ABNF rule.

    Tony Hansen
    tony@att.com


06.12.2010 17:01, Barry Leiba wrote: 
On Mon, Dec 6, 2010 at 4:23 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:

I am writing to reuqest the review of my draft folowing the advice of
Russ Housley

...

You are able to find it here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1

It's short; I'll give it a review for form here.  I'll leave it to
Dave to discuss why such list constructs aren't in 5234.

Starting with a nit: How did you create this draft?  The abstract is
in the "wrong" place (I initially thought it was missing), so it seems
you're not using the latest tools.

The abstract is too brief.  How about this?:

OLD
   This document specifies Augmented Backus-Naur Form (ABNF) notation
   for separated lists. It updates RFC 5234.

NEW
   This document defines Augmented Backus-Naur Form (ABNF) notation
   for representing lists separated by any specified character. It
updates RFC 5234.
Will be taken into consideration.
Introduction:
   ABNF provides a possibility to express lists of elements, separated
   by commas (",") via the construction <a>#<b>element.

Where is that documented?  It's not in RFC 5234.
See above - in RFC2616 (however it is not a specification of ABNF).

Section 2:
The ABNF isn't right.  You don't show that <n> and <m> are optional,
and you define them as having at least one digit each... and then you
say that either or both can be omitted in some cases.

Also, "<m-n>" as an arithmetic difference isn't meaningful in ABNF.
Perhaps the text that's there is sufficient to make it clear, but I
think it won't pass automated processing.  I'm not sure what the best
way to handle that is.
See above.
A section with a few examples would be helpful.
Will be added.
Barry
Mykyta Yevstifeyev
--------------010201000700000009040401-- From tony@att.com Mon Dec 6 08:36:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDBD3A6828 for ; Mon, 6 Dec 2010 08:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGBPi4wA+XId for ; Mon, 6 Dec 2010 08:36:55 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id D5FFE3A681D for ; Mon, 6 Dec 2010 08:36:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-2.tower-161.messagelabs.com!1291653251!35334051!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 20063 invoked from network); 6 Dec 2010 16:34:36 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Dec 2010 16:34:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6GYUtl015421 for ; Mon, 6 Dec 2010 11:34:31 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6GYPCS015307 for ; Mon, 6 Dec 2010 11:34:25 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6GY55P002501 for ; Mon, 6 Dec 2010 11:34:05 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6GY1sx002367 for ; Mon, 6 Dec 2010 11:34:01 -0500 Received: from [135.70.226.222] (vpn-135-70-226-222.vpn.east.att.com[135.70.226.222]) by maillennium.att.com (mailgw1) with ESMTP id <20101206163401gw1004lkl6e> (Authid: tony); Mon, 6 Dec 2010 16:34:01 +0000 X-Originating-IP: [135.70.226.222] Message-ID: <4CFD1078.6030902@att.com> Date: Mon, 06 Dec 2010 11:34:00 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> In-Reply-To: <4CFD0B37.7010601@gmail.com> Content-Type: multipart/alternative; boundary="------------000407010009060504000901" Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 16:36:57 -0000 This is a multi-part message in MIME format. --------------000407010009060504000901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/6/2010 11:11 AM, Mykyta Yevstifeyev wrote: > Hi all, > > Some answers: >>>> Your draft is inconsistent. In one place, you use "m" and another >>>> place >>>> you use "o". >>>> >>>> I don't see why you use "o" at all -- I recommend you just use "m". >>> o = m-n as m is maximum and n we have already used as it is mimimum. >>> So we can use only he differebce between them. >> >> We *can*, but that doesn't mean we *should*. >> >> Other ABNF constructs use "m" and "n" directly -- they do *not* use >> the difference. >> >> I think using the difference for this case is just asking for trouble >> and will introduce subtle errors in future protocols that use this >> construct. >> >> Consider the normal 5234 ABNF rule *element. is the minimum >> and is the maximum. It is *not* *element. >> >> The 822 ABNF rule #element, which your rule is updating, also >> used the same minimum and maximum values -- it did *not* use the >> difference. > However we MUST use *n* elements and MAY use all more *(m-n)*. If we > say that we use the we MAY use more *m*, it is possible that we use > *(m+n)* togetger, but we MUST use at most *m* while > *m+n is not m* m+n is not m, nor is m-n. The second number that is used is the * and # rules is not how many more are allowed beyond the minimum, but really is the maximum. That is, 2*3 and 2#3 mean a minimum of 2 and a maximum of 3 -- it's not a minimum of 2 plus possible 3 more for a maximum of 5. This rule should do likewise. >> Note also: your introduction is incorrect. It talks about ABNF having >> the # rule. However, it does not. The original 822 ABNF had the # >> rule, but it was dropped when ABNF was extracted for the *234 series. > Maybe I meant the construction form RFC 2616. That's fine -- say so then. Note that the #rule in 2616 also uses a minimum of n and a maximum of m -- it does not use a difference for the second number. If you're going to offer this as an update to RFC 5234, you may wish to specify that the #rule be added in as well. Tony Hansen tony@att.com --------------000407010009060504000901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/6/2010 11:11 AM, Mykyta Yevstifeyev wrote:
Hi all,

Some answers:
Your draft is inconsistent. In one place, you use "m" and another place
you use "o".

I don't see why you use "o" at all -- I recommend you just use "m".
o = m-n as m is maximum and n we have already used as it is mimimum.
So we can use only he differebce between them.

We *can*, but that doesn't mean we *should*.

Other ABNF constructs use "m" and "n" directly -- they do *not* use the difference.

I think using the difference for this case is just asking for trouble and will introduce subtle errors in future protocols that use this construct.

Consider the normal 5234 ABNF rule <a>*<b>element. <a> is the minimum and <b> is the maximum. It is *not* <a>*<b-a>element.

The 822 ABNF rule <a>#<b>element, which your rule is updating, also used the same minimum and maximum values -- it did *not* use the difference.
However we MUST use *n* elements and MAY use all more *(m-n)*. If we say that we use the we MAY use more *m*, it is possible that we use *(m+n)* togetger, but we MUST use at most *m* while
m+n is not m

m+n is not m, nor is m-n. The second number that is used is the * and # rules is not how many more are allowed beyond the minimum, but really is the maximum. That is, 2*3 and 2#3 mean a minimum of 2 and a maximum of 3 -- it's not a minimum of 2 plus possible 3 more for a maximum of 5.

This rule should do likewise.

Note also: your introduction is incorrect. It talks about ABNF having the # rule. However, it does not. The original 822 ABNF had the # rule, but it was dropped when ABNF was extracted for the *234 series.
Maybe I meant the construction form RFC 2616.

That's fine -- say so then.

Note that the #rule in 2616 also uses a minimum of n and a maximum of m -- it does not use a difference for the second number.

If you're going to offer this as an update to RFC 5234, you may wish to specify that the #rule be added in as well.

    Tony Hansen
    tony@att.com
--------------000407010009060504000901-- From evnikita2@gmail.com Mon Dec 6 08:41:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B603A686C for ; Mon, 6 Dec 2010 08:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuOAUr5hPKj4 for ; Mon, 6 Dec 2010 08:41:19 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6E4C23A6873 for ; Mon, 6 Dec 2010 08:40:01 -0800 (PST) Received: by fxm9 with SMTP id 9so10245883fxm.31 for ; Mon, 06 Dec 2010 08:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YczsAfVn5sIYOoK4qpsG+I0tdVBaFpgbjErRGY1DYyA=; b=PPul6CH9xdItVZBHWfNQXTF/sGVDQCvEVyacWxnIIU4ghae5UEZiSOLJbWv5zga0+B FtwDO3HpWbzz8m5PSWgzJ7fFFgwyiJTsS2m+X4GcSkiQLkFUtFLkrb74ZDJ28Tcm9lOq 89ApDwoYUyCLzGJoE6W1rOrGlwCk8GCKo5c4c= 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=svptBDt+QMeP5fQiwpCgWaR/3J1tsstRwVSAQCaAeyxU0hI7MZ9sLpOP0jHHwsKLqW AwruZBoELQTVdkg5x9OErgAhvIgGwNOklTc35+VpJC9wUlBKVVPRAFopJDhFtLa7OTUL TvZIRTwKoOLZ2Z2oNs8/IbRB07SGAicg9pvyg= Received: by 10.223.86.16 with SMTP id q16mr5812783fal.58.1291653684059; Mon, 06 Dec 2010 08:41:24 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id g8sm2595235bkg.11.2010.12.06.08.41.21 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 08:41:23 -0800 (PST) Message-ID: <4CFD1238.4090902@gmail.com> Date: Mon, 06 Dec 2010 18:41:28 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> In-Reply-To: <4CFD0B37.7010601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Dave CROCKER Subject: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 16:41:21 -0000 Hello all, FYI, a new version of the my draft is available. The link is given below. The link to the draft: https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ Almost all comments and suggestions were taken into account. Among other: -updated ABNF; -added Examples section; -added Acknowledgments section; -other minor changes. Any suggestions for improvement are welcome. All the best, Mykyta Yevstifeyev From tony@att.com Mon Dec 6 10:07:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DF63A684B for ; Mon, 6 Dec 2010 10:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJM-LALA-LYo for ; Mon, 6 Dec 2010 10:07:06 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 7C8873A6822 for ; Mon, 6 Dec 2010 10:07:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-10.tower-167.messagelabs.com!1291658903!25990682!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 6502 invoked from network); 6 Dec 2010 18:08:26 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Dec 2010 18:08:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6I8htx013707 for ; Mon, 6 Dec 2010 13:08:43 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6I8eAH013683 for ; Mon, 6 Dec 2010 13:08:40 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6I8KKa008277 for ; Mon, 6 Dec 2010 13:08:20 -0500 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6I8GqP008158 for ; Mon, 6 Dec 2010 13:08:17 -0500 Received: from [135.70.94.119] (vpn-135-70-94-119.vpn.swst.att.com[135.70.94.119]) by maillennium.att.com (mailgw1) with ESMTP id <20101206180815gw1004lklne> (Authid: tony); Mon, 6 Dec 2010 18:08:15 +0000 X-Originating-IP: [135.70.94.119] Message-ID: <4CFD268E.3090701@att.com> Date: Mon, 06 Dec 2010 13:08:14 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1078.6030902@att.com> In-Reply-To: <4CFD1078.6030902@att.com> Content-Type: multipart/alternative; boundary="------------080402050606030300050108" Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:07:07 -0000 This is a multi-part message in MIME format. --------------080402050606030300050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/6/2010 11:34 AM, Tony Hansen wrote: > ... I'm happy with the definitions of n, m and o that are given in -01. >>> Note also: your introduction is incorrect. It talks about ABNF >>> having the # rule. However, it does not. The original 822 ABNF had >>> the # rule, but it was dropped when ABNF was extracted for the *234 >>> series. >> Maybe I meant the construction form RFC 2616. > > That's fine -- say so then. > > Note that the #rule in 2616 also uses a minimum of n and a maximum of > m -- it does not use a difference for the second number. > > If you're going to offer this as an update to RFC 5234, you may wish > to specify that the #rule be added in as well. You may wish to add to the Introduction that RFCs 733, 822, 1945, 2068, 2543, 2616 and 2831 all defined a limited version of this rule, specifically for a comma separator. More comments from version -01: I disagree with adding SP / HT to the production list for a: a = VCHAR / SP / HT / Your example that uses this: 1^(SP)element indicates the list of elements separated by spaces which consists of any amount of elements but not less than 1. has serious issues as a protocol element. It allows for arbitrary amounts of SP or HT followed by a single SP followed by arbitary amounts of SP or HT. What any self-respecting protocol would really want is a list separated by at least one SP or HT, as in 1*(1*LWS element) This is more obvious and exact. I'd hate to write a parser for 1^(SP), or debug protocol problems with it. (Is there really at least one SP character between those elements?) The example ^(-)element indicates the list of elements separated by hyphens ("-") cannot use a bare "-" like that. It must be specified as ^("-")element Hope this helps. I think it would be useful to find ABNF constructs in existing protocols that provide for lists and give examples of how their ABNF would have been simplified if this new ABNF construct were available. Tony Hansen tony@att.com --------------080402050606030300050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/6/2010 11:34 AM, Tony Hansen wrote:
...
I'm happy with the definitions of n, m and o that are given in -01.
Note also: your introduction is incorrect. It talks about ABNF having the # rule. However, it does not. The original 822 ABNF had the # rule, but it was dropped when ABNF was extracted for the *234 series.
Maybe I meant the construction form RFC 2616.

That's fine -- say so then.

Note that the #rule in 2616 also uses a minimum of n and a maximum of m -- it does not use a difference for the second number.

If you're going to offer this as an update to RFC 5234, you may wish to specify that the #rule be added in as well.

You may wish to add to the Introduction that RFCs 733, 822, 1945, 2068, 2543, 2616 and 2831 all defined a limited version of this rule, specifically for a comma separator.

More comments from version -01:

I disagree with adding SP / HT to the production list for a:

    a = VCHAR / SP / HT / <any other separator>

Your example that uses this:

    1^(SP)element indicates the list of elements separated by spaces
    which consists of any amount of elements but not less than 1.

has serious issues as a protocol element. It allows for arbitrary amounts of SP or HT followed by a single SP followed by arbitary amounts of SP or HT. What any self-respecting protocol would really want is a list separated by at least one SP or HT, as in

    1*(1*LWS element)

This is more obvious and exact. I'd hate to write a parser for 1^(SP), or debug protocol problems with it. (Is there really at least one SP character between those elements?)

The example

    ^(-)element indicates the list of elements separated by hyphens ("-")

cannot use a bare "-" like that. It must be specified as

    ^("-")element

Hope this helps.

I think it would be useful to find ABNF constructs in existing protocols that provide for lists and give examples of how their ABNF would have been simplified if this new ABNF construct were available.

    Tony Hansen
    tony@att.com
--------------080402050606030300050108-- From barryleiba.mailing.lists@gmail.com Mon Dec 6 10:18:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E543A684B for ; Mon, 6 Dec 2010 10:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.406, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuNiWnvOhKOf for ; Mon, 6 Dec 2010 10:18:20 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6D3723A6838 for ; Mon, 6 Dec 2010 10:18:20 -0800 (PST) Received: by ywk9 with SMTP id 9so114091ywk.31 for ; Mon, 06 Dec 2010 10:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=lKqC8wTQLCzP7McdMeibmQGC/CFK2bIxDx67EF3LSb0=; b=O/Pf/p9vfQfJWj00ORyTV88whsC/oGqHOVyLPSuOQyRiVY5Fp4HMIdxIFEK7aGaPGI UeSIJx0z4kL4greMzj2wRPmG0k6Gs0bJ0L0iL1RomIgGhbruCxxhPt4XjsbbL5pwAChf 47w642zToIxnQYaYoFn5NIRm4tISPnSGLQNCc= 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=WH5+Omkwqum3u8kC62bvDy12tbls0oHNW7X1dEHgBfLCYD6S6vgN/giGbGRbwdRxv/ OwV8SUnbzBWaJ3wEa2dpUrzs7Gsj9oatvpLrIrWz72gVrqZHKw2Z2KyHSkFb1wAFwnfb nFgDW9s3sa3EPj2JmF+2TXAzspGhimukONqdM= MIME-Version: 1.0 Received: by 10.42.165.131 with SMTP id k3mr1633859icy.312.1291659583700; Mon, 06 Dec 2010 10:19:43 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.225.4 with HTTP; Mon, 6 Dec 2010 10:19:43 -0800 (PST) In-Reply-To: <4CFD1238.4090902@gmail.com> References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> Date: Mon, 6 Dec 2010 13:19:43 -0500 X-Google-Sender-Auth: VXHuwkxSQVp_rtrNEBLMUbztjuc Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:18:21 -0000 > https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ > > Almost all comments and suggestions were taken > into account. Among other: > -updated ABNF; > -added Examples section; > -added Acknowledgments section; > -other minor changes. The changes to the ABNF are good, and they resolve my concerns from -00. I note a remaining problem with the ABNF that I missed the first time: n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) The first clause on the right is incorrect: it specifies occurrences of with *no* between them. As you add that, you need to make sure to get the cases where n=0 and n=1 correct, as well as where n=m (I think that last one is already OK). This points out the difficulty of getting such a general list construct defined correctly, and shows why it was removed. I agree with Tony that if you can't include examples of how we should have had this before, it'll be hard to convince the community and the IESG that it's needed now. We can always come up with things that *might* be useful, but part of the challenge is keeping the language as simple as possible (and no simpler). Barry From john-ietf@jck.com Mon Dec 6 12:15:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FAF3A68A0 for ; Mon, 6 Dec 2010 12:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD8Xo8QVQR0W for ; Mon, 6 Dec 2010 12:15:08 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4BFD93A6894 for ; Mon, 6 Dec 2010 12:15:08 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PPhTn-000NhO-GB; Mon, 06 Dec 2010 15:16:11 -0500 Date: Mon, 06 Dec 2010 15:16:10 -0500 From: John C Klensin To: Barry Leiba , Tony Hansen , Mykyta Yevstifeyev Message-ID: <73E9EBC74013BAFC7501F9A2@PST.JCK.COM> In-Reply-To: References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@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 Cc: Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 20:15:10 -0000 --On Monday, December 06, 2010 13:08 -0500 Tony Hansen wrote: > I think it would be useful to find ABNF constructs in existing > protocols that provide for lists and give examples of how > their ABNF would have been simplified if this new ABNF > construct were available. and --On Monday, December 06, 2010 13:19 -0500 Barry Leiba wrote: > I agree with Tony that if you can't include examples of how we > should have had this before, it'll be hard to convince the > community and the IESG that it's needed now. We can always > come up with things that *might* be useful, but part of the > challenge is keeping the language as simple as possible (and > no simpler). And _that_, it seems to me, is the more fundamental problem with this proposal. One can always add more elements, constructors, or decorations to a metalanguage like this one. One can also go minimalist: while some things would be quite tedious to express, I don't believe there is anything that can be expressed in RFC 5234 ABNF, with or without this extension, that cannot be expressed in classical/original BNF. The advantage of a more powerful metalanguage is that expressions become more concise, often leading to greater clarity for those who understand it. The disadvantage is that the language becomes harder to write optimally and _much_ harder to examine for errors and debug. Empirically, ABNF has already become daunting enough that we need to talk about ABNF experts in the IETF, that people routinely get grammars written in ABNF wrong, and that it is not a metalanguage that most of those who can otherwise write specs in the IETF feel that they can use efficiently and accurately. The question shouldn't be whether we can describe a new feature of find syntax for it. It should be whether that new feature is really important enough to justify the additional complexity it adds to the metalanguage, especially if the chosen syntax makes the metalanguage more subtle and/or obscure. IMO, that case has not been made at all convincingly yet. The sorts of examples that Barry and Tony suggest would be a useful step in the process of convincing people, but I suggest that, unless it can be shown that this construction actually simplifies a large number of practical cases, every error we find in the ABNF when documents that use the metalanguage are examine is an argument against more operators and complexity. john From julian.reschke@gmx.de Mon Dec 6 15:01:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE6728C0CF for ; Mon, 6 Dec 2010 15:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.54 X-Spam-Level: X-Spam-Status: No, score=-104.54 tagged_above=-999 required=5 tests=[AWL=-1.941, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6x6TZKM2rIz for ; Mon, 6 Dec 2010 15:01:33 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 40ED53A68CD for ; Mon, 6 Dec 2010 15:01:32 -0800 (PST) Received: (qmail invoked by alias); 06 Dec 2010 23:02:56 -0000 Received: from p508FC319.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.195.25] by mail.gmx.net (mp070) with SMTP; 07 Dec 2010 00:02:56 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19aLhdH/79avl55+Hi1/p5EA9nD6Di2mfZxDz7x5G n40V7LCnns3WNC Message-ID: <4CFD6B9C.2070807@gmx.de> Date: Tue, 07 Dec 2010 00:02:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: John C Klensin References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <73E9EBC74013BAFC7501F9A2@PST.JCK.COM> In-Reply-To: <73E9EBC74013BAFC7501F9A2@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mykyta Yevstifeyev , Barry Leiba , Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:01:34 -0000 On 06.12.2010 21:16, John C Klensin wrote: > ... > IMO, that case has not been made at all convincingly yet. The > sorts of examples that Barry and Tony suggest would be a useful > step in the process of convincing people, but I suggest that, > unless it can be shown that this construction actually > simplifies a large number of practical cases, every error we > find in the ABNF when documents that use the metalanguage are > examine is an argument against more operators and complexity. > ... Right. We spent a considerable amount of time in 2008 and 2009 on HTTPbis ABNF work, and we ended up *keeping* the # syntax for the actual spec text, but added a normative mapping to RFC 5234 ABNF, and also have auto-generated appendices with the expanded notation. See and If we *were* adding features to RFC 5234, the one thing I'm missing most is a shorthand notation for defining a set of characters as a difference from another set, such as myoctdigits = DIGIT - ( "8" / "0" ) Without this feature, many people use prose production instead (""), or create proper ABNF which then is hard to follow. Best regards, Julian From julian.reschke@gmx.de Mon Dec 6 15:05:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E939728C0CF for ; Mon, 6 Dec 2010 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.509 X-Spam-Level: X-Spam-Status: No, score=-104.509 tagged_above=-999 required=5 tests=[AWL=-1.910, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuDqnfPIa4oG for ; Mon, 6 Dec 2010 15:05:37 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id A56BF3A68D6 for ; Mon, 6 Dec 2010 15:05:36 -0800 (PST) Received: (qmail invoked by alias); 06 Dec 2010 23:07:00 -0000 Received: from p508FC319.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.195.25] by mail.gmx.net (mp069) with SMTP; 07 Dec 2010 00:07:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18yGkNXg5wyNlsWiBx7Wn3wdzKoNGd+cEC0eKapS/ bVm4PXRl1Vfj4A Message-ID: <4CFD6C8F.6010901@gmx.de> Date: Tue, 07 Dec 2010 00:06:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <73E9EBC74013BAFC7501F9A2@PST.JCK.COM> <4CFD6B9C.2070807@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:05:38 -0000 On 07.12.2010 00:05, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> If we *were* adding features to RFC 5234, the one thing I'm missing most >> is a shorthand notation for defining a set of characters as a difference >>from another set, such as >> >> myoctdigits = DIGIT - ( "8" / "0" ) Where the "0" was supposed to be a "9". It's later over here. >> Without this feature, many people use prose production instead ("> except ...>"), or create proper ABNF which then is hard to follow. > > (I suppose case-sensitive literals would be the next thing.) Indeed. Best regards, Julian From lear@cisco.com Mon Dec 6 23:05:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177FD3A691C; Mon, 6 Dec 2010 23:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.232 X-Spam-Level: X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2a4m+ClJI76; Mon, 6 Dec 2010 23:05:54 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6A8333A672E; Mon, 6 Dec 2010 23:05:53 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAOxr/UyQ/khNgWdsb2JhbACDT5sIhF8VAQEWIiKkNopBkQiEVnMEim4 X-IronPort-AV: E=Sophos;i="4.59,310,1288569600"; d="scan'208,217";a="14777265" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2010 07:07:17 +0000 Received: from dhcp-10-55-81-114.cisco.com (dhcp-10-55-81-114.cisco.com [10.55.81.114]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oB777HAi018326; Tue, 7 Dec 2010 07:07:17 GMT Message-ID: <4CFDDD2F.2020201@cisco.com> Date: Tue, 07 Dec 2010 08:07:27 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, eai-chairs@tools.ietf.org, "apps-discuss@ietf.org" , "'IESG'" , Ted Hardie X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------010001010405060808040104" Subject: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 07:05:56 -0000 This is a multi-part message in MIME format. --------------010001010405060808040104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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-eai-rfc5337bis-01 Title: Internationalized Delivery Status and Disposition Notifications Reviewer: Eliot Lear Review Date: 7 Dec 2010 Summary: This draft is almost ready for publication but has a few *minor* issues that should be considered prior to publication. Great job! Major Issues: none. Cool! Minor Issues: The document does not state clearly what the differences between this specification and RFC5337. Doing so could speed adoption of this specification. As some of the changes seem subtle, such an addition would be particularly welcome. ABNF: Courtesy of Bill Fenner's ABNF checker, there are several changes that could be made for clarity: Upper-casify hex (e.g., 2a->2A) [throughout] Combine "Diagnostic-Code" ":" -> ""Diagnostic-Code:" Combine "Localized-Diagnostic" ":" -> ""Localized-Diagnostic:" Combine "Failure" ":" -> "Failure:" Combine "Warning" ":" -> "Warning:" More importantly, the specification makes use of the =/ operator from RFC 5234, but for constructs that it does not control. I don't know if this was the original intent or not, but I am a little concerned that use of =/ in a construct that is not wholly controlled by a single specification is asking for confusion later. This is an optional specification, right? Finally, in the beginning of the document you discuss whether or not to create a new registration, and indicate that the working group chose not to create a new registration. I can easily imagine good reasoning for this, but perhaps you might elaborate in descriptive language the nature of the choice and why you chose one way rather than the other, especially in light of what may seem like a contrary decision in 5336bis. Regards, Eliot --------------010001010405060808040104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-eai-rfc5337bis-01
Title: Internationalized Delivery Status and Disposition Notifications
Reviewer: Eliot Lear
Review Date: 7 Dec 2010

Summary:

This draft is almost ready for publication but has a few minor issues that should be considered prior to publication.  Great job!

Major Issues:  none.  Cool!

Minor Issues:

The document does not state clearly what the differences between this specification and RFC5337.  Doing so could speed adoption of this specification.  As some of the changes seem subtle, such an addition would be particularly welcome.

ABNF:  Courtesy of Bill Fenner's ABNF checker, there are several changes that could be made for clarity:

Upper-casify hex (e.g., 2a->2A) [throughout]
Combine "Diagnostic-Code" ":" -> ""Diagnostic-Code:"
Combine "Localized-Diagnostic" ":" -> ""Localized-Diagnostic:"
Combine "Failure" ":" -> "Failure:"
Combine "Warning" ":" -> "Warning:"

More importantly, the specification makes use of the =/ operator  from RFC 5234, but for constructs that it does not control.  I don't know if this was the original intent or not, but I am a little concerned that use of =/ in a construct that is not wholly controlled by a single specification is asking for confusion later.  This is an optional specification, right?

Finally, in the beginning of the document you discuss whether or not to create a new registration, and indicate that the working group chose not to create a new registration. I can easily imagine good reasoning for this, but perhaps you might elaborate in descriptive language the nature of the choice and why you chose one way rather than the other, especially in light of what may seem like a contrary decision in 5336bis.

Regards,

Eliot
--------------010001010405060808040104-- From evnikita2@gmail.com Mon Dec 6 23:39:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B04D3A6923 for ; Mon, 6 Dec 2010 23:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSLJ5yK5zsOj for ; Mon, 6 Dec 2010 23:39:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 08DC63A691C for ; Mon, 6 Dec 2010 23:39:41 -0800 (PST) Received: by gyb13 with SMTP id 13so7272269gyb.31 for ; Mon, 06 Dec 2010 23:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2rmz0QVmzsVHZXACMYk/WXhbiJ2v+gXyBfnKnCoqxbk=; b=gSK2KYnW5lU1laxal1EJCyySuxtXyS5gxWARyU2H1354+srS7UanitxlDd3AzasTC4 RmcYJQHlKHFTSp3H/RPAf+lfHXAHWov9RNPXDFSAr8Sl7QZt0uLHOXhFWzN89r0BkEld VZQrCqfjBObbW2OHXvDpzQIVh+MzxokL4cZ1o= 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=ntIaGYy/SorS1AF3PKA84lrUz13tWhKb+656sJXQSWF/+2KByeuMy949psLhTIHkWe mICGrKuDaVrrFET0Nv2Yh6Q660pdsvMnqogKDwwkZlwjuxQ/TDkQsm4tmDpUG72rw+IO f8Ggh4YdfoGtsZY6fITxsMCsZd685B9OkP0mk= MIME-Version: 1.0 Received: by 10.151.109.14 with SMTP id l14mr1266491ybm.285.1291707666748; Mon, 06 Dec 2010 23:41:06 -0800 (PST) Received: by 10.150.52.19 with HTTP; Mon, 6 Dec 2010 23:41:06 -0800 (PST) In-Reply-To: References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> Date: Tue, 7 Dec 2010 09:41:06 +0200 Message-ID: From: Mykyta Yevstifeyev To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 07:39:43 -0000 Hello all, 2010/12/6, Barry Leiba : >> https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ >> >> Almost all comments and suggestions were taken >> into account. Among other: >> -updated ABNF; >> -added Examples section; >> -added Acknowledgments section; >> -other minor changes. > > The changes to the ABNF are good, and they resolve my concerns from -00. > > I note a remaining problem with the ABNF that I missed the first time: > > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) > > The first clause on the right is incorrect: it specifies > occurrences of with *no* between them. As you add that, > you need to make sure to get the cases where n=0 and n=1 correct, as > well as where n=m (I think that last one is already OK). Maybe such constrution should be used: n^(a)m element = ( n(*LWS element *LWS a) *o(*LWS a *LWS element) ) However this construction does not solve the problem when only REQUIRED amount of elements are use as will be used after the last element. > > This points out the difficulty of getting such a general list > construct defined correctly, and shows why it was removed. > > I agree with Tony that if you can't include examples of how we should > have had this before, it'll be hard to convince the community and the > IESG that it's needed now. We can always come up with things that > *might* be useful, but part of the challenge is keeping the language > as simple as possible (and no simpler). > The construction will be used while definig the HTTP headers which contain the list of element. Now I am thinking about some other examples. > Barry > From julian.reschke@gmx.de Tue Dec 7 00:42:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8BC3A693E for ; Tue, 7 Dec 2010 00:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.479 X-Spam-Level: X-Spam-Status: No, score=-104.479 tagged_above=-999 required=5 tests=[AWL=-1.880, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETXR56H9GoGW for ; Tue, 7 Dec 2010 00:42:19 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id D96863A693C for ; Tue, 7 Dec 2010 00:42:18 -0800 (PST) Received: (qmail invoked by alias); 07 Dec 2010 08:43:42 -0000 Received: from p508FCB2C.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.203.44] by mail.gmx.net (mp021) with SMTP; 07 Dec 2010 09:43:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19XhYs1NQVXmVvsKA+RfgCjJJI0b+QptjHmAvOXD0 RUyicmZ1lPVoh2 Message-ID: <4CFDF3BB.30101@gmx.de> Date: Tue, 07 Dec 2010 09:43:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 08:42:20 -0000 On 07.12.2010 08:41, Mykyta Yevstifeyev wrote: > ... >> I agree with Tony that if you can't include examples of how we should >> have had this before, it'll be hard to convince the community and the >> IESG that it's needed now. We can always come up with things that >> *might* be useful, but part of the challenge is keeping the language >> as simple as possible (and no simpler). >> > The construction will be used while definig the HTTP headers which > contain the list of element. Now I am thinking about some other > examples. > ... If your use case is to specify new HTTP headers, I'd recommend that you stick with the RFC 2616 syntax (because you want to inherit the rules for implied LWS anyway). If you can wait for HTTPbis, you can use RFC 5234 syntax with # as an extension as defined by HTTPbis. Best regards, Julian From evnikita2@gmail.com Tue Dec 7 03:04:05 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471683A6966 for ; Tue, 7 Dec 2010 03:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.843 X-Spam-Level: X-Spam-Status: No, score=-3.843 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sJVOqL2Oyfl for ; Tue, 7 Dec 2010 03:04:04 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 635AC3A6949 for ; Tue, 7 Dec 2010 03:04:04 -0800 (PST) Received: by yxt33 with SMTP id 33so3307534yxt.31 for ; Tue, 07 Dec 2010 03:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ezzGUxZgWj4J3el6WFLDdW37S7FW37ss1YJoIUXZAYg=; b=PxmBfhdszX4hHXk3Mh33fkTaUnX/ul5xRHVoclzo2FDl6W5iFmpKl4JBV0pQ7UBnrf F9U4y4C/ZruVpe7MEgMsYRge3fdBXA9h3r9AUhnuEt3XI9d5P5Rx/eEgBdWriEhJlUI2 ZYYxy4jwV5ojN87+QyniKaIMqP3H3bZcMmkLg= 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=pukvLTExJdopKwVAQvMPd9pkugLBVBezsuUG+34k42pcaI4+kHwi8gs2m5J+1YlMcR e9St6F16Gfdw4DR20m6zfaxjo+w8hmKrV1lppPA4IluFrGa+vSyM4I3zZUPPcqMGxChI JqAkdmalEpcgv/Cb+aYSX7m6JajsZAHL8wKDM= MIME-Version: 1.0 Received: by 10.150.158.15 with SMTP id g15mr1699237ybe.57.1291719929365; Tue, 07 Dec 2010 03:05:29 -0800 (PST) Received: by 10.150.52.19 with HTTP; Tue, 7 Dec 2010 03:05:29 -0800 (PST) In-Reply-To: <4CFDF3BB.30101@gmx.de> References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <4CFDF3BB.30101@gmx.de> Date: Tue, 7 Dec 2010 13:05:29 +0200 Message-ID: From: Mykyta Yevstifeyev To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , Dave CROCKER , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 11:04:05 -0000 Hello all, I think I'll published the revised draft today with the folloeing constr: n^(a)m = *LWS element *(*LWS a *LWS element) like used in the HttpBIS WG draft. So this constr. will be available on the ABNF spec. 2010/12/7, Julian Reschke : > On 07.12.2010 08:41, Mykyta Yevstifeyev wrote: >> ... >>> I agree with Tony that if you can't include examples of how we should >>> have had this before, it'll be hard to convince the community and the >>> IESG that it's needed now. We can always come up with things that >>> *might* be useful, but part of the challenge is keeping the language >>> as simple as possible (and no simpler). >>> >> The construction will be used while definig the HTTP headers which >> contain the list of element. Now I am thinking about some other >> examples. >> ... > > If your use case is to specify new HTTP headers, I'd recommend that you > stick with the RFC 2616 syntax (because you want to inherit the rules > for implied LWS anyway). LWS rule can simply be copied to rge specification of discussed construction. > > If you can wait for HTTPbis, you can use RFC 5234 syntax with # as an > extension as defined by HTTPbis. Yes, I agree but I want to put this rule but improved to RFC5234 as it doe *not* have this rule. And what means "If you can wait for HTTPbis ..." > > Best regards, Julian > All the best, Mykyta Yevstifeyev From derhoermi@gmx.net Mon Dec 6 15:03:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E27828C0FD for ; Mon, 6 Dec 2010 15:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHIXzXYJmxu6 for ; Mon, 6 Dec 2010 15:03:48 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id BFF1328C0FB for ; Mon, 6 Dec 2010 15:03:47 -0800 (PST) Received: (qmail invoked by alias); 06 Dec 2010 23:05:10 -0000 Received: from dslb-094-222-156-080.pools.arcor-ip.net (EHLO xn--bjrn-6qa.xn--hhrmann-90a.de) [94.222.156.80] by mail.gmx.net (mp055) with SMTP; 07 Dec 2010 00:05:10 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18roOsjvYYrAL8UCK885CULrxwcBmMamEBCCFK6QZ Drt5WpQV0II0v2 From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 07 Dec 2010 00:05:08 +0100 Message-ID: References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <73E9EBC74013BAFC7501F9A2@PST.JCK.COM> <4CFD6B9C.2070807@gmx.de> In-Reply-To: <4CFD6B9C.2070807@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 07 Dec 2010 08:08:33 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:03:49 -0000 * Julian Reschke wrote: >If we *were* adding features to RFC 5234, the one thing I'm missing most >is a shorthand notation for defining a set of characters as a difference >from another set, such as > > myoctdigits = DIGIT - ( "8" / "0" ) > >Without this feature, many people use prose production instead ("except ...>"), or create proper ABNF which then is hard to follow. (I suppose case-sensitive literals would be the next thing.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From evnikita2@gmail.com Wed Dec 8 09:41:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364C03A6826 for ; Wed, 8 Dec 2010 09:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+2RLrWXrHki for ; Wed, 8 Dec 2010 09:41:26 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id C50D63A6808 for ; Wed, 8 Dec 2010 09:41:25 -0800 (PST) Received: by bwz8 with SMTP id 8so1680662bwz.38 for ; Wed, 08 Dec 2010 09:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=K+cLQCsA/aaiFyZwT/PL81B28hJ8ps6636dprzfIlDw=; b=vpx7ZDqF0VL8z2F7W//MACKTExfFVs2bRhAEryV+4ZFzRSFoIOyuCXsSxdfTm+IO6B gZTwSjVVmXo2QcoGFVSKL67vEZ9vhlU03Fv/Ry0/dtOsSh7Vyzputm2OBYqOMY5J1eYF YfOrhlDNIrXOIdH04hZnd/+Ajb2skrZ+7KE3k= 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=fotQ4a53ew1FQLtG08F6grGHBWbV+tzppEhBDuWxrDeRTBec06bQFdOIgUwG3jVP1R 60BQb175HEVsoh54oAHZGhIBA1cJs26Nr7KSbH4WfgmP5+pHDZSS//p2S7zZRpa4jSmF yaCAyjQdoNJUd8kDqWVXmhNu22hNBXUyuKc4U= Received: by 10.204.45.142 with SMTP id e14mr2221236bkf.108.1291830171239; Wed, 08 Dec 2010 09:42:51 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id b17sm470305bku.20.2010.12.08.09.42.48 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Dec 2010 09:42:49 -0800 (PST) Message-ID: <4CFFC3A2.5050301@gmail.com> Date: Wed, 08 Dec 2010 19:42:58 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <4CFDF3BB.30101@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Dave CROCKER Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 17:41:27 -0000 Hello all, I have uploaded the new version (-02) of my draft for ABNF for separated lists. Here is the link: https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1 Among other, there is updated ABNF for defined construction which is OK for cases when n = 0, n >= 1 and other cases. Any suggestions are welcome. All the best, Mykyta Yevstifeyev From stpeter@stpeter.im Thu Dec 9 13:14:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680733A6BE1 for ; Thu, 9 Dec 2010 13:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQifFvd7GMsY for ; Thu, 9 Dec 2010 13:14:51 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9D98F3A6BE3 for ; Thu, 9 Dec 2010 13:14:51 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 603B0400F6 for ; Thu, 9 Dec 2010 14:28:19 -0700 (MST) Message-ID: <4D014724.5020009@stpeter.im> Date: Thu, 09 Dec 2010 14:16:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 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="------------ms080800000903030405020106" Subject: [apps-discuss] IETF 79 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 21:14:52 -0000 This is a cryptographically signed message in MIME format. --------------ms080800000903030405020106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Your lazy Area Directors have finally posted minutes for the AppsArea session at IETF79: http://www.ietf.org/proceedings/79/minutes/apparea.txt Please ping Alexey and me regarding any corrections. Thanks to Ted Hardie for scribing! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080800000903030405020106 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw OTIxMTYyMFowIwYJKoZIhvcNAQkEMRYEFIaBw+U0x8hB7+awieyAXY0hrkj/MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAtEF1o3WBJGUa8wMj0XsTAMWyr15g9u3lV96ziNuyCo3B4741RsXmCiPYe Tte0BT4i6w33ksAr40vXkLbgsPHZhMZR8+BhbvKwBrmf3bZJDwNwkwfsasHk+Lpnsh31uCer NMUvJvEcnd5AhqUa7rbfOE1cE/y38QKFlA6BL3nJOTf+JGxwpdEgVFC3ypwOuILmxriONcvd RqM4ZsrchsIUG4PRAxeGmOP5ec26ardAB1w44bAqjCbEFmOmMaOux0Dq9lr6mZG0qy+DfwDY KOp7ZsdlKcRVd5bpD/CFzs2y25MmIqzyw5o/s58QMJYt/+vl4H/2AciYP6ACNisGjnxkAAAA AAAA --------------ms080800000903030405020106-- From Martin.Thomson@andrew.com Thu Dec 9 14:31:50 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B9828C131 for ; Thu, 9 Dec 2010 14:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, MANGLED_OFF=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgKOkYG2yuVt for ; Thu, 9 Dec 2010 14:31:49 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 8688228C122 for ; Thu, 9 Dec 2010 14:31:49 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:5833 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S39931994Ab0LIWdT (ORCPT ); Thu, 9 Dec 2010 16:33:19 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 9 Dec 2010 16:33:19 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 10 Dec 2010 06:33:14 +0800 From: "Thomson, Martin" To: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Date: Fri, 10 Dec 2010 06:33:12 +0800 Thread-Topic: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt Thread-Index: AcuW/1vKTlJlhUbKTzWN/RXOyBlfKwA8Kckw Message-ID: <8B0A9FCBB9832F43971E38010638454F03F347E79F@SISPE7MB1.commscope.com> References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <4CFDF3BB.30101@gmx.de> <4CFFC3A2.5050301@gmail.com> In-Reply-To: <4CFFC3A2.5050301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Barry Leiba , Dave CROCKER Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 22:31:50 -0000 SGkgTXlreXRhLA0KDQpJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHlvdXIgcmVzcG9uc2Ug dG86DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2liaW4vYzVpP21pZD02JnJpZD00OSZnaWQ9MCZr MT05MzMmazI9NTQ3NzImdGlkPTEyOTE5MzM0MDkNCmh0dHBzOi8vd3d3LmlldGYub3JnL2liaW4v YzVpP21pZD02JnJpZD00OSZnaWQ9MCZrMT05MzMmazI9NTQ3NzMmdGlkPTEyOTE5MzM0MDkNCg0K VGhpcyByZWdhcmRzIHRoZSB1c2Ugb2YgTFdTLCB0aGUgZGVmaW5pdGlvbiBvZiBBQk5GIGZvciB0 aGUgbmV3IGNvbnN0cnVjdCwgYW5kIGEgZmV3IG90aGVyIHRoaW5ncyB0aGF0IHlvdSBkaWRuJ3Qg YWRkcmVzcyBpbiB0aGlzIGxhdGVzdCByZXZpc2lvbi4NCg0KVGhlIG5ldyBCTkYgc2VlbXMgbW9y ZSBjb3JyZWN0LCB0aG91Z2ggYXQgYSBwcmljZSBpbiBjb21wbGV4aXR5IChhbmQgYSBuZXcgc3lu dGFjdGljYWwgaW52ZW50aW9uKS4gIFRoZSBkZWZpbml0aW9uIG9mICdmJyBpcyBxdWl0ZSBzdHJh bmdlLCBlc3BlY2lhbGx5IHNpbmNlIHRoZXkgZG9uJ3Qgc2VlbSB0byBiZSBsaW5rZWQgYmFjayB0 byBuIGFuZCBtLg0KDQpZb3UgZG9uJ3QgbmVlZCB0byBiZSBzbyByaWdvcm91cyBpbiB5b3VyIGRl ZmluaXRpb24gb2YgdGhlIGV4cGFuc2lvbi4gIEknZCBwcmVmZXIgdG8gc2VlIG1vcmUgcmlnb3Vy IGRldm90ZWQgdG8gdGhlIEFCTkYgZm9yIHRoZSBBQk5GLg0KDQotLU1hcnRpbg0KDQoNCk9uIDIw MTAtMTItMDkgYXQgMDQ6NDI6NTgsIE15a3l0YSBZZXZzdGlmZXlldiB3cm90ZToNCj4gSGVsbG8g YWxsLA0KPiANCj4gSSBoYXZlIHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbiAoLTAyKSBvZiBteSBk cmFmdA0KPiBmb3IgQUJORiBmb3Igc2VwYXJhdGVkIGxpc3RzLg0KPiANCj4gSGVyZSBpcyB0aGUg bGluazoNCj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlldnN0 aWZleWV2LWFibmYtc2VwYXJhdGVkLQ0KPiBsaXN0cy8/aW5jbHVkZV90ZXh0PTENCj4gDQo+IEFt b25nIG90aGVyLCB0aGVyZSBpcyB1cGRhdGVkIEFCTkYgZm9yIGRlZmluZWQNCj4gY29uc3RydWN0 aW9uIHdoaWNoIGlzIE9LIGZvciBjYXNlcyB3aGVuIG4gPSAwLA0KPiBuID49IDEgYW5kIG90aGVy IGNhc2VzLg0KPiANCj4gQW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KPiANCj4gQWxsIHRo ZSBiZXN0LA0KPiBNeWt5dGEgWWV2c3RpZmV5ZXYNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBh cHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcHBzLWRpc2N1c3MNCg0KDQo= From sm@resistor.net Thu Dec 9 15:03:23 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8B828C152 for ; Thu, 9 Dec 2010 15:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G75aXE72YnB9 for ; Thu, 9 Dec 2010 15:03:19 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 7766B28C144 for ; Thu, 9 Dec 2010 15:03:19 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oB9N3mFY011168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Dec 2010 15:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1291935888; x=1292022288; bh=8CdyFyEEiIrQXQYO1S/CDL0ZUEV0pNvhWqKx756qCHo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=BPA7OJUVHf2oUexbfmJz3Oio8e7eZhq13tONcYVMi7EEkGSdtafWfV6JGVakzVwuS crCe+sOAsI/ZZ3CIlto+lx7YCIZm9YhtoaOl2p1i2YNExcdtkCJcdqatc+QgD2Rmfz Lgv8vg6NZG946GV8bfLW4LyE1NpbxBmafKP6erCk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1291935888; x=1292022288; bh=8CdyFyEEiIrQXQYO1S/CDL0ZUEV0pNvhWqKx756qCHo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VMzZ8wYdLismMzJEePuVHqxVsK6+4Z/FOpILaOwSpRjqjjtA+FsQP42glGtw0uEKa vcc77iTCIN+yyxvsduO9ejKZAqoOe9/YbOg9H+RsNXxuXAfmURjPMd1a9/ZB/2ZBLR fTPnmvJckH1ft/33bCfojf44wh2ya+394O7zc1VA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=QHLtWoUqEamXXrgijfBEALYtkJj5ReRv1h32P6zKIdKaT6fEdHsm1h0UEJwttCYh0 KDDmRGsVxiKXizU9f9ZUbl51knuk1aeyGfGoErkGZm47g7tK3FEMOwapoEPt7XmzNHf dMT0UyRj0ENQhzW3a2SsO1+WNkrT2DhnozNWfaM= Message-Id: <6.2.5.6.2.20101209150042.0c0a5bf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Dec 2010 15:03:28 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: <4D014724.5020009@stpeter.im> References: <4D014724.5020009@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] IETF 79 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 23:03:23 -0000 At 13:16 09-12-10, Peter Saint-Andre wrote: >Your lazy Area Directors have finally posted minutes for the AppsArea >session at IETF79: > >http://www.ietf.org/proceedings/79/minutes/apparea.txt Thanks LADs. "Barry mentions the three drafts already suggested: draft-nottingham-http-portal, Patrik Faltstrom's IDNAbis I-D (already discussed), and draft-merrit-jms-uri." Is APPSAWG taking on draft-merrit-jms-uri as a work item? Regards, -sm From dcrocker@bbiw.net Thu Dec 9 15:09:30 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A275328C155 for ; Thu, 9 Dec 2010 15:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS2XGFuNOvVO for ; Thu, 9 Dec 2010 15:09:29 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4F9A528C144 for ; Thu, 9 Dec 2010 15:09:29 -0800 (PST) Received: from [192.168.43.47] (m4a2436d0.tmodns.net [208.54.36.74]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oB9NApxZ026709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Dec 2010 15:10:59 -0800 Message-ID: <4D0161EB.6020509@bbiw.net> Date: Thu, 09 Dec 2010 18:10:35 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: multipart/mixed; boundary="------------010009050700090207050305" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 09 Dec 2010 15:11:00 -0800 (PST) Subject: [apps-discuss] Fwd: Re: Fwd: I-D Action:draft-yevstifeyev-abnf-separated-lists-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 23:09:30 -0000 This is a multi-part message in MIME format. --------------010009050700090207050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is from my ABNF co-author. It took a couple of days to get his approval to forward it, so it refers to a previous version of the document. I will yet be sending my own comments. (It's been a busy week.) d/ -------- Original Message -------- Subject: Re: Fwd: I-D Action:draft-yevstifeyev-abnf-separated-lists-00.txt Date: Mon, 6 Dec 2010 21:12:19 +0000 From: Paul Overell To: Dave CROCKER >1. Introduction > > ABNF provides a possibility to express lists of elements, separated > by commas (",") via the construction #element. No, RFC5234 ABNF doesn't have the # construct. The # notation is an RFC822 construct. AFAIR the consensus was to exclude it from ABNF as it was too RFC822 specific and could trivially be handled as foo *("," foo). Note RFC822 also allowed a single comma to be replaced by any number of commas. >However > sometimes it is needed to express list of elements, separated by > other characters, such as semicolons, points etc. In this case the > following ABNF construction is used: > > ([*LWS] element [n*([*LWS] separator [*LWS] element)]) LWS is not defined in RFC5234 (or RFC822), it should be WSP. The [] around [*LWS] is redundant. element *(*WSP separator *WSP element) >It is obvious that this construction is too bulky. This is subjective, too bulky for what? > The ABNF for this construction is: > > n^(a)m element = ( n([*LWS] element) [*o([*LWS] a [*LWS] element)]) > n = 1*DIGIT ;minimum amount of elements > m = 1*DIGIT ;maximum amount of elements > o = ;difference between and > a = VCHAR ;separator > 1) The above is *not* ABNF for the proposed extension. It is an attempt to define the semantics of the extension with an ABNF equivalent. The above is not legal ABNF. 2) I'm not even clear what the proposed syntax is. Is a comma separated list of foo given as ^,foo or as ^(,)foo ? The former is broken because the separator might be a digit which would result in ambiguous syntax. The latter could be made to work but it is a bit obscure and overloads (). 3) The proposed syntax introduce an unquoted character as a terminal symbol, whereas in all other constructs a terminal character has to be quoted. 4) Unlike RFC822, ABNF deliberately avoids any implicit whitespace. In any ABNF specified language all whitespace must be explicit. This extension re-introduces implicit whitespace around the separator. I would strongly object to this extension on this ground alone. 5) Trying to decode the above ABNF semantics: the author seems to have specified that 2^,4foo matches foo foo, foo, foo i.e. The first 2 foo are not separated by a comma. If this extension is supposed to follow RFC822 then he has misunderstood RFC822 # operator, in which all elements are separated. 6) Why are separators restricted to VCHAR? Why not num-value, or another element? I recommend that this extension is rejected. Even if the design and specification faults were addressed I don't see having a specific syntax for lists gives sufficient (or any) advantage to warrant changing the language. Do I need to send my comments anywhere official? Regards -- Paul Overell -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------010009050700090207050305 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IFBHUCBTREsgMy4yLjIN Cg0KaVFBL0F3VUFUUDFSc2g4V1J5K3dkZ2UrRVFLN2lRQ2d2UjJ2eFcvWVZTdHB5RVcxcm1y dGF6OFBxMTBBb0txUA0KYjZVVzJjZ1kvcE5aVHdpOS9JcUlZZko3DQo9dXVPYg0KLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg== --------------010009050700090207050305-- From yaojk@cnnic.cn Thu Dec 9 17:50:30 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8527728C11B for ; Thu, 9 Dec 2010 17:50:30 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -98.209 X-Spam-Level: X-Spam-Status: No, score=-98.209 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl+hBROjJ6fT for ; Thu, 9 Dec 2010 17:50:28 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 7A3B03A6BFD for ; Thu, 9 Dec 2010 17:50:27 -0800 (PST) Received: (eyou send program); Fri, 10 Dec 2010 09:51:57 +0800 Message-ID: <491945917.26303@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 10 Dec 2010 09:51:57 +0800 Message-ID: From: "Jiankang YAO" To: , "SM" References: <4D014724.5020009@stpeter.im> <491935898.11016@cnnic.cn> Date: Fri, 10 Dec 2010 09:50:10 +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.5994 Subject: Re: [apps-discuss] IETF 79 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 01:50:30 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNNIiA8c21AcmVzaXN0b3Iu bmV0Pg0KVG86IDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIERlY2VtYmVy IDEwLCAyMDEwIDc6MDMgQU0NClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBJRVRGIDc5IG1p bnV0ZXMNCg0KDQo+IEF0IDEzOjE2IDA5LTEyLTEwLCBQZXRlciBTYWludC1BbmRyZSB3cm90ZToN Cj4+WW91ciBsYXp5IEFyZWEgRGlyZWN0b3JzIGhhdmUgZmluYWxseSBwb3N0ZWQgbWludXRlcyBm b3IgdGhlIEFwcHNBcmVhDQo+PnNlc3Npb24gYXQgSUVURjc5Og0KPj4NCj4+aHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy83OS9taW51dGVzL2FwcGFyZWEudHh0DQo+IA0KPiBUaGFua3Mg TEFEcy4NCj4gDQo+ICAgIkJhcnJ5IG1lbnRpb25zIHRoZSB0aHJlZSBkcmFmdHMgYWxyZWFkeSBz dWdnZXN0ZWQ6DQo+ICAgIGRyYWZ0LW5vdHRpbmdoYW0taHR0cC1wb3J0YWwsIFBhdHJpayBGYWx0 c3Ryb20ncyBJRE5BYmlzDQo+ICAgIEktRCAoYWxyZWFkeSBkaXNjdXNzZWQpLCBhbmQgZHJhZnQt bWVycml0LWptcy11cmkuIg0KPiANCj4gSXMgQVBQU0FXRyB0YWtpbmcgb24gZHJhZnQtbWVycml0 LWptcy11cmkgYXMgYSB3b3JrIGl0ZW0/DQo+IA0KDQpJIHRoaW5rIHRoYXQgaXQgaXMgc3VnZ2Vz dGlvbiBvciBwcm9wb3NhbC4NCnllcywgaWYgIEFQUFNBV0cgaGFzIHRoZSBjb25zZW5zdXMgdG8g ZG8gaXQuDQoNCkppYW5rYW5nIFlhbw0KDQo+IFJlZ2FyZHMsDQo+IC1zbQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNz IG1haWxpbmcgbGlzdA0KPiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M= From evnikita2@gmail.com Thu Dec 9 23:42:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DDB3A6C68 for ; Thu, 9 Dec 2010 23:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-2.529, BAYES_00=-2.599, MANGLED_OFF=2.3, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YENoqox1Mq9 for ; Thu, 9 Dec 2010 23:42:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 9DE8E3A6C67 for ; Thu, 9 Dec 2010 23:42:48 -0800 (PST) Received: by yxt33 with SMTP id 33so2039068yxt.31 for ; Thu, 09 Dec 2010 23:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=E7YV+mlfRnfRRmCu5C8i67bswNWXBPJmiF4PrNRGYXo=; b=rAuUcUWVfwlf/T6xWnM/KBd2WsxhXVypBn8NHAv2bUpZxVwsl7VC9QNDpiFODeiySf vixdHcg+oESkPFhLym4jJd9z1i8e1HqlMCtAmkiZT1DhHUofOR+lvrvIHZGRUaGZRSP7 jTlez/zObAznJLIoLlclG0FoS/dF8R++HFSUo= 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=Fsd25MQnzle4f6FeJaAxhOiwCjzC9m2vVjPL6jWM6eZYZHQgX7s1NOhFpffLYVWLk8 c7rbhXbzEiN8HOqwL0vPZ7CgsODN5WZ6jCumy8oaNACBjOFcEjDAZJUm7q6Yn2adPvOK f8zBCK7ARTBNDGUkIU/QcbH+fY4i8+5bEI+sA= MIME-Version: 1.0 Received: by 10.151.143.20 with SMTP id v20mr924830ybn.114.1291967058423; Thu, 09 Dec 2010 23:44:18 -0800 (PST) Received: by 10.150.52.19 with HTTP; Thu, 9 Dec 2010 23:44:18 -0800 (PST) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F347E79F@SISPE7MB1.commscope.com> References: <4CFC4694.5070408@att.com> <4CFCF71C.4050908@att.com> <4CFD0B37.7010601@gmail.com> <4CFD1238.4090902@gmail.com> <4CFDF3BB.30101@gmx.de> <4CFFC3A2.5050301@gmail.com> <8B0A9FCBB9832F43971E38010638454F03F347E79F@SISPE7MB1.commscope.com> Date: Fri, 10 Dec 2010 09:44:18 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , Dave CROCKER , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 07:42:49 -0000 Hello all, Some notes: 2010/12/10, Thomson, Martin : > Hi Mykyta, > > I'd be interested in hearing your response to: > > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=54772&tid=1291933409 > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=54773&tid=1291933409 > They generally refer to -01 version draft. Most of problems have been solved in the -02 version. As for the second link, I'll try to take these comments into account while prepaing the new version of the draft or maybe response it later. > This regards the use of LWS, the definition of ABNF for the new construct, > and a few other things that you didn't address in this latest revision. > > The new BNF seems more correct, though at a price in complexity (and a new > syntactical invention). The definition of 'f' is quite strange, especially > since they don't seem to be linked back to n and m. > I tried to found the construction which will return 0 if no elements used and 1 if at least one elemnt is used. What I assigned for 'F' of a definition of this construction. There is no simplier way to express it. The problem I am trying to solve is if we have n=0 and do not put the f(element) construction in the end, separator will occure at the end of the list. And if we put just 'element', it will be obligatory 1 element even if we don't use any. > You don't need to be so rigorous in your definition of the expansion. I'd > prefer to see more rigour devoted to the ABNF for the ABNF. > > --Martin > > > On 2010-12-09 at 04:42:58, Mykyta Yevstifeyev wrote: >> Hello all, >> >> I have uploaded the new version (-02) of my draft >> for ABNF for separated lists. >> >> Here is the link: >> >> https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated- >> lists/?include_text=1 >> >> Among other, there is updated ABNF for defined >> construction which is OK for cases when n = 0, >> n >= 1 and other cases. >> >> Any suggestions are welcome. >> >> All the best, >> Mykyta Yevstifeyev >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > All the best, Mykyta Yevstifeyev From evnikita2@gmail.com Fri Dec 10 06:28:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2DC28C0EE; Fri, 10 Dec 2010 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNjsCHMMoht1; Fri, 10 Dec 2010 06:28:07 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 0373428C0E6; Fri, 10 Dec 2010 06:28:06 -0800 (PST) Received: by bwz8 with SMTP id 8so4259180bwz.38 for ; Fri, 10 Dec 2010 06:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=jIdN4rs7RR2VU1+DVEl51BRtF8SLEG2YDUIxO2IBkCs=; b=E+qApaC9BatbS8xN3SLrKVtBFUDfrKsGZhzW4rVyT9K6R1F+lslFhDZwlfleOBk14c NxA9miSzuW7anQ6NeNIy+BY3acKc0QrbCkffGI1aapVexPD6aOlgKYppzwwh3QZD5NSp D0kBsgw8uSLKDBHCPy69mX0NCmtTbRpdyXVsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=hrPE5kDVkNRG10i8alAAum7N2Lsm856j7MRXsKOItcdkJ38IGa9a7kOue2TgmFaTn9 EqIvIW1gSWTRqBXcz1x7j4Gkomlxri59Hiwy2p3IK9EXXplYBa4w1Qzpn25e1EnucZo6 dkRYD0yFBZCs4ZDUMj92YRvQ2O4HLWI/UJIe8= Received: by 10.204.113.65 with SMTP id z1mr785285bkp.86.1291991376945; Fri, 10 Dec 2010 06:29:36 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id q15sm1571910bkk.13.2010.12.10.06.29.35 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 06:29:36 -0800 (PST) Message-ID: <4D023959.3070604@gmail.com> Date: Fri, 10 Dec 2010 16:29:45 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: IETF Discussion , apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill McQuillan , Martin.Thomson@andrew.com Subject: Re: [apps-discuss] I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:28:08 -0000 Hello all, I have get known that there is a discussion of my draft on this list (IETF-discuss). So some notes on what have been already posted: > > I wholly agree with Bill on this. > > You want something a little more complicated than you have already > specified: > > {n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0 > {e} *{m ? m-1 : ''}({a} {e}) ; where n == 0 or n undefined This is not what is mentioned in my draft. Especially in the case when n=0. > > Note the n == 0 is a special case. Note that this assumes that m > n. > There seems little point in this construction if m == 1, but this does > handle that case. If m=1, there is no need to use the defined construction. It is 1 and nothing else. > > Aside from those sorts of problems, the definition of 'a' is a little > loose. You should try to build on the RFC 5234 ABNF in your definitions. > > The proposed rule has an ABNF definition something like (?): > > hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT > a = VCHAR / SP / HT / > > That's a lot of flexibility in the internal part. Too much > flexibility. Using parentheses means that they need to be > distinguished from the parentheses that might appear in the 'a' part. > > If you see this as a substitute for the "*" in a normal repetition > rule, that makes it easier. Given that it has length longer than 1 > character, by providing a clear delineation of the start and end you > can be more flexible on the content. Either that or to restrict what > follows the ^. > > Preferably delineate better AND restrict content: > > repeat /= hat-rule > hat-rule = *DIGIT "^" element "^" *DIGIT OK. It will be taken into consideration. > > This restricts the content without preventing the use of more complex > content - you just have to use a rulename instead. > > You can't use elements (note the 's') here because that sort of > complexity is a real pain to specify. What do you mean? > > That leaves examples: > > 1^";"^3element ; 1 to 3 elements separated by ; > 1^SP^element ; 1 or more elements separated by SP rule > ^","^3element ; 0 to 3 elements separated by , > ^%x20.20^element ; any number of elements separated by a two space > characters Will be corrected. > > You should try to answer the question in the draft: why use the '^' > character instead of the '#' character? I guess that this is an > arbitrary choice more than anything else. # is already used in RFC2616 and ^ is used in order to to make the conflict between these documents. > > --Martin > > On 2010-12-07 at 11:07:17, Bill McQuillan wrote: > > I found several problems with this draft. > > > > In overview, the reason that we removed the #rule from ABNF was that it > > was > > very difficult to specify for a general case. This draft has the same > > problem. > > > > The production given does not actually produce the desired results. > > > > > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) > > > > If the usage is: > > > > 5^(",")10 "abc" > > > > it would allow something like: > > > > abc abc abc abc abc abc , abc > > > > not: > > > > abc, abc, abc, abc, abc, abc, abd > > > > which was probably intended. > > > > ----- > > > > The production: > > > > > a = VCHAR / SP / HT / > > > > does not seem to address the possibility of multi-character separators > > very > > clearly. What if I want to define a list like: > > > > abc and def and ghi and jkl > > > > can I use: > > > > ^(" and ")ident > > > > ----- > > > > I also do not believe that *FWS belongs in such a general rule and > > should > > rather be defined by the actual usage. E.g.: > > > > 5^(*FWS "," *FWS)10 "abc" > > > > ----- > > > > Typo: 2.1 Examples, fourth example should be: ^("-")element > > > > -- > > Bill McQuillan > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > Bill, All your propositions have been taken into consideration. These comments concern -01 draft. As for FWS, it is *element so it can be used and can not be used. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf I really believe that the construction I have used is acceptable for all cases. Now I am working on -03 version of the draft so I'll get known when it will become available. All the best, Mykyta Yevstifeyev From evnikita2@gmail.com Fri Dec 10 06:38:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89ABB28C0F7; Fri, 10 Dec 2010 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsjblSoTDRjF; Fri, 10 Dec 2010 06:38:26 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id C6F6D28C0F6; Fri, 10 Dec 2010 06:38:25 -0800 (PST) Received: by bwz8 with SMTP id 8so4270729bwz.38 for ; Fri, 10 Dec 2010 06:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=qGodP4I3OTSDF0BJ9/u/dszzNhoEyQTAYjQm+4K4GvU=; b=nTD7q7SxTLeiHlLPgPfNi7Vi1ihc/TFXwUyTusSnY5aTP6jKxMH9IrFPfGoEcQ7DnZ q5MLZUzbWeBWtgTXiYb2mBNHMq0yoFhjHZXmsfLhroVC4XxhcQd/AkvacZgK3PkVkk7P rmwrgyYwZcH9iRTLAb+qG9/bn/qwXhx9lKXQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=VpovOsgvUCbTpQjmyY9BbqBwtcqCzv06QwFLKawwPbkKGQEDVPR/RmXD+2NzE9RDrz ak2hpSUK8Te6jEpHs6oMeeNCUPmRsjtXdnsU7RjZc5y3mVaO6crguBuXmkpyxZG5lpkE eiqG262sRx2qd0HMaDOmjKw2/0ZToJDMxDYwU= Received: by 10.204.101.13 with SMTP id a13mr782373bko.119.1291991995052; Fri, 10 Dec 2010 06:39:55 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id d27sm1578859bkw.2.2010.12.10.06.39.53 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 06:39:54 -0800 (PST) Message-ID: <4D023BC3.9030006@gmail.com> Date: Fri, 10 Dec 2010 16:40:03 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: apps-discuss@ietf.org, IETF Discussion Content-Type: multipart/alternative; boundary="------------040400080704080608040207" Subject: [apps-discuss] A new version of draft-yevstifeyev-abnf-separated-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:38:27 -0000 This is a multi-part message in MIME format. --------------040400080704080608040207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03). It is available here: https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ Almost all comments were taken into account. Any suggestions and comments are welcome. All the best, Mykyta Yevstifeyev --------------040400080704080608040207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03).

It is available here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/

Almost all comments were taken into account.

Any suggestions and comments are welcome.

All the best,
Mykyta Yevstifeyev
--------------040400080704080608040207-- From stpeter@stpeter.im Fri Dec 10 09:49:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439FB28C0D9 for ; Fri, 10 Dec 2010 09:49:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rV0GnXjHCNM for ; Fri, 10 Dec 2010 09:49:41 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 78F2028C0E5 for ; Fri, 10 Dec 2010 09:49:41 -0800 (PST) Received: from dhcp-64-101-72-173.cisco.com (dhcp-64-101-72-173.cisco.com [64.101.72.173]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 19ADF400F6 for ; Fri, 10 Dec 2010 11:03:16 -0700 (MST) Message-ID: <4D026890.9090103@stpeter.im> Date: Fri, 10 Dec 2010 10:51:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 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="------------ms070006070205060809060100" Subject: [apps-discuss] Fwd: [ietf-calsify] WG Action: Conclusion of Calendaring and Scheduling Standards Simplification (calsify) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 17:49:43 -0000 This is a cryptographically signed message in MIME format. --------------ms070006070205060809060100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. -------- Original Message -------- Subject: [ietf-calsify] WG Action: Conclusion of Calendaring and Scheduling Standards Simplification (calsify) Date: Fri, 10 Dec 2010 09:47:27 -0800 (PST) From: IESG Secretary To: IETF Announcement list CC: ietf-calsify@osafoundation.org The Calendaring and Scheduling Standards Simplification (calsify) working= group in the Applications Area has concluded. The IESG contact persons ar= e Peter Saint-Andre and Alexey Melnikov. The CALSIFY WG is now closed. The group was chartered to complete revisions to the core Internet calendaring object specification or "iCalendar" (RFC 2445), the iCalendar transport-independent interoperability protocol (RFC 2446), and the iCalendar message-based interoperability protocol (RFC 2447). With the publication of RFC 5545 and RFC 5546 in 2009, and now RFC 6047 in 2010, the group has achieved the goals for which it was created. Thanks to document editors Bernard Desruisseaux, Cyrus Daboo, and Alexey Melnikov for their work on the specifications, to chairs Aki Niemi (2005-2009) and Eliot Lear (2006-2010) for leading this group to a successful conclusion, and to former area director Lisa Dusseault for her guidance and her early contributions as chair (2005-2006). The mailing list will remain open and the list archive will be retained. - Peter Saint-Andre, Responsible Area Director _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --------------ms070006070205060809060100 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MDE3NTExMlowIwYJKoZIhvcNAQkEMRYEFPQ1gjrgwubO7SsC3ZdyyIujDTlBMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQABKI46a/ZUT4BphsLhQ86uCpfmaZQ/yHsTDJbYBcN5c4y8ocBJPBV9r/qw o/KHS9DIH7Fwg1ju2OS07ZWgfB24HZSslHZd8yFJDFtqwDh0ZGoRRyBu9kHMPD16Eq39OcwD c3oTul/wfVPTXf5/lHHTKVqjk2PXM2fWGKed+eSAVuhRhxk9r7SDiBWhLOcDIrDk9YyHxeGq Md5uagTT0NvR5ZMA7ZbYeWSqR6zj/2d58sFuGCRJl087OLyYLYGq34D2RT59FBBVfdln5Z1U ARzHMYEULyhSC1vXTqEO9FY14YsCJOQgLLdefpRjO+taWylQzNmn6IUYklMDArGgLyWMAAAA AAAA --------------ms070006070205060809060100-- From alexey.melnikov@isode.com Fri Dec 10 10:50:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8A628C0F8 for ; Fri, 10 Dec 2010 10:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYUtzw2fDa+t for ; Fri, 10 Dec 2010 10:50:36 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6042F28C0E6 for ; Fri, 10 Dec 2010 10:50:36 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 10 Dec 2010 18:52:06 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D0276CC.70109@isode.com> Date: Fri, 10 Dec 2010 18:51:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org References: <4D014724.5020009@stpeter.im> <491935898.11016@cnnic.cn> <491945917.26303@cnnic.cn> In-Reply-To: <491945917.26303@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] IETF 79 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 18:50:37 -0000 Jiankang YAO wrote: >----- Original Message ----- >From: "SM" >To: >Sent: Friday, December 10, 2010 7:03 AM >Subject: Re: [apps-discuss] IETF 79 minutes > > >>At 13:16 09-12-10, Peter Saint-Andre wrote: >> >> >>>Your lazy Area Directors have finally posted minutes for the AppsArea >>>session at IETF79: >>> >>>http://www.ietf.org/proceedings/79/minutes/apparea.txt >>> >>> >>Thanks LADs. >> >> "Barry mentions the three drafts already suggested: >> draft-nottingham-http-portal, Patrik Faltstrom's IDNAbis >> I-D (already discussed), and draft-merrit-jms-uri." >> >>Is APPSAWG taking on draft-merrit-jms-uri as a work item? >> >> >I think that it is suggestion or proposal. >yes, if APPSAWG has the consensus to do it. > > After hearing the discussion about draft-merrit-jms-uri in Beijing I decided to progress it as an individual submission. However I would still appreciate more reviews of it. From eric@tibco.com Fri Dec 10 11:05:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D9528C11E for ; Fri, 10 Dec 2010 11:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suBSxAZJfu9E for ; Fri, 10 Dec 2010 11:05:12 -0800 (PST) Received: from mx1-app.tibco.com (mx1-app.tibco.com [63.100.100.142]) by core3.amsl.com (Postfix) with ESMTP id C137428C10D for ; Fri, 10 Dec 2010 11:05:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,325,1288594800"; d="scan'208";a="19107982" Received: from tibco-5.tibco.com (HELO na-pa-fe01.na.tibco.com) ([63.100.100.5]) by mx1-app.tibco.com with ESMTP; 10 Dec 2010 11:06:30 -0800 Received: from Eric-Johnsons-MacBook-Pro.local ([10.105.178.20]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Dec 2010 11:06:29 -0800 Message-ID: <4D027A34.2010507@tibco.com> Date: Fri, 10 Dec 2010 11:06:28 -0800 From: Eric Johnson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: SM References: <4D014724.5020009@stpeter.im> <6.2.5.6.2.20101209150042.0c0a5bf0@resistor.net> In-Reply-To: <6.2.5.6.2.20101209150042.0c0a5bf0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2010 19:06:29.0232 (UTC) FILETIME=[59B20F00:01CB989D] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17820.006 X-TM-AS-Result: No--19.327300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] IETF 79 minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 19:05:14 -0000 Hi, Just a small correction - I think you're referring below to draft-merrick-jms-uri (not merrit) https://datatracker.ietf.org/doc/draft-merrick-jms-uri/ -Eric. On 12/9/10 3:03 PM, SM wrote: > At 13:16 09-12-10, Peter Saint-Andre wrote: >> Your lazy Area Directors have finally posted minutes for the AppsArea >> session at IETF79: >> >> http://www.ietf.org/proceedings/79/minutes/apparea.txt > > Thanks LADs. > > "Barry mentions the three drafts already suggested: > draft-nottingham-http-portal, Patrik Faltstrom's IDNAbis > I-D (already discussed), and draft-merrit-jms-uri." > > Is APPSAWG taking on draft-merrit-jms-uri as a work item? > > Regards, > -sm > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dcrocker@bbiw.net Fri Dec 10 12:37:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8585228C13A for ; Fri, 10 Dec 2010 12:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUoGNjic7Lgm for ; Fri, 10 Dec 2010 12:37:36 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 7979928C11D for ; Fri, 10 Dec 2010 12:37:34 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBAKd0ol017630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 12:39:05 -0800 Message-ID: <4D028FE0.20906@bbiw.net> Date: Fri, 10 Dec 2010 12:38:56 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mykyta Yevstifeyev 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]); Fri, 10 Dec 2010 12:39:06 -0800 (PST) Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 20:37:38 -0000 Document Reviewed: draft-yevstifeyev-abnf-separated-lists-02 Reviewer: Dave Crocker Summary: This specification adds a built-in mechanism to ABNF [RFC5234], to provide a concise notation for list syntax, with the ability to specify the list separator. A list notation ( #(rule) ) that only permitted comma as the separator was introduced into the original ABNF in [RFC733]. The DRUMS working group removed it when moving the ABNF specification to its own document [RFC2234]. I am probably misremembering, but I believe that the working group consensus was that a) it was not used enough to warrant its inclusion in the core, and b) it added noticeable complexity to an ABNF processing engine. In other words, it was too expensive. However note that HTTP-related efforts re-introduced the construct. Discussion of this new proposal on the apps-discuss mailing list appears to indicate that consensus is still against standardizing a list construct or, at least, against adding it to the ABNF core. However the existing "#" mechanism for HTTP is still popular with that effort. To be standardized, the mechanism needs to demonstrate significant support. So far, that is lacking. However should it emerge, it still seems unlikely to warrant inclusion in the ABNF core. For one thing, discussion on the list suggests that there might need to be variants of this proposed mechanism, to cover different styles or templates for lists. Given continuance of the old "#" form, I wonder whether it might be worth assembling whatever ABNF enhancements are out in the wild into an Informational document, so that they stand on their own and are easily citable? Should anyone have need of one or another of these, they can simply invoke it rather than having to (once again) specify it. Detailed Comments: > 1. Introduction ... > (*LWS element n*m(*LWS separator *LWS element)) I think the initial *LWS is not as common and that the typical form for the list, itself, is: element n*m(*LWS separator *LWS element) This is worth noting simply to make the core definition simpler. There's nothing 'wrong' with what is in the doc, but I can easily imagine cases in which the leading white space (or even ANY white space...) is not wanted. Also: > It is obvious that this construction is too simplified and bulky. It is not obvious to /me/ that it is too simplified... > This document uses ABNF notation and core rules defined in RFC 5234 > [RFC5234]. The construction in {} is used for expressing arithmetic > expressions. For instance, if a=2, b=3 and c={b-a}, c is 1. In this > case c=1*DIGIT. "In this case..."?? In what case? I don't see how the production rule was obtained. I understand that a subtraction was performed before that, but where is the previous version of the rule? > he ABNF notation for separated lists is ^()element The ABNF itself should be on a new line and indented, IMO. FWIW, I'm not fond of this notation. The parenthetical seems clunky, especially since it overloads the use of parens. I also don't like putting it in between the upper/lower bound. Out of curiosity, why ^ rather than re-use #? That said, I don't have a form that I think is wonderful. I'll note that the original RFC733 ABNF was merely one of many differerent BNF variants that were developed in the mid-70s. That this particular variant became popular is worth some curiosity. My best guess is that it happened to hit a balance between complexity and power. It was simple enough and useful enough. I am very hard-pressed to look at the current proposal and feel that it maintains that balance, even though I personally really like the idea of a list notation and was sorry to see it removed by DRUMS. And I think that having a list mechanism with the ability to specify the separator is quite reasonable. > 2.1. Examples > > The section contains a few examples of using the defined > construction. > > 1^(";")3element indicates the list of elements separated by > semicolons (";") and OPTIONAL linear-white-spaces which consists of > at least 1 and at most 3 elements. > > 1^(SP)element indicates the list of elements separated by spaces and > OPTIONAL linear-white-spaces which consists of any amount of elements > but not less than 1. > > ^(",")3element indicates the list of elements separated by commas > (",") and OPTIONAL linear-white-spaces which consists of any amount For me, these examples emphasize my concern about the appearance of the notation. Perhaps one can get used to this notation and come to interpret it naturally. However I tend to view a mass of graphics within BNF as pretty distracting and not at all intuitive. While yes, this is more terse that the 'full' notation, I can't say I'm impressed with the result. > 3. Security Considerations > > Security issues are not discussed by this document. A notation that can create obscure effects might well introduce security holes. That's an issue that is not specific to this document, but I wonder whether it isn't time to raise this point in the Considerations sectin? -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Fri Dec 10 14:52:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E28328C160; Fri, 10 Dec 2010 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pooBEj5tHnYh; Fri, 10 Dec 2010 14:52:27 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5CB8428C0F3; Fri, 10 Dec 2010 14:52:24 -0800 (PST) Received: from dhcp-64-101-72-173.cisco.com (dhcp-64-101-72-173.cisco.com [64.101.72.173]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69D59400F6; Fri, 10 Dec 2010 16:05:59 -0700 (MST) Message-ID: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 15:53:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: http-auth@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="------------ms010603010501000706070400" Cc: "kitten@ietf.org" , websec@ietf.org, saag@ietf.org, "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: [apps-discuss] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 22:52:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010603010501000706070400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it time to start thinking about next-generation authentication technologies for HTTP? We all know that BASIC and DIGEST are ancient and crufty and lacking many features and security properties we might want, but there hasn't been much discussion about more modern approaches. Here are a few things I've found: 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt 2. In 2007, Robert Sayre put together a few slides on the topic: http://people.mozilla.com/~sayrer/2007/auth.html 3. Yutaka Oiwa and his colleagues have been working on a protocol for mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08 Other than that, I'm not aware of much activity. What have I missed? Does it make sense to perhaps hold an exploratory BoF at the next IETF meeting (Prague, March 2011) to get people thinking about this topic? If you're interested, please discuss on the http-auth@ietf.org list: https://www.ietf.org/mailman/listinfo/http-auth Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010603010501000706070400 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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MDIyNTM1M1owIwYJKoZIhvcNAQkEMRYEFEc4/NVCfSwpT+QNDvCgpHSbEhzeMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQArS8iF6UaxjKPP8ZrqY92kvXQSzbAWneUkedNjKuuEe+NjbnMcEyOJKrEL JQ6vyvnJcH8alEuqqtib17GOLwhc9gZ91SrgglZw/tcmCGLop3wCZX1bLxWBgCGwKpV4YOHU UqFh+TiUA4zJ2xZgx97JdozaI93e/4r4fLHUOfQkmh9i6XiFK98MZJtprN7evEQSSz+J31Mg vH9Qk3lOdITQhaXYoPCiJY7UPJopWHIs8jsBsdAUDptcrR6QpEdgx4y8D6UY/xQUfS4ifFHR 6Vaqs4gELB0xUoaB0ICY9s8rRdLdWDM+hCxRETfM7Mh8RECSUmKr4LE80SvA+0ChR5vkAAAA AAAA --------------ms010603010501000706070400-- From mnot@mnot.net Fri Dec 10 15:04:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDF328C171; Fri, 10 Dec 2010 15:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.583 X-Spam-Level: X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9qujG0fX4XH; Fri, 10 Dec 2010 15:04:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 9199D28C170; Fri, 10 Dec 2010 15:04:34 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B455722E1EB; Fri, 10 Dec 2010 18:06:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D02AF81.6000907@stpeter.im> Date: Sat, 11 Dec 2010 10:06:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <52E9BD81-E64B-47DA-83FC-C820B15D8B18@mnot.net> References: <4D02AF81.6000907@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:04:36 -0000 There was a very well-attended and wide-ranging bar BoF in Vancouver, = and lots of background discussion (/noise). My impression at that point was that the use cases that people wanted to = put into scope were so diverse, and the requirements so exacting, that = it was a non-starter.=20 That may still be the case, and I think that without a concrete target, = starting the discussion again will ultimately just waste a lot of = engineer hours*. Having said that -- since we now have OAuth shaving off some of those = use cases, it may be that a purely browsing-focused authentication = mechanism might be able to get traction, provided we can get browser = vendors on board (naturally). I'd expect them to instigate this, = however. Cheers, * Waste, of course, is subjective. A cynical person would think that the = opportunity cost of having a bunch of standards people working on = something non-productive could, in the end, be a useful diversion. = However, I'm not that person, because I'm not thinking it, I'm saying = it. But I digress. On 11/12/2010, at 9:53 AM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? >=20 > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few = things > I've found: >=20 > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt >=20 > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html >=20 > 3. Yutaka Oiwa and his colleagues have been working on a protocol for > mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08 >=20 > Other than that, I'm not aware of much activity. What have I missed? > Does it make sense to perhaps hold an exploratory BoF at the next IETF > meeting (Prague, March 2011) to get people thinking about this topic? >=20 > If you're interested, please discuss on the http-auth@ietf.org list: >=20 > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Thanks! >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Fri Dec 10 15:08:11 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E792D28C176; Fri, 10 Dec 2010 15:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.456 X-Spam-Level: X-Spam-Status: No, score=-101.456 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA2caBcrvZhs; Fri, 10 Dec 2010 15:08:10 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2D28428C170; Fri, 10 Dec 2010 15:08:10 -0800 (PST) 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 oBAN9eKg012365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 16:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4D02AF81.6000907@stpeter.im> References: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 15:09:39 -0800 To: Peter Saint-Andre , http-auth@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "kitten@ietf.org" , websec@ietf.org, saag@ietf.org, "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:08:11 -0000 At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >Other than that, I'm not aware of much activity. What have I missed? TLS client certificates. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@oracle.com Fri Dec 10 21:20:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED453A6CD6; Fri, 10 Dec 2010 21:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOl0oREfL3jB; Fri, 10 Dec 2010 21:20:34 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 342833A6CD4; Fri, 10 Dec 2010 21:20:34 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBB5M48l019515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Dec 2010 05:22:05 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBB5M31Y020970; Sat, 11 Dec 2010 05:22:03 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 845443701292044884; Fri, 10 Dec 2010 21:21:24 -0800 Received: from oracle.com (/10.135.193.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Dec 2010 21:21:23 -0800 Date: Fri, 10 Dec 2010 23:21:18 -0600 From: Nicolas Williams To: Peter Saint-Andre Message-ID: <20101211052117.GA29086@oracle.com> References: <4D02AF81.6000907@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D02AF81.6000907@stpeter.im> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 05:20:35 -0000 On Fri, Dec 10, 2010 at 03:53:53PM -0700, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few things > I've found: > > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt I have this: draft-williams-tls-app-sasl-opt-04.txt which could easily be made usable from HTTP. > If you're interested, please discuss on the http-auth@ietf.org list: > > https://www.ietf.org/mailman/listinfo/http-auth One more list... :) Nico -- From evnikita2@gmail.com Sat Dec 11 02:48:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9EB3A6C9A for ; Sat, 11 Dec 2010 02:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI4ebvFTxbYR for ; Sat, 11 Dec 2010 02:48:51 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 1D22E3A6D1E for ; Sat, 11 Dec 2010 02:48:50 -0800 (PST) Received: by bwz8 with SMTP id 8so5230004bwz.38 for ; Sat, 11 Dec 2010 02:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=z0tFz535inG5qN9aHZynWmBQWtoqop6X9qYwkEEmVJg=; b=uyTpBEmxiXRpHIw5n+LkvskpeWQqxwFwWRB+imjY0z7rzLB29s1cKf30vNucvnMgMp AUSmk/TWyNXZb+s1QRVYT2kFKpzeGuwqNSMS8+zjTONBiK4ZWrhd1QQVNCZkvybnhUBJ pRXKYzhHk05grRm3QwMHfX5Tr3tzUux4iBmCs= 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=NTu2SwBCBQSZd3gMTrIrfSM2sMH2ZQm95T/9pF6JWUVWpJKmi+RfEibsK9kdp9tbBy eCKAzlteIEN0so1p+mpSCb10b/BdxyqZhND9AeL5yMR7TH5bWKBQdQ4Ioub46R+06/Fz JR/HCD3CGix/VVIsAl/VQSYk+3uxWKmtakI+E= Received: by 10.204.65.135 with SMTP id j7mr1703157bki.85.1292064621836; Sat, 11 Dec 2010 02:50:21 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id s16sm1995974bkk.12.2010.12.11.02.50.20 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Dec 2010 02:50:20 -0800 (PST) Message-ID: <4D035776.4080206@gmail.com> Date: Sat, 11 Dec 2010 12:50:30 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dave CROCKER References: <4D028FE0.20906@bbiw.net> In-Reply-To: <4D028FE0.20906@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 10:48:53 -0000 Hello all, Some notes: Firstly, this is a review of -02 version and many issues have been corrected in -03 one. Also, see below: 10.12.2010 22:38, Dave CROCKER wrote: > > Document Reviewed: draft-yevstifeyev-abnf-separated-lists-02 > Reviewer: Dave Crocker > > > > Summary: > > This specification adds a built-in mechanism to ABNF [RFC5234], > to provide a concise notation for list syntax, with the ability to > specify the list separator. > > A list notation ( #(rule) ) that only permitted comma as the > separator was introduced into the original ABNF in [RFC733]. The > DRUMS working group removed it when moving the ABNF specification to > its own document [RFC2234]. > > I am probably misremembering, but I believe that the working > group consensus was that a) it was not used enough to warrant its > inclusion in the core, and b) it added noticeable complexity to an > ABNF processing engine. In other words, it was too expensive. However > note that HTTP-related efforts re-introduced the construct. > > Discussion of this new proposal on the apps-discuss mailing list > appears to indicate that consensus is still against standardizing a > list construct or, at least, against adding it to the ABNF core. > However the existing "#" mechanism for HTTP is still popular with that > effort. > > To be standardized, the mechanism needs to demonstrate > significant support. So far, that is lacking. However should it > emerge, it still seems unlikely to warrant inclusion in the ABNF > core. For one thing, discussion on the list suggests that there might > need to be variants of this proposed mechanism, to cover different > styles or templates for lists. > > Given continuance of the old "#" form, I wonder whether it might > be worth assembling whatever ABNF enhancements are out in the wild > into an Informational document, so that they stand on their own and > are easily citable? Should anyone have need of one or another of > these, they can simply invoke it rather than having to (once again) > specify it. > > > > Detailed Comments: > >> 1. Introduction > ... >> (*LWS element n*m(*LWS separator *LWS element)) > > I think the initial *LWS is not as common and that the typical form > for the list, itself, is: > > element n*m(*LWS separator *LWS element) > > This is worth noting simply to make the core definition simpler. > There's nothing 'wrong' with what is in the doc, but I can easily > imagine cases in which the leading white space (or even ANY white > space...) is not wanted. > > Also: > >> It is obvious that this construction is too simplified and bulky. > > It is not obvious to /me/ that it is too simplified... > > >> This document uses ABNF notation and core rules defined in RFC 5234 >> [RFC5234]. The construction in {} is used for expressing arithmetic >> expressions. For instance, if a=2, b=3 and c={b-a}, c is 1. In this >> case c=1*DIGIT. > > "In this case..."?? In what case? I don't see how the production > rule was obtained. I understand that a subtraction was performed > before that, but where is the previous version of the rule? > If the construction {} is used. > >> he ABNF notation for separated lists is ^()element > > The ABNF itself should be on a new line and indented, IMO. > > FWIW, I'm not fond of this notation. The parenthetical seems clunky, > especially since it overloads the use of parens. I also don't like > putting it in between the upper/lower bound. > > Out of curiosity, why ^ rather than re-use #? # is already used in RFC2616 so it is made not to create a conflict. > > That said, I don't have a form that I think is wonderful. > > I'll note that the original RFC733 ABNF was merely one of many > differerent BNF variants that were developed in the mid-70s. That > this particular variant became popular is worth some curiosity. My > best guess is that it happened to hit a balance between complexity and > power. It was simple enough and useful enough. > > I am very hard-pressed to look at the current proposal and feel that > it maintains that balance, even though I personally really like the > idea of a list notation and was sorry to see it removed by DRUMS. And > I think that having a list mechanism with the ability to specify the > separator is quite reasonable. > > >> 2.1. Examples >> >> The section contains a few examples of using the defined >> construction. >> >> 1^(";")3element indicates the list of elements separated by >> semicolons (";") and OPTIONAL linear-white-spaces which consists of >> at least 1 and at most 3 elements. >> >> 1^(SP)element indicates the list of elements separated by spaces and >> OPTIONAL linear-white-spaces which consists of any amount of elements >> but not less than 1. >> >> ^(",")3element indicates the list of elements separated by commas >> (",") and OPTIONAL linear-white-spaces which consists of any amount > > For me, these examples emphasize my concern about the appearance of > the notation. Perhaps one can get used to this notation and come to > interpret it naturally. However I tend to view a mass of graphics > within BNF as pretty distracting and not at all intuitive. > > While yes, this is more terse that the 'full' notation, I can't say > I'm impressed with the result. > > >> 3. Security Considerations >> >> Security issues are not discussed by this document. > > A notation that can create obscure effects might well introduce > security holes. That's an issue that is not specific to this > document, but I wonder whether it isn't time to raise this point in > the Considerations sectin? How can a simple notation have any security consideration? > > > At the moment -03 version is available where many issues were corrected. You can find it here: https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ Could you please review and comment this. Any suggestions are welcome. All the best, Mykyta Yevstifeyev From julian.reschke@gmx.de Sat Dec 11 03:09:11 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9A83A6D0F for ; Sat, 11 Dec 2010 03:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.492 X-Spam-Level: X-Spam-Status: No, score=-104.492 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LOAgoNjTOO6 for ; Sat, 11 Dec 2010 03:09:10 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 1B0B33A6AC1 for ; Sat, 11 Dec 2010 03:09:09 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2010 11:10:41 -0000 Received: from p508FB594.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.181.148] by mail.gmx.net (mp066) with SMTP; 11 Dec 2010 12:10:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18F0rJ2hFIFFqW5Isl8lOENSRvZgn1xEioDJ7AQns Pbi0GgeosvjiRV Message-ID: <4D035C28.6070804@gmx.de> Date: Sat, 11 Dec 2010 12:10:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave CROCKER References: <4D028FE0.20906@bbiw.net> In-Reply-To: <4D028FE0.20906@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 11:09:11 -0000 On 10.12.2010 21:38, Dave CROCKER wrote: > ... > Given continuance of the old "#" form, I wonder whether it might be > worth assembling whatever ABNF enhancements are out in the wild into an > Informational document, so that they stand on their own and are easily > citable? Should anyone have need of one or another of these, they can > simply invoke it rather than having to (once again) specify it. > ... Indeed, that would be a good idea. Some more thoughts: - Please don't mess with RFC 5234 until those extensions are well understood and *in use*. - Specifying is not sufficient; the few parsing and validation tools need to be extended. (*) - I'm not sure why a new list production that is inspired by "#" can't have the same name. Best regards, Julian (*) In HTTPbis, we extended Bill Fenner's ABNF parser ("BAP") to accept the list production and re-serialize it in plain RFC 5234; this is what we're using to produce the 5234-style ABNF. See . From d3e3e3@gmail.com Fri Dec 10 17:00:53 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F7B28C158; Fri, 10 Dec 2010 17:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRzW7CTdLXlV; Fri, 10 Dec 2010 17:00:52 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0864528C118; Fri, 10 Dec 2010 17:00:51 -0800 (PST) Received: by wyf23 with SMTP id 23so4125351wyf.31 for ; Fri, 10 Dec 2010 17:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u7lRdjuVq9l8uiOaPR1XmWRgNHnVuGaBq4TRZDrKau4=; b=iQECOg1JyfCPONWsFYBezei4pcjW0nMrIgSWp4960rQwsVToSdOvqpiSJe0Dj0Wgdj 3Od1/rG5pSCn5eaYP46MT1h9fX1Zch50x0zWeK8LYrKmVpVABqkQQj5ZJZzmlyqBY9yk IShCtVIEgfSN2ehCKI70CdQA1FJdIPrJb6GCc= 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=AE5t0H26c0tVwjBCpQbDgoEUaUvsfGld9+F8a7paRYaZPHVn4Zj7mnaWeL7dCbwEtN hsedIsW356Q/mT+6YfwJMqmNXfLlLVqGGma4VL2RGzFqzmscs+KcNNMrkf1j5iIUTvGb oWtUPVIY+lcnODKdTTQOY0FaojOCgMEiAuNNk= MIME-Version: 1.0 Received: by 10.227.167.8 with SMTP id o8mr81121wby.166.1292029343126; Fri, 10 Dec 2010 17:02:23 -0800 (PST) Received: by 10.227.153.8 with HTTP; Fri, 10 Dec 2010 17:02:23 -0800 (PST) In-Reply-To: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> References: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> Date: Fri, 10 Dec 2010 20:02:23 -0500 Message-ID: From: Donald Eastlake To: Doug Ewell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 11 Dec 2010 08:08:23 -0800 Cc: Mykyta Yevstifeyev , IETF Discussion , apps-discuss@ietf.org Subject: Re: [apps-discuss] A new version of draft-yevstifeyev-abnf-separated-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 01:00:53 -0000 On Fri, Dec 10, 2010 at 1:02 PM, Doug Ewell wrote: > Mykyta Yevstifeyev wrote: > >... > >> Acknowledgments >> >> =A0 =A0Many thanks to (in alphabetical order): Tony Hansen, Thomson Mart= in >> =A0 =A0and Barry Leiba for their weighty input to this document. > > This doesn't look like alphabetical order to me. =A0... Isn't it obvious? They are in inverse alphabetic order by first name. > Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org > RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s =AD Donald From doug@ewellic.org Fri Dec 10 10:00:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9206228C0FC for ; Fri, 10 Dec 2010 10:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUTCplO-YGMi for ; Fri, 10 Dec 2010 10:00:57 -0800 (PST) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by core3.amsl.com (Postfix) with SMTP id 8FF3A3A6B9B for ; Fri, 10 Dec 2010 10:00:57 -0800 (PST) Received: (qmail 29937 invoked from network); 10 Dec 2010 18:02:29 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 10 Dec 2010 18:02:28 -0000 Received: (qmail 30859 invoked by uid 99); 10 Dec 2010 18:02:28 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.190 User-Agent: Web-Based Email 5.3.00 Message-Id: <20101210110228.665a7a7059d7ee80bb4d670165c8327d.7d33a4a589.wbe@email03.secureserver.net> From: "Doug Ewell" To: "Mykyta Yevstifeyev" Date: Fri, 10 Dec 2010 11:02:28 -0700 Mime-Version: 1.0 X-Mailman-Approved-At: Sat, 11 Dec 2010 08:08:40 -0800 Cc: IETF Discussion , apps-discuss@ietf.org Subject: Re: [apps-discuss] A new version of draft-yevstifeyev-abnf-separated-lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 18:00:58 -0000 Mykyta Yevstifeyev wrote: > A new vesrion of draft-yevstifeyev-abnf-separated-lists is available (-03= ). >=20 > It is available here: >=20 > https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/ This document includes: > Acknowledgments > > Many thanks to (in alphabetical order): Tony Hansen, Thomson Martin > and Barry Leiba for their weighty input to this document. This doesn't look like alphabetical order to me. Is the parenthetical comment really necessary when only three names are involved? -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s =C2=AD From dhc@dcrocker.net Sat Dec 11 08:08:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A273A6D30 for ; Sat, 11 Dec 2010 08:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHhjED1rrpxv for ; Sat, 11 Dec 2010 08:08:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 99D313A6D2F for ; Sat, 11 Dec 2010 08:08:43 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBBGABMR030558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2010 08:10:16 -0800 Message-ID: <4D03A25E.9060709@dcrocker.net> Date: Sat, 11 Dec 2010 08:10:06 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <4D028FE0.20906@bbiw.net> In-Reply-To: <4D028FE0.20906@bbiw.net> 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]); Sat, 11 Dec 2010 08:10:17 -0800 (PST) Cc: Mykyta Yevstifeyev Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 11 Dec 2010 16:08:43 -0000 Folks, On 12/10/2010 12:38 PM, Dave CROCKER wrote: > FWIW, I'm not fond of this notation. The parenthetical seems clunky, especially > since it overloads the use of parens. I also don't like > putting it in between the upper/lower bound. > > Out of curiosity, why ^ rather than re-use #? I see that the new version of the notation is: > ^()^element Having the same character used twice invites some parsing errors, though perhaps I'm being a purist on this point. But having the separator be buried within the repetition boundaries numbers this way still causes me some discomfort. At this point I am wondering whether it would not be cleaner to have the notation be: *[^()]element In other words, augment the existing repetition construct with a clean separator construct. The up-arrow only specifies a separator, it does not also specify repetition. Hence: 1*10^":"tag-val would be 1 to 10 tag-vals separated by colons, and *^" "words would be zero or more words separated by a space. I'm still not in love with the up-arrow, but can see an argument for not overloading #, which runs the risk that a reader won't know which definition of # is in force. Also the issue of allowing LWS or the like around the separator might best be expressed within the separator construct rather than be implied. (On reflection, I have a vague memory that one of the other concerns about # was that whitespace was implied.) Hence: 1*3^(*LWSP "," *LWSP) makes whitespace optional around the separator, whereas: 1*3^("," LWSP) requires exactly one whitespace character after each comma. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From flefauch@cisco.com Fri Dec 10 23:31:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E4F3A6C5A for ; Fri, 10 Dec 2010 23:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXmJXAmZSV9h for ; Fri, 10 Dec 2010 23:31:19 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id CA68D3A69D2 for ; Fri, 10 Dec 2010 23:31:18 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,328,1288569600"; d="scan'208,217";a="15066216" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Dec 2010 07:32:51 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBB7Wovf003932; Sat, 11 Dec 2010 07:32:50 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary=Apple-Mail-9-212967878 Date: Sat, 11 Dec 2010 08:33:00 +0100 Message-Id: <9A1F150A-C3AE-4439-BD33-2F6EC9676210@cisco.com> To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sat, 11 Dec 2010 08:09:21 -0800 Cc: Francois Le Faucheur Subject: [apps-discuss] New Mailing List "CDNi -- Interconnection of Content Delivery Networks (CDNs)" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 07:31:20 -0000 --Apple-Mail-9-212967878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, A new mailing list has been created to discuss issues associated with = the "Interconnection of Content Delivery Networks (CDNs)". In particular, we encourage discussion on that list about the "CDN = Interconnection Problem Statement": = (http://www.ietf.org/internet-drafts/draft-jenkins-cdni-problem-statement-= 00.txt). See below the pointer "To subscribe" if you are interested in this = topic. Cheers Francois Begin forwarded message: > From: IETF Secretariat > Date: 10 December 2010 19:56:37 CET > To: IETF Announcement list > Cc: cdni@ietf.org, flefauch@cisco.com, ben@niven-jenkins.co.uk > Subject: New Non-WG Mailing List: Cdni -- Interconnection of Content = Delivery Networks (CDNs)=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: cdni@ietf.org > Archive: http://www.ietf.org/mail-archive/web/cdni/ > To subscribe: https://www.ietf.org/mailman/listinfo/cdni >=20 > Description: There is an emerging requirement for interconnecting = content > delivery networks (CDNs) so they can interoperate as an open content > delivery infrastructure for the end-to-end delivery of content from > Content Service Providers (CSPs) to end users. This list is to discuss = the > proposed development of IETF standards to facilitate such CDN > interconnection. These standards might include protocols for >=20 > 1) exchange of metadata between CDNs, > 2) exchange of transaction logs > 3) exchange of monitoring information > 4) exchange of policies & capabilities, and > 5) content management/flushing >=20 > For additional information, please contact the list administrators. --Apple-Mail-9-212967878 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,

A new = mailing list has been created to discuss issues associated with the = "Interconnection of Content  Delivery Networks = (CDNs)".

In particular, we encourage discussion = on that list about the "CDN Interconnection Problem = Statement":

See below the = pointer "To subscribe" if you are interested in this = topic.

Cheers

Francois

Begin forwarded message:

From: IETF Secretariat = <ietf-secretariat@ietf.org>= ;
10 December 2010 19:56:37 CET
To: IETF Announcement = list <ietf-announce@ietf.org>
<= /span>
New Non-WG Mailing List: Cdni -- Interconnection = of Content Delivery Networks (CDNs) 

A = new IETF non-working group email list has been created.

List = address: cdni@ietf.org
Archive: http://www.ietf.org/ma= il-archive/web/cdni/
To subscribe: https://www.ietf.org/m= ailman/listinfo/cdni

Description: There is an emerging = requirement for interconnecting content
delivery networks (CDNs) so = they can interoperate as an open content
delivery infrastructure for = the end-to-end delivery of content from
Content Service Providers = (CSPs) to end users. This list is to discuss the
proposed development = of IETF standards to facilitate such CDN
interconnection. These = standards might include protocols for

1) exchange of metadata = between CDNs,
2) exchange of transaction logs
3) exchange of = monitoring information
4) exchange of policies & capabilities, = and
5) content management/flushing

For additional information, = please contact the list administrators.
In-Reply-To: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 18:59:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D02AF81.6000907@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Sat, 11 Dec 2010 08:09:38 -0800 Cc: "apps-discuss@ietf.org" , "websec@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 02:58:26 -0000 On Dec 10, 2010, at 2:53 PM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt I think http://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04 is = the most recent iteration on the concept. This is at the TLS layer, not = the http layer. As Paul Hoffman said, X.509 client cert's. In fact one could argue = that's the traditional solution and that software support is already = widely available. Some organizations make this more practical by = issuing the client certs with KX509. = http://tools.ietf.org/search/draft-hotz-kx509-01 (-; Comments are still = desired! ;-) http://tools.ietf.org/html/rfc4559 (Microsoft's HTTP-Negotiate) Note = that W7/2K8 add channel binding to that, but it's an incompatible = upgrade, so it may not get the use it should. There is also active work in the abfab wg which is related. Please try = to synergise, not compete with that work. SAML Web-sso ---- IMO there are already enough options which don't do channel binding with = the enclosing TLS session. I believe any solution you propose should = either do that, or should operate as part of TLS itself. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From marsh@extendedsubset.com Fri Dec 10 15:52:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52628C16B; Fri, 10 Dec 2010 15:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T0nlJOeG43h; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6FEB928C13D; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRCnG-0007jy-Mx; Fri, 10 Dec 2010 23:54:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BC33060C7; Fri, 10 Dec 2010 23:54:28 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/98GPaWAVDLHrWGRfLI2yC8jrjm0RWGOw= Message-ID: <4D02BDB3.7060801@extendedsubset.com> Date: Fri, 10 Dec 2010 17:54:27 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D02AF81.6000907@stpeter.im> In-Reply-To: <4D02AF81.6000907@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 11 Dec 2010 08:09:49 -0800 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:52:59 -0000 On 12/10/2010 04:53 PM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? No? :-) IMHO, authentication just doesn't belong at the HTTP layer. HTTP is inherently bad at being stateful. Stateless interfaces can be fantastic, but it doesn't support the "login session" concept that most people have in mind when they talk about authentication. Unless you're properly using TLS, you have no reason to believe that the byte you just received is from the same party as the previous byte you received. So under those circumstances, what exactly are you authenticating, and to whom? I use a lot of web sites and none of them do authentication via HTTP. Every single one of them expects a username/password via HTTP(s) POST variables and returns a cookie of varying duration. But what could we possibly do for a stateless, unMACed protocol like HTTP, except integrate and bind it better with a lower layer providing real integrity? I think what the world needs are ways for web apps (literally, the Ruby code) to easily work with the strongly-authenticated identities which are supported at the TLS layer. TLS already supports "sessions" and "client authentication", but for whatever reasons they're not being utilized. We should make using those facilities as easy for web developers as doing cookie-based logins. Improving the "authentication" for a protocol lacking basic message integrity would just be giving a false sense of security. It's like improving the login authentication for telnet or FTP sessions. But I do think there are lots of improvements waiting to be made in the right directions. - Marsh From dhc@dcrocker.net Sat Dec 11 08:15:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5183A6D25 for ; Sat, 11 Dec 2010 08:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vruq+b6KgPNR for ; Sat, 11 Dec 2010 08:15:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 485213A6B55 for ; Sat, 11 Dec 2010 08:15:19 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBBGGlK7030808 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2010 08:16:53 -0800 Message-ID: <4D03A3EA.60006@dcrocker.net> Date: Sat, 11 Dec 2010 08:16:42 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <4D028FE0.20906@bbiw.net> <4D035776.4080206@gmail.com> In-Reply-To: <4D035776.4080206@gmail.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]); Sat, 11 Dec 2010 08:16:53 -0800 (PST) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 11 Dec 2010 16:15:21 -0000 On 12/11/2010 2:50 AM, Mykyta Yevstifeyev wrote: > Hello all, > > Some notes: > > Firstly, this is a review of -02 version and many issues have been > corrected in -03 one. However I raised a number of questions and concerns that do not appear to be resolved in the new version. Since the number of comments in the review is not all that large, it would be helpful to see responses to each, even for those having the response "resolved in -03." That will make it easy for readers to form their own opinions about the resolutions. >>> 3. Security Considerations >>> >>> Security issues are not discussed by this document. >> >> A notation that can create obscure effects might well introduce security >> holes. That's an issue that is not specific to this document, but I wonder >> whether it isn't time to raise this point in the Considerations sectin? > How can a simple notation have any security consideration? Whether it is simple is not the point. The point is that a meta-syntax that makes syntax specifications less clear can make it legal to have data in forms that might not have been intended or desired. This can, in turn, allow in types of data that are potentially dangerous. This is often a problem with space, for example, which seeks to bypass filters. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Josh.Howlett@ja.net Sun Dec 12 00:28:29 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9493A6D83; Sun, 12 Dec 2010 00:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.098 X-Spam-Level: X-Spam-Status: No, score=-102.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uijQy4we-7Wr; Sun, 12 Dec 2010 00:28:28 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 845183A6D03; Sun, 12 Dec 2010 00:28:28 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 8D3C64A6BAA_D04880AB; Sun, 12 Dec 2010 08:30:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 3F5484A6BA3_D0487FFF; Sun, 12 Dec 2010 08:29:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Sun, 12 Dec 2010 08:30:08 +0000 From: Josh Howlett To: Yaron Sheffer , Luke Howard Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U4= Date: Sun, 12 Dec 2010 08:30:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:16:27 -0800 Cc: Josh Howlett , "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 08:28:29 -0000 AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based mutual authentication (i.e. password based auth that's *not* susceptible to dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From alexey.melnikov@isode.com Sun Dec 12 06:09:09 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AFD3A6DC1; Sun, 12 Dec 2010 06:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RKNwzBRmOBT; Sun, 12 Dec 2010 06:09:08 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ED60D3A6DBE; Sun, 12 Dec 2010 06:09:07 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Dec 2010 14:10:42 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D04D7D6.4090105@isode.com> Date: Sun, 12 Dec 2010 17:10:30 +0300 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: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> In-Reply-To: <4D0479E3.4050508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Dec 2010 08:16:45 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , Luke Howard , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:09:10 -0000 Yaron Sheffer wrote: > Hi Luke, > > I am not a big fan of EAP myself (although I am a co-author on Yoav's > TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. > > There is a number of EAP methods that provide zero-knowledge password > based mutual authentication (i.e. password based auth that's *not* > susceptible to dictionary attacks). These include (see > http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): > EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. > > As far as I can see > (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), > SASL does not provide any equivalent method. There is an expired SASL SRP draft, which can be revived, if needed. > Thanks, > Yaron > > On 12/12/2010 03:38 AM, Luke Howard wrote: > >> On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >> >>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >>> >>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> >>>>> Other than that, I'm not aware of much activity. What have I missed? >>>> >>>> >>>> TLS client certificates. >>> >>> >>> TLS client certificates work, but as we've learned both with the web >>> and with IPsec clients, people would much rather not use them. A few >>> IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS >>> with EAP authentication. >>> >>> http://tools.ietf.org/html/draft-nir-tls-eap >> >> >> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral >> equivalent? >> >> -- Luke > From Josh.Howlett@ja.net Sun Dec 12 01:15:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51F33A6C70; Sun, 12 Dec 2010 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCxxAMcVq9eP; Sun, 12 Dec 2010 01:15:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 514483A6D8E; Sun, 12 Dec 2010 01:15:18 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F0B604A6B4E_D049304B; Sun, 12 Dec 2010 09:16:52 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 9E1374A6BA3_D0492F9F; Sun, 12 Dec 2010 09:16:41 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Sun, 12 Dec 2010 09:16:58 +0000 From: Josh Howlett To: Yoav Nir , Yaron Sheffer , Luke Howard Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U6AAAIIsIAACxBo Date: Sun, 12 Dec 2010 09:16:58 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:16:57 -0800 Cc: Josh Howlett , "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 09:15:19 -0000 Right, HTTP authentication is out of Abfab's scope. My point was that Abfab= is doing stuff that may nonetheless be useful for some other effort lookin= g at the problem. I agree with your observation re federation, but note that EAP authenticati= on does not imply federation. Josh. --- original message --- From: "Yoav Nir" Subject: RE: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 8:42:08 am To quote from Abfab's charter: This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, For just adding authentication to HTTP, I don't think it makes sense to add= federation. All kinds of services such as web mail, online gaming, and onl= ine shopping require authentication, but there's no federation involved. -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@ja.net] Sent: 12 December 2010 10:30 To: Yaron Sheffer; Luke Howard Cc: apps-discuss@ietf.org; pgut001@cs.auckland.ac.nz; Yoav Nir; websec; Pau= l Hoffman; kitten@ietf.org; http-auth@ietf.org; saag@ietf.org; Hannes Tscho= fenig; Josh Howlett; ietf-http-wg@w3.org Group Subject: Re: [kitten] [saag] HTTP authentication: the next generation AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-E= AP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based= mutual authentication (i.e. password based auth that's *not* susceptible t= o dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by gu= arantee which is registered in England under No. 2881024 and whose Register= ed Office is at Lumen House, Library Avenue, Harwell Science and Innovation= Campus, Didcot, Oxfordshire. OX11 0SG Scanned by Check Point Total Security Gateway. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From lukeh@padl.com Sat Dec 11 17:37:09 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7E13A6CE2; Sat, 11 Dec 2010 17:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTb5wLZeH8eU; Sat, 11 Dec 2010 17:37:05 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 55CB128C0CE; Sat, 11 Dec 2010 17:37:04 -0800 (PST) Received: by us.padl.com with ESMTP id oBC1c2GK007734; Sat, 11 Dec 2010 20:38:07 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sun, 12 Dec 2010 12:38:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> References: <4D02AF81.6000907@stpeter.im> To: Yoav Nir X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:08 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 01:37:09 -0000 On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >=20 > On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >=20 >> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>> Other than that, I'm not aware of much activity. What have I missed? >>=20 >> TLS client certificates. >=20 > TLS client certificates work, but as we've learned both with the web = and with IPsec clients, people would much rather not use them. A few = IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with = EAP authentication. >=20 > http://tools.ietf.org/html/draft-nir-tls-eap Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral = equivalent? -- Luke= From yaronf.ietf@gmail.com Sat Dec 11 23:28:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B39C3A6D75; Sat, 11 Dec 2010 23:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiBC6E4S4MDM; Sat, 11 Dec 2010 23:28:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 418D43A69D5; Sat, 11 Dec 2010 23:28:10 -0800 (PST) Received: by wwa36 with SMTP id 36so5250627wwa.13 for ; Sat, 11 Dec 2010 23:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4BFdEbuS5k7moTIeZMWDbonXYuvqM+FTh7HK4s3ELV0=; b=R7zZPnIdBOKNp2nPeY3K2NZhjgou7tvoXebnAJFu57k1tGQrLCFj+l0rpZR0asu1S6 2w7t4qH9SMTmg+62Ci7lXDKi8KFqbb4U3GJflfE+2VX4jvyr6NhqzA/nEe0l6QNG+9wf Jf6l+cPirQMhESjYBt+yEvnELn1yt0qMx9xWw= 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=NUSfE1FKnrB8OjMzRVgLCWMde44hlMwveBcDaHt41pcHQnnk89wsCZhMagUfqgOjXR Zf+GPV9NVwiXT7GAOXfi4tJIs6cL5w36QmIFg5SoO9g2ZTjBOWGrcLT8iglgpe9PJHuG QjEuWGoIbHF99bjbQz2K1rmlXb6r4q6kNy5cY= Received: by 10.216.50.72 with SMTP id y50mr900755web.28.1292138984263; Sat, 11 Dec 2010 23:29:44 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id m10sm3466389wbc.16.2010.12.11.23.29.40 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Dec 2010 23:29:42 -0800 (PST) Message-ID: <4D0479E3.4050508@gmail.com> Date: Sun, 12 Dec 2010 09:29:39 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Luke Howard References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> In-Reply-To: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:16 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 07:28:12 -0000 Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based mutual authentication (i.e. password based auth that's *not* susceptible to dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equivalent? > > -- Luke From ynir@checkpoint.com Sat Dec 11 15:08:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2943A6CC6; Sat, 11 Dec 2010 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=1.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNfpvjyZj955; Sat, 11 Dec 2010 15:08:57 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E78FF3A6CC3; Sat, 11 Dec 2010 15:08:53 -0800 (PST) X-CheckPoint: {4D0404E3-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBBNAFio001572; Sun, 12 Dec 2010 01:10:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 01:10:15 +0200 From: Yoav Nir To: Paul Hoffman , websec , Peter Saint-Andre Date: Sun, 12 Dec 2010 01:10:11 +0200 Thread-Topic: [saag] HTTP authentication: the next generation Thread-Index: AcuZiJEeUrzxMlnURUmsuTqhB7a9Ww== Message-ID: References: <4D02AF81.6000907@stpeter.im> 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 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:24 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 23:08:59 -0000 On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: > At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >> Other than that, I'm not aware of much activity. What have I missed? >=20 > TLS client certificates. TLS client certificates work, but as we've learned both with the web and wi= th IPsec clients, people would much rather not use them. A few IETFs ago (C= hicago?), a bunch of us tried to push the idea of TLS with EAP authenticati= on. http://tools.ietf.org/html/draft-nir-tls-eap At the time, the TLS working group (and an AD) told us that this would cont= radict the applicability statement of EAP, so no, you cannot use EAP for an= ything other than network access.=20 Now we have the abfab working group, so I don't think this still holds. Also, I agree with Marsh, that authentication is not enough, and you need t= he rest of TLS anyway. So yes, I think that it is time to resurrect HTTP authentication. Yoav From ynir@checkpoint.com Sat Dec 11 15:14:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BDD3A6CF7; Sat, 11 Dec 2010 15:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.364 X-Spam-Level: X-Spam-Status: No, score=-9.364 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a-6pFCQ27YO; Sat, 11 Dec 2010 15:14:20 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 94A583A6D09; Sat, 11 Dec 2010 15:14:19 -0800 (PST) X-CheckPoint: {4D040629-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBBNFrmj001961; Sun, 12 Dec 2010 01:15:53 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 01:15:52 +0200 From: Yoav Nir To: websec , Peter Saint-Andre Date: Sun, 12 Dec 2010 01:15:51 +0200 Thread-Topic: [saag] HTTP authentication: the next generation Thread-Index: AcuZiVq4ANG3mfypQUiHj/vOrV2Hpw== Message-ID: <5C0D484C-682B-4B7B-B7EA-DFC78ADA3ED4@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> 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 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:34 -0800 Cc: "http-auth@ietf.org" , "saag@ietf.org" , "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 23:14:20 -0000 resending with less recipients... On Dec 12, 2010, at 1:10 AM, Yoav Nir wrote: >=20 > On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >=20 >> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>> Other than that, I'm not aware of much activity. What have I missed? >>=20 >> TLS client certificates. >=20 > TLS client certificates work, but as we've learned both with the web and = with IPsec clients, people would much rather not use them. A few IETFs ago = (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentica= tion. >=20 > http://tools.ietf.org/html/draft-nir-tls-eap >=20 > At the time, the TLS working group (and an AD) told us that this would co= ntradict the applicability statement of EAP, so no, you cannot use EAP for = anything other than network access.=20 >=20 > Now we have the abfab working group, so I don't think this still holds. >=20 > Also, I agree with Marsh, that authentication is not enough, and you need= the rest of TLS anyway. >=20 > So yes, I think that it is time to resurrect HTTP authentication. >=20 > Yoav >=20 >=20 From ynir@checkpoint.com Sun Dec 12 00:40:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62523A6D89; Sun, 12 Dec 2010 00:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy4+jBAiaJoV; Sun, 12 Dec 2010 00:40:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0CB0E3A6D03; Sun, 12 Dec 2010 00:40:00 -0800 (PST) X-CheckPoint: {4D048ABF-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBC8fOCj014846; Sun, 12 Dec 2010 10:41:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 10:41:24 +0200 From: Yoav Nir To: "'Josh Howlett'" , Yaron Sheffer , Luke Howard Date: Sun, 12 Dec 2010 10:41:23 +0200 Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U6AAAIIsA== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD449F@il-ex01.ad.checkpoint.com> 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 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:42 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 08:40:02 -0000 To quote from Abfab's charter: This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP,=20 For just adding authentication to HTTP, I don't think it makes sense to add= federation. All kinds of services such as web mail, online gaming, and onl= ine shopping require authentication, but there's no federation involved.=20 -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@ja.net]=20 Sent: 12 December 2010 10:30 To: Yaron Sheffer; Luke Howard Cc: apps-discuss@ietf.org; pgut001@cs.auckland.ac.nz; Yoav Nir; websec; Pau= l Hoffman; kitten@ietf.org; http-auth@ietf.org; saag@ietf.org; Hannes Tscho= fenig; Josh Howlett; ietf-http-wg@w3.org Group Subject: Re: [kitten] [saag] HTTP authentication: the next generation AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-E= AP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based= mutual authentication (i.e. password based auth that's *not* susceptible t= o dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by gu= arantee which is registered in England under No. 2881024 and whose Register= ed Office is at Lumen House, Library Avenue, Harwell Science and Innovation= Campus, Didcot, Oxfordshire. OX11 0SG Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Sun Dec 12 06:20:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6F83A6DC3; Sun, 12 Dec 2010 06:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.459 X-Spam-Level: X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nFTpAiwfcwo; Sun, 12 Dec 2010 06:20:47 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EB9663A6DC0; Sun, 12 Dec 2010 06:20:46 -0800 (PST) X-CheckPoint: {4D04DA9D-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBCEMKn0026696; Sun, 12 Dec 2010 16:22:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 16:22:20 +0200 From: Yoav Nir To: Alexey Melnikov Date: Sun, 12 Dec 2010 16:22:23 +0200 Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AcuaB/xyAYCHWnJxTlaeEDShPLa+xg== Message-ID: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> In-Reply-To: <4D04D7D6.4090105@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 12 Dec 2010 08:17:51 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:20:49 -0000 EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETE= R infrastructure.=20 On Dec 12, 2010, at 4:10 PM, Alexey Melnikov wrote: > Yaron Sheffer wrote: >=20 >> Hi Luke, >>=20 >> I am not a big fan of EAP myself (although I am a co-author on Yoav's=20 >> TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent= . >>=20 >> There is a number of EAP methods that provide zero-knowledge password=20 >> based mutual authentication (i.e. password based auth that's *not*=20 >> susceptible to dictionary attacks). These include (see=20 >> http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-= 3):=20 >> EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. >>=20 >> As far as I can see=20 >> (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml),= =20 >> SASL does not provide any equivalent method. >=20 > There is an expired SASL SRP draft, which can be revived, if needed. >=20 >> Thanks, >> Yaron >>=20 >> On 12/12/2010 03:38 AM, Luke Howard wrote: >>=20 >>> On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >>>=20 >>>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >>>>=20 >>>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>>>=20 >>>>>> Other than that, I'm not aware of much activity. What have I missed? >>>>>=20 >>>>>=20 >>>>> TLS client certificates. >>>>=20 >>>>=20 >>>> TLS client certificates work, but as we've learned both with the web=20 >>>> and with IPsec clients, people would much rather not use them. A few=20 >>>> IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS=20 >>>> with EAP authentication. >>>>=20 >>>> http://tools.ietf.org/html/draft-nir-tls-eap >>>=20 >>>=20 >>> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral=20 >>> equivalent? >>>=20 >>> -- Luke >>=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From lear@cisco.com Sun Dec 12 08:39:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DBF28C0E6 for ; Sun, 12 Dec 2010 08:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.015 X-Spam-Level: X-Spam-Status: No, score=-110.015 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZe0-Cah95PK for ; Sun, 12 Dec 2010 08:39:13 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DD05428C0D7 for ; Sun, 12 Dec 2010 08:39:12 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,332,1288569600"; d="scan'208,217";a="15107511" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 16:40:48 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCGel7F004241; Sun, 12 Dec 2010 16:40:47 GMT Message-ID: <4D04FB1A.6030804@cisco.com> Date: Sun, 12 Dec 2010 17:40:58 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Eliot Lear , Apps Discuss , "apps-review@ietf.org" , draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, "'IESG'" References: <4CFDDD2F.2020201@cisco.com> In-Reply-To: <4CFDDD2F.2020201@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------020207080800030402090202" Subject: Re: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 16:39:14 -0000 This is a multi-part message in MIME format. --------------020207080800030402090202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I wrote: On 12/7/10 8:07 AM, Eliot Lear 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-eai-rfc5337bis-01 > Title: Internationalized Delivery Status and Disposition Notifications > Reviewer: Eliot Lear > Review Date: 7 Dec 2010 > ... > More importantly, the specification makes use of the =/ operator from > RFC 5234, but for constructs that it does not control. I don't know > if this was the original intent or not, but I am a little concerned > that use of =/ in a construct that is not wholly controlled by a > single specification is asking for confusion later. This is an > optional specification, right? After discussing this a bit with Dave Crocker, perhaps this problem is all in my head. Therefore, I recommend no change to the spec on this point. Eliot --------------020207080800030402090202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I wrote:

On 12/7/10 8:07 AM, Eliot Lear 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-eai-rfc5337bis-01
Title: Internationalized Delivery Status and Disposition Notifications
Reviewer: Eliot Lear
Review Date: 7 Dec 2010


...

More importantly, the specification makes use of the =/ operator  from RFC 5234, but for constructs that it does not control.  I don't know if this was the original intent or not, but I am a little concerned that use of =/ in a construct that is not wholly controlled by a single specification is asking for confusion later.  This is an optional specification, right?

After discussing this a bit with Dave Crocker, perhaps this problem is all in my head.  Therefore, I recommend no change to the spec on this point.

Eliot
--------------020207080800030402090202-- From dhc@dcrocker.net Sun Dec 12 09:15:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431C83A6DEC; Sun, 12 Dec 2010 09:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoAuPyNymyLN; Sun, 12 Dec 2010 09:15:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id EA2653A6DE5; Sun, 12 Dec 2010 09:15:04 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBCHGZi5026913 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 12 Dec 2010 09:16:40 -0800 Message-ID: <4D050373.40406@dcrocker.net> Date: Sun, 12 Dec 2010 09:16:35 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org References: <4CFDDD2F.2020201@cisco.com> <4D04FB1A.6030804@cisco.com> In-Reply-To: <4D04FB1A.6030804@cisco.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]); Sun, 12 Dec 2010 09:16:41 -0800 (PST) Cc: Apps Discuss , 'IESG' , "apps-review@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 12 Dec 2010 17:15:07 -0000 On 12/12/2010 8:40 AM, Eliot Lear wrote: >> More importantly, the specification makes use of the =/ operator from RFC >> 5234, but for constructs that it does not control. I don't know if this was >> the original intent or not, but I am a little concerned that use of =/ in a >> construct that is not wholly controlled by a single specification is asking >> for confusion later. This is an optional specification, right? > > After discussing this a bit with Dave Crocker, perhaps this problem is all in my > head. Therefore, I recommend no change to the spec on this point. While I believe the current specification's use of =/ is not only legal but that it is in fact exactly the sort of use that was intended, I also note that it's a pretty unusual ABNF construct and that it might invite some confusion. Cross-referencing a rule from another specification strikes me as a big deal and that it's worth helping the reader as much as possible. So I suggest having a citation for the original version of the rule be included in a comment associated with the new rule. For example: generic-address =/ utf-8-enc-addr ; updates Section 3.2.3 of [RFC3798] d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Sun Dec 12 10:39:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B343A6DF1; Sun, 12 Dec 2010 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fihkoYXOihe; Sun, 12 Dec 2010 10:39:27 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AFFEB3A6DEE; Sun, 12 Dec 2010 10:39:26 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Dec 2010 18:41:01 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D051731.1020400@isode.com> Date: Sun, 12 Dec 2010 21:40:49 +0300 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: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 18:39:28 -0000 Yoav Nir wrote: >EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETER infrastructure. > True. And SASL has an advantage that it is easier to integrate with LDAP infrastructure. I think this just demonstrates that before an HTTP authentication mechanism can be evaluated, people need to agree on a common evaluation criteria for HTTP authentication. From lear@cisco.com Sun Dec 12 13:34:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D433A6E08; Sun, 12 Dec 2010 13:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.055 X-Spam-Level: X-Spam-Status: No, score=-110.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NebqHih4IIKe; Sun, 12 Dec 2010 13:34:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3D5EE3A6D47; Sun, 12 Dec 2010 13:34:15 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAEAIjPBE2Q/khLgWdsb2JhbACDXKAqFQEBFiIppWmKSY9SgSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="15112279" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 21:35:51 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCLZoMB011735; Sun, 12 Dec 2010 21:35:50 GMT Message-ID: <4D054041.7010203@cisco.com> Date: Sun, 12 Dec 2010 22:36:01 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexey Melnikov References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> In-Reply-To: <4D051731.1020400@isode.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , Yoav Nir , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:34:17 -0000 Why settle for one? On 12/12/10 7:40 PM, Alexey Melnikov wrote: > Yoav Nir wrote: > >> EAP has one advantage. It is easy to integrate with existing >> RADIUS/DIAMETER infrastructure. >> > True. > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From lyndon@gandalf.orthanc.ca Sun Dec 12 13:47:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61CF83A6D0C for ; Sun, 12 Dec 2010 13:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xDB1FWaI1uy for ; Sun, 12 Dec 2010 13:47:18 -0800 (PST) Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by core3.amsl.com (Postfix) with ESMTP id 764C33A6CEE for ; Sun, 12 Dec 2010 13:47:18 -0800 (PST) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id oBCLmqAU082703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Dec 2010 13:48:52 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id oBCLmq5e082702; Sun, 12 Dec 2010 13:48:52 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Received: from gandalf.orthanc.ca (frodo.orthanc.ca [172.16.0.3]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id oBCLmnE4051762; Sun, 12 Dec 2010 13:48:49 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Message-ID: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> To: dhc@dcrocker.net, draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" Date: Sun, 12 Dec 2010 13:48:48 -0800 In-Reply-To: <4D050373.40406@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org, iesg@ietf.org, apps-review@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:47:19 -0000 > So I suggest having a citation for the original version of the rule be included > in a comment associated with the new rule. > > For example: > > generic-address =/ utf-8-enc-addr > ; updates Section 3.2.3 of [RFC3798] FWIW, this is what I did for IMAP Binary (3516); it doesn't seem to have caused any confusion: 7. Formal Protocol Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [IMAP4rev1]. append =/ "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal8 fetch-att =/ "BINARY" [".PEEK"] section-binary [partial] / "BINARY.SIZE" section-binary literal8 = "~{" number "}" CRLF *OCTET ; represents the number of OCTETs ; in the response string. msg-att-static =/ "BINARY" section-binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP number partial = "<" number "." nz-number ">" resp-text-code =/ "UNKNOWN-CTE" section-binary = "[" [section-part] "]" The base IMAP RFC (3501) made this construct easy and (I think) relatively obvious. YMMV. If a grammar extension is globally applicable to a parent specification, I think the subject document reads easier if the extension is called out at the top of the grammar, rather than littering each ABNF element with a callout comment. The alternatives can get very noisy, especially if there is multiple inheritance involved. --lyndon From lear@cisco.com Sun Dec 12 13:57:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28693A6E74 for ; Sun, 12 Dec 2010 13:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.072 X-Spam-Level: X-Spam-Status: No, score=-110.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLTviKxItMDI for ; Sun, 12 Dec 2010 13:57:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A583C3A6E62 for ; Sun, 12 Dec 2010 13:57:47 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAEADfUBE2Q/khLgWdsb2JhbACDXKAqFQEBFiIppgmKSY9RgSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="71478366" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2010 21:59:23 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCLxN3J014633; Sun, 12 Dec 2010 21:59:23 GMT Message-ID: <4D0545C5.5040608@cisco.com> Date: Sun, 12 Dec 2010 22:59:33 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" References: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> In-Reply-To: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, discuss@apps.ietf.org, iesg@ietf.org, apps-review@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:57:49 -0000 On 12/12/10 10:48 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > The base IMAP RFC (3501) made this construct easy and (I think) > relatively obvious. YMMV. If a grammar extension is globally > applicable to a parent specification, I think the subject document > reads easier if the extension is called out at the top of the grammar, > rather than littering each ABNF element with a callout comment. The > alternatives can get very noisy, especially if there is multiple > inheritance involved. I take your point but then if you are calling out multiple specifications someone has to go on a fishing expedition to understand perhaps the single definition they want out of a specification. Eliot From fielding@gbiv.com Sun Dec 12 14:37:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2483A6DFA; Sun, 12 Dec 2010 14:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F7DPk-i9+xg; Sun, 12 Dec 2010 14:37:48 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id E3FE33A6CCA; Sun, 12 Dec 2010 14:37:47 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 765EE1F0069; Sun, 12 Dec 2010 14:39:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=FYJb5G/ckuimNYH2 EAMF3uuc/bmghPYH8ir/SmwsMldYFoE+q6MzaGFSbJI9RRh/KECrXuBVc6f27dDE yhWSaZliwtQsnTI1hlclvSpj7YkVT+8KdfyzMKny2yqtt3roZAfNF7h3tWfvOKEl SiiYD3rxArbXfIIhT3q52pL2QAA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=AY54s7iPVjMmfy217h64SJv5wQw=; b=cyn7LDvPTexWvZcI80dZLqHSlJG2 E1gBEKD8jFcSwDbV5YdfvdzZHIXMaoq+R3IN+Ssx1HqjKORiTU7yYahe0XDvqbAM /XzSPPuTPFS5TVncRhVYQ6NaMqT4zN462bWQbXkR52lqQjt4FoIDFAeLLne3QyTS +587nIlVypmcR3A= Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id 01E541F0065; Sun, 12 Dec 2010 14:39:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D051731.1020400@isode.com> Date: Sun, 12 Dec 2010 14:39:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1082) Cc: "apps-discuss@ietf.org" , Yoav Nir , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 22:37:49 -0000 On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > Yoav Nir wrote: >=20 >> EAP has one advantage. It is easy to integrate with existing = RADIUS/DIAMETER infrastructure. >>=20 > True. > And SASL has an advantage that it is easier to integrate with LDAP = infrastructure. >=20 > I think this just demonstrates that before an HTTP authentication = mechanism can be evaluated, people need to agree on a common evaluation = criteria for HTTP authentication. Define them all and let's have a bake-off. It has been 16 years since HTTP auth was taken out of our hands so that the security experts could define something perfect. Zero progress so far. We should just define everything and let the security experts do what they do best -- find the holes and tell us what not to implement. ....Roy= From Martin.Thomson@andrew.com Sun Dec 12 20:57:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB423A6DAE for ; Sun, 12 Dec 2010 20:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+cki-MzIMpo for ; Sun, 12 Dec 2010 20:57:22 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 0B38D3A6D93 for ; Sun, 12 Dec 2010 20:57:22 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:58985 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S512742Ab0LME66 (ORCPT ); Sun, 12 Dec 2010 22:58:58 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 12 Dec 2010 22:58:58 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 13 Dec 2010 12:58:56 +0800 From: "Thomson, Martin" To: "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Date: Mon, 13 Dec 2010 12:58:54 +0800 Thread-Topic: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 Thread-Index: AcuZTezMHyHe3/qlTuGNhRprTlW7TgBK2u7g Message-ID: <8B0A9FCBB9832F43971E38010638454F03F34FAB84@SISPE7MB1.commscope.com> References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> In-Reply-To: <4D03A25E.9060709@dcrocker.net> 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 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Mykyta Yevstifeyev Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 04:57:23 -0000 T24gMjAxMC0xMi0xMiBhdCAwMzoxMDowNiwgRGF2ZSBDUk9DS0VSIHdyb3RlOg0KPiBBdCB0aGlz IHBvaW50IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgaXQgd291bGQgbm90IGJlIGNsZWFuZXIgdG8g aGF2ZQ0KPiB0aGUNCj4gbm90YXRpb24gYmU6DQo+IA0KPiAgICAgICA8bj4qPG0+W14oPGE+KV1l bGVtZW50DQoNCkkgd2FzIGluaXRpYWxseSBhcHByZWhlbnNpdmUgb2YgeW91ciBwcm9wb3NlZCBy ZXVzZSBvZiAiKiIgZm9yIHRoaXMgY29uc3RydWN0LiAgSG93ZXZlciwgb24gcmVmbGVjdGlvbiwg SSBsaWtlIGl0LiAgVGhpcyBpcyBhIHN0YXRlbWVudCB0aGF0IHNheXMgdGhlcmUgYXJlIDxuPiB0 byA8bT4gZWxlbWVudHMsIGV4Y2VwdCB0aGF0IHRoaXMgaXMgdHdlYWtlZCBzbyB0aGF0IGVhY2gg cmVwZXRpdGlvbiBpcyBzZXBhcmF0ZWQgYnkgPGE+LiAgVGhlIGRlZmF1bHQgdmFsdWUgZm9yIDxh PiBpcyB0aGUgZW1wdHkgc3RyaW5nLg0KDQpEcm9wIHRoZSBwYXJlbnRoZXNlcy4NCg0KSSdtIHN0 aWxsIGNvbmNlcm5lZCBhYm91dCBob3cgPGE+IGlzIGRlZmluZWQuICBJdCBzZWVtcyB0aGF0IDxl bGVtZW50PiBpcyB0aGUgcmlnaHQgcnVsZSB0byB1c2UgaGVyZTsgdGhlIC0wMyBkcmFmdCBzdGls bCB1c2VzIGBgKihWQ0hBUiAvIFNQIC8gSFQpJycsIHdoaWNoIEkgdGhpbmsgaXMgd3JvbmcuDQoN ClRoYXQgZ2l2ZXMgYSBuZXcsIGV4cGFuZGVkIGRlZmluaXRpb24gZm9yIHRoZSA8cmVwZWF0PiBy dWxlOg0KDQogIHJlcGVhdCAgICAgICAgID0gICgxKkRJR0lUIC8gKCpESUdJVCAiKiIgKkRJR0lU KSkgWyJeIiBlbGVtZW50XQ0KDQpNeWt5dGE6IHRoaXMgaXMgd2hhdCB0aGUgZHJhZnQgaXMgc3Rp bGwgbWlzc2luZy4gIFJhdGhlciB0aGFuIGNvbmNlbnRyYXRpbmcgb24gdGhlIGV4cGFuZGVkIGZv cm07IHVzZSBwcm9zZSBhbmQgZXhhbXBsZSBhbmQgaW5zdGVhZCBjb25jZW50cmF0ZSBvbiBnZXR0 aW5nIHRoZSBzeW50YXggcmlnaHQuDQoNCj4gSSdtIHN0aWxsIG5vdCBpbiBsb3ZlIHdpdGggdGhl IHVwLWFycm93IFsuLi5dDQoNCkkgdG9vIGhhZCBhIHNpbWlsYXIgcmVhY3Rpb24sIGJ1dCBpdCdz IG9ubHkgZmFpciB0aGF0IE15a3l0YSBnZXRzIHRvIGNob29zZSwgaGF2aW5nIGhhZCB0aGUgaW5p dGlhdGl2ZSB0byB3cml0ZSB0aGlzIGRvd24uICBJIHJlYWxseSBjYW4ndCB0aGluayBvZiBhIHJl YXNvbiBvdGhlciB0aGFuIHRoZSBhZXN0aGV0aWMgb25lLCB3aGljaCBpc24ndCByZWFsbHkgc3Ry b25nIGVub3VnaCB0byBhc2sgZm9yIGEgY2hhbmdlLg0KDQo+IEFsc28gdGhlIGlzc3VlIG9mIGFs bG93aW5nIExXUyBvciB0aGUgbGlrZSBhcm91bmQgdGhlIHNlcGFyYXRvciBtaWdodA0KPiBiZXN0 IGJlIGV4cHJlc3NlZCB3aXRoaW4gdGhlIHNlcGFyYXRvciBjb25zdHJ1Y3QgcmF0aGVyIHRoYW4g YmUgaW1wbGllZC4gIA0KDQpQbGVhc2UsIHllcy4gIExldCB0aGUgdXNlciBjaG9vc2Ugd2hhdCBz ZXBhcmF0b3JzIGFyZSB2YWxpZC4gIE9wdGlvbmFsIHdoaXRlc3BhY2UgbWlnaHQgYmUgY29tbW9u cGxhY2UgaW4gc29tZSBncmFtbWFycywgYnV0IHlvdSBzaG91bGQgbm90IGFzc3VtZSB0aGF0IGl0 J3MgYWx3YXlzIGRlc2lyZWQuDQoNCi0tTWFydGluDQoNCg0K From julian.reschke@gmx.de Mon Dec 13 01:54:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CE33A6D7A for ; Mon, 13 Dec 2010 01:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.551 X-Spam-Level: X-Spam-Status: No, score=-104.551 tagged_above=-999 required=5 tests=[AWL=-1.952, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skpByBEp3+f9 for ; Mon, 13 Dec 2010 01:54:34 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 32A933A6CD8 for ; Mon, 13 Dec 2010 01:54:33 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2010 09:56:09 -0000 Received: from p508F9B21.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.155.33] by mail.gmx.net (mp022) with SMTP; 13 Dec 2010 10:56:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18edqUArBceCu6thYf/nrGI+DqXYgcBywY5HUiiim kFzAq5J1V+kDj7 Message-ID: <4D05EDB8.6090901@gmx.de> Date: Mon, 13 Dec 2010 10:56:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> In-Reply-To: <4D03A25E.9060709@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 09:54:35 -0000 On 11.12.2010 17:10, Dave CROCKER wrote: > ... > At this point I am wondering whether it would not be cleaner to have the > notation be: > > *[^()]element > > In other words, augment the existing repetition construct with a clean > separator construct. The up-arrow only specifies a separator, it does > not also specify repetition. > > Hence: > > 1*10^":"tag-val > > would be 1 to 10 tag-vals separated by colons, and > > *^" "words > > would be zero or more words separated by a space. > ... Looks better to me. I believe it would be useful to have a look at existing specs that use list productions, and see how they could use this format. That might discover missing pieces, or just things that are done differently across specs, which may make it harder to find a common syntax. For instance, in HTTP we have: "Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two." -- I don't think the proposal addresses this use case, so it appears it would be unusable for expressing the HTTP ABNF. Best regards, Julian From dave@cridland.net Mon Dec 13 02:24:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A64D28C0E3; Mon, 13 Dec 2010 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYtbAzJLozZ9; Mon, 13 Dec 2010 02:24:25 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 7F1B33A6D7A; Mon, 13 Dec 2010 02:24:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 2834911680FB; Mon, 13 Dec 2010 10:26:00 +0000 (GMT) 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 718q9D-RRrSU; Mon, 13 Dec 2010 10:25:53 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EDEAF1168110; Mon, 13 Dec 2010 10:25:52 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> MIME-Version: 1.0 Message-Id: <2229.1292235952.971571@puncture> Date: Mon, 13 Dec 2010 10:25:52 +0000 From: Dave Cridland To: Yoav Nir , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:24:26 -0000 On Sun Dec 12 22:06:29 2010, Yoav Nir wrote: > - It has to be integrated in the protocol, not the application What?! No. It must be integrated in the application. If nothing else can be learnt, then learn this one thing - we have had Basic and Digest support in the protocol for years, but because they cannot easily be integrated into the application, no serious consumer applications use them, even though what they provide is never any better than Basic. If I could wave a magic wand and have all my wishes come true, I'd embed SASL into the web browser such that: - Users are presented with visually-distinct controls embedded into a web page for authentication, much like Extended Validation. Perhaps focussing them turns the address bar red or something. - The SASL message exchanges happen over a WebSocket or equivalent low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I imagine a webbrowser gets given one or more URIs to use for communications). - The result of this is a one-time password intializer. - Subsequent requests and responses occur with traditional HTTP auth, using some OTP mechanism that requires only a single message. The two parts of the protocol can, and should, be split - many existing websites use a cookie as the result of authentication, and having a more secure variant of this alone would be extremely useful. Note that the key portion of this - embedded SASL - is not really HTTP auth at all, but a Web Application Auth - since that's really the other party to the authentication, it seems quite obvious to me that this should be the authenticating entity. > - It has to be secure against phishing - if the attacker gets you > to authenticate, they can't later use that authentication to > connect to the real server > - If the authentication succeeded, then (a) you typed your password > correctly, and (b) this is really the server > > EAP has some methods that do this. SASL can probably be made to do > this, but with an extra layer. > > SASL also has methods that will do this, I think - I'm not sure what additional layer you're referring to here. 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 dave@cridland.net Mon Dec 13 03:21:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6325F28C0D0; Mon, 13 Dec 2010 03:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj7BugRYLD1g; Mon, 13 Dec 2010 03:21:33 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 63DCA3A6CD9; Mon, 13 Dec 2010 03:21:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E14FD1168112; Mon, 13 Dec 2010 11:23:08 +0000 (GMT) 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 CPfyXaB0kJvE; Mon, 13 Dec 2010 11:23:04 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 43BFF1168110; Mon, 13 Dec 2010 11:23:04 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> In-Reply-To: <4D05FB8F.3070804@qbik.com> MIME-Version: 1.0 Message-Id: <2229.1292239384.281779@puncture> Date: Mon, 13 Dec 2010 11:23:04 +0000 From: Dave Cridland To: Adrien de Croy , Yoav Nir , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:21:34 -0000 On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote: > for instance what would you propose for non-browsers, which perform > a large proportion of all HTTP transactions. > > I agree a solution is needed for non-browsers (including IPP, for example). I disagree this needs to be, or should be, the same as a solution for web apps. I disagree that non-browser security is even a major priority at this point in time - it's adequately served by TLS and client certificates and/or Basic auth, depending on the security model desired - this latter I appreciate is a personal opinion. However there is no doubt at all that current webapp deployments are in need of a serious improvement in security, given that these generally use TLS only during authentication itself, and use plaintext usernames and passwords for the authentication itself. > Also, it seems like it would make the problem about a billion times > worse putting the auth into the application, where there are no > standards, and therefore it would need to be re-implemented for > each different application... kinda like what we have now already. Yet every webapp currently uses a form, and it's so close a standard that browsers can, and do, spot login forms and allow the credentials to be cached. As such, I fail to see why we wouldn't want to place better authentication at that layer, where it's quite likely to be actually used. > SASL is an orthogonal concept. It's just a framework to negotiate > auth, whether that's over HTTP or something else. So, it's a bit > of a red herring in this. Right, that's fair enough. > The trick is to get the application to actually use the auth of the > protocol. Yes, but the problem is that existing, deployed, webapps could use Basic right now - they all just ask for a username and password after all. Yet none of them do, in part because of integration issues, but mostly I suspect due to usability and branding issues. We could deploy some more advanced mechanisms in HTTP auth tomorrow, and nobody would use those either. 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 lear@cisco.com Mon Dec 13 03:28:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92723A6E8A; Mon, 13 Dec 2010 03:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6ZgrQY9HnNt; Mon, 13 Dec 2010 03:28:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 299D23A6D9A; Mon, 13 Dec 2010 03:28:00 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEABmSBU2Q/khNgWdsb2JhbACDXKAgFQEBFiIppjSKSZAggSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="71514783" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2010 11:29:37 +0000 Received: from dhcp-10-61-107-163.cisco.com (dhcp-10-61-107-163.cisco.com [10.61.107.163]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDBTack011491; Mon, 13 Dec 2010 11:29:36 GMT Message-ID: <4D0603AA.7000004@cisco.com> Date: Mon, 13 Dec 2010 12:29:46 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:28:02 -0000 And here-in lies the problem: I am concerned that in a large group we will not be able to reduce down to a single requirements list – AT THIS TIME. Also- my own experience is that having some decent proposals in front of you often helps drive at least SOME consolidation. From evnikita2@gmail.com Mon Dec 13 03:53:16 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FD93A6E91 for ; Mon, 13 Dec 2010 03:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYEiOnv51kqP for ; Mon, 13 Dec 2010 03:53:15 -0800 (PST) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 002B33A6E8F for ; Mon, 13 Dec 2010 03:53:14 -0800 (PST) Received: by gwb20 with SMTP id 20so5635209gwb.15 for ; Mon, 13 Dec 2010 03:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=8yeuFSN+vzXuSK0uFcUyB2/Bxo+ylhUT4ZDZhnyb9yY=; b=dk3fTWga1Xmj/hJDczyRUvTOfxXXxPGcvtXAvO4bYxjl3fl8actJy+5lxHWfMGXB9W GyTAeFUocufii04gR52DfzofRYEa7gA5HodPLKsX8xTo2OcYkM0bQbIBeF1AcXxbnna9 CK201awQNTA60DJ8mT0CirlmvkYCGoxd0wFho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Fjp15ithx6LYq1KrEI51GNYujWjh9gpnNZv10fYmHfwizhdSYJWXjzc8tMh/0cyKlJ 8QSTar8LYkWZX0c8631FdxXpMpZWJm2vQnR2HCYr6KloYMrM4z5j5Z1FPXrGpD4IRh8L 8jiVhQC7OAfUlIaN8QT/rprRoTVHU8BoHImEY= MIME-Version: 1.0 Received: by 10.150.158.15 with SMTP id g15mr6232540ybe.57.1292241292345; Mon, 13 Dec 2010 03:54:52 -0800 (PST) Received: by 10.150.52.19 with HTTP; Mon, 13 Dec 2010 03:54:52 -0800 (PST) Date: Mon, 13 Dec 2010 13:54:52 +0200 Message-ID: From: Mykyta Yevstifeyev To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dcrocker@bbiw.net Subject: [apps-discuss] Some notes on ABNF notation for separated lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:53:16 -0000 Hello all, I have carefully reviewed all the messges which concern my ABNF notation for separated lists. So some omments and thoughts: Firstly, there have been a discusion about the form of notation. Several variants have been proposed, the latest is *[^]element and I think it is quite acceptable. Moreover, the corresponding form ^element has been proposed. I think that will be OK too. These proposals will be taken into consideration while preparing the new version of the draft. Secondly, there have been a discussion on to put or not to put the LWS in the notation ABNF description. Maybe it is OK to remove it from the definition but allow the user to put it manually in the part. Thirdly, it is a topic to discuss about the definition of separator. However I don't think the form 1*VCHAR is bad or not acceptable for this occasion. It is obvious that separator can be only visible chars. But I think it would be useful to put the restriction on maximum amount of chars in separator - maybe 56 is enough. what do you think about this? Lastly, the problem seems to be in security Consideration section. The only issue mentioned while discussing was that spaces may occure in the defined rule while we do not need them and this will cause the problem. However as I'll correct the rule it will not create any problems. However any suggestions for Sec. Cons. section are welcome as well as other ones. So I'll try to take all the comments into considerations. I'll let you know when the new version of the draft will be available. Best regards, Mykyta Yevstifeyev From cabo@tzi.org Mon Dec 13 04:12:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5B63A6D9E; Mon, 13 Dec 2010 04:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.316 X-Spam-Level: X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlx35im81SA2; Mon, 13 Dec 2010 04:12:35 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A20C03A6DAA; Mon, 13 Dec 2010 04:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oBDCE5FS003904; Mon, 13 Dec 2010 13:14:05 +0100 (CET) Received: from [192.168.217.101] (p5489B2BC.dip.t-dialin.net [84.137.178.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 908AF497; Mon, 13 Dec 2010 13:14:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <2229.1292239384.281779@puncture> Date: Mon, 13 Dec 2010 13:14:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> To: General discussion of application-layer protocols , http-auth@ietf.org X-Mailer: Apple Mail (2.1082) Cc: Common Authentication Technologies - Next Generation , websec , saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 12:12:36 -0000 On Dec 13, 2010, at 12:23, Dave Cridland wrote: > every webapp currently uses a form Yes. Nice demonstration of conflicting requirements. As a webapp developer, I want to control the user interface during = authentication. Leaving the user alone with the bland and unforgiving browser user = interface for HTTP auth is suicide. I want to provide extra buttons for forgotten passwords, maybe even = password hints, and a "sign up" method. HTML/CSS/JS lends itself well to providing such a friendly user = interface. As a security geek, I recognize this as exactly the problem that creates = the potential for phishing. Having the user type credentials into a random form is never going to be = secure, HSTS notwithstanding. Maybe the only way to address both requirements is to have something in = HTML/CSS/JS that addresses authentication interactions. Replacing for the 21st century. This would = allow web app designers to design a nice context for this interaction, = and would allow running security protocols that are binding themselves = to a browser-server security association that may be identical to or = different from the TLS envelope. "Storing passwords" in the browser = might turn into storing those security associations. This is not "HTTP authentication", but it might be more useful in the = long run. We'll need the browser people to start any such effort. Gruesse, Carsten PS.: And I'd still like to have some better form of authentication for = machine-to-machine that can be independent from the TLS envelope. But = that is a completely different animal. From lear@cisco.com Mon Dec 13 05:44:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689453A6E96; Mon, 13 Dec 2010 05:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.119 X-Spam-Level: X-Spam-Status: No, score=-110.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txPFAo4BN0aO; Mon, 13 Dec 2010 05:44:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B6EF53A6E8E; Mon, 13 Dec 2010 05:44:15 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEALOxBU2Q/khNgWdsb2JhbACDXKAlFQEBFiIppxWKSZAogSGBcYFEdASKeQ X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="71525320" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2010 13:45:53 +0000 Received: from dhcp-10-61-107-163.cisco.com (dhcp-10-61-107-163.cisco.com [10.61.107.163]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDDjqBp005402; Mon, 13 Dec 2010 13:45:52 GMT Message-ID: <4D06239A.60208@cisco.com> Date: Mon, 13 Dec 2010 14:46:02 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Carsten Bormann References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 13:44:17 -0000 On 12/13/10 1:14 PM, Carsten Bormann wrote: > As a webapp developer, I want to control the user interface during authentication. > Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. > I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. > HTML/CSS/JS lends itself well to providing such a friendly user interface. On the other hand, that's what you have today. What is it you want for tomorrow? Eliot From dave@cridland.net Mon Dec 13 07:14:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7A83A6EA8; Mon, 13 Dec 2010 07:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oai1jUCwfRGx; Mon, 13 Dec 2010 07:14:42 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 751923A6EA4; Mon, 13 Dec 2010 07:14:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 640601168110; Mon, 13 Dec 2010 15:16:17 +0000 (GMT) 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 fI2-sW0P2Uy5; Mon, 13 Dec 2010 15:16:12 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 9E21A11680FB; Mon, 13 Dec 2010 15:16:12 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> MIME-Version: 1.0 Message-Id: <2229.1292253372.639419@puncture> Date: Mon, 13 Dec 2010 15:16:12 +0000 From: Dave Cridland To: Carsten Bormann , Common Authentication Technologies - Next Generation , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , General discussion of application-layer protocols , "http-auth@ietf.org" Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:14:43 -0000 On Mon Dec 13 12:14:03 2010, Carsten Bormann wrote: > Maybe the only way to address both requirements is to have > something in HTML/CSS/JS that addresses authentication interactions. > Replacing for the 21st century. This > would allow web app designers to design a nice context for this > interaction, and would allow running security protocols that are > binding themselves to a browser-server security association that > may be identical to or different from the TLS envelope. "Storing > passwords" in the browser might turn into storing those security > associations. > > Or storing credentials rather than username/password pairs, possibly. But in any case, I think that's close to what we want. As I say, I think we need to establish a session credential of some kind that can be used over unencrypted sessions with some improvement in security over typical fixed cookies that exist today. I'm fine if one of these credential options happens to tie into a TLS property, but I think we'll have to have reasonable security over non-TLS, too. (And by "reasonable", I'm expecting this to be "not as good as if you had TLS") And I absolutely agree that this effort needs strong support from the browser implementors from the start - we also need the same from a few major webapps. 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 julian.reschke@gmx.de Mon Dec 13 07:44:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D06C28C0E2 for ; Mon, 13 Dec 2010 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.842 X-Spam-Level: X-Spam-Status: No, score=-104.842 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOI8T47bhd5V for ; Mon, 13 Dec 2010 07:44:27 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E58D528C0F4 for ; Mon, 13 Dec 2010 07:44:26 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2010 15:39:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 13 Dec 2010 16:39:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UHbgtRrAUjdGBQU5gg4BvM7LRRZTDqhBbrFmn67 sCLQ8sxb3b/4dZ Message-ID: <4D063E2A.3010108@gmx.de> Date: Mon, 13 Dec 2010 16:39:22 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D02AF81.6000907@stpeter.im> In-Reply-To: <4D02AF81.6000907@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" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:44:27 -0000 On 10.12.2010 23:53, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few things > I've found: > ... Probably. But while doing so, we need to look at the existing base as well. HTTPbis now includes the HTTP authentication framework (essentially RFC2617 minus Basic and Digest). The HTTPbis WG is interested on feedback on the remaining issues (such as Realm required?, and considerations for new schemes). Also, I believe Basic is not going to go away, and I'd really like to fix its I18N problem. Proposal here: . Best regards, Julian From stpeter@stpeter.im Mon Dec 13 09:45:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8108928C100 for ; Mon, 13 Dec 2010 09:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3kIcFBM5q+Y for ; Mon, 13 Dec 2010 09:44:59 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9044A28C0F8 for ; Mon, 13 Dec 2010 09:44:59 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86173400F6 for ; Mon, 13 Dec 2010 10:58:56 -0700 (MST) Message-ID: <4D065BEA.5070900@stpeter.im> Date: Mon, 13 Dec 2010 10:46:18 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 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="------------ms090206030008040507010909" Subject: [apps-discuss] location for HTTP auth discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 17:45:00 -0000 This is a cryptographically signed message in MIME format. --------------ms090206030008040507010909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, the HTTP authentication discussion was intended to happen on the http-auth@ietf.org list. I cc'd apps-discuss only to let you know where to post if you were interested in this topic. Please refrain from cc'ing apps-discuss and instead join the http-auth list if you want to continue the conversation: https://www.ietf.org/mailman/listinfo/http-auth Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090206030008040507010909 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 BjQwggQcoAMCAQICASIwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT 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 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAABz nBL1seNFAhfG5hdukfQLzqsDJ452dB9CVqgUeTobh4x55PngizYKZ6+ieVlDtPd2MB7U2ck6 L7tyMxMpvRoa74Sokhl5ZgwTQZb7xB9rKoUPxygFX2biNm+r+l04+COmJGb02iLSPR9OFgqh k5qNK83IpT8QJD5VXP7heTH3TdHGFWXimRYGXBmuVOXEpXYaZjn7syQuXr7k4RZuFp32FOzf zTBrZWDgixjJB+OJkMfpyu6GvEXeYWrks+ILjHt78VUj8DHxB2i6JTkmA51vR181KEiAYtZb iDK21UgncNxEIeU3b0vhpE4cKT5kcZaXFK58fLRthoHae6br4lQsZIMEbHhScnzH9uAg3qL7 AGBILDwu6iasejOhkoSp6opZDeUSUfEPE0tHwKFur3Ts1K52EyXBAr1aA67ECgL9ka2yPt1Y A/mj7frpI9li/F311dn7+pHT1C3lFPRRzOc6i9gAXjBOWJq+Yl0dSubTn2xVdS+swwfjR0uL WqoSH9Hra4sXDHxslb/KaDXJw8g1EvBzgP0ZUHolzyrDgvwL/WOuLWek6koXP89CRPuWtC0i C/vZ4IcCgGuhniwYV4XhrdAW9FKlKdRi8SEBGYpVQiCPVhC5wF2oQvsEs6szAThCuamfAmZn FCUBdCcVTXQuX/OXoQe4Fl70ePaZhjS6MIIGxzCCBa+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 BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MzE3NDYxOFowIwYJKoZIhvcNAQkEMRYEFBbSBa3uFX0yWZqiBtGQAChh3aFAMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAzE0c+2rrc0XVtKwf4QMAshFHo74ex6MvwdjnyPyV+q2+ShHtKnrGmDhHN EGFabNht6gyrRha4vPmOZXPdYD6O/FSH1fqdRAn7idQIC/O0zlULPdNSwI9g+JNxdDKU79BV UPFU+BJPKQVjazt3fYu9tBSUKjCrtEJoI3EAvhpGWWUkY2cuXLFofh6CnorGaSdD4prNQ7uz rfStsapgiRZHoiIeRI3QclJ0HNdK0zRMpbJ1Nz3BiVKqtzT23dJW9eHB0piQJSHrQgnFswP3 H+7ki+nMZ7vtZ96unU9srMhF5W1h3l93wVNJU3mNpMKEp/txhHqCPAumnRFq8vkexfxyAAAA AAAA --------------ms090206030008040507010909-- From adrien@qbik.com Mon Dec 13 02:53:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E4F28C0DB; Mon, 13 Dec 2010 02:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=-3.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA-g+RFm1zpx; Mon, 13 Dec 2010 02:53:37 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 796D63A6E85; Mon, 13 Dec 2010 02:53:36 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3102)) with SMTP id <0017850742@smtp.qbik.com>; Mon, 13 Dec 2010 23:55:11 +1300 Message-ID: <4D05FB8F.3070804@qbik.com> Date: Mon, 13 Dec 2010 23:55:11 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> In-Reply-To: <2229.1292235952.971571@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:49:33 -0800 Cc: Eliot Lear , General discussion of application-layer protocols , Yoav Nir , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:53:39 -0000 you might want to reconsider. for instance what would you propose for non-browsers, which perform a large proportion of all HTTP transactions. Also, it seems like it would make the problem about a billion times worse putting the auth into the application, where there are no standards, and therefore it would need to be re-implemented for each different application... kinda like what we have now already. SASL is an orthogonal concept. It's just a framework to negotiate auth, whether that's over HTTP or something else. So, it's a bit of a red herring in this. Yoav is correct, the auth must be in the protocol (1 of these) as opposed to the application (too many of these). The trick is to get the application to actually use the auth of the protocol. Adrien On 13/12/2010 11:25 p.m., Dave Cridland wrote: > On Sun Dec 12 22:06:29 2010, Yoav Nir wrote: >> - It has to be integrated in the protocol, not the application > > What?! No. It must be integrated in the application. If nothing else > can be learnt, then learn this one thing - we have had Basic and > Digest support in the protocol for years, but because they cannot > easily be integrated into the application, no serious consumer > applications use them, even though what they provide is never any > better than Basic. > > If I could wave a magic wand and have all my wishes come true, I'd > embed SASL into the web browser such that: > > - Users are presented with visually-distinct controls embedded into a > web page for authentication, much like Extended Validation. Perhaps > focussing them turns the address bar red or something. > - The SASL message exchanges happen over a WebSocket or equivalent > low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I > imagine a webbrowser gets given one or more URIs to use for > communications). > - The result of this is a one-time password intializer. > - Subsequent requests and responses occur with traditional HTTP auth, > using some OTP mechanism that requires only a single message. > > The two parts of the protocol can, and should, be split - many > existing websites use a cookie as the result of authentication, and > having a more secure variant of this alone would be extremely useful. > > Note that the key portion of this - embedded SASL - is not really HTTP > auth at all, but a Web Application Auth - since that's really the > other party to the authentication, it seems quite obvious to me that > this should be the authenticating entity. > > >> - It has to be secure against phishing - if the attacker gets you to >> authenticate, they can't later use that authentication to connect to >> the real server >> - If the authentication succeeded, then (a) you typed your password >> correctly, and (b) this is really the server >> >> EAP has some methods that do this. SASL can probably be made to do >> this, but with an extra layer. >> >> > SASL also has methods that will do this, I think - I'm not sure what > additional layer you're referring to here. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From aland@deployingradius.com Mon Dec 13 06:15:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0275E3A6E96; Mon, 13 Dec 2010 06:15:21 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+DQnsAnEMXX; Mon, 13 Dec 2010 06:15:20 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 1E2D728C0E4; Mon, 13 Dec 2010 06:15:20 -0800 (PST) Message-ID: <4D062AD8.4080805@deployingradius.com> Date: Mon, 13 Dec 2010 15:16:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:49:40 -0800 Cc: Eliot Lear , "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 14:15:21 -0000 Yoav Nir wrote: > Because I'd rather not implement too many mechanisms in my browser or in my web server. > > And if EAP integrates better with RADIUS, It's more "already integrated with RADIUS", and "RADIUS integrates with LDAP". > while SASL integrates better with LDAP, it's still bad design to expose the server's backend to the client by the authentication protocol. EAP is already being transported over PPP, ethernet, RADIUS, Diameter, and other transport/authentication protocols. It's used because adding it is easy, and it separates the authentication protocols from the application. As for SASL, that's not my area. Alan DeKok. From benl@google.com Mon Dec 13 04:07:11 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56D23A6E8E for ; Mon, 13 Dec 2010 04:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVFw5N9jl637 for ; Mon, 13 Dec 2010 04:07:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E49673A6E8D for ; Mon, 13 Dec 2010 04:07:08 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id oBDC8jrK017216 for ; Mon, 13 Dec 2010 04:08:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292242126; bh=IjyN8R0N33aGAIFAsPoKvVzfyyw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Yb3kzYgDWRmY5mxDWtFvaHfcsHnwpFnk7d/XudI0GYrG1a01QcMwyKKbTQO+DQwjw xZY2rLIyubGVind62c8pw== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by kpbe17.cbf.corp.google.com with ESMTP id oBDC8hBH010757 for ; Mon, 13 Dec 2010 04:08:44 -0800 Received: by pzk9 with SMTP id 9so929869pzk.15 for ; Mon, 13 Dec 2010 04:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jnk/rIg1eD9tZ2qzrBPET1JpYPZwhSbJgLeKzkK3VjE=; b=xbhr0gmJzm0BSQVE4EXZPxPvzxwDbzk8RYeu/+ztSagtknC/eRAIHNvgO9f4wsz56P CYomMJegFuaBAnXh8Dng== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rw1xtelJDClcXIznUGgalnYuvnVjjorS/PQoclxpboKmnhAPy2zJmoWpritlHxlap0 Y59t0yFafY3Qv7+O0gBw== MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr3107000wff.419.1292242123701; Mon, 13 Dec 2010 04:08:43 -0800 (PST) Received: by 10.142.47.14 with HTTP; Mon, 13 Dec 2010 04:08:43 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> Date: Mon, 13 Dec 2010 12:08:43 +0000 Message-ID: From: Ben Laurie To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 13 Dec 2010 09:49:55 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 12:07:11 -0000 On 11 December 2010 23:10, Yoav Nir wrote: > TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication. I think what we've learnt is that we need to provide good UI and portability if we want people to use them. From dsr@w3.org Mon Dec 13 02:16:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA3E28C0DD; Mon, 13 Dec 2010 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QhYXMl8RCJH; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 55D863A6CF3; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.3]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PS5TJ-0003FO-IJ; Mon, 13 Dec 2010 10:17:33 +0000 From: Dave Raggett To: "Roy T. Fielding" In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset="UTF-8" Organization: W3C Date: Mon, 13 Dec 2010 10:17:34 +0000 Message-ID: <1292235454.20343.122.camel@ivy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:50:10 -0800 Cc: Jan Camenisch , "apps-discuss@ietf.org" , Yoav Nir , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:16:17 -0000 And let's not ignore secure privacy enhancing technologies like anonymous credentials and zero knowledge proofs, see e.g: http://www.w3.org/QA/2010/11/boosting_privacy_online_-_anon.html It is often sufficient to know that someone is a member of a group or has certain attributes rather than knowing exactly who that person is. Perhaps we could add to SASL the notion of secure anonymous access for authenticated access? This involves the client generating and passing a proof to the server that satisfies the proof specification and nonce provided by the server. [ Jan, see http://datatracker.ietf.org/wg/kitten/charter/ ] n.b. this work was carried out with support from the European PrimeLife project on privacy and identity, see http://www.primelife.eu/ On Sun, 2010-12-12 at 14:39 -0800, Roy T. Fielding wrote: > On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > > > Yoav Nir wrote: > > > >> EAP has one advantage. It is easy to integrate with existing > RADIUS/DIAMETER infrastructure. > >> > > True. > > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > Define them all and let's have a bake-off. It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. Zero progress so far. We should just define > everything and let the security experts do what they do best -- find the > holes and tell us what not to implement. > > ....Roy > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Dave Raggett http://www.w3.org/People/Raggett From marsh@extendedsubset.com Sun Dec 12 16:47:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF99E3A6D90; Sun, 12 Dec 2010 16:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWvmuEKtAYSh; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 653B93A6D16; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRwbI-00080u-0i; Mon, 13 Dec 2010 00:49:12 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2788E60C6; Mon, 13 Dec 2010 00:49:09 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+LS98k8zKrRc2V9A6d+dLVfNCJcc+FPxg= Message-ID: <4D056D83.2020704@extendedsubset.com> Date: Sun, 12 Dec 2010 18:49:07 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:50:24 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 00:47:37 -0000 On 12/12/2010 04:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. It has been 16 years > since HTTP auth was taken out of our hands so that the security > experts could define something perfect. Zero progress so far. Perhaps it's a bad idea? > We > should just define everything and let the security experts do what > they do best -- find the holes and tell us what not to implement. I know some professional pen-testers who would love that! Check out these videos. This is what happens when you take a general-purpose authentication protocol and repurpose it for use across the internet for an insecure application protocol: http://extendedsubset.com/smb_relay_fully_patched.wmv http://extendedsubset.com/smb_reflection_arp_poisoning.wmv http://extendedsubset.com/?p=36 This case is NTLMv2, but the phenomenon is not limited to that. The problem is that most general-purpose authentication protocols do not require enough specificity about the context of the authentication: who and what are you authenticating, to whom, and how does each side know it's operating under the same beliefs as the other? This means that even if the client wants to be careful and authenticate only for the purpose of setting up a secure connection, the attacker can possibly forward that authentication to auth his own connection or transaction on some other service (on the same or even a different server). Most auth protocols don't let the client strongly verify the server's identity before the client has to authenticate with his own. This is probably at least in part because it requires some common infrastructure to do this. So Kerberos and x509 PKI systems can authenticate the server (and sometimes even the target service), but most others do not. Since HTTP lacks connection integrity, it's meaningless to speak of "an authenticated client". Perhaps the only thing that could be meaningfully authenticated is the request data itself. But auth protocols designed for setting up persistent connections typically don't have defined inputs for the message data/digest being signed, so it's often impractical to reuse them for that purpose. These issues have been mostly addressed at the protocol level for TLS client cert authentication. If it really just comes down to deployment and client usability issues, it's hard to imagine coming up with something at another layer which would have less risk than building on top of that. Deploying new uses of compatible, standard authentication protocols over insecure application protocols can be bad for the greater security ecosystem because it widens the field for cross-protocol attacks. - Marsh From tim-projects@sentinelchicken.org Mon Dec 13 09:15:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E7128C0EF for ; Mon, 13 Dec 2010 09:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0wiIuW8LfqZ for ; Mon, 13 Dec 2010 09:15:37 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 674AA28C0EC for ; Mon, 13 Dec 2010 09:15:37 -0800 (PST) Received: (qmail 28267 invoked from network); 13 Dec 2010 17:21:10 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Dec 2010 17:21:10 -0000 Received: (qmail 2438 invoked from network); 13 Dec 2010 17:14:14 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 13 Dec 2010 17:14:14 -0000 Received: (nullmailer pid 4529 invoked by uid 1000); Mon, 13 Dec 2010 17:10:33 -0000 Date: Mon, 13 Dec 2010 09:10:33 -0800 From: Tim Morgan To: Dave Cridland Message-ID: <20101213171033.GA2111@sentinelchicken.org> References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2229.1292253372.639419@puncture> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 13 Dec 2010 09:50:37 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 17:36:58 -0000 Hi Everyone, These last few messages do a great job outlining both the real problems that face adoption of HTTP authentication without a customizable user interface, and the fact that HTTP authentication is perhaps more secure than form-based authentication (as well as being a requirement for automated/non-GUI clients). I did some work not long ago on this and found that we can have our cake and eat it too. That is, even with current browser implementations, one can utilize HTTP Basic/Digest with an HTML form (if desired). (Yes, once again, HTML forms may allow for easier phishing, etc, but that is what the HTTP Mutual authentication proposal can address.) My position paper is here: http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf And some proof of concept code for forms-based HTTP authentication can be found on this page: http://vsecurity.com/resources/tool The implementation is hacky right now, because, at the time of development and testing, browsers didn't adhere well to the draft XMLHttpRequest standard. I haven't checked the status of browser implementations, but the proposed standard still requires a behavior that is workable with such a system. So all of these pieces are coming together on their own to allow for forms-based HTTP authentication. The major outstanding piece needed for most web applications with HTTP authentication is the ability to log out. The ability to instruct a browser, in an standard way (preferrably with HTTP response headers) to forget the credentials it has cached. Writing a draft RFC for this has been on my list for some time, but I've been quite busy this year. For those interested, I can dig up some of the previous discussion threads... cheers, tim From yaronf.ietf@gmail.com Mon Dec 13 07:31:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A940F28C113; Mon, 13 Dec 2010 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ8HbcaePJoN; Mon, 13 Dec 2010 07:31:29 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9A8C328C111; Mon, 13 Dec 2010 07:31:28 -0800 (PST) Received: by wyf23 with SMTP id 23so6133663wyf.31 for ; Mon, 13 Dec 2010 07:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+0szgrNyk3mkmUDxf309oDZ+9GRtr8meNZqDA8AcMUE=; b=dNDusxC6geA5feEhxkQO/3IBIf77RSA4FBQR+bRQEH5tRXO/8PbfYInvGtfM9K8trB hcCmyCPLhLZDyJghltMS9GriRS04fRXtgKCYQbBqKzCt67nUbMaoehetoJAzO/+z7NgW Qd/tH93nfYIo2etamhq1o40Uf5iY0/vfVQCus= 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=ordqzJOVIbEfXFOsrikEoukznWeWMJCAiKTavCcDclq3YG2b4+ifhCv+/xIbEbrVvF bUpQvvk84xgm+pBbhP2bOCrwpM3LeQDpzqpCaAtJBKdvymqaMMv5wGqUxNRmsyHZ+S/T Mco8vjpjuS7KD/s07YacFrp4iBmzd1JkDQZMU= Received: by 10.227.155.138 with SMTP id s10mr1735853wbw.61.1292254386127; Mon, 13 Dec 2010 07:33:06 -0800 (PST) Received: from [10.0.0.1] (bzq-79-176-46-32.red.bezeqint.net [79.176.46.32]) by mx.google.com with ESMTPS id m10sm4489129wbc.16.2010.12.13.07.32.56 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:33:04 -0800 (PST) Message-ID: <4D063CA5.8060907@gmail.com> Date: Mon, 13 Dec 2010 17:32:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> In-Reply-To: <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:50:51 -0800 Cc: Common@core3.amsl.com, General discussion of application-layer protocols , websec , - Next Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:31:32 -0000 Just like the phrase "I am not a lawyer" is always followed by amateur legal advice (I know that for sure, I've done it myself), the same goes for "I am not a UI expert". Two comments: - There are in fact a few security-usability experts. I don't know if any of them participate in the IETF. This is an emerging research field, see e.g. http://oreilly.com/catalog/9780596008277. - (I am not a UI expert, but...) Devising UI cues is extremely difficult. People will gladly enter their password when the web site displays a JPEG-rendered padlock icon. In fact *legitimate* sites have been known to display such icons, strange as it may sound. Thanks, Yaron On 12/13/2010 03:08 PM, Yoav Nir wrote: > > On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote: > >> On Dec 13, 2010, at 12:23, Dave Cridland wrote: >> >>> every webapp currently uses a form >> >> Yes. Nice demonstration of conflicting requirements. >> >> As a webapp developer, I want to control the user interface during authentication. >> Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. >> I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. >> HTML/CSS/JS lends itself well to providing such a friendly user interface. > > Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari). So if we invent, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ? > >> >> As a security geek, I recognize this as exactly the problem that creates the potential for phishing. >> Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding. > > Agree. > >> Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions. >> Replacing for the 21st century. This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope. "Storing passwords" in the browser might turn into storing those security associations. > > I don't think the security requirements can be met using this (although I'd love to hear differently from browser people). Maybe if we could customize the authentication dialog with some kind of icon (like favicon), and maybe a frame or a div with some HTML elements (buttons, links). I am not a UI expert (IANAUIE ?) but I think it's important that user authentication be quite distinct from the rest of the flow. IOW the user should know that at this point, she is not just surfing, but actually authenticating to a particular server, and if she's ever presented with some web form that says "username:_______ password:_______" she's going to know that something is wrong. > >> >> This is not "HTTP authentication", but it might be more useful in the long run. >> We'll need the browser people to start any such effort. > > Fully agree. We really need to hear from both browser people and web application developers. No point in designing something really secure if the people in google/amazon/BOA then say "no, we'll never use that" > >> >> Gruesse, Carsten >> >> PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope. But that is a completely different animal. >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From ynir@checkpoint.com Sun Dec 12 14:05:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4ABE28C0D9; Sun, 12 Dec 2010 14:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[AWL=1.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4vmhh7ZUTmo; Sun, 12 Dec 2010 14:05:00 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 8DA9A28C0D6; Sun, 12 Dec 2010 14:04:59 -0800 (PST) X-CheckPoint: {4D05476B-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBCM6VZI007290; Mon, 13 Dec 2010 00:06:31 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 00:06:31 +0200 From: Yoav Nir To: Eliot Lear Date: Mon, 13 Dec 2010 00:06:29 +0200 Thread-Topic: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation Thread-Index: AcuaSNSrne/txJ/+ThWOBmTF9om+dQ== Message-ID: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> In-Reply-To: <4D054041.7010203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Dec 2010 09:51:06 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 22:05:02 -0000 Because I'd rather not implement too many mechanisms in my browser or in my= web server. And if EAP integrates better with RADIUS, while SASL integrates better with= LDAP, it's still bad design to expose the server's backend to the client b= y the authentication protocol. Let's try and list the requirements for HTTP authentication: - It has to be integrated in the protocol, not the application - It has to be secure against phishing - if the attacker gets you to authen= ticate, they can't later use that authentication to connect to the real ser= ver - If the authentication succeeded, then (a) you typed your password correct= ly, and (b) this is really the server EAP has some methods that do this. SASL can probably be made to do this, bu= t with an extra layer. On Dec 12, 2010, at 11:36 PM, Eliot Lear wrote: > Why settle for one? >=20 > On 12/12/10 7:40 PM, Alexey Melnikov wrote: >> Yoav Nir wrote: >>=20 >>> EAP has one advantage. It is easy to integrate with existing >>> RADIUS/DIAMETER infrastructure. >>>=20 >> True. >> And SASL has an advantage that it is easier to integrate with LDAP >> infrastructure. >>=20 >> I think this just demonstrates that before an HTTP authentication >> mechanism can be evaluated, people need to agree on a common >> evaluation criteria for HTTP authentication. >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Mon Dec 13 05:07:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DB528C0DC; Mon, 13 Dec 2010 05:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbzEQ2t+Rgvk; Mon, 13 Dec 2010 05:07:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6A0423A6DA5; Mon, 13 Dec 2010 05:07:01 -0800 (PST) X-CheckPoint: {4D061AD6-A-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBDD8b6B008607; Mon, 13 Dec 2010 15:08:37 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 15:08:37 +0200 From: Yoav Nir To: Carsten Bormann Date: Mon, 13 Dec 2010 15:08:40 +0200 Thread-Topic: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation Thread-Index: AcuaxtqbIpwUgQEmQVSWqnfszltQeg== Message-ID: <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.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 X-Mailman-Approved-At: Mon, 13 Dec 2010 09:51:14 -0800 Cc: General discussion of application-layer protocols , websec , - Next Generation , "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , Common, "saag@ietf.org" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 13:07:03 -0000 On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote: > On Dec 13, 2010, at 12:23, Dave Cridland wrote: >=20 >> every webapp currently uses a form >=20 > Yes. Nice demonstration of conflicting requirements. >=20 > As a webapp developer, I want to control the user interface during authen= tication. > Leaving the user alone with the bland and unforgiving browser user interf= ace for HTTP auth is suicide. > I want to provide extra buttons for forgotten passwords, maybe even passw= ord hints, and a "sign up" method. > HTML/CSS/JS lends itself well to providing such a friendly user interface= . Yes. That's a big part of the problem. To get the security result we're loo= king for, the login field has to be clearly marked. A user should never be = allowed to make the mistake of thinking that a regular input field is actua= lly the password field. With Basic Auth you get some very distinctive clues= (like the sheet in Safari). So if we invent , how can the browser show it that would not be possible to replicate wit= h HTML/CSS/JS ? >=20 > As a security geek, I recognize this as exactly the problem that creates = the potential for phishing. > Having the user type credentials into a random form is never going to be = secure, HSTS notwithstanding. Agree. > Maybe the only way to address both requirements is to have something in H= TML/CSS/JS that addresses authentication interactions. > Replacing for the 21st century. This would al= low web app designers to design a nice context for this interaction, and wo= uld allow running security protocols that are binding themselves to a brows= er-server security association that may be identical to or different from t= he TLS envelope. "Storing passwords" in the browser might turn into storin= g those security associations. I don't think the security requirements can be met using this (although I'd= love to hear differently from browser people). Maybe if we could customize= the authentication dialog with some kind of icon (like favicon), and maybe= a frame or a div with some HTML elements (buttons, links). I am not a UI = expert (IANAUIE ?) but I think it's important that user authentication be q= uite distinct from the rest of the flow. IOW the user should know that at t= his point, she is not just surfing, but actually authenticating to a partic= ular server, and if she's ever presented with some web form that says "user= name:_______ password:_______" she's going to know that something is wrong. >=20 > This is not "HTTP authentication", but it might be more useful in the lon= g run. > We'll need the browser people to start any such effort. Fully agree. We really need to hear from both browser people and web applic= ation developers. No point in designing something really secure if the peop= le in google/amazon/BOA then say "no, we'll never use that" >=20 > Gruesse, Carsten >=20 > PS.: And I'd still like to have some better form of authentication for ma= chine-to-machine that can be independent from the TLS envelope. But that i= s a completely different animal. >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Mon Dec 13 07:49:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D15E28C0FB; Mon, 13 Dec 2010 07:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.673 X-Spam-Level: X-Spam-Status: No, score=-9.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zflb53p1RFGT; Mon, 13 Dec 2010 07:49:16 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id D009628C0E4; Mon, 13 Dec 2010 07:49:15 -0800 (PST) X-CheckPoint: {4D0640DD-4-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBDFooSV009459; Mon, 13 Dec 2010 17:50:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 17:50:50 +0200 From: Yoav Nir To: Yaron Sheffer Date: Mon, 13 Dec 2010 17:50:52 +0200 Thread-Topic: [saag] [websec] [kitten] [apps-discuss] HTTP authentication: the next generation Thread-Index: Acua3YNg2kbXw68wS5e96OwOd0Ko4A== Message-ID: <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> In-Reply-To: <4D063CA5.8060907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Dec 2010 09:51:21 -0800 Cc: "Common@core3.amsl.com" , protocols , websec , -, General, Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:49:17 -0000 On Dec 13, 2010, at 5:32 PM, Yaron Sheffer wrote: > Just like the phrase "I am not a lawyer" is always followed by amateur=20 > legal advice (I know that for sure, I've done it myself), the same goes=20 > for "I am not a UI expert". >=20 > Two comments: >=20 > - There are in fact a few security-usability experts. I don't know if=20 > any of them participate in the IETF. This is an emerging research field,= =20 > see e.g. http://oreilly.com/catalog/9780596008277. >=20 > - (I am not a UI expert, but...) Devising UI cues is extremely=20 > difficult. People will gladly enter their password when the web site=20 > displays a JPEG-rendered padlock icon. I don't know how to stop them, unless the "special" UI cue becomes so ubiqu= itous, that its absence causes the user to think, "wait a minute. This does= not look like authentication!" As long as every website has authentication that looks different and not di= fferent enough from regular web browsing, people are going to accept any we= b form as a legitimate authentication dialog. > In fact *legitimate* sites have=20 > been known to display such icons, strange as it may sound. >=20 > Thanks, > Yaron From dhc2@dcrocker.net Mon Dec 13 09:59:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E3528C0F8 for ; Mon, 13 Dec 2010 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuqjoXTsBtDW for ; Mon, 13 Dec 2010 09:59:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 80FBB28C0E9 for ; Mon, 13 Dec 2010 09:59:58 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBDI1Via017477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 10:01:36 -0800 Message-ID: <4D065F79.1010205@dcrocker.net> Date: Mon, 13 Dec 2010 10:01:29 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eliot Lear References: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> <4D0545C5.5040608@cisco.com> In-Reply-To: <4D0545C5.5040608@cisco.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]); Mon, 13 Dec 2010 10:01:37 -0800 (PST) Cc: apps-review@ietf.org, draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, discuss@apps.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] [apps-review] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 13 Dec 2010 17:59:59 -0000 On 12/12/2010 1:59 PM, Eliot Lear wrote: > On 12/12/10 10:48 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> The base IMAP RFC (3501) made this construct easy and (I think) >> relatively obvious. YMMV. If a grammar extension is globally >> applicable to a parent specification, ... > I take your point but then if you are calling out multiple > specifications someone has to go on a fishing expedition to understand > perhaps the single definition they want out of a specification. +1 I'm sympathetic to the desire to be "efficient" in writing this stuff, but specifications need to be very clear and very unambiguous. Anything that requires extra searching by the reader is a big negative in specification writing. There are different way of satisfying this requirement (that is, avoiding the searching or confusion.) As long as there is almost no change a reader can miss that it's an externally-defined rule nor miss the citation to the external specification for that rule, then it ought to be acceptable. The per-rule citation approach that I've suggested is by far the safest, but yes there are certainly situations where other approaches will work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tobias.gondrom@gondrom.org Mon Dec 13 10:03:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260DB3A6EA8 for ; Mon, 13 Dec 2010 10:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.102 X-Spam-Level: X-Spam-Status: No, score=-95.102 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVsYEb6NnREY for ; Mon, 13 Dec 2010 10:03:09 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id AAA403A6EA0 for ; Mon, 13 Dec 2010 10:03:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=XC4qhtXxSBi41iqCq0jEKophYqJ7kgds+nujUL6H9oMmXEG2x7qHbE3t9sjU+qNP//nZ9c5PdEQaIJ5FfCl1pAbzqqNmrjfpGP/zCXyu7ujmLDSNwrE9Ln5QQC7EA6CQ; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 16357 invoked from network); 13 Dec 2010 19:04:05 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Dec 2010 19:04:05 +0100 Message-ID: <4D066076.1010206@gondrom.org> Date: Mon, 13 Dec 2010 18:05:42 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec@ietf.org, apps-discuss@ietf.org X-Priority: 4 (Low) References: <4D065CFE.8060109@stpeter.im> In-Reply-To: <4D065CFE.8060109@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------080507010505020108050902" Subject: Re: [apps-discuss] where to discuss HTTP authentication X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 18:03:10 -0000 This is a multi-part message in MIME format. --------------080507010505020108050902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you Peter for the info. If you're interested in the topic of HTTP auth, please don't copy WEBSEC on your messages but instead join the http-auth list: https://www.ietf.org/mailman/listinfo/http-auth Unless you believe it is of explicit interest to the websec wg's work. Tobias chair of websec On 12/13/2010 05:50 PM, Peter Saint-Andre wrote: > Howdy. As you've noticed, the websec list has been full of discussion > about HTTP authentication. However, I cc'd the websec list only to keep > people here in the loop about the discussion. If you are interested in > this topic, please join the http-auth list (and don't cc websec): > > https://www.ietf.org/mailman/listinfo/http-auth > > Thanks! > > Peter > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------080507010505020108050902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you Peter for the info.
If you're interested in the topic of HTTP auth, please don't copy WEBSEC on your messages but instead join the http-auth list:

https://www.ietf.org/mailman/listinfo/http-auth

Unless you believe it is of explicit interest to the websec wg's work.

Tobias
chair of websec




On 12/13/2010 05:50 PM, Peter Saint-Andre wrote: 
Howdy. As you've noticed, the websec list has been full of discussion
about HTTP authentication. However, I cc'd the websec list only to keep
people here in the loop about the discussion. If you are interested in
this topic, please join the http-auth list (and don't cc websec):

https://www.ietf.org/mailman/listinfo/http-auth

Thanks!

Peter



_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

--------------080507010505020108050902-- From Martin.Thomson@andrew.com Mon Dec 13 14:11:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927DD3A6D38 for ; Mon, 13 Dec 2010 14:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-OkdiDwC+ez for ; Mon, 13 Dec 2010 14:11:45 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 3BE053A6E12 for ; Mon, 13 Dec 2010 14:11:45 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:62283 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S40061160Ab0LMWNX (ORCPT ); Mon, 13 Dec 2010 16:13:23 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 13 Dec 2010 16:13:23 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 14 Dec 2010 06:13:21 +0800 From: "Thomson, Martin" To: Julian Reschke , "dcrocker@bbiw.net" Date: Tue, 14 Dec 2010 06:13:18 +0800 Thread-Topic: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 Thread-Index: Acuaq/28mkEFgBeMT0CW5g1z/qX+tgAZfIvg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> In-Reply-To: <4D05EDB8.6090901@gmx.de> 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 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 22:11:46 -0000 T24gMjAxMC0xMi0xMyBhdCAyMDo1NjowOCwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQo+ICJXaGVy ZXZlciB0aGlzIGNvbnN0cnVjdCBpcyB1c2VkLCBudWxsIGVsZW1lbnRzIGFyZSBhbGxvd2VkLCBi dXQgZG8gbm90DQo+IGNvbnRyaWJ1dGUgdG8gdGhlIGNvdW50IG9mIGVsZW1lbnRzIHByZXNlbnQu IFRoYXQgaXMsICIoZWxlbWVudCksICwNCj4gKGVsZW1lbnQpICIgaXMgcGVybWl0dGVkLCBidXQg Y291bnRzIGFzIG9ubHkgdHdvIGVsZW1lbnRzLiBUaGVyZWZvcmUsDQo+IHdoZXJlIGF0IGxlYXN0 IG9uZSBlbGVtZW50IGlzIHJlcXVpcmVkLCBhdCBsZWFzdCBvbmUgbm9uLW51bGwgZWxlbWVudA0K PiBNVVNUIGJlIHByZXNlbnQuIERlZmF1bHQgdmFsdWVzIGFyZSAwIGFuZCBpbmZpbml0eSBzbyB0 aGF0ICIjZWxlbWVudCINCj4gYWxsb3dzIGFueSBudW1iZXIsIGluY2x1ZGluZyB6ZXJvOyAiMSNl bGVtZW50IiByZXF1aXJlcyBhdCBsZWFzdCBvbmU7DQo+IGFuZCAiMSMyZWxlbWVudCIgYWxsb3dz IG9uZSBvciB0d28uIiAtLQ0KPiA8aHR0cDovL2dyZWVuYnl0ZXMuZGUvdGVjaC93ZWJkYXYvcmZj MjYxNi5odG1sI3JmYy5zZWN0aW9uLjIuMT4NCg0KRm9yIEhUVFAsIHRoZSAjIHJ1bGUgY2FuIGJl IGhhbmRsZWQgd2l0aCBzb21lIHR3ZWFraW5nLi4uDQoNCiAgYSA9ICNiDQoNCi0+DQoNCiAgYSA9 ICpMV1MgKl4oKkxXUyAiLCIgKkxXUylbYl0NCg0KSXQgbWVhbnMgdGhhdCB0aGlzIGlzbid0IGFz IGRpcmVjdGx5IHVzYWJsZSBieSBIVFRQLCB0aG91Z2ggZXN0YWJsaXNoaW5nIGEgY29udmVudGlv biB3b3VsZCBtYWtlIHRoaXMgYSBsaXR0bGUgZWFzaWVyLg0KDQogIGEgPSAqTFdTICpeQ09NTUFb Yl0NCg== From Martin.Thomson@andrew.com Mon Dec 13 14:18:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F1B28C0F3 for ; Mon, 13 Dec 2010 14:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lVQuyGDjTdL for ; Mon, 13 Dec 2010 14:18:54 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id D223328C0D8 for ; Mon, 13 Dec 2010 14:18:54 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:28748 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S515283Ab0LMWUd (ORCPT ); Mon, 13 Dec 2010 16:20:33 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 13 Dec 2010 16:20:33 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 14 Dec 2010 06:20:30 +0800 From: "Thomson, Martin" To: Mykyta Yevstifeyev , "apps-discuss@ietf.org" Date: Tue, 14 Dec 2010 06:20:29 +0800 Thread-Topic: [apps-discuss] Some notes on ABNF notation for separated lists Thread-Index: AcuavJGRzX3dwaMWS8GAWOE211tbzAAVpVwA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F34FAC7B@SISPE7MB1.commscope.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "dcrocker@bbiw.net" Subject: Re: [apps-discuss] Some notes on ABNF notation for separated lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 22:18:57 -0000 T24gMjAxMC0xMi0xMyBhdCAyMjo1NDo1MiwgTXlreXRhIFlldnN0aWZleWV2IHdyb3RlOg0KPiBU aGlyZGx5LCBpdCBpcyBhIHRvcGljIHRvIGRpc2N1c3MgYWJvdXQgdGhlIGRlZmluaXRpb24gb2Yg c2VwYXJhdG9yLg0KPiBIb3dldmVyIEkgZG9uJ3QgdGhpbmsgdGhlIGZvcm0gMSpWQ0hBUiBpcyBi YWQgb3Igbm90IGFjY2VwdGFibGUgZm9yDQo+IHRoaXMgb2NjYXNpb24uIEl0IGlzIG9idmlvdXMg dGhhdCBzZXBhcmF0b3IgY2FuIGJlIG9ubHkgdmlzaWJsZSBjaGFycy4NCg0KVGhlcmUgYXJlIHR3 byBjb25jZXJuczogDQoNCiAtIHdoYXQgaXMgYWNjZXB0YWJsZSBpbiB0aGUgQUJORiBzeW50YXgg Zm9yIHRoZSAgZGVzY3JpYmluZyB0aGUgc2VwYXJhdG9yDQogLSB3aGF0IGlzIGFjY2VwdGFibGUg aW4gdGhlIHRhcmdldCBncmFtbWFyIGZvciB0aGUgc2VwYXJhdG9yDQoNClRoZSBBQk5GIHN5bnRh eCBuZWVkcyB0byBiZSBjb25zdHJhaW5lZCBzbyB0aGF0IHRoZSBBQk5GIHBhcnNlciBpcyBhYmxl IHRvIGRpc3Rpbmd1aXNoIHNlcGFyYXRvciBmcm9tIG90aGVyIHBhcnRzLiAgVGhpcyBpcyBlYXN5 OiB1c2UgdGhlIGV4aXN0aW5nIEFCTkYgZm9yIEFCTkYgY29uc3RydWN0cyB0byBkZXNjcmliZSB0 aGVzZSBsaW1pdGF0aW9ucy4NCg0KVGhlIHRhcmdldCBncmFtbWFyIHNob3VsZCBub3QgYmUgc2lt aWxhcmx5IGNvbnN0cmFpbmVkLiAgSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHVzZSBhbnkgZm9y bSBvZiBzZXBhcmF0b3IuDQoNClRoZSBleGlzdGluZyA8ZWxlbWVudD4gcnVsZSBzZWVtcyBtb3N0 IGFwcHJvcHJpYXRlLg0KDQo+IEJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwdXQg dGhlIHJlc3RyaWN0aW9uIG9uIG1heGltdW0NCj4gYW1vdW50IG9mIGNoYXJzIGluIHNlcGFyYXRv ciAtIG1heWJlIDU2IGlzIGVub3VnaC4gd2hhdCBkbyB5b3UgdGhpbmsNCj4gYWJvdXQgdGhpcz8N Cg0KQXJiaXRyYXJ5IGNvbnN0cmFpbnRzIG9uIGxlbmd0aCBhcmVuJ3QgaGVscGZ1bC4NCg0KLS1N YXJpdG4NCg== From julian.reschke@gmx.de Mon Dec 13 23:27:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776613A6F6F for ; Mon, 13 Dec 2010 23:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=-2.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm-7Qk9O5Gnd for ; Mon, 13 Dec 2010 23:27:42 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id DE6333A6EFB for ; Mon, 13 Dec 2010 23:27:41 -0800 (PST) Received: (qmail invoked by alias); 14 Dec 2010 07:29:19 -0000 Received: from p508FD842.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.216.66] by mail.gmx.net (mp005) with SMTP; 14 Dec 2010 08:29:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19GZ4BeOopG50DZK/GHHRaFjDJtGQYL8F8N6n9H3j 6uFrmAkqgsxyMd Message-ID: <4D071CCB.5040509@gmx.de> Date: Tue, 14 Dec 2010 08:29:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Thomson, Martin" References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mykyta Yevstifeyev , "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 07:27:43 -0000 On 13.12.2010 23:13, Thomson, Martin wrote: > On 2010-12-13 at 20:56:08, Julian Reschke wrote: >> "Wherever this construct is used, null elements are allowed, but do not >> contribute to the count of elements present. That is, "(element), , >> (element) " is permitted, but counts as only two elements. Therefore, >> where at least one element is required, at least one non-null element >> MUST be present. Default values are 0 and infinity so that "#element" >> allows any number, including zero; "1#element" requires at least one; >> and "1#2element" allows one or two." -- >> > > For HTTP, the # rule can be handled with some tweaking... > > a = #b > > -> > > a = *LWS *^(*LWS "," *LWS)[b] > > It means that this isn't as directly usable by HTTP, though establishing a convention would make this a little easier. > > a = *LWS *^COMMA[b] Maybe I wasn't clear about the problem I see. When in the HTTP grammar, we say 1#2element that matches the following header field values element element, element element, , element So empty elements aren't counted. I note that has the same rule. Is there a use case for this notation where empty list elements behave differently? Best regards, Julian From hotz@jpl.nasa.gov Mon Dec 13 14:59:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B02E3A6E17; Mon, 13 Dec 2010 14:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUbgw5CTrroQ; Mon, 13 Dec 2010 14:59:21 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 74E583A6E08; Mon, 13 Dec 2010 14:59:21 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBDN0lTC010816 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 13 Dec 2010 15:00:48 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4D0672F2.4070600@extendedsubset.com> Date: Mon, 13 Dec 2010 15:00:46 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Tue, 14 Dec 2010 08:57:49 -0800 Cc: "Common@core3.amsl.com" , protocols , Yoav Nir , websec , "General@core3.amsl.com" , Generation , Yaron Sheffer , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [apps-discuss] [http-auth] [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 22:59:22 -0000 On Dec 13, 2010, at 11:24 AM, Marsh Ray wrote: > So IMHO, significant improvements in web authentication would be greatly > beneficial. But they will have to: > > * Require connection integrity. This probably means mandatory TLS. > > * Require a user interaction that takes place outside the insecure > browser rectangle and feels different enough that it's easy to explain > the difference. > > * Not leak info to untrusted parties. These days privacy is often more > important than traditional security. > > * Support browser vendors in making a UI that "sucks less" to have to > use, or possibly have to use it less. Put users in control of their > identity and auth credentials without nagging them repeatedly until they > give in and click the "Yes to all" button. > > * Represent an actual improvement in security over the current standard > of HTML form POST password and secret HTTP session cookie. > > - Marsh +1 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hotz@jpl.nasa.gov Mon Dec 13 15:02:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3B028C0D8; Mon, 13 Dec 2010 15:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaTpeSJZroRq; Mon, 13 Dec 2010 15:02:08 -0800 (PST) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id D13563A6E1A; Mon, 13 Dec 2010 15:02:08 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBDN3T2I012748 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 13 Dec 2010 15:03:30 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 13 Dec 2010 15:03:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5649AF9C-AEF5-401C-AE45-85D361743D2E@jpl.nasa.gov> References: <4D02AF81.6000907@stpeter.im> To: Ben Laurie X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Tue, 14 Dec 2010 08:58:03 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [http-auth] [websec] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:02:10 -0000 On Dec 13, 2010, at 4:08 AM, Ben Laurie wrote: > On 11 December 2010 23:10, Yoav Nir wrote: >> TLS client certificates work, but as we've learned both with the web = and with IPsec clients, people would much rather not use them. A few = IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with = EAP authentication. >=20 > I think what we've learnt is that we need to provide good UI and > portability if we want people to use them. I think it's a "complete system" problem. You need a decent UI paradigm (not just a GUI), a respectable means of = issuing/deploying them, a respectable means of storing them for use by = multiple applications, and APIs and hooks that make them as easy to = develop with as cookies. Also all the capability needs to already be in = place, so there's no "plug-in installation" or equivalent. By "respectable" I mean something a security expert won't laugh at, = which doesn't also violate the UI paradigm. For all the people who say that we don't have to have perfect security, = or we need to support http:, not just https:, I respectfully claim that = you're off base. We don't need *more* less-than-secure mechanisms. We = need actually-secure mechanisms that real people can actually use. TLS with client certs qualifies as "actually-secure" (as would TLS with = draft-williams..sasl..04). Wouldn't we be better off putting our energy = into making it actually-usable, than in starting from scratch? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From marsh@extendedsubset.com Mon Dec 13 11:23:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7037028C0DF; Mon, 13 Dec 2010 11:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiu44KNobs2s; Mon, 13 Dec 2010 11:23:01 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 11CFF3A6DEB; Mon, 13 Dec 2010 11:23:01 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PSE0k-000367-F9; Mon, 13 Dec 2010 19:24:38 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 794AD60C6; Mon, 13 Dec 2010 19:24:34 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Q37PlkAZHnTRK33n7uni+GlAsvheYsbA= Message-ID: <4D0672F2.4070600@extendedsubset.com> Date: Mon, 13 Dec 2010 13:24:34 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> In-Reply-To: <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Dec 2010 08:58:19 -0800 Cc: "Common@core3.amsl.com" , protocols , websec , General@core3.amsl.com, Generation , Yaron Sheffer , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [apps-discuss] [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 19:23:03 -0000 On 12/13/2010 09:29 AM, Yoav Nir wrote: > > On Dec 13, 2010, at 4:24 PM, Rene Struik wrote: > >> Hi Yoav: >> >> Could you summarize the main problems with client certificates. To >> my knowledge, there are no technical problems with computational >> bottlenecks on the client side yet. The only problem area I could >> think of would be storage of private keys, but this seems >> solvable. >> >> Similarly, if you could point out main usability problems with >> certs that would be great (is this a general problem, or just an >> artifact of the way these are currently used?). Problems stem from >> realistic requirements not being met, so it is good to capture >> these. > > I can see several problems with client certificates, most related to > usability, but some also to security: > > * Certificates do not authenticate the user. They authenticate a > device. I don't think they do that exactly either. The client cert is generally public, its private key is a secret like a password, but one that's too hard to memorize. > Placing a certificate on my laptop is a close enough > approximation to authenticating *me*, but then I can't use the same > certificate on my home computer, my phone, Why not? > or the computer at some > Internet cafe or hotel business center. But there's nothing that you can do securely on an untrusted computer. Sometimes people propose the idea of a secure boot CD users carry around, but those can't defend against trojaned firmware or hardware. > Passwords, on the other hand, > are with me wherever I go, and can be used with any device. They have some pretty significant limitations too. > * A possible solution to the first problem would be to issue multiple > certificates for use in phone, laptop and desktop. But this makes the > management of all these certificates even more complicated, N users, M sites. N is billions, M is millions. N * M = a big number. Perhaps if we accept it as an inherently complicated problem then we can give people tools that they need? > and increases the attack surface. Honestly, could it be any worse? > * While some places of business, governments and militaries are > willing to spend the money and effort required to provision > certificates for all employees, I don't see companies doing it for > customers. It's never a good idea to bet that something is too big > for Google to do, but I can't imagine them issuing client > certificates to all gmail users. Ha! I bet if we double-dog dared them, they just might. Remember that they went all-TLS for gmail, when every other smaller site was saying it was un-economic. > Even banks, with real money at stake > don't do it, because the support costs would exceed the losses to > phishing. My understanding is that some banks do, in fact, use client certs. But from what I've seen, the economics and risk motivations of the banking sector are just really weird. It varies by country, and in the US it's still not entirely clear yet who's liable for losses due to online security. Banking is just so different than everyone else that it's usually not helpful to use it as an example it in general security discussion. > * Issuing certificates does not solve the problem with Internet > cafes. It makes no sense for me to install a browser certificate on > some random computer. Again, there's nothing you can do to make a login session secure from an untrusted machine. Perhaps we should throw this scenario out for the purposes of this discussion? > But don't take my word for it. Certificates are so inconvenient, that > people would rather use some two-factor authentication solution, > where you type in a password, and then get a one-time code on either > a fob or through an SMS message to your phone, which is what Marsh's > company does. The key thing is that the phone is something most people already have and are comfortable using. It's hard to overstate the value of that. Nevertheless, what we (well, Marketing in particular :-) are continually up against is this: on some level, the entire purpose of strengthening the authentication is to make it harder to log in to the computer. We can do our best to minimize how much harder it is for the legitimate user, and maximize how much harder it is for the bad guy, but at the end of the day the system ends up having more ways to say 'no'. For most systems, the vast majority of 'no's are not actual attacks. Theatrics that don't provide real security are obviously worthless, but so are strong systems that people don't use. This trade-off between security and usability is very real, not theoretical. Perfect example: On 12/13/2010 06:14 AM, Carsten Bormann wrote: > > As a webapp developer, I want to control the user interface during > authentication. Leaving the user alone with the bland and > unforgiving browser user interface for HTTP auth is suicide. I want > to provide extra buttons for forgotten passwords, maybe even > password hints, and a "sign up" method. Yeah. How did the user select their password for the website in the first place, if not by an HTML form POST? If it was good enough for the initial sign up, why should the web designer use something other than HTML form POST for the regular login? (These are rhetorical questions.) > HTML/CSS/JS lends itself > well to providing such a friendly user interface. > > As a security geek, I recognize this as exactly the problem that > creates the potential for phishing. Having the user type > credentials into a random form is never going to be secure, HSTS > notwithstanding. Right. Any time there's an untrusted app painting into a rectangle (e.g. the browser window) the only ways to communicate with the user securely is outside of that rectangle. Which is why the URL and lock icon are in the browser chrome (and why we're in the out-of-band authentication business). As people use more mobile devices with smaller screens, this chrome gets mostly optimized away (and may confuse the degree to which the phone is truly out-of-band). There's clearly a large set of users for whom this "rectangle" principle is too complicated. (It probably doesn't help that browsers allow web pages to open new windows, set the title bar and icon, and that they repurpose the untrusted rectangle to discuss certificate errors.) The most secure way I've seen to handle password entry is (don't laugh) MS Windows NT through Vista. Windows NT implemented Orange Book security and required a "secure attention key" sequence (ctrl+alt+del) before every password request. Vista UAC, though a failure in many ways, would switch the entire console session, going so far as to reinitializing hardware drivers in the process. It performs a whole-screen dimming effect which was said to be difficult to duplicate (I'm not sure in practice). So IMHO, significant improvements in web authentication would be greatly beneficial. But they will have to: * Require connection integrity. This probably means mandatory TLS. * Require a user interaction that takes place outside the insecure browser rectangle and feels different enough that it's easy to explain the difference. * Not leak info to untrusted parties. These days privacy is often more important than traditional security. * Support browser vendors in making a UI that "sucks less" to have to use, or possibly have to use it less. Put users in control of their identity and auth credentials without nagging them repeatedly until they give in and click the "Yes to all" button. * Represent an actual improvement in security over the current standard of HTML form POST password and secret HTTP session cookie. - Marsh From Nicolas.Williams@oracle.com Mon Dec 13 15:16:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB6E28C122; Mon, 13 Dec 2010 15:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElC+7mJvPtgK; Mon, 13 Dec 2010 15:16:44 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2EE153A6E22; Mon, 13 Dec 2010 15:16:36 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDNI0IX021792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 23:18:01 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDNFlHt003010; Mon, 13 Dec 2010 23:17:59 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 870944751292282232; Mon, 13 Dec 2010 15:17:12 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 15:17:10 -0800 Date: Mon, 13 Dec 2010 17:17:08 -0600 From: Nicolas Williams To: Luke Howard Message-ID: <20101213231708.GB1091@oracle.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Mailman-Approved-At: Tue, 14 Dec 2010 08:58:30 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:16:45 -0000 On Sun, Dec 12, 2010 at 12:38:07PM +1100, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > > > > > On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: > > > >> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: > >>> Other than that, I'm not aware of much activity. What have I missed? > >> > >> TLS client certificates. > > > > TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication. > > > > http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equivalent? _I_ believe it does :) From Nicolas.Williams@oracle.com Mon Dec 13 15:18:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048B53A6E08; Mon, 13 Dec 2010 15:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sxbTWuIL3ji; Mon, 13 Dec 2010 15:18:45 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E7FC23A6D4A; Mon, 13 Dec 2010 15:18:44 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBDNK9sd024453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 23:20:10 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBDNDrdP001633; Mon, 13 Dec 2010 23:20:05 GMT Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 870947501292282318; Mon, 13 Dec 2010 15:18:38 -0800 Received: from oracle.com (/10.135.188.51) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Dec 2010 15:18:37 -0800 Date: Mon, 13 Dec 2010 17:18:36 -0600 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20101213231836.GC1091@oracle.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D0479E3.4050508@gmail.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Mailman-Approved-At: Tue, 14 Dec 2010 08:58:53 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , Yoav Nir , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , Luke Howard , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:18:46 -0000 On Sun, Dec 12, 2010 at 09:29:39AM +0200, Yaron Sheffer wrote: > I am not a big fan of EAP myself (although I am a co-author on > Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral > equivalent. > > There is a number of EAP methods that provide zero-knowledge > password based mutual authentication (i.e. password based auth > that's *not* susceptible to dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): > EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. You missed the ABFAB thing... ABFAB WG is producing [drumroll please] a GSS-API mechanism that uses EAP. And SASL can use GSS mechanisms (via "GS2" [RFC5801]). So, I believe that the answer is "yes". Nico -- From smb@cs.columbia.edu Mon Dec 13 10:55:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F4628C0DF; Mon, 13 Dec 2010 10:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PESEjYVnT6nU; Mon, 13 Dec 2010 10:55:32 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 4A39128C0F8; Mon, 13 Dec 2010 10:55:32 -0800 (PST) Received: from dyn-209-2-229-36.dyn.columbia.edu (dyn-209-2-229-36.dyn.columbia.edu [209.2.229.36]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id oBDIv34P024750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Dec 2010 13:57:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <4D063CA5.8060907@gmail.com> Date: Mon, 13 Dec 2010 13:57:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 X-Mailman-Approved-At: Tue, 14 Dec 2010 08:59:10 -0800 Cc: Common@core3.amsl.com, General discussion of application-layer protocols , Yoav Nir , websec , - Next Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 18:55:34 -0000 On Dec 13, 2010, at 10:32 53AM, Yaron Sheffer wrote: > Just like the phrase "I am not a lawyer" is always followed by amateur = legal advice (I know that for sure, I've done it myself), the same goes = for "I am not a UI expert". >=20 > Two comments: >=20 > - There are in fact a few security-usability experts. I don't know if = any of them participate in the IETF. This is an emerging research field, = see e.g. http://oreilly.com/catalog/9780596008277. >=20 > - (I am not a UI expert, but...) Devising UI cues is extremely = difficult. People will gladly enter their password when the web site = displays a JPEG-rendered padlock icon. In fact *legitimate* sites have = been known to display such icons, strange as it may sound. Security and usability *is* one of my research areas. I agree with = Yoav: there are many problems with use of client-side certificates. In = general, I like them -- the only way to log in to the computers I = control is with public-key authenticated SSH -- but there are very good = reasons why they are seldom used. Private key storage and transport is = the major one, but key issuance and recovery from lost or stolen keys = are serious issues as well. The security community has made that worse = by layering heavyweight policies and procedures on top of the = certificate issuance process, even when the value of the resource being = protected isn't high enough to justify it. (I've been worrying about usability issues for a long time. There was = one I-D that I dealt with as AD that I abstained on -- I wouldn't vote = "no-ob" because I did object, but I had no better suggestion than "go = back and start over". While dealing with that document, I emailed one = of the top usability people and asked Do you know of papers on the difficulty of administering complex=20= access control lists? I'm trying to convince people that a=20 seriously-complex scheme will lead to massive security failures,=20= because no one will be able to get the ACLs right. So yes, there are people in the IETF who worry about UI issues.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From Martin.Thomson@andrew.com Tue Dec 14 11:51:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF2D28C0FF for ; Tue, 14 Dec 2010 11:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znrTFkhf9IEO for ; Tue, 14 Dec 2010 11:51:14 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id A0E3228C0E9 for ; Tue, 14 Dec 2010 11:51:14 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:48167 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S520445Ab0LNTwy (ORCPT ); Tue, 14 Dec 2010 13:52:54 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 14 Dec 2010 13:52:54 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 15 Dec 2010 03:52:52 +0800 From: "Thomson, Martin" To: Julian Reschke Date: Wed, 15 Dec 2010 03:52:50 +0800 Thread-Topic: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 Thread-Index: AcubYLDgAwrr/YgRSXaSnbEVUtF1LAAZ5g3w Message-ID: <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> In-Reply-To: <4D071CCB.5040509@gmx.de> 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 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Mykyta Yevstifeyev , "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 19:51:15 -0000 T24gMjAxMC0xMi0xNCBhdCAxODoyOToxNSwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQo+IFdoZW4g aW4gdGhlIEhUVFAgZ3JhbW1hciwgd2Ugc2F5DQo+IA0KPiAgICAxIzJlbGVtZW50DQo+IA0KPiB0 aGF0IG1hdGNoZXMgdGhlIGZvbGxvd2luZyBoZWFkZXIgZmllbGQgdmFsdWVzDQo+IA0KPiAgICBl bGVtZW50DQo+IA0KPiAgICBlbGVtZW50LCBlbGVtZW50DQo+IA0KPiAgICBlbGVtZW50LCAsIGVs ZW1lbnQNCj4gDQo+IFNvIGVtcHR5IGVsZW1lbnRzIGFyZW4ndCBjb3VudGVkLg0KDQpPaCwgd2Vs bCB0aGF0J3MgYWN0dWFsbHkgZXZlbiBlYXNpZXIuLi4NCg0KICAgIDEqMl4oKkxXUyAqKCIsIiAq TFdTKSllbGVtZW50DQoNCi0tTWFydGluDQo= From Kurt.Zeilenga@Isode.com Wed Dec 15 07:20:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCC828C181 for ; Wed, 15 Dec 2010 07:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.979 X-Spam-Level: X-Spam-Status: No, score=-100.979 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFZH6e3J6qjm for ; Wed, 15 Dec 2010 07:20:01 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C443628C180 for ; Wed, 15 Dec 2010 07:20:00 -0800 (PST) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 15 Dec 2010 15:21:42 +0000 From: Kurt Zeilenga Date: Wed, 15 Dec 2010 07:21:39 -0800 Message-Id: <00650698-AADF-4BF1-A036-2B95AEFE6069@Isode.com> To: Alexey Melnikov , draft-ietf-sipcore-sec-flows@tools.ietf.org X-Mailer: Apple Mail (2.1082) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 15:20:03 -0000 I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please = seehttp://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-sipcore-sec-flows (rev-07 reviewed) Title: Example call flows using Session Initiation Protocol (SIP) = security mechanisms Reviewer: Kurt Zeilenga Review Date: 12/15/2010 IETF Last Call Date: [include if known] IESG Telechat Date: 2011-01-20 Summary: This draft is basically ready for publication as an = Informational RFC but has a few issues that should be fixed before = publication. Major Issues: None. Minor Issues:=20 I see some inconsistencies in how Distinguished Names (DNs) are = presented in the RFC. For instance (from 2.1): Issuer: C=3DUS, ST=3DCalifornia, L=3DSan Jose, O=3Dsipit, OU=3DSipit Test Certificate Authority vs. (also from 2.1) DirName:/C=3DUS/ST=3DCalifornia/L=3DSan Jose/O=3Dsipit/ OU=3DSipit Test Certificate Authority The former kind of looks like the LDAP DN format but, if that's what was = intended, the RDNs appear in the incorrect order. Note that in the LDAP = DN format, the most specific element appears first (the reverse of how = they appear in the BER/DER encoding of a DN). Also, there should be no = spaces after the RDN separators (the commas). The latter appears to be DCE format. I would think it appropriate to use a single format for all DNs and, if = one chooses to use the LDAP DN format, that values ought to be = constructed per RFC 4514. I note that Appendix A of RFC 4514 discusses = presentation issues of Distinguished Names. Nits: The usual (many acronyms are not spelled out on first use, etc.)= From john-ietf@jck.com Tue Dec 14 11:22:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345883A6EBD; Tue, 14 Dec 2010 11:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpbgKEsWC2f5; Tue, 14 Dec 2010 11:22:12 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7A8CE3A6EA8; Tue, 14 Dec 2010 11:22:11 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PSaTT-00003D-Bz; Tue, 14 Dec 2010 14:23:47 -0500 Date: Tue, 14 Dec 2010 14:23:45 -0500 From: John C Klensin To: Steven Bellovin Message-ID: <9EC2FC766CCD8D29F96C688A@PST.JCK.COM> In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Wed, 15 Dec 2010 08:03:48 -0800 Cc: Common@core3.amsl.com, General discussion of application-layer protocols , Yoav Nir , websec , - Next Generation , Yaron Sheffer , http-auth@ietf.org, "ietf-http-wg@w3.org Group" , saag@ietf.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 19:22:14 -0000 --On Monday, December 13, 2010 13:57 -0500 Steven Bellovin wrote: >... >> Just like the phrase "I am not a lawyer" is always followed >> by amateur legal advice (I know that for sure, I've done it >> myself), the same goes for "I am not a UI expert". >> >> Two comments: >> >> - There are in fact a few security-usability experts. I don't >> know if any of them participate in the IETF. This is an >> emerging research field, see e.g. >> http://oreilly.com/catalog/9780596008277. >> >> - (I am not a UI expert, but...) Devising UI cues is >> extremely difficult. People will gladly enter their password >> when the web site displays a JPEG-rendered padlock icon. In >> fact *legitimate* sites have been known to display such >> icons, strange as it may sound. > > Security and usability *is* one of my research areas. I agree > with Yoav: there are many problems with use of client-side > certificates. In general, I like them -- the only way to log > in to the computers I control is with public-key authenticated > SSH -- but there are very good reasons why they are seldom > used. Private key storage and transport is the major one, but > key issuance and recovery from lost or stolen keys are serious > issues as well. The security community has made that worse by > layering heavyweight policies and procedures on top of the > certificate issuance process, even when the value of the > resource being protected isn't high enough to justify it. > > (I've been worrying about usability issues for a long time. > There was one I-D that I dealt with as AD that I abstained on > -- I wouldn't vote "no-ob" because I did object, but I had no > better suggestion than "go back and start over". While > dealing with that document, I emailed one of the top usability > people and asked > > Do you know of papers on the difficulty of administering > complex access control lists? I'm trying to convince people > that a seriously-complex scheme will lead to massive > security failures, because no one will be able to get the > ACLs right. > > So yes, there are people in the IETF who worry about UI > issues.) Steve, I worry too. And, while I effectively dropped out of the field --in terms of making any useful contributions-- about 25 years ago, I do try to track the literature (without great success). Observations: (1) The folks who taught me about what was then called "human factors in computing" in the 70s suggested that one key issue was to design from error/failure states backwards to both detailed system design and UI. If one could not do an analysis of failure states, then one wasn't ready to design the interfaces of the system. If the right information is not available in the right place to produce a coherent message and make it actionable, patching things on just don't work. From that perspective, it is as hard or harder to graft a good UI onto a system that wasn't designed with UIs in mind as it is to graft good security onto a system that wasn't designed for that. A large number of modern systems --and IETF protocols-- fail on both dimensions. (2) Even without any research, it should be obvious to us all that presenting a user with a dialog box with a string of text that might be informative to an expert but is pure gibberish to the user, followed by some choice, is not going to produce good results. The question of whether the choice in that situation should be a pair of boxes labeled "yes" or "no" (or equivalent) or a single box labeled "ok" (or equivalent) is, IMO, of purely academic concern. Unless the user can make an informed decision, decision/dialog boxes or other types of questions aren't about UIs but about attempted sops for the conscience of the implementer. Almost everything I've seen that attempts to deal with certificate validation failures falls into that general category. Things would be considerable better if we never had a false negative (bad certs could just be rejected, action dependent on them stopped, and the user informed, not asked), but that seems unlikely at least as long as we have relatively simple cases like administrative failures to install new certs before old ones expire. (3) I think the above suggests that your "seriously complex scheme" criterion is much too high a bar. Even a moderately complex scheme that depends on lots of factors or subtle interactions will fail. If the ACLs don't get people, then user inability to deal with explanations of the failures will. (4) The problem with your comments, and even more so the problem with mine above, is that they are not usefully actionable in the IETF. We could round up a collection of UI experts to look at some of these things and have them shake their heads and say "royal mess you have gotten yourselves into". That, like your comments and I hope mine, would be true... and equally useless vis-a-vis digging ourselves out. I hope this isn't as hopeless as it feels to me sometimes, but... do you have suggestions? john From tim-research@sentinelchicken.org Tue Dec 14 09:11:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5453F3A6FB5 for ; Tue, 14 Dec 2010 09:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOjfk1niLTsr for ; Tue, 14 Dec 2010 09:11:15 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id A97773A6FB6 for ; Tue, 14 Dec 2010 09:11:12 -0800 (PST) Received: (qmail 10544 invoked from network); 14 Dec 2010 17:23:07 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 14 Dec 2010 17:23:07 -0000 Received: (qmail 24957 invoked from network); 14 Dec 2010 17:16:30 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 14 Dec 2010 17:16:30 -0000 Received: (nullmailer pid 6184 invoked by uid 1000); Tue, 14 Dec 2010 17:12:50 -0000 Date: Tue, 14 Dec 2010 09:12:50 -0800 From: Tim Morgan To: Marsh Ray Message-ID: <20101214171250.GB5009@sentinelchicken.org> References: <4D02AF81.6000907@stpeter.im> <4D02BDB3.7060801@extendedsubset.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D02BDB3.7060801@extendedsubset.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Wed, 15 Dec 2010 08:03:58 -0800 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [http-auth] [websec] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 17:11:20 -0000 Hi Marsh, > IMHO, authentication just doesn't belong at the HTTP layer. Hmm, can't necessarily disagree there... However, I think having it in the next layer up (POST requests/cookies) is even worse. > HTTP is inherently bad at being stateful. Stateless interfaces can > be fantastic, but it doesn't support the "login session" concept > that most people have in mind when they talk about authentication. HTTP isn't good at being stateful, but it is. One could argue that even just Basic auth alone adds state. Cookies add state, and we have connection state. Ultimately, a non-security form of state management buys a security protocol nothing. I think time and again we have found that relying on insecure underlying state mechanisms in a secure protocol will bring about insecurities. Secure protocols need their own state management independent of the underlying layers. > Unless you're properly using TLS, you have no reason to believe that > the byte you just received is from the same party as the previous > byte you received. So under those circumstances, what exactly are > you authenticating, and to whom? Agreed. > I use a lot of web sites and none of them do authentication via > HTTP. Every single one of them expects a username/password via > HTTP(s) POST variables and returns a cookie of varying duration. Right, and this needs to change, IMHO. While I'd love to see lots more adoption of TLS client certificates, I don't think it will ever completely supplant username/password pairs. This is because most people don't understand certificates while everyone understands usernames and passwords. Also, there are some real differences in use cases which will create problems for some sites. > But what could we possibly do for a stateless, unMACed protocol like > HTTP, except integrate and bind it better with a lower layer > providing real integrity? That's pretty much the solution that Yutaka OIWA and the other Mutual auth folks have come up with. You have a protocol over HTTP which mutually guarantees the server and client have the same password without leaking the password (this prevents phishing even if users don't look at the domain name) and this cryptographic process is tied to the TLS server certificate to prevent MitM. Could the same security properties be achieved with TLS and say, SRP? Probably. The hurdle that SRP has is the user interface. Users and web developers are accustomed to being able to build their own login forms. Now that we (the security community) let them get away with this foolishness, we can't really take it away from them again. Very few web developers will give up the ability to build a branded, custom login form just to use something more secure like SRP over TLS. So, how would you go about making it usable with HTML login forms? I'm not sure. What I *have* investigated in the past is the ability to do HTTP authentication with custom HTML login forms. I've found it's not only possible right now, but the tools to do it (XMLHttpRequest, mostly) are becoming standardized in a way that makes it well-defined. So, there we could have a reasonable tradeoff between usability and improved security if we pushed for HTML login forms with Mutual auth. > I think what the world needs are ways for web apps (literally, the > Ruby code) to easily work with the strongly-authenticated identities > which are supported at the TLS layer. TLS already supports > "sessions" and "client authentication", but for whatever reasons > they're not being utilized. We should make using those facilities as > easy for web developers as doing cookie-based logins. Yes, exactly. So we've already covered how there are many protocols and protocol frameworks which are secure and integrate well with this, that, or the other backend system. Why aren't these adopted already? It all comes down to how easy it is for web developers to present a "user friendly" login process. I think we have enough good crypto out there. We should focus on how to make that crypto easier to deploy. Regards, tim From ted.ietf@gmail.com Wed Dec 15 12:28:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC06A28B23E for ; Wed, 15 Dec 2010 12:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+JeXBy31CpY for ; Wed, 15 Dec 2010 12:28:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CEDEB3A7076 for ; Wed, 15 Dec 2010 12:28:31 -0800 (PST) Received: by vws7 with SMTP id 7so1044733vws.31 for ; Wed, 15 Dec 2010 12:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=LJHLjUd6E5MYrPCGWsr2cb5kdZGHJQNuzSMoMD5IjJY=; b=hh0eBOMYO4PqjvMEthadpY4pKCOjdfF/6xWRaqy8JaPZlpoqXHSRHGdEZBph/PMR9C KUSFGUeRiUGVdEx4Xb03R/pOaNks9+qbUug3T5R5XnDtkNV5fqpwpWXdT9szaGwN97zW UIpQYXJdW9gzq9atp9qx5c4JkG/M4+aMwDgtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Evg7So1ckxUqoE4kPp2B7yYbxwBPzl5oRw0DeEcu1Z5Y/1dV2amg2c2RbgKhQKjbjk vemtTzdG/QdCyTyl5S5Pr0MBAHDz3H82RKQGejXM0NpgqOP8zv6THI7klJhxTMvBpD+q 5qS2F1mkrM/B+3/5Qu2DKGm5TAuI1mPaPDCBI= MIME-Version: 1.0 Received: by 10.229.215.9 with SMTP id hc9mr845528qcb.117.1292445013300; Wed, 15 Dec 2010 12:30:13 -0800 (PST) Received: by 10.229.230.138 with HTTP; Wed, 15 Dec 2010 12:30:13 -0800 (PST) Date: Wed, 15 Dec 2010 12:30:13 -0800 Message-ID: From: Ted Hardie To: apps-discuss@ietf.org, Alexey Melnikov , Peter Saint-Andre , tony+eaidsn@maillennium.att.com, chris.newman@oracle.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] draft-ietf-eai-rfc5337bis-dsn-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:28:32 -0000 I have been selected as an 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); note that Eliot Lear is also reviewing this draft as part of this 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-eai-rfc5337bis-dsn-01.txt Title: Internationalized Delivery Status and Disposition Notifications Reviewer: Ted Hardie Review Date: December 15, 2010 Summary: Reviewers were asked to look specifically at the ABNF; it appears to me correct and the output from abnfgen seemed sensible. Eliot and Dave Crocker have already discussed the citation issue. There are two other issues which I feel should be resolved. Major Issues: The document says: NOTE: The only issue for which there is (as yet) no consensus yet is whether to change the name of the Address Type from "UTF-8" to something different, such as "UTF8", to reflect the fact that the ">" address syntax is no longer permitted. Reviewing the mailing list there appeared to be one participant advocating change (SM) and one "not an exciting question" (Shawn Steele) and one noting a problem with changing it (Martin D=FCrst). 5335bis in the current version still calls this UTF-8; I believe that should govern this spec's usage and this note should be removed. A note to the RFC Editor to update this docum= ent if the nomenclature changes in the normative reference should do this; if not, then I believe that the IESG can permit a change by later adding a new RFC Editor note while it is in queue. Minor Issues: The document says: The ability to encode characters with the EmbeddedUnicodeChar encodings should be viewed as a transitional mechanism. It is hoped that as systems lacking support for UTF8SMTP become less common over time, these encodings can eventually be phased out. Transitional mechanisms generally live a long, long time, and this one seem= s likely to me to live at least to the end of my career. I would personally suggest striking this text, but it does no harm if left in. Nits: Chris Newman's address in the draft appears to be old. From evnikita2@gmail.com Thu Dec 16 08:07:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611FC3A6998 for ; Thu, 16 Dec 2010 08:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNCC2QQ+kC3j for ; Thu, 16 Dec 2010 08:07:42 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 929C03A68F3 for ; Thu, 16 Dec 2010 08:07:41 -0800 (PST) Received: by bwz8 with SMTP id 8so3900887bwz.38 for ; Thu, 16 Dec 2010 08:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=giDTQhU7ctjotUtwLVi4TE3tji9hqZzaXGSam221bFI=; b=BDB/V4wuBMhb58zju+RcGDJhp0smzqBgSooRraVcqOEEM/ZCJ/alEDcgJkV5lR/XJJ 5dKgtUqF2KRdfJ+CBQ+yGNB/KO2lwz7zt7XKg0TlCtwdByJ7tCRc+EeUTCN8B5OfZMOd L8gnKv/wW2obXdhyzxJQ1cWDTsRfm9rbEqwzY= 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=ZkKlpO34aoOKN8ARq45DawTjQHRhSfhFUXvedA6CRbR4LDXNjoFzGHWmTXHdmEAL8P Ma10JoI9ovPv8jodoY1zdkN+jsNkHWvEpAiZnyB7Oc6LRjwoIBGTx3fOe6vOf9M8fvMy IEyimpVwbeLVYSCDfy5KPeS7AY7DNgyWhFZp8= Received: by 10.204.74.219 with SMTP id v27mr8671397bkj.178.1292515766008; Thu, 16 Dec 2010 08:09:26 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id q18sm1242164bka.3.2010.12.16.08.09.24 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Dec 2010 08:09:25 -0800 (PST) Message-ID: <4D0A39C0.2070308@gmail.com> Date: Thu, 16 Dec 2010 18:09:36 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Thomson, Martin" References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 16:07:43 -0000 Hello all, I've just uploaded the new version of draft-yevstifeyev-abnf-separated-lists - -02. It has many issues corrected (see diffs). Among other, a new form is presented - n*m#a(element), as was proposed, the definition has been updated also. Could you please review *this* version? Any suggestions are welcome. All the best, Mykyta Yevstifeyev From cheshire@apple.com Wed Dec 15 14:28:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CFF28C106 for ; Wed, 15 Dec 2010 14:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.788 X-Spam-Level: X-Spam-Status: No, score=-106.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCfAQdoPnHDq for ; Wed, 15 Dec 2010 14:28:22 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id E17CB28C102 for ; Wed, 15 Dec 2010 14:28:19 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 1B43AC46926E for ; Wed, 15 Dec 2010 14:30:03 -0800 (PST) X-AuditID: 11807134-b7c51ae000005439-fd-4d094167574c Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id 9A.5E.21561.761490D4; Wed, 15 Dec 2010 14:30:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDH00CQBQHZQ710@gertie.apple.com> for Apps-Discuss@ietf.org; Wed, 15 Dec 2010 14:29:59 -0800 (PST) In-reply-to: References: Message-id: <25D96544-35C3-494A-BB86-FD236C57152A@apple.com> From: Stuart Cheshire Date: Wed, 15 Dec 2010 14:30:06 -0800 To: Joseph Yee X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 16 Dec 2010 09:03:31 -0800 Cc: Marc Krochmal , Apps-Discuss@ietf.org, Ralph Droms Subject: Re: [apps-discuss] Apps-Review Team Review: draft-cheshire-dnsext-dns-sd-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 22:28:24 -0000 On 3 Dec 2010, at 12:58 PM, Joseph Yee wrote: > I have been selected as the Applications Area Review Team reviewer > for this draft > > Major Issues: > 1) Section 4.1, last paragraph, need update on terminologies > > The paragraph use terminologies from IDNA2003 (ie. UTF-8 NFC, > punycode), and best to update it to IDNA2008 (U-label, A-label, > etc). The paragraph needs to cite RFC5890 instead of > RFC3492/3490. The references, whether it's RFC 3490/3492/5980, are > missing in both normative and informative reference section. > > Note: Two issues mentioned here. Update of terminologies is > Major. The lack of reference is Minor (no repeat in Minor section). Terminology and references fixed. > ---- > 2) Concerns on key/value pair in TXT > Section 6.3, 2nd paragraph > Section 6.4, 1st paragraph > > section 6.3: If an implementation sees unknown > keys in a service TXT record, it MUST silently ignore them. > > section 6.4: The "Key" MUST be at least one character. Strings > beginning with an > '=' character (i.e. the key is missing) SHOULD be silently ignored. > > If unknown-key (6.3) MUST be ignored, undefined-key (6.4) is > more of a configuration error than unknown-key. Undefined-key > needs to have same level of ignores in unknown-key. SHOULD gives > the dangerous "freedom". > > Recommendation (Section 6.4, 1st paragraph) > The "Key" MUST be at least one character. Strings beginning > with an > '=' character (i.e. the key is missing) MUST be silently ignored. I changed it to MUST. > ---- > 3) Section 6.7 (1st paragraph), version tag being 1st key/value > pair in TXT records > > The first paragraph mentioned if using version tag, it > "require it to be the first key/value pair in the TXT records" to > help client to determine if there's any compatibility concerns. In > regular DNS, when there are multiple TXT records, the order is > giving out in "pseudo random" order (some rotate the order in > predictable manner). The first order appearance can't be guarantee > in regular DNS even version tag is the first inserted/defined TXT > into configuration. > > My recommendation is to update the paragraph to have client to > inspect version value after capturing all key/value pairs, and > proceed only after checking the compatibility concerns. > > Note 1: I interpret the "require it to be the first key/value > pair in the TXT record" as equivalent to "MUST be the first pair > for client to receive". The order that *different* TXT records are returned is undefined by DNS, but the order of constituent strings within a *single* DNS TXT record is well defined. > ---- > 4) Mandatory of TXT record (Section 6, general, interoperability) > There are many SRV records deployed without the associated > TXT. With this draft trying to "merge" 2 sides of the world, this > draft needs to address the potential lack of TXT RR in some services. > > The draft needs to bring up the following: > - New services need to have TXT record, even it's empty (this > was addressed) > - Client implementations need to be robust to expect TXT RR may > not be there > - In absence of TXT, client implementations MAY > - treat the service has empty parameter > OR > - treat the service as not serviceable at the moment > > NOTE: What's saying at client implementations are suggestion. I > would leave it to authors to determine the scenarios, but I believe > the need to expand the text (no pun intended). The current draft > had gone in great details to explain many issues (they are great), > I believed this draft is the right place to address it. I have added: Note that this requirement for a mandatory TXT record applies exclusively to DNS-SD service advertising, i.e. services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. The DNS SRV record datatype [RFC 2782] may still be used in other contexts without any requirement for accompanying PTR and TXT records. I have also added: An empty TXT record containing zero strings is disallowed by RFC 1035. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD clients MUST treat the following as equivalent: o A TXT record containing a single zero byte. (i.e. a single empty string.) o An empty (zero-length) TXT record (This is not strictly legal, but should one be received it should be interpreted as the same as a single empty string.) o No TXT record. (i.e. an NXDOMAIN or no-error-no-answer response.) > ------------------ > Minor Issues: > 1) Section 4.1, 2nd paragraph on page 7 > "However, the Unicode > characters with longer UTF-8 encodings tend to be the more rarely- > used ones, and tend to be the ones that convey greater meaning per > character." > > recommendation > "However, the Unicode > characters with longer octet length under UTF-8 encoding tend to > be the more rarely- > used ones, and tend to be the ones that convey greater meaning per > character." Fixed. > ---- > 2) Section 4.3, 2nd paragraph, first sentence > original > "Any dots in the portion should be escaped by preceding > them with a backslash" > recommendation > "Any dots in the portion MUST be escaped by preceding > them with a backslash" IETF standards specify on-the-wire protocol requirements. This section points out an issue implementers should be aware of, but I'm wary of actually dictating internal implementation decisions regarding how to address that issue. Is this new text satisfactory? If client software takes the , and portions of a Service Instance Name and internally concatenates them together into a single string, then because the portion is allowed to contain any characters, including dots, appropriate precautions MUST be taken to ensure that boundaries are properly preserved. Client software can do this in a variety of ways, such as character escaping. This document RECOMMENDS that if concatenating the three portions of a Service Instance Name, any dots in the portion should be escaped following the customary DNS convention for text files: by preceding literal dots with a backslash (so "." becomes "\."). Likewise, any backslashes in the portion should also be escaped by preceding them with a backslash (so "\" becomes "\\"). Having done this, the three components of the name may be safely concatenated. The backslash-escaping allows literal dots in the name (escaped) to be distinguished from label-separator dots (not escaped), and the resulting concatenated string may be safely passed to standard DNS APIs like res_query(), which will interpret the backslash-escaped string as intended. > ---- > 3) Section 7, 3rd paragraph, first sentence > original > "Application Protocol Names may be no more than fifteen characters > (not counting the mandatory underscore)" > recommendation > "Application Protocol Names RECOMMENDED be no more than fifteen > characters > (not counting the mandatory underscore)" > > This is a soft (recommendation) limit rather than hard limit. No, it's a hard limit. Implementations set buffer sizes and protocol fields based on this limit. There is no benefit to be had in allowing some Application Protocol Names to be bigger than this. This is also documented in draft-ietf-tsvwg-iana-ports. > ----------------- > Nits: > > 1) Status of this Memo, Last paragraph, the sole sentence. > "This Internet-Draft will expire on 8th September 2010." > > Wrong date and not necessary. Boilerplate issue? Fixed. > ----------------- > Questions > > 1. Ever thought of creating an ABNF for the whole service name? I am not a fan of ABNF. I feel it is frequently used where not necessary just because it makes a document look more "technical", even though for many people is *less* comprehensible than plain English. And if the document contains both, then which is normative? > 2. What will the IANA Consideration section like after draft-ietf- > tsvwg-iana-ports published (what part will get deleted)? Is DNS-SD > draft depend on draft-ietf-tsvwg-iana-ports to publish first? > Wouldn't the suggestions of how IANA to manage service name be > better suggest in draft-ietf-tsvwg-iana-ports (and discuss there) > instead? That will depend on the final form draft-ietf-tsvwg-iana-ports takes. I am willing to hold this document until draft-ietf-tsvwg-iana-ports is published, as long as that does not take too long. Remember that this document first started in 2001 (draft-cheshire-dnsext- nias-00.txt), seven years before draft-ietf-tsvwg-iana-ports-00. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From dhc@dcrocker.net Thu Dec 16 09:38:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF153A695D for ; Thu, 16 Dec 2010 09:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqw2Bodm+gWB for ; Thu, 16 Dec 2010 09:38:57 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 2821C3A6928 for ; Thu, 16 Dec 2010 09:38:57 -0800 (PST) Received: from [192.168.1.15] (adsl-67-124-149-131.dsl.pltn13.pacbell.net [67.124.149.131]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBGHeZnD032439 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 09:40:41 -0800 Message-ID: <4D0A4F0E.7090604@dcrocker.net> Date: Thu, 16 Dec 2010 09:40:30 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com> In-Reply-To: <4D0A39C0.2070308@gmail.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, 16 Dec 2010 09:40:41 -0800 (PST) Cc: "apps-discuss@ietf.org" , Paul Overell Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 16 Dec 2010 17:38:58 -0000 Folks, Note: We still do not have statements of support for standardizing a mechanism, in spite of the continued activity on this thread. So far, this is a fun exercise, but that's all. Comments on the latest draft: > Abstract > > This document defines Augmented Backus-Naur Form (ABNF) notation for > representing lists separated by any specified character. It updates > RFC 5234. The form of the mechanism permits the separator to be a string, not just a character. > 1. Introduction > > ABNF does not provide the possibility to express the separated lists > of elements via specific construction. If it is needed (generally for > defining HTTP headers or human-readable forms), the following ABNF > construction is used: the following ABNF construction is used -> the following is an example of an ABNF construction that would be used { There are many different list forms; the one given here builds in certain assumptions that do not always apply. /d } > (*LWS element n*m(*LWS separator *LWS element)) > > It is obvious that this construction is too simplified and bulky. Statements about human perception and assessment are almost always a mistake in a technical specification. Don't make them. It is enough to assert that a 'list' is a common pattern in ABNF specifications and it would make list specifications more convenient to have a construct that supports them. > This document specifies universal ABNF notation for lists, separated > by arbitrary specified characters. This document specifies universal ABNF notation -> This document specifies a concise ABNF notation > 2. Notation Description Notation Description -> List Notation { This section is the formal definition of the construct; it's not just a "description". /d } > This document augment the ABNF notation *element with OPTIONAL augment -> augments ABNF notation -> ABNF repetition notation > separator part, so that the construction for separated lists is: > > *[#()]element In reviewing the way Section 3 of RFC 5234 specifies things, I believe that the specification, here needs to be made without the square brackets and without the parentheses. (I think someone earlier commented about the parens.) In the place the construct is being specified, all of the pieces are required. The concept of being optional comes into play later. So I think the specification of the construct needs to be: *#element > where is a separator. This construction indicates at least a separator -> a separator string that is used in between element repetitions > and at most elements separated by . > > The corresponding construction element is also updated so that for > separated lists it stands as: > > [#()]element #element > indicating exactly elements separated by . > > The ABNF for this construction is: > > n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element)) n*m#a element) = (n_1*m_1(element 1*SP a) f(element)) > n#(a)(element) = (n_1(element 1*SP a) element) n#a element = (n_1(element 1*SP a) element) > 1*3#(";")element indicates the list of elements separated by Question to the audience: are the parentheses needed here? The quotation marks would seem to provide sufficient lexical uniqueness, but this is the sort of nuance I usually get wrong. > 3. Security Considerations > > Security issues are not discussed by this document. Improper or confusing specifications can introduce extensive security risks. The new construct provides a concise and clear means of specifying a common pattern that might otherwise permit data variations that could be used for hiding unwanted content, such as encoding a spam message that would bypass filters. { I didn't create this observation. Mark Delaney didn't either, but during the DomainKeys development he was particularly adept at demonstrating this exploit. /d } -- Dave Crocker Brandenburg InternetWorking bbiw.net From julian.reschke@gmx.de Thu Dec 16 13:55:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DCB3A69F6 for ; Thu, 16 Dec 2010 13:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.574 X-Spam-Level: X-Spam-Status: No, score=-104.574 tagged_above=-999 required=5 tests=[AWL=-1.975, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJLYgVPg82Rx for ; Thu, 16 Dec 2010 13:55:00 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id CC2C63A6919 for ; Thu, 16 Dec 2010 13:54:59 -0800 (PST) Received: (qmail invoked by alias); 16 Dec 2010 21:56:43 -0000 Received: from p508FC012.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.192.18] by mail.gmx.net (mp046) with SMTP; 16 Dec 2010 22:56:43 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/PzRdc9lXPSY0/4m6EYhMGbbToY5uq5knL63ll32 jDxzbfpwgenZaA Message-ID: <4D0A8B14.6080803@gmx.de> Date: Thu, 16 Dec 2010 22:56:36 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com> <4D0A4F0E.7090604@dcrocker.net> In-Reply-To: <4D0A4F0E.7090604@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" , Paul Overell Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 21:55:01 -0000 On 16.12.2010 18:40, Dave CROCKER wrote: > ... >> 1*3#(";")element indicates the list of elements separated by > > Question to the audience: are the parentheses needed here? The quotation > marks would seem to provide sufficient lexical uniqueness, but this is > the sort of nuance I usually get wrong. > ... Parentheses please. > ... Best regards, Julian From Martin.Thomson@andrew.com Thu Dec 16 14:03:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA2B3A6953 for ; Thu, 16 Dec 2010 14:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, MANGLED_OFF=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xF7nmK5vMj1 for ; Thu, 16 Dec 2010 14:03:26 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id ABDB03A691D for ; Thu, 16 Dec 2010 14:03:26 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:57699 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S40293172Ab0LPWFL (ORCPT ); Thu, 16 Dec 2010 16:05:11 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 16 Dec 2010 16:05:11 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 17 Dec 2010 06:05:08 +0800 From: "Thomson, Martin" To: "dcrocker@bbiw.net" Date: Fri, 17 Dec 2010 06:04:54 +0800 Thread-Topic: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 Thread-Index: AcudSGAVNaWOOSLUQcS2sPx6C5Xr/AAIBPGA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F34FB125@SISPE7MB1.commscope.com> References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com> <4D0A4F0E.7090604@dcrocker.net> In-Reply-To: <4D0A4F0E.7090604@dcrocker.net> 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 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "apps-discuss@ietf.org" , Paul Overell Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 22:03:28 -0000 KzEgdG8gdGhlIHJlc3Qgb2YgdGhpcy4gIE90aGVyIHN0dWZmIGJlbG93Lg0KDQpPbiAyMDEwLTEy LTE3IGF0IDA0OjQwOjMwLCBEYXZlIENST0NLRVIgd3JvdGU6DQo+IE5vdGU6ICBXZSBzdGlsbCBk byBub3QgaGF2ZSBzdGF0ZW1lbnRzIG9mIHN1cHBvcnQgZm9yIHN0YW5kYXJkaXppbmcgYQ0KPiBt ZWNoYW5pc20sDQo+IGluIHNwaXRlIG9mIHRoZSBjb250aW51ZWQgYWN0aXZpdHkgb24gdGhpcyB0 aHJlYWQuICBTbyBmYXIsIHRoaXMgaXMgYQ0KPiBmdW4NCj4gZXhlcmNpc2UsIGJ1dCB0aGF0J3Mg YWxsLg0KDQorMS4gIEknbSBzdGlsbCBvcGVuIHRvIGJlaW5nIGNvbnZpbmNlZCB0aG91Z2guICBU aGUgSFRUUC1zcGVjaWZpYyBleHRlbnNpb25zIHRvIEFCTkYgYXJlIGEgYml0IG9mIGFuIGlycml0 YW50LCBhcyBhcmUgb3RoZXIgc3VjaCBzcGVjaWZpY2F0aW9uLXNwZWNpZmljIGV4dGVuc2lvbnMu ICBBcyBpdCBzdGFuZHMsIHRoZSBkcmFmdCBpcyBub3QgZW5vdWdoIHRvIGNvbnZpbmNlIG1lLg0K DQo+IHsgVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IGxpc3QgZm9ybXM7IHRoZSBvbmUgZ2l2ZW4g aGVyZSBidWlsZHMgaW4NCj4gY2VydGFpbg0KPiBhc3N1bXB0aW9ucyB0aGF0IGRvIG5vdCBhbHdh eXMgYXBwbHkuICAvZCB9DQo+IA0KPiANCj4gPiAgICAoKkxXUyBlbGVtZW50IG4qbSgqTFdTIHNl cGFyYXRvciAqTFdTIGVsZW1lbnQpKQ0KDQpJbiBmYWN0LCB1c2luZyBtb3JlIHByZXNjcmlwdGl2 ZSBwcm9zZSBhbmQgc3BlY2lmaWMgZXhhbXBsZXMgaXMgcHJvYmFibHkgYmV0dGVyLiAgRXhwbGFp biBpbiBwcm9zZSwgdGhlbiBwcm92aWRlIGEgZmV3IGFjdHVhbCBleGFtcGxlcywgd2l0aCBleGFt cGxlcyBvZiB0aGUgc3ludGF4IHRoYXQgY29uZm9ybXMgdG8gdGhlc2UgZ3JhbW1hcnMgYXMgd2Vs bC4gIFRoZSBzdHlsZSBvZiBSRkMgNTIzNCBpcyBhIGdvb2QgZ3VpZGU7IEkgZG9uJ3QgbGlrZSB0 aGUgZmFjdCB0aGF0IHRoaXMgZHJhZnQgc3RyYXlzIHNvIGZhciBmcm9tIHRoYXQuDQoNClRoZSBl bnRpcmUgZHJhZnQgbWlnaHQgYmUgc3VtbWFyaXplZCBzbyBtdWNoIG1vcmUgc3VjY2luY3RseSBh bmQgY2xlYXJseSBpbiB0aGlzIGZhc2hpb246DQoNCg0KLS04PC0tDQozLjExICBTZXBhcmF0ZWQg bGlzdDogbiptI3MgcnVsZQ0KDQpBIGhhc2ggZm9sbG93aW5nIGEgcmVwZXRpdGlvbiBpbmRpY2F0 ZXMgYSBzZXBhcmF0b3IgdGhhdCBhcHBlYXJzIGJldHdlZW4gZWFjaCBvZiB0aGUgbXVsdGlwbGUg aW5zdGFuY2VzIG9mIHRoZSBlbGVtZW50LiAgQW55IHZhcmlhYmxlIG9yIHNwZWNpZmljIHJlcGV0 aXRpb24gY2FuIGJlIGZvbGxvd2VkIGJ5IGEgc2VwYXJhdG9yLiAgVGhlIGZ1bGwgZm9ybSBpczoN Cg0KICA8YT4qPGI+IzxzZXBhcmF0b3I+ZWxlbWVudA0KDQpXaGVyZSA8c2VwYXJhdG9yPiBpcyBh bnkgdmFsaWQgZWxlbWVudCAtIGluY2x1ZGluZyBncm91cGVkIGVsZW1lbnRzIC0gZm9sbG93ZWQg Ynkgb3B0aW9uYWwgd2hpdGVzcGFjZS4NCg0KQSBydWxlIG9mIHRoZSBmb3JtOg0KDQogICA0Kjcj IiwiIGZvbw0KDQppcyBlcXVpdmFsZW50IHRvOg0KDQogICBmb28gMyo2KCIsIiBmb28pDQoNClNp bWlsYXJseSwgYSBydWxlIG9mIHRoZSBmb3JtOg0KDQogICAqI1sqV1NQICI7IiAqV1NQXSBmb28N Cg0KaXMgZXF1aXZhbGVudCB0bzoNCg0KICAgW2ZvbyAqKFsqV1NQICI7IiAqV1NQXSBmb28pXQ0K DQo0LjEgQUJORiBEZWZpbml0aW9uIG9mIEFCTkYNCgkNClRoZSA8cmVwZWF0PiBydWxlIGlzIGV4 dGVuZGVkIGZyb20gdGhhdCBpbiBbUkZDNTIzNF0gZnJvbToNCg0KICAgcmVwZWF0ID0gMSpESUdJ VCAvICgqRElHSVQgIioiICpESUdJVCkNCg0KdG86DQoNCiAgIHJlcGVhdCA9IDEqRElHSVQgLyAo KkRJR0lUICIqIiAqRElHSVQpIFsgIiMiIGVsZW1lbnQgKmMtd3NwIF0NCg0KLS0+OC0tDQoNCnsg SSBtaXNzZWQgdGhlIG9wdGlvbmFsIGMtd3NwIGluIG15IHByZXZpb3VzIGNvbW1lbnRzIC0gdGhh dCdzIG5lY2Vzc2FyeSB0byBzZXBhcmF0ZSB0aGUgdHdvIGNvbnNlY3V0aXZlIDxydWxlbmFtZT4g Y29uc3RydWN0cyBpbiBhIHJlcGV0aXRpb24uICBGb3IgaW5zdGFuY2U6DQoNCiAgIGV4YW1wbGUg PSAzKjEwI2NvbW1hIGxpc3QtaXRlbQ0KfQ0KDQo+IEluIHJldmlld2luZyB0aGUgd2F5IFNlY3Rp b24gMyBvZiBSRkMgNTIzNCBzcGVjaWZpZXMgdGhpbmdzLCBJIGJlbGlldmUNCj4gdGhhdCB0aGUN Cj4gc3BlY2lmaWNhdGlvbiwgaGVyZSBuZWVkcyB0byBiZSBtYWRlIHdpdGhvdXQgdGhlIHNxdWFy ZSBicmFja2V0cyBhbmQNCj4gd2l0aG91dCB0aGUNCj4gcGFyZW50aGVzZXMuICAoSSB0aGluayBz b21lb25lIGVhcmxpZXIgY29tbWVudGVkIGFib3V0IHRoZSBwYXJlbnMuKQ0KDQpUaGF0IHdhcyBw cm9iYWJseSBtZS4gIFlvdSBhcmUgY29ycmVjdC4gIEJhc2VkIG9uIHRoaXMsIHRoZSBncmFtbWFy IHNob3VsZCBiZSBhcyBhYm92ZS4NCg0KPiA+ICAgIGluZGljYXRpbmcgZXhhY3RseSA8bj4gZWxl bWVudHMgc2VwYXJhdGVkIGJ5IDxhPi4NCj4gPg0KPiA+ICAgIFRoZSBBQk5GIGZvciB0aGlzIGNv bnN0cnVjdGlvbiBpczoNCj4gPg0KPiA+ICAgIG4qbSMoYSkoZWxlbWVudCkgPSAobl8xKm1fMShl bGVtZW50IDEqU1AgYSkgZihlbGVtZW50KSkNCj4gDQo+ICAgICBuKm0jYSBlbGVtZW50KSA9IChu XzEqbV8xKGVsZW1lbnQgMSpTUCBhKSBmKGVsZW1lbnQpKQ0KDQpBbGwgdGhpcyBuXzEsIG1fMSBh bmQgZiBzdHVmZiBpcyBjb25mdXNpbmcgYW5kIHVubmVjZXNzYXJ5LiAgSXQgcmVsaWVzIG9uIHdo YXQgYW1vdW50cyB0byBhbm90aGVyIG1vZGlmaWNhdGlvbiB0byB0aGUgZ3JhbW1hci4gIFRoZSBk ZWZpbml0aW9uIG9mIDxmPiBzdGlsbCBkb2Vzbid0IG1ha2Ugc2Vuc2UuICB1LSh1LTEpIGlzIDEs IGFsd2F5cy4NCg0KPiA+ICAgIDEqMyMoIjsiKWVsZW1lbnQgaW5kaWNhdGVzIHRoZSBsaXN0IG9m IGVsZW1lbnRzIHNlcGFyYXRlZCBieQ0KPiANCj4gUXVlc3Rpb24gdG8gdGhlIGF1ZGllbmNlOiAg YXJlIHRoZSBwYXJlbnRoZXNlcyBuZWVkZWQgaGVyZT8gIFRoZQ0KPiBxdW90YXRpb24gbWFya3MN Cj4gd291bGQgc2VlbSB0byBwcm92aWRlIHN1ZmZpY2llbnQgbGV4aWNhbCB1bmlxdWVuZXNzLCBi dXQgdGhpcyBpcyB0aGUNCj4gc29ydCBvZg0KPiBudWFuY2UgSSB1c3VhbGx5IGdldCB3cm9uZy4N Cg0KUGFyZW50aGVzZXMgYXJlIG5vdCByZXF1aXJlZCBoZXJlIC0gaWYgd2UgYXNzdW1lIHRoYXQg dGhlIHNlcGFyYXRvciBncmFtbWFyIGNvbmZvcm1zIHRvIDxlbGVtZW50Pi4gIFRoZXkgd291bGQg YmUgcGVybWl0dGVkLCBidXQgdGhlIGRyYWZ0IHN0aWxsIGRvZXMgbm90IGRlc2NyaWJlIHRoZSBn cmFtbWFyIGZvciB0aGUgc2VwYXJhdG9yLg0KDQotLU1hcnRpbg0KDQo= From tbray@textuality.com Thu Dec 16 15:59:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98C43A6A36 for ; Thu, 16 Dec 2010 15:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaXJEmejDVUt for ; Thu, 16 Dec 2010 15:59:42 -0800 (PST) Received: from mail-fx0-f52.google.com (mail-fx0-f52.google.com [209.85.161.52]) by core3.amsl.com (Postfix) with ESMTP id 1FAA53A6A1F for ; Thu, 16 Dec 2010 15:59:41 -0800 (PST) Received: by fxm5 with SMTP id 5so120099fxm.39 for ; Thu, 16 Dec 2010 16:01:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.100.15 with SMTP id w15mr399277fan.121.1292544086973; Thu, 16 Dec 2010 16:01:26 -0800 (PST) Received: by 10.223.27.13 with HTTP; Thu, 16 Dec 2010 16:01:26 -0800 (PST) X-Originating-IP: [216.113.201.123] Date: Thu, 16 Dec 2010 16:01:26 -0800 Message-ID: From: Tim Bray To: SM , Apps Discuss , m8philli@uk.ibm.com, peaston@progress.com, derek.rokicki@softwareag.com, eric@tibco.com, Alexey Melnikov , The IESG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 23:59:43 -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-merrick-jms-uri-10 Title: URI Scheme for Java(tm) Message Service 1.0 Reviewer: Tim Bray Review Date: Dec 16, 2010 Summary: The draft has some mechanical issues which are not show-stoppers. I have questions whether this ought to be an RFC since there seems very modest expectation of interoperability between implementations; why, then, an IETF RFC, which suggests that the resulting URIs should be useful for identification of resources on an internetworked scale. Major Issues: 1. the draft suggests that given a =93jms:=94 URI, there is little expectation that, without checking on the value of the =93variant=94 and for the presence of vendor-specific parameters, it can be used interoperably in more than one implementation. In which case, I have to wonder about the appropriateness of using a *Uniform* resource identifier for whatever purposes are contemplated for these things; no motivations or use-cases are provided. The last paragraph of section 1 is troubling. For convenience, I quote: <<<<< As a consequence of building upon an API, rather than a protocol, the utility of a "jms" URI depends on the context in which it is used. That context includes agreement on the same JMS provider or underlying protocol, agreement on how to look up endpoints (JNDI), and when using serialized Java object messages, sufficiently similar Java Class environments that serialized objects can be appropriately read and written. Users of this scheme need to establish the necessary shared context parts as just enumerated - a context which can span the globe, or merely a small local network. With that shared context, this URI scheme enables endpoint identification in a uniform way, and the means to connect to those endpoints. >>>> Given this, what are the advantages of having a *Uniform* resource identifier, if there is not much expectation of uniformity in implementations? 2. Section 3.3 says =93 If users plan switching between JMS vendors, they might also need to plan on regenerating resources that contain URIs in this vendor specific form=94; this sharpens my concerns about the lack of interoperability... I=92m getting the impression, reading this, that =93jms:jndi=94 is probably quite interoperable, but the variants are maybe a back-door for vendor abuse. Minor Issues: 1. Section 1. Need references for terms like javax.jms.Destination for people who aren=92t familiar with Java pathname voodoo. 2. Section 4 para beginning =93Each variant can have query parameters...=94 - did you consider separating the variant prefix from the rest of the parameter name with =93.=94 or some other syntax marker? I note that you use =93jndi-=94 for another class of parameter names below. 3. Same paragraph. Should the variant be used as a prefix even if it=92s a vendor-supplied one starting with =93vnd.=94? An example of this would be nice. 4. 4.1.1 and so on, should the draft impose any constraints on the syntax of these parameter values? Perhaps they are inherited from the referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I see that 4.1.3 does specify some syntax, albeit loosely; there are a lot of different syntaxes which may be used to specify =93 number between 0 and 9, inclusive=94. Are you OK with 0x3 or, for timeToLive, =931,500=94? 5. 4.2.1 Perhaps a note prior to launching into all the parameters on syntax constraints, with, I=92m assuming, normative references into the JMS spec? 6. 4.2.2 includes great gobs of Java code illustrating how to use such an endpoint. Does this not contradict with the assertion at the top of section 4 which says =93 Operations available on JMS destinations are fully and normatively defined by the JMS specification and as such, are out of scope for this URI specification=94? In any case, 4.2.2 needs a bit of preparatory language explaining what it is. Is it normative behavior for implementations? Is it there for illustrative purposes? Is it required to use Java, or could I code something equivalent in C# or Ruby? A few paragraphs in there=92s a passing reference to =93the following (non-normative) code...=94 7. 4.3.1, see comments on 4.2.2 above. Is this description of programming practice normative, illustrative, or what? 8. Section 6, 3rd para: I haven=92t ever seen anything like the note about what an OASIS TC might be doing in an RFC before, but possibly I=92ve just missed the examples. 9. Section 7, last para: =93As described in Section 4, others can define additional variants=94... there is no description in Section 4 of how to define additional variants. Also, while the language in the opening of the draft suggests that the set of variants is open-ended, this is the first explicit mention of this possibility that I encountered. Is there a registry? Oh, there it is in section 9.2. OK, I think that the beginning of the doc needs to say that the set of variants is open-ended and vendor-extensible. It also smells like a big huge honking interoperability hole. Nits: 1. Section 4 para 3, superfluous comma after =93Both the variant=94. 2. Section 4 para beginning =93Each variant can have query parameters...=94 - did you consider separating the variant prefix from the rest of the parameter name with =93.=94 or some other syntax marker? I note that you use =93jndi-=94 for another class of parameter names below. 3. Section 4.1 I assume =93shared=94 means =93available in all variants=94?= If so, why not say so? 4. Section 4.1 first para, the word =93property=94 suddenly appears for the first time. Is this a synonym of =93parameter=94? 5. Section 4.1.1 Lots of references here need to be turned into RFC style with square brackets 5. Same section, missing full stop after =93following shared parameters=94. 6. 4.1.1 Probably more idiomatic of normative text to say, instead of =93This MUST be=94, =93The value of this parameter MUST be...=94 7. 4.1.1 Missing full-stop at end. 8. 6, 2nd para: What=92s an =93SPI=94? From john-ietf@jck.com Fri Dec 17 03:09:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3F23A6AE1; Fri, 17 Dec 2010 03:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDpbY0xUl6Tg; Fri, 17 Dec 2010 03:09:34 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 103673A6AE0; Fri, 17 Dec 2010 03:09:34 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PTYDQ-0004Hs-Dd; Fri, 17 Dec 2010 06:11:12 -0500 X-Vipre-Scanned: 07A7194C001DEB07A71A99-TDI Date: Fri, 17 Dec 2010 06:11:11 -0500 From: John C Klensin To: Peter Gutmann Message-ID: <97844CCF96DABB3B5F2A976F@[192.168.1.128]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Common@core3.amsl.com, apps-discuss@ietf.org, websec@ietf.org, smb@cs.columbia.edu, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 11:09:35 -0000 --On Friday, December 17, 2010 6:18 PM +1300 Peter Gutmann wrote: > John C Klensin writes: > >> We could round up a collection of UI experts to look at some >> of these things and have them shake their heads and say >> "royal mess you have gotten yourselves into". > > The problem isn't that UI experts haven't looked at this, > there have been a large number of papers published on this > problem over the last decade or so, it's that it's proven > pretty much impossible to get any action taken over it. The > browser approach is "PKI isn't working, so we'll respond with > even more PKI (EV certs) while stridently ignoring any > workable alternatives (TLS-SRP and -PSK)", and there's no > sign that this will ever change. There simply isn't a hammer > big enough to force a change here (or, if there is, no-one's > managed to identify it yet). I perhaps should have said "...yet another collection of UI experts..." and "shake their heads again...". But I don't think we disagree: from my point of view, you are just describing some aspects of what I tried to summarize as "royal mess". I do think there is at least one big enough hammer although I'm not predicting we will get there soon and really don't like seeing protocols designed by a sequence of disaster, legal action, and legislation. And, I am not, for the record, offering an opinion as to whether the approaches you suggest are workable and/or the right answers. john From evnikita2@gmail.com Fri Dec 17 06:37:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B743A6B5E for ; Fri, 17 Dec 2010 06:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FipTE77om3IC for ; Fri, 17 Dec 2010 06:37:13 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id 532FE3A6B53 for ; Fri, 17 Dec 2010 06:37:13 -0800 (PST) Received: by bwg12 with SMTP id 12so941320bwg.37 for ; Fri, 17 Dec 2010 06:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=ajXJ4uR8h8YICmRZL5oF64BZS7mOIzrZhLAjYb3mOGI=; b=uaXHHO6OS7tySACI3xfHcAqHbMo1c9qVm63gZKIl99uZj9X6YtnilT7iID3uuY76dY S5/7Ad0wB2C+JM5/9M/OGXz3dKICNjryz9KaH9MkmanvRR3tMuMOB1VMumOm6z8wkLph +w/Ikdhm+g6ut+5wJGIgEXRPN+alIZY/rYvvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=rAmkAouWrvY0qNYRW/59iamXE2erN4jCOuWkslBb8QbFk8bFmEG3znOgCmmL6qTAHR XKwtrGg/vsvfoQ1pVZtm+9tc5ZtW25wmfOMis7NN8QyC6BQxaIIHSU89QWgZsSRWyEtT ILR8gSGIDxL8xBCnLprzPgIPDOH7ZOXvNN8N0= Received: by 10.204.104.15 with SMTP id m15mr656557bko.108.1292596738604; Fri, 17 Dec 2010 06:38:58 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v1sm1996400bkt.17.2010.12.17.06.38.57 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Dec 2010 06:38:57 -0800 (PST) Message-ID: <4D0B760C.50901@gmail.com> Date: Fri, 17 Dec 2010 16:39:08 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary="------------000109070200060306010708" Subject: [apps-discuss] ABNF Notation for Separated lists - any comments? and some other topics... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 14:37:14 -0000 This is a multi-part message in MIME format. --------------000109070200060306010708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, What I know is that there have not been any comments or suggestion to the draft connected with ABNF notation for separated lists. Does it mean that there is nothing to discuss there (as there are *many* topics to discuss there yet)? Or there is just no interest for this work?.. Moreover, could I ask you to review another my work - draft-yevstifeyev-hcitp, which can be found here: http://www.ietf.org/id/draft-yevstifeyev-hcitp-09.txt I think that concerns greatly to AppsAREA WG. Thank you for your time. You can write me if any information is needed. All the best, Mykyta Yevstifeyev P.S. The link to the draft mentioned in 1st paragraph: http://tools.ietf.org/html/draft-yevstifeyev-abnf-separated-lists-04 Mykyta. --------------000109070200060306010708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

What I know is that there have not been any comments or suggestion
to the draft connected with ABNF notation for separated lists. Does
it mean that there is nothing to discuss there (as there are *many*
topics to discuss there yet)? Or there is just no interest for this work?..

Moreover, could I ask you to review another my work -
draft-yevstifeyev-hcitp, which can be found here:

http://www.ietf.org/id/draft-yevstifeyev-hcitp-09.txt

I think that concerns greatly to AppsAREA WG. Thank you for
your time. You can write me if any information is needed.

All the best,
Mykyta Yevstifeyev

P.S. The link to the draft mentioned in 1st paragraph:

http://tools.ietf.org/html/draft-yevstifeyev-abnf-separated-lists-04

Mykyta.



 --------------000109070200060306010708-- From barryleiba@gmail.com Fri Dec 17 07:54:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F043A68DA for ; Fri, 17 Dec 2010 07:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ds0Me7BWwZn for ; Fri, 17 Dec 2010 07:54:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 228283A68E2 for ; Fri, 17 Dec 2010 07:54:52 -0800 (PST) Received: by iyi42 with SMTP id 42so554276iyi.31 for ; Fri, 17 Dec 2010 07:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lBGpK48QXqdROQj3DSxjZXJcOjwwRUqzwd8QNqf3MsY=; b=a17kcxizIRtfBkycOs2zKU3qFn7NTRggjC9bYFxR46sqLqvlS3i4MQ3yI+yj45VxnH GbgeyrfXdqR0fOCnpriM6GhC1VH24VlPH2Y8w0ybPL4QwizmjPZLSvjS5pvEXYD1mrDU r4xp9M2TyI+1m0TDDtw1T76E10mo5tS5x6EFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=R42lsXjQAj0wQFr6QtQPpe/hForBu2e3y54tOGsTLcLLX9CKOZlSNs/Xqb6ZTdhwJl CtA8SR87E6Nemo7FOde0TcTP1pUa73xClCyWRsQwr51j2YypXjfQsnpN1wToJIGhlv52 7RPy26QTUZ4qsTYYHFAuuWTzUG7BKjJ0PdX8c= MIME-Version: 1.0 Received: by 10.231.11.204 with SMTP id u12mr920932ibu.109.1292601399247; Fri, 17 Dec 2010 07:56:39 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Fri, 17 Dec 2010 07:56:39 -0800 (PST) Date: Fri, 17 Dec 2010 10:56:39 -0500 X-Google-Sender-Auth: djDpOp1t7hg3JrLzPGBX6jIE3Ik Message-ID: From: Barry Leiba To: draft-cdmi-mediatypes.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: [apps-discuss] apps-team review of draft-cdmi-mediatypes-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 15:54:54 -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. Summary: The draft is pretty much ready to go, but there are quite a few minor items that really should be fixed. There's a pervasive number-agreement problem. Remember that "a set of X" is *singular*, even if there are many X, because the subject is "a set", not "50 X". If that's not what you want, you need to re-word. No major issues. Minor issues: 3.1, number agreement error OLD A CDMI object is the basic storage element in a CDMI system and are analogous to files within a filesystem. NEW A CDMI object is the basic storage element in a CDMI system and is analogous to a file within a filesystem. 3.1, JSON reference It seems odd to me to have a general reference to the JSON web site, followed immediately by a proper reference to the RFC that defines the format. I see no reason for the reference to the web site. Alternatively, if you want to cite the web site, maybe putting it inline would be better, like this: The object is represented in the CDMI interface in JSON format [RFC4627] (see the JSON web site at http://www.json.org/ for general information about JSON). 3.1, number agreement error OLD defines the JSON format. Each data object has a set of well-defined fields that include a single value and optional metadata. NEW, if the subject is "set" defines the JSON format. Each data object has a set of well-defined fields that includes a single value and optional metadata. NEW, if the subject is "a field" defines the JSON format. Each data object has a set of well-defined fields; each field includes a single value and optional metadata. 3.1, normative language ? OLD but the application/cdmi-object should be represented in the CDMI interface as defined in section 8 of the CDMI specification. NEW but the application/cdmi-object SHOULD be represented in the CDMI interface as defined in section 8 of the CDMI specification. 3.2, number agreement error OLD Container objects are the fundamental grouping of stored data within CDMI and is analogous to directories within a filesystem. NEW A container object is the fundamental grouping of stored data within CDMI and is analogous to a directory within a filesystem. 3.2, number agreement error OLD Each container has zero or more child objects and a set of well-defined fields that include standardized and optional metadata. NEW Each container has zero or more child objects and a set of well-defined fields that includes standardized and optional metadata. (Consider whether "includes" should be "represents".) 3.2, normative language ? OLD implementations are free to represent the container in amy form they choose, but the application/cdmi-container should be represented in the CDMI interface as defined in section 9 of the CDMI specification. NEW implementations are free to represent the container in amy form they choose, but the application/cdmi-container SHOULD be represented in the CDMI interface as defined in section 9 of the CDMI specification. 3.4, number agreement error OLD Capability objects are a special class of container object that allow a CDMI client to discover what subset of the CDMI standard is implemented by a CDMI provider. NEW Capability objects form a special class of container object that allows a CDMI client to discover what subset of the CDMI standard is implemented by a CDMI provider. 3.4, number agreement error OLD For each URI in a CDMI system, the set of interactions that the system is capable of performing against that URI are described by the presence of named "capabilities". NEW For each URI in a CDMI system, the set of interactions that the system is capable of performing against that URI is described by the presence of named "capabilities". 3.5, dangling subject error OLD If supported by the cloud storage system, cloud clients create the queue objects by using the same mechanism used to create data objects. NEW If queues are supported by the cloud storage system, cloud clients create the queue objects by using the same mechanism used to create data objects. 4, definition of "transport protocols" I have a bit of a problem, in general, with referring to HTTP and SMTP as "transports"; they are application protocols that sit above the transport layer, and they, themselves, use transport protocols such as TCP (and there's an experiment doing HTTP over SCTP). Maybe I'm alone in this concern, but I'd rather avoid that terminology. I also don't really see a need to mention SMTP (and not, say, BEEP or whatever). Why not this?: OLD The CDMI uses HTTP (RFC 2616) transport and does not make sense outside the HTTP realm. We do not expect the CDMI to use other transports like SMTP (RFC2821) or raw TCP (RFC 793) protocols. NEW The CDMI operates over HTTP (RFC 2616) and does not make sense outside the HTTP realm. We do not expect the CDMI to operate over other protocols, nor to use a transport protocol, such as TCP (RFC 793), directly. 6.1: You don't need to capitalize "confidentiality" in the first sentence. 6.1, I suggest this change: OLD CDMI does not contain any specific mechanisms and relies on transport mechanisms like https [RFC2818] for confidentiality and integrity of the messages across the network. NEW CDMI does not contain any specific mechanisms for this, and relies on mechanisms such as TLS (see https [RFC2818]) for confidentiality and integrity of the messages across the network. I'm also wondering whether 2818 should be a normative reference, rather than informative. I'm on the fence.... 6.2, missing comma; I had to read this three times to understand it. OLD If required applications should use appropriate URL authentication and authorization techniques. NEW If required, applications should use appropriate URL authentication and authorization techniques. (In the next sentence, "fine-grained" should be hyphenated.) 6.3; what does "to facilitate the access" mean? Please reword. 6.4; hyphen, commas, number agreement OLD JSON related security considerations described in RFC 4627 [RFC4627] applies. NEW JSON-related security considerations, described in RFC 4627 [RFC4627], apply. 7; a comma after "Faltstrom" would make this easier to understand. -- Barry Leiba From joelja@bogus.com Thu Dec 16 16:29:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17AD3A6A3E; Thu, 16 Dec 2010 16:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXphg1ZS4Rod; Thu, 16 Dec 2010 16:29:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 8B3063A6A25; Thu, 16 Dec 2010 16:29:38 -0800 (PST) Received: from dhcp-176.nokia.net (dhcp-176.nokia.net [192.103.16.176] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id oBH0UpdV066899 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Dec 2010 00:30:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4D0A5CA1.2090004@bogus.com> Date: Thu, 16 Dec 2010 10:38:25 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eliot Lear References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <4D06239A.60208@cisco.com> In-Reply-To: <4D06239A.60208@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:06 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 00:29:39 -0000 On 12/13/10 5:46 AM, Eliot Lear wrote: > > > On 12/13/10 1:14 PM, Carsten Bormann wrote: >> As a webapp developer, I want to control the user interface during authentication. >> Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. >> I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. >> HTML/CSS/JS lends itself well to providing such a friendly user interface. > > On the other hand, that's what you have today. What is it you want for > tomorrow? A picture of a monopoly boot everytime I long into bank of america. Nah that's what happens today, I'd like something a lot stonger that 50 odd mostly similar passwords and some inane questions about what school I went to and what my pet rat's name was. > Eliot > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From marsh@extendedsubset.com Thu Dec 16 11:31:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5B93A69C8; Thu, 16 Dec 2010 11:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaS+aehBc6ck; Thu, 16 Dec 2010 11:31:18 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 435043A69C7; Thu, 16 Dec 2010 11:31:17 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PTJZW-000DRV-CF; Thu, 16 Dec 2010 19:33:02 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8B07360C6; Thu, 16 Dec 2010 19:32:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/FJrTY9uCYiXUNsZ5gCCuFYP7jyQqh5RI= Message-ID: <4D0A6969.7010309@extendedsubset.com> Date: Thu, 16 Dec 2010 13:32:57 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: der Mouse References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:20 -0800 Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org Subject: Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 19:31:19 -0000 On 12/16/2010 12:27 PM, der Mouse wrote: > > Quite aside from memorizability, few-to-no humans are capable of > performing the cryptographic operations (large-number arithmetic, > usually) necessary to carry out certificate operations, at least not > with the required levels of reliability. (I can do multi-hundred-digit > arithmetic, yes, but not nearly either fast enough or free enough of > mistakes to be useful for the purpose.) Which is a good argument for it being an example of something a computer is better at. Many auth systems have a component which involves something humans are good at and computers are lousy at. > Certificates, at best, determine that some device which is capable of > performing the cryptographic operations has been given access to the > corresponding private data.... All passwords demonstrate is > that some device capable of injecting data into the comm channel in > question knows the password. That's a good way to describe it. > But passwords rarely lull people into > forgetting the difference. Pen-and-paper signatures work because people have thousands of years of history behind pen technology. It fits well the courtroom test "did you or did you not sign that document". It surely happens, but is extremely rare that someone who actually signed a contract would later claim that it was a forgery, or that their pen and paper were compromised by an attacker. >> For most systems, the vast majority of 'no's are not actual attacks. > > Are you sure of that? There are an awful lot of doorknob-rattlers out > there. Most of the login failures I see on my machines actually _are_ > attackers poking to see if I've made stupid mistakes. OK so there's a baseline attack rate for any given port number. If you use the system infrequently enough, attackers outweigh the legitimate users. But, for example, I personally mistype my password about 10 to 25% of the time. That's a correct 'authentication denied' scenario but it's not an attack. Systems with a meaningful amount of legitimate activity, and are not specially targeted for some reason, are going to have many more mistyped passwords than credible attacks. >> Yeah. How did the user select their password for the website in the >> first place, if not by an HTML form POST? > >> If it was good enough for the initial sign up, why should the web >> designer use something other than HTML form POST for the regular >> login? > > For all that that's rhetorical, there is an answer: because one occurs > only once while the other occurs many times. I bet for a lot of systems, people sign up once and try it out then go away and leave their accounts dormant. E.g., I might create an account to buy tickets for something and never go back. So why can't the attacker attack it that one time then? You've never signed up for a new account from a hotel or a public wifi? Even still, how do you convince a web designer that they must give up their HTML login form for security when they have an HTML login form to choose the password in the first place? - Marsh From masinter@adobe.com Fri Dec 17 09:45:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9F63A6975 for ; Fri, 17 Dec 2010 09:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u26vgl3laSOA for ; Fri, 17 Dec 2010 09:45:34 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id 67CDD3A697A for ; Fri, 17 Dec 2010 09:45:34 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTQuiGfl8w2k3Yz4SR44skSBzc/lJkPwi@postini.com; Fri, 17 Dec 2010 09:47:22 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oBHHke3f009472; Fri, 17 Dec 2010 09:46:40 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oBHHkxtm003352; Fri, 17 Dec 2010 09:46:59 -0800 (PST) Received: from excas01.corp.adobe.com (10.8.188.201) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Dec 2010 09:46:59 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by excas01.corp.adobe.com ([10.8.188.201]) with mapi; Fri, 17 Dec 2010 09:46:59 -0800 From: Larry Masinter To: Tim Bray , SM , Apps Discuss , "m8philli@uk.ibm.com" , "peaston@progress.com" , "derek.rokicki@softwareag.com" , "eric@tibco.com" , Alexey Melnikov , The IESG Date: Fri, 17 Dec 2010 09:47:48 -0800 Thread-Topic: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 Thread-Index: Acudfd5/7SCzBBNDTz+TU+YLUbd/mAAlFsjA 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 X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:38 -0800 Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 17:45:36 -0000 I'm wondering if the process for review of registration material should include a provision for incorporation of reviewer comments (or a pointer to them) in the registry itself. Larry -- http://larry.masinter.net -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Tim Bray Sent: Thursday, December 16, 2010 4:01 PM To: SM; Apps Discuss; m8philli@uk.ibm.com; peaston@progress.com; derek.roki= cki@softwareag.com; eric@tibco.com; Alexey Melnikov; The IESG Subject: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 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-merrick-jms-uri-10 Title: URI Scheme for Java(tm) Message Service 1.0 Reviewer: Tim Bray Review Date: Dec 16, 2010 Summary: The draft has some mechanical issues which are not show-stoppers. I have questions whether this ought to be an RFC since there seems very modest expectation of interoperability between implementations; why, then, an IETF RFC, which suggests that the resulting URIs should be useful for identification of resources on an internetworked scale. Major Issues: 1. the draft suggests that given a "jms:" URI, there is little expectation that, without checking on the value of the "variant" and for the presence of vendor-specific parameters, it can be used interoperably in more than one implementation. In which case, I have to wonder about the appropriateness of using a *Uniform* resource identifier for whatever purposes are contemplated for these things; no motivations or use-cases are provided. The last paragraph of section 1 is troubling. For convenience, I quote: <<<<< As a consequence of building upon an API, rather than a protocol, the utility of a "jms" URI depends on the context in which it is used. That context includes agreement on the same JMS provider or underlying protocol, agreement on how to look up endpoints (JNDI), and when using serialized Java object messages, sufficiently similar Java Class environments that serialized objects can be appropriately read and written. Users of this scheme need to establish the necessary shared context parts as just enumerated - a context which can span the globe, or merely a small local network. With that shared context, this URI scheme enables endpoint identification in a uniform way, and the means to connect to those endpoints. >>>> Given this, what are the advantages of having a *Uniform* resource identifier, if there is not much expectation of uniformity in implementations? 2. Section 3.3 says " If users plan switching between JMS vendors, they might also need to plan on regenerating resources that contain URIs in this vendor specific form"; this sharpens my concerns about the lack of interoperability... I'm getting the impression, reading this, that "jms:jndi" is probably quite interoperable, but the variants are maybe a back-door for vendor abuse. Minor Issues: 1. Section 1. Need references for terms like javax.jms.Destination for people who aren't familiar with Java pathname voodoo. 2. Section 4 para beginning "Each variant can have query parameters..." - did you consider separating the variant prefix from the rest of the parameter name with "." or some other syntax marker? I note that you use "jndi-" for another class of parameter names below. 3. Same paragraph. Should the variant be used as a prefix even if it's a vendor-supplied one starting with "vnd."? An example of this would be nice. 4. 4.1.1 and so on, should the draft impose any constraints on the syntax of these parameter values? Perhaps they are inherited from the referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I see that 4.1.3 does specify some syntax, albeit loosely; there are a lot of different syntaxes which may be used to specify " number between 0 and 9, inclusive". Are you OK with 0x3 or, for timeToLive, "1,500"? 5. 4.2.1 Perhaps a note prior to launching into all the parameters on syntax constraints, with, I'm assuming, normative references into the JMS spec? 6. 4.2.2 includes great gobs of Java code illustrating how to use such an endpoint. Does this not contradict with the assertion at the top of section 4 which says " Operations available on JMS destinations are fully and normatively defined by the JMS specification and as such, are out of scope for this URI specification"? In any case, 4.2.2 needs a bit of preparatory language explaining what it is. Is it normative behavior for implementations? Is it there for illustrative purposes? Is it required to use Java, or could I code something equivalent in C# or Ruby? A few paragraphs in there's a passing reference to "the following (non-normative) code..." 7. 4.3.1, see comments on 4.2.2 above. Is this description of programming practice normative, illustrative, or what? 8. Section 6, 3rd para: I haven't ever seen anything like the note about what an OASIS TC might be doing in an RFC before, but possibly I've just missed the examples. 9. Section 7, last para: "As described in Section 4, others can define additional variants"... there is no description in Section 4 of how to define additional variants. Also, while the language in the opening of the draft suggests that the set of variants is open-ended, this is the first explicit mention of this possibility that I encountered. Is there a registry? Oh, there it is in section 9.2. OK, I think that the beginning of the doc needs to say that the set of variants is open-ended and vendor-extensible. It also smells like a big huge honking interoperability hole. Nits: 1. Section 4 para 3, superfluous comma after "Both the variant". 2. Section 4 para beginning "Each variant can have query parameters..." - did you consider separating the variant prefix from the rest of the parameter name with "." or some other syntax marker? I note that you use "jndi-" for another class of parameter names below. 3. Section 4.1 I assume "shared" means "available in all variants"? If so, why not say so? 4. Section 4.1 first para, the word "property" suddenly appears for the first time. Is this a synonym of "parameter"? 5. Section 4.1.1 Lots of references here need to be turned into RFC style with square brackets 5. Same section, missing full stop after "following shared parameters". 6. 4.1.1 Probably more idiomatic of normative text to say, instead of "This MUST be", "The value of this parameter MUST be..." 7. 4.1.1 Missing full-stop at end. 8. 6, 2nd para: What's an "SPI"? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From mouse@Sparkle.Rodents-Montreal.ORG Thu Dec 16 10:25:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FE73A695C; Thu, 16 Dec 2010 10:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.592 X-Spam-Level: X-Spam-Status: No, score=-8.592 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+kGeUEiyEFF; Thu, 16 Dec 2010 10:25:54 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 156FD3A6953; Thu, 16 Dec 2010 10:25:53 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA03511; Thu, 16 Dec 2010 13:27:37 -0500 (EST) Date: Thu, 16 Dec 2010 13:27:37 -0500 (EST) From: der Mouse Message-Id: <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 16 Dec 2010 12:54:01 -0500 (EST) To: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org In-Reply-To: <4D0672F2.4070600@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:47 -0800 Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 18:25:55 -0000 >> * Certificates do not authenticate the user. They authenticate a >> device. > I don't think they do that exactly either. The client cert is > generally public, its private key is a secret like a password, but > one that's too hard to memorize. Quite aside from memorizability, few-to-no humans are capable of performing the cryptographic operations (large-number arithmetic, usually) necessary to carry out certificate operations, at least not with the required levels of reliability. (I can do multi-hundred-digit arithmetic, yes, but not nearly either fast enough or free enough of mistakes to be useful for the purpose.) Certificates, at best, determine that some device which is capable of performing the cryptographic operations has been given access to the corresponding private data. This is close enough to authenticating a user to be useful for many purposes, but it is not the same thing. Of course, the same is true of passwords. All passwords demonstrate is that some device capable of injecting data into the comm channel in question knows the password. But passwords rarely lull people into forgetting the difference. > For most systems, the vast majority of 'no's are not actual attacks. Are you sure of that? There are an awful lot of doorknob-rattlers out there. Most of the login failures I see on my machines actually _are_ attackers poking to see if I've made stupid mistakes. > Yeah. How did the user select their password for the website in the > first place, if not by an HTML form POST? > If it was good enough for the initial sign up, why should the web > designer use something other than HTML form POST for the regular > login? For all that that's rhetorical, there is an answer: because one occurs only once while the other occurs many times. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse@Sparkle.Rodents-Montreal.ORG Thu Dec 16 12:00:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC0A3A69C5; Thu, 16 Dec 2010 12:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.7 X-Spam-Level: X-Spam-Status: No, score=-8.7 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuSzAo7VvG49; Thu, 16 Dec 2010 12:00:29 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 2665E3A6A61; Thu, 16 Dec 2010 12:00:20 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA04308; Thu, 16 Dec 2010 15:02:04 -0500 (EST) Date: Thu, 16 Dec 2010 15:02:04 -0500 (EST) From: der Mouse Message-Id: <201012162002.PAA04308@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 16 Dec 2010 14:44:07 -0500 (EST) To: Marsh Ray , apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org In-Reply-To: <4D0A6969.7010309@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> <4D0A6969.7010309@extendedsubset.com> X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:55 -0800 Subject: Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 20:00:31 -0000 > You've never signed up for a new account from a hotel or a public > wifi? I don't think so. Most certainly not for an account of nontrivial value (see below) without something at least as strong as ssh securing the channel from a computer I trust (which is a subset of computers I own and administer). >> For all that that's rhetorical, there is an answer: because [initial >> signup] occurs only once while [login] occurs many times. > I bet for a lot of systems, people sign up once and try it out then > go away and leave their accounts dormant. You quite likely are right. But in that case the account clearly is of little value to the holder, so I have trouble getting too worried. :) > Even still, how do you convince a web designer that they must give up > their HTML login form for security when they have an HTML login form > to choose the password in the first place? Personally, I don't. I mostly don't bother with Web stuff at all - you may note that what I've said here is almost entirely non-Web-specific - and _never_ do anything involving signups or the like "online" (meaning, on the Web; I have done such things unsecured over the Internet, such as creating a login on nethack.alt.org or creating characters on muds - these are examples of accounts of trivial value). But if someone were to argue that way with me, I'd basically just shrug and let it go as "I pointed out the issues; if you want to ignore them you may be right or you may get burned, and, if the latter, I feel no responsibility for it". /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From tim-research@sentinelchicken.org Thu Dec 16 12:47:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FE33A696C for ; Thu, 16 Dec 2010 12:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITvMMO8btX4E for ; Thu, 16 Dec 2010 12:47:06 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 81B9E3A69CC for ; Thu, 16 Dec 2010 12:47:06 -0800 (PST) Received: (qmail 6686 invoked from network); 16 Dec 2010 20:58:24 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 16 Dec 2010 20:58:24 -0000 Received: (qmail 17024 invoked from network); 16 Dec 2010 20:52:27 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 16 Dec 2010 20:52:27 -0000 Received: (nullmailer pid 10758 invoked by uid 1000); Thu, 16 Dec 2010 20:48:49 -0000 Date: Thu, 16 Dec 2010 12:48:49 -0800 From: Tim To: Marsh Ray Message-ID: <20101216204849.GX5009@sentinelchicken.org> References: <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> <4D0A6969.7010309@extendedsubset.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D0A6969.7010309@extendedsubset.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Fri, 17 Dec 2010 14:12:09 -0800 Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, der Mouse , saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 20:47:06 -0000 > Even still, how do you convince a web designer that they must give > up their HTML login form for security when they have an HTML login > form to choose the password in the first place? This is a good point. Something that may need to be considered in any transition plan away from form+cookie auth. Should some HTTP Authentication mechanism to sign up for new accounts and change passwords? tim From dhc@dcrocker.net Fri Dec 17 14:46:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C86B3A6BBF for ; Fri, 17 Dec 2010 14:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsNbSri79Zbx for ; Fri, 17 Dec 2010 14:46:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B18903A69B8 for ; Fri, 17 Dec 2010 14:46:49 -0800 (PST) Received: from [192.168.1.15] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBHMmS9c030722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 14:48:34 -0800 Message-ID: <4D0BE8B6.2040507@dcrocker.net> Date: Fri, 17 Dec 2010 14:48:22 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julian Reschke References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com> <4D0A4F0E.7090604@dcrocker.net> <4D0A8B14.6080803@gmx.de> In-Reply-To: <4D0A8B14.6080803@gmx.de> 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]); Fri, 17 Dec 2010 14:48:34 -0800 (PST) Cc: "apps-discuss@ietf.org" , Paul Overell Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 17 Dec 2010 22:46:51 -0000 On 12/16/2010 1:56 PM, Julian Reschke wrote: > On 16.12.2010 18:40, Dave CROCKER wrote: >>> 1*3#(";")element indicates the list of elements separated by >> >> Question to the audience: are the parentheses needed here? The quotation >> marks would seem to provide sufficient lexical uniqueness, but this is >> the sort of nuance I usually get wrong. >> ... > > Parentheses please. In the form of the specifications in that part of the document, that means that the parentheses are terminals. They are required to be used in the construct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Dec 18 22:56:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5393A67A1 for ; Sat, 18 Dec 2010 22:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ifatEbR045t for ; Sat, 18 Dec 2010 22:56:17 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D41733A679C for ; Sat, 18 Dec 2010 22:56:17 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.131]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oBJ6vwho006335; Sat, 18 Dec 2010 22:58:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1292741887; bh=zF/WsRWgbDQ+78lQejN+CpzHeM4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cGUIIXPbMnVPd1m1S4zU8EGJCEqCSk3agyfKqDvyELAuh1Cgxi09eCgGPsIOp+hW1 RS9qMJSGGXwn+BN8CuH4G1/OZVSEVGqfDZAdOq5Nmc6Eyi1jDNRGLOU7XujewhqvZa 4V9tYHzlulOZpInLzB0H7TpOVD9Sr5vMD3nk3PzQ= Message-Id: <6.2.5.6.2.20101218221926.0a678da0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Dec 2010 22:57:44 -0800 To: Larry Masinter From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 06:56:20 -0000 Hi Larry, [I trimmed the Cc down to the Apps-discuss mailing list as the discussion is about process] At 09:47 17-12-10, Larry Masinter wrote: >I'm wondering if the process for review of registration material >should include a provision for incorporation of reviewer comments >(or a pointer to them) in the registry itself. A registration request is generally reviewed on a mailing list dedicated for that purpose. There is, for example, a Uri-review mailing list where URI schemes are discussed. If the process for review requires the inclusion of material with reviewer comments, it is like writing an Internet-Draft to summarize the discussion. This is akin to the Document Shepherding Process. That output of that process rarely provides a summary of the views. The registry documents the decision and not the pros and cons of the registration proposal. That's its purpose. Regards, S. Moonesamy From adrien@qbik.com Sun Dec 19 03:10:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2EB3A6853; Sun, 19 Dec 2010 03:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[AWL=-3.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZWRmsCQ7a2; Sun, 19 Dec 2010 03:10:17 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 048063A6852; Sun, 19 Dec 2010 03:10:15 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3109)) with SMTP id <0017864197@smtp.qbik.com>; Mon, 20 Dec 2010 00:12:02 +1300 Message-ID: <4D0DE882.50201@qbik.com> Date: Mon, 20 Dec 2010 00:12:02 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Dec 2010 08:25:22 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 11:10:18 -0000
I think we need to go a bit further and consider the issue of trust.

one problem with delegating account-holding back to a domain under the control of the account-holder, is you have no trust.  I could be hacker@hackyou.com or spammer@spamyou.com.  I can set up whatever account I like.  Websites have no information about whether I'm trustworthy or not, and have to build up their own individual profile of me.

To be really useful, the account-holding must be with a trusted independent organisation able to be relied on by other websites. 

The organisation then has the opportunity to add value by

a) verifying the true identity of the account holder
b) maintaining reputation information about the account holder
c) revoking abusive accounts.

Ends up looking a lot like X.509 certificate infrastructure.  Imagine if everyone needed a client certificate to send any mail.  We'd have no spam.

Of course these sorts of concepts are completely unpalatable to many people on account of privacy issues. Some of these activities are the sort of things that governments should really be doing (and already are in many cases).

Solving this problem has implications for all internet use, not just HTTP.

Regards

Adrien

On 19/12/2010 5:48 a.m., Phillip Hallam-Baker wrote:
I think that we need to distinguish between an authentication mechanism and an authentication infrastructure.

Part of the problem with HTTP authentication is that it was quickly superseded by HTML based authentication mechanisms. And these in turn suffer from the problem that password authentication fails when people share their passwords across sites, which of course they have no choice but to do when every stupid web site requires them to create yet another stupid account. 

Since Digest Authentication became an RFC, I don't think there has ever been more than about 6 weeks elapsed without someone suggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when the major flaw in the authentication infrastructure is the lack of an authentication infrastructure. The original reason for designing Digest the way that I did was that public key cryptography was encumbered. Had public key cryptography been available, I would have used it.

By authentication infrastructure, I mean an infrastructure that allows the user to employ the same credentials at multiple sites with minimal or no user interaction. I do not mean a framework that allows for the use of 20 different protocols for verifying a username and password.


We do have almost as many proposals for federated authentication as authentication schemes of course. But each time there seems to be an obsession with things that technocrats obsess about and at best contempt for the actual user.

OpenID almost succeeded. But why on earth did we have to adopt URIs as the means of representing a user account? And why was it necessary to design a spec around the notion that what mattered most in the design of the spec was the ability to hack together an account manager using obsolete versions of common scripting languages?

Another feature of that debate I cannot understand is why we had to start talking about 'identity' as if it was some new and somehow profound problem that had only just been discovered.


There is of course a standard for representing federated user accounts that has already emerged on the net. And once that is realized, the technical requirements of a solution become rather obvious.

As Web sites discover that their account holders cannot remember their username, most have adopted email addresses as account identifiers. That is what we should use as the basis for federated web authentication. 


So if the user account identifier looks like username@example.com, how does an entity verify that a purported user has a valid claim to that account?

The obvious mechanism in my view is to use DNS based discovery of an authentication service. For example, we might use the ESRV scheme I have been working on:

_auth._ws.example.com  ESRV 0 prot "_saml._ws"
_auth._ws.example.com  ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols may be used to resolve authentication requests.


One major advantage of this approach is that it makes it easy for sites to move to using the new federated auth scheme. Most sites already store an email address that is used to validate the account. 


The actual mechanism by which the authentication claim is verified is not very interesting, nor does it particularly need to be standardized. What does require standardization is the ability to embed the protocol in 'the Web' in a fluent and secure manner.

Here is how I suggest this be achieved:

1) HTTP header

The Web browser attaches an offer of authentication by means  of an account attached to a specific domain to (potentially) every request:

Auth-N: domain=example.com

If the server does not support Auth-N, the header will simply be ignored. Otherwise  the server can ask for automated authentication.


2) HTTP Response

If the server decides to use the authentication mechanism, it responds with information that tells the client what level of authentication is required. For example, a bank might require a 2 factor scheme. There is going to be at a minimum a nonce.

Auth-N: snonce=<128bits>



3) HTTP Request

It should be possible for the client to prove that it has ownership of the authentication token corresponding to the account. 

It is not necessarily the case that the account owner wants to reveal to the site all their information. For example, it may not even want the site to know the account name. This is all fairly easy to set up using symmetric techniques.

Auth-N: domain=example.com; blindedaccount=<> snonce=<128bits>; cnonce=<128bits>


One feature that the OpenID work has highlighted the need for is some form of user directed account manager. If the user is going to be in control of this process, they need to be able to specify what information is made available to specific sites.


Conclusion:

I think that what we require here is not yet another authentication framework or protocol. What we need is the glue to bind it into an infrastructure that makes it useful.

The most important design decision is to make use of RFC822 email address format as the format for federated authentication accounts. 

Once that decision is made, the rest will simply fall out of stating the requirements precisely. 

The risk here is that yet again we end up redo-ing the parts that we know how to build rather than focus on the real problem which is fitting them together. 

Above all, the user has to be the first priority in any design. 

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
From hallam@gmail.com Sat Dec 18 08:46:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F373A6B32; Sat, 18 Dec 2010 08:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV17309iSGMG; Sat, 18 Dec 2010 08:46:56 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6A1333A6B31; Sat, 18 Dec 2010 08:46:55 -0800 (PST) Received: by ywk9 with SMTP id 9so813314ywk.31 for ; Sat, 18 Dec 2010 08:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ijwI0GcNw4czVPTgUUhQd5LnD/RhxnVpgX9bs7S46fo=; b=f96paZmYl+d36RVMk/yETNHaI+A0ENWSmj9gEcmHadBN3MOj2LNYl7KGFFCjRSpSZl qzAVYfc3oq62xCBzMEpSAqxmVjTbNL8qfBAuJIwDLwT9JR+FkXDZEHKr8uuAO/foYCMT uK8nrOVgxXkHnHcly1gWX0vlutoC5GSyY4nQs= 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; b=W15I6zVxvEU7S1jlvsHCHLRXhE4NgdTTYqYbij3m0QzKNxBHgjmx+2rjdXGf4nkr1H VxhhU7heQRETf1mM/zhx2oVrjmblBwQgMTEz4MPWcVnuz0oBbUUzN02nTGeP11GS4djp 4xqDuMZueByWSToL4nYZwhauFryx8cPJdLEUc= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr1380812ank.1.1292690922503; Sat, 18 Dec 2010 08:48:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 18 Dec 2010 08:48:42 -0800 (PST) In-Reply-To: <2229.1292253372.639419@puncture> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> Date: Sat, 18 Dec 2010 16:48:42 +0000 Message-ID: From: Phillip Hallam-Baker To: Common Authentication Technologies - Next Generation , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , General discussion of application-layer protocols , "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=00163662e65b3d7fce0497b20fd7 X-Mailman-Approved-At: Sun, 19 Dec 2010 08:25:32 -0800 Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 16:46:57 -0000 --00163662e65b3d7fce0497b20fd7 Content-Type: text/plain; charset=ISO-8859-1 I think that we need to distinguish between an authentication mechanism and an authentication infrastructure. Part of the problem with HTTP authentication is that it was quickly superseded by HTML based authentication mechanisms. And these in turn suffer from the problem that password authentication fails when people share their passwords across sites, which of course they have no choice but to do when every stupid web site requires them to create yet another stupid account. Since Digest Authentication became an RFC, I don't think there has ever been more than about 6 weeks elapsed without someone suggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when the major flaw in the authentication infrastructure is the lack of an authentication infrastructure. The original reason for designing Digest the way that I did was that public key cryptography was encumbered. Had public key cryptography been available, I would have used it. By authentication infrastructure, I mean an infrastructure that allows the user to employ the same credentials at multiple sites with minimal or no user interaction. I do not mean a framework that allows for the use of 20 different protocols for verifying a username and password. We do have almost as many proposals for federated authentication as authentication schemes of course. But each time there seems to be an obsession with things that technocrats obsess about and at best contempt for the actual user. OpenID almost succeeded. But why on earth did we have to adopt URIs as the means of representing a user account? And why was it necessary to design a spec around the notion that what mattered most in the design of the spec was the ability to hack together an account manager using obsolete versions of common scripting languages? Another feature of that debate I cannot understand is why we had to start talking about 'identity' as if it was some new and somehow profound problem that had only just been discovered. There is of course a standard for representing federated user accounts that has already emerged on the net. And once that is realized, the technical requirements of a solution become rather obvious. As Web sites discover that their account holders cannot remember their username, most have adopted email addresses as account identifiers. That is what we should use as the basis for federated web authentication. So if the user account identifier looks like username@example.com, how does an entity verify that a purported user has a valid claim to that account? The obvious mechanism in my view is to use DNS based discovery of an authentication service. For example, we might use the ESRV scheme I have been working on: _auth._ws.example.com ESRV 0 prot "_saml._ws" _auth._ws.example.com ESRV 0 prot "_xcat._ws" Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols may be used to resolve authentication requests. One major advantage of this approach is that it makes it easy for sites to move to using the new federated auth scheme. Most sites already store an email address that is used to validate the account. The actual mechanism by which the authentication claim is verified is not very interesting, nor does it particularly need to be standardized. What does require standardization is the ability to embed the protocol in 'the Web' in a fluent and secure manner. Here is how I suggest this be achieved: 1) HTTP header The Web browser attaches an offer of authentication by means of an account attached to a specific domain to (potentially) every request: Auth-N: domain=example.com If the server does not support Auth-N, the header will simply be ignored. Otherwise the server can ask for automated authentication. 2) HTTP Response If the server decides to use the authentication mechanism, it responds with information that tells the client what level of authentication is required. For example, a bank might require a 2 factor scheme. There is going to be at a minimum a nonce. Auth-N: snonce=<128bits> 3) HTTP Request It should be possible for the client to prove that it has ownership of the authentication token corresponding to the account. It is not necessarily the case that the account owner wants to reveal to the site all their information. For example, it may not even want the site to know the account name. This is all fairly easy to set up using symmetric techniques. Auth-N: domain=example.com; blindedaccount=<> snonce=<128bits>; cnonce=<128bits> One feature that the OpenID work has highlighted the need for is some form of user directed account manager. If the user is going to be in control of this process, they need to be able to specify what information is made available to specific sites. Conclusion: I think that what we require here is not yet another authentication framework or protocol. What we need is the glue to bind it into an infrastructure that makes it useful. The most important design decision is to make use of RFC822 email address format as the format for federated authentication accounts. Once that decision is made, the rest will simply fall out of stating the requirements precisely. The risk here is that yet again we end up redo-ing the parts that we know how to build rather than focus on the real problem which is fitting them together. Above all, the user has to be the first priority in any design. --00163662e65b3d7fce0497b20fd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that we need to distinguish between an authentication mechanism and= an authentication infrastructure.

Part of the problem with HTTP authentication is that it= was quickly=A0superseded by HTML based authentication mechanisms. And thes= e in turn suffer from the problem that password authentication fails when p= eople share their passwords across sites, which of course they have no choi= ce but to do when every stupid web site requires them to create yet another= stupid account.=A0

Since Digest Authentication became an RFC, I don't = think there has ever been more than about 6 weeks elapsed without someone s= uggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which i= s of course pointless when the major flaw in the authentication infrastruct= ure is the lack of an authentication infrastructure. The original reason fo= r designing Digest the way that I did was that public key cryptography was = encumbered. Had public key cryptography been available, I would have used i= t.

By authentication infrastructure, I mean an infrastruct= ure that allows the user to employ the same credentials at multiple sites w= ith minimal or no user interaction. I do not mean a framework that allows f= or the use of 20 different protocols for verifying a username and password.=


We do have almost as many proposals for = federated authentication as authentication schemes of course. But each time= there seems to be an obsession with things that technocrats obsess about a= nd at best contempt for the actual user.

OpenID almost succeeded. But why on earth did we have t= o adopt URIs as the means of representing a user account? And why was it ne= cessary to design a spec around the notion that what mattered most in the d= esign of the spec was the ability to hack together an account manager using= obsolete versions of common scripting languages?

Another feature of that debate I cannot understand is w= hy we had to start talking about 'identity' as if it was some new a= nd somehow profound problem that had only just been discovered.


There is of course a standard for representin= g federated user accounts that has already emerged on the net. And once tha= t is realized, the technical requirements of a solution become rather obvio= us.

As Web sites discover that their account holders cannot= remember their username, most have adopted email addresses as account iden= tifiers. That is what we should use as the basis for federated web authenti= cation.=A0


So if the user account identifier looks = like username@example.com, how = does an entity verify that a purported user has a valid claim to that accou= nt?

The obvious mechanism in my view is to use DNS based di= scovery of an authentication service. For example, we might use the ESRV sc= heme I have been working on:

_auth._ws.example.com =A0ESRV 0 prot "_saml._ws"=
_auth._ws.ex= ample.com =A0ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in XML)= protocols may be used to resolve authentication requests.


One major advantage of this approach is = that it makes it easy for sites to move to using the new federated auth sch= eme. Most sites already store an email address that is used to validate the= account.=A0


The actual mechanism by which the authen= tication claim is verified is not very interesting, nor does it particularl= y need to be standardized. What does require standardization is the ability= to embed the protocol in 'the Web' in a fluent and secure manner.<= /div>

Here is how I suggest this be achieved:

<= /div>
1) HTTP header

The Web browser attaches = an offer of authentication by means =A0of an account attached to a specific= domain to (potentially) every request:

Auth-N: domain=3Dexample= .com

If the server does not support Auth-N, th= e header will simply be ignored. Otherwise =A0the server can ask for automa= ted authentication.


2) HTTP Response

If the server decides to use the authentication mechanism, it responds wi= th information that tells the client what level of authentication is requir= ed. For example, a bank might require a 2 factor scheme. There is going to = be at a minimum a nonce.

Auth-N: snonce=3D<128bits>= ;



3) HTTP Request

It should be possible for the client to prove that i= t has ownership of the authentication token corresponding to the account.= =A0

It is not necessarily the case that the account owner w= ants to reveal to the site all their information. For example, it may not e= ven want the site to know the account name. This is all fairly easy to set = up using symmetric techniques.

Auth-N: domain=3Dexample.com; blindedaccount=3D<> snonce=3D<12= 8bits>; cnonce=3D<128bits>


One feature that the OpenID work has highlighted the need for is some form= of user directed account manager. If the user is going to be in control of= this process, they need to be able to specify what information is made ava= ilable to specific sites.


Conclusion:

I t= hink that what we require here is not yet another authentication framework = or protocol. What we need is the glue to bind it into an infrastructure tha= t makes it useful.

The most important design decision is to make use of RF= C822 email address format as the format for federated authentication accoun= ts.=A0

Once that decision is made, the rest will s= imply fall out of stating the requirements precisely.=A0

The risk here is that yet again we end up redo-ing the = parts that we know how to build rather than focus on the real problem which= is fitting them together.=A0

Above all, the user = has to be the first priority in any design.=A0
--00163662e65b3d7fce0497b20fd7-- From nathan@webr3.org Sun Dec 19 06:12:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAB13A6452 for ; Sun, 19 Dec 2010 06:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VElUis9n-sHb for ; Sun, 19 Dec 2010 06:12:02 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 83D9A3A6405 for ; Sun, 19 Dec 2010 06:12:02 -0800 (PST) Received: (qmail 8465 invoked from network); 19 Dec 2010 13:47:14 -0000 Received: from unknown (86.156.126.71) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 19 Dec 2010 13:47:13 -0000 Message-ID: <4D0E0CDA.6030605@webr3.org> Date: Sun, 19 Dec 2010 13:47:06 +0000 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adrien de Croy References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: <4D0DE882.50201@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Dec 2010 08:25:39 -0800 Cc: General discussion of application-layer protocols , websec , foaf-protocols , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , Story Henry , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nathan@webr3.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 14:12:04 -0000 Hi Adrien, All, What you describe sounds very much like WebID Protocol (formerly FOAF+SSL) - there's an incubator group just starting at the W3C [1] although the protocol [2] has been under development for some time. Essentially it leverages X509 certificates on the client side, which contains an identifier (in the form of a URI) which can then be dereferenced to machine readable data (containing the public key from the x509 and any other data the entity wishes to expose), it serves as decentralized stateless authentication / identification, compatible with and built on the deployed stack of internet technologies, and further enables all kinds of trust & reputation hooks. cc'd: Henry Story, foaf-protocols [1] http://bblfish.net/tmp/2010/12/15/webid-charter-draft.html [2] http://getwebid.org/spec/drafts/ED-webid-20100809/index.html Best, Nathan Adrien de Croy wrote: > I think we need to go a bit further and consider the issue of trust. > > one problem with delegating account-holding back to a domain under the control > of the account-holder, is you have no trust. I could be hacker@hackyou.com or > spammer@spamyou.com. I can set up whatever account I like. Websites have no > information about whether I'm trustworthy or not, and have to build up their own > individual profile of me. > > To be really useful, the account-holding must be with a trusted independent > organisation able to be relied on by other websites. > > The organisation then has the opportunity to add value by > > a) verifying the true identity of the account holder > b) maintaining reputation information about the account holder > c) revoking abusive accounts. > > Ends up looking a lot like X.509 certificate infrastructure. Imagine if > everyone needed a client certificate to send any mail. We'd have no spam. > > Of course these sorts of concepts are completely unpalatable to many people on > account of privacy issues. Some of these activities are the sort of things that > governments should really be doing (and already are in many cases). > > Solving this problem has implications for all internet use, not just HTTP. > > Regards > > Adrien > > On 19/12/2010 5:48 a.m., Phillip Hallam-Baker wrote: >> I think that we need to distinguish between an authentication mechanism and an >> authentication infrastructure. >> >> Part of the problem with HTTP authentication is that it was quickly superseded >> by HTML based authentication mechanisms. And these in turn suffer from the >> problem that password authentication fails when people share their passwords >> across sites, which of course they have no choice but to do when every stupid >> web site requires them to create yet another stupid account. >> >> Since Digest Authentication became an RFC, I don't think there has ever been >> more than about 6 weeks elapsed without someone suggesting to me that we >> include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when >> the major flaw in the authentication infrastructure is the lack of an >> authentication infrastructure. The original reason for designing Digest the >> way that I did was that public key cryptography was encumbered. Had public key >> cryptography been available, I would have used it. >> >> By authentication infrastructure, I mean an infrastructure that allows the >> user to employ the same credentials at multiple sites with minimal or no user >> interaction. I do not mean a framework that allows for the use of 20 different >> protocols for verifying a username and password. >> >> >> We do have almost as many proposals for federated authentication as >> authentication schemes of course. But each time there seems to be an obsession >> with things that technocrats obsess about and at best contempt for the actual >> user. >> >> OpenID almost succeeded. But why on earth did we have to adopt URIs as the >> means of representing a user account? And why was it necessary to design a >> spec around the notion that what mattered most in the design of the spec was >> the ability to hack together an account manager using obsolete versions of >> common scripting languages? >> >> Another feature of that debate I cannot understand is why we had to start >> talking about 'identity' as if it was some new and somehow profound problem >> that had only just been discovered. >> >> >> There is of course a standard for representing federated user accounts that >> has already emerged on the net. And once that is realized, the technical >> requirements of a solution become rather obvious. >> >> As Web sites discover that their account holders cannot remember their >> username, most have adopted email addresses as account identifiers. That is >> what we should use as the basis for federated web authentication. >> >> >> So if the user account identifier looks like username@example.com >> , how does an entity verify that a purported user >> has a valid claim to that account? >> >> The obvious mechanism in my view is to use DNS based discovery of an >> authentication service. For example, we might use the ESRV scheme I have been >> working on: >> >> _auth._ws.example.com ESRV 0 prot "_saml._ws" >> _auth._ws.example.com ESRV 0 prot "_xcat._ws" >> >> Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols >> may be used to resolve authentication requests. >> >> >> One major advantage of this approach is that it makes it easy for sites to >> move to using the new federated auth scheme. Most sites already store an email >> address that is used to validate the account. >> >> >> The actual mechanism by which the authentication claim is verified is not very >> interesting, nor does it particularly need to be standardized. What does >> require standardization is the ability to embed the protocol in 'the Web' in a >> fluent and secure manner. >> >> Here is how I suggest this be achieved: >> >> 1) HTTP header >> >> The Web browser attaches an offer of authentication by means of an account >> attached to a specific domain to (potentially) every request: >> >> Auth-N: domain=example.com >> >> If the server does not support Auth-N, the header will simply be ignored. >> Otherwise the server can ask for automated authentication. >> >> >> 2) HTTP Response >> >> If the server decides to use the authentication mechanism, it responds with >> information that tells the client what level of authentication is required. >> For example, a bank might require a 2 factor scheme. There is going to be at a >> minimum a nonce. >> >> Auth-N: snonce=<128bits> >> >> >> >> 3) HTTP Request >> >> It should be possible for the client to prove that it has ownership of the >> authentication token corresponding to the account. >> >> It is not necessarily the case that the account owner wants to reveal to the >> site all their information. For example, it may not even want the site to know >> the account name. This is all fairly easy to set up using symmetric techniques. >> >> Auth-N: domain=example.com ; blindedaccount=<> >> snonce=<128bits>; cnonce=<128bits> >> >> >> One feature that the OpenID work has highlighted the need for is some form of >> user directed account manager. If the user is going to be in control of this >> process, they need to be able to specify what information is made available to >> specific sites. >> >> >> Conclusion: >> >> I think that what we require here is not yet another authentication framework >> or protocol. What we need is the glue to bind it into an infrastructure that >> makes it useful. >> >> The most important design decision is to make use of RFC822 email address >> format as the format for federated authentication accounts. >> >> Once that decision is made, the rest will simply fall out of stating the >> requirements precisely. >> >> The risk here is that yet again we end up redo-ing the parts that we know how >> to build rather than focus on the real problem which is fitting them together. >> >> Above all, the user has to be the first priority in any design. > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > From paul@bayleaf.org.uk Sun Dec 19 08:46:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347203A6826 for ; Sun, 19 Dec 2010 08:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prlUEBRDdrUK for ; Sun, 19 Dec 2010 08:46:40 -0800 (PST) Received: from mail.o2.co.uk (sidious.london.02.net [82.132.130.152]) by core3.amsl.com (Postfix) with ESMTP id 1DD4B3A6823 for ; Sun, 19 Dec 2010 08:46:40 -0800 (PST) Received: from paul.bayleaf.org.uk (188.221.115.62) by mail.o2.co.uk (8.5.119.05) (authenticated as paul_overell) id 4D035EC301FCBE21 for apps-discuss@ietf.org; Sun, 19 Dec 2010 17:06:52 +0000 Message-ID: Date: Sun, 19 Dec 2010 16:46:58 +0000 To: apps-discuss@ietf.org From: Paul Overell References: <4D028FE0.20906@bbiw.net> <4D03A25E.9060709@dcrocker.net> <4D05EDB8.6090901@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAC7A@SISPE7MB1.commscope.com> <4D071CCB.5040509@gmx.de> <8B0A9FCBB9832F43971E38010638454F03F34FAE12@SISPE7MB1.commscope.com> <4D0A39C0.2070308@gmail.com> <4D0A4F0E.7090604@dcrocker.net> <4D0A8B14.6080803@gmx.de> <4D0BE8B6.2040507@dcrocker.net> In-Reply-To: <4D0BE8B6.2040507@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii User-Agent: Turnpike/6.07-M (<1PLohZL5GCIk4mjZxNHp0TcHBS>) Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 16:49:42 -0000 In message <4D0BE8B6.2040507@dcrocker.net>, Dave CROCKER writes Hi, A few comments on 1) > (*LWS element n*m(*LWS separator *LWS element)) > > It is obvious that this construction is too simplified and bulky. This is a subjective statement and does not belong in a formal specification. It does not make the case for this proposal. I do not understand what is "too simplified" in the above. Here is an ABNF example from RFC5322 > mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list Here is the same with the proposed notation mailbox-list = 1*#(",")mailbox / obs-mbox-list Is it clearer? It it easier to understand? The proposed syntax may (slightly) reduce bulk, but by putting the "," before the mailbox I think it also reduces clarity. The original # list notation from RFC822 was dropped from RFC2234, AFAIR, because it was deemed to be too specialized and so easily replaced with the other constructs. 2) > The ABNF for this construction is: > > n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element)) > n#(a)(element) = (n_1(element 1*SP a) element) > n = *DIGIT ;the minimum amount of elements > m = *DIGIT ;the maximum amount of elements > n_1 = {n-1} > n_1 =/ *DIGIT > m_1 = {m-1} > m_1 =/ *DIGIT > u = > f = {u-(u-1)} > f =/ 1*DIGIT ;will be 0 if no elements are used > ;and 1 if at least one is used The above is *NOT* the ABNF of the proposed construct. Instead it tries to define the semantics in term of ABNF extended with {}, but I find it confusing and overly complex. Nor it is syntactically correct ABNF (illegal rulenames, undefined). Instead, the formal syntax for the proposal should extend the existing RFC5234 syntax for a repetition using the =/ operator. The semantics should be specified in prose. Something like: repetition =/ [repeat] list-spec element list-spec = "#" separator separator = group >> >> Parentheses please. > > >In the form of the specifications in that part of the document, that >means that the parentheses are terminals. They are required to be used >in the construct. > >d/ > Note that using for the separator ensures the use of parentheses. 3) One of the design decisions we made for ABNF in RFC2234, still preserved in RFC5234 para 3.1 is: > NOTE: > > This specification for ABNF does not provide for implicit > specification of linear white space. > > Any grammar that wishes to permit linear white space around > delimiters or string segments must specify it explicitly. This proposal seems to break this design decision by re-introducing implicit linear white space. > n*m#(a)(element) = (n_1*m_1(element 1*SP a) f(element)) The above seems to require at least one space before the separator. Whereas the examples talks of "OPTIONAL spaces". In summary, if this proposal is to be adopted then I think the following need to be addressed: 1) The case needs to be made for adding the proposed construct. ABNF can already define lists, is a more succinct specialized syntax really necessary? 2) The formal syntax should be given as an extension to that given in RFC5234. The semantics should be expressed in prose. 3) The RFC5234 design decision to have no implicit white space should be respected. Regards -- Paul Overell From adrien@qbik.com Sun Dec 19 14:04:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7373A6914; Sun, 19 Dec 2010 14:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-3.338, BAYES_00=-2.599, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQQ--g7lqNuP; Sun, 19 Dec 2010 14:04:45 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 834BF3A6915; Sun, 19 Dec 2010 14:04:43 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3109)) with SMTP id <0017865124@smtp.qbik.com>; Mon, 20 Dec 2010 11:06:32 +1300 Message-ID: <4D0E81E8.8010000@qbik.com> Date: Mon, 20 Dec 2010 11:06:32 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Dec 2010 08:30:31 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:04:46 -0000 On 20/12/2010 10:49 a.m., Ben Laurie wrote: > On 19 December 2010 11:12, Adrien de Croy wrote: >> Imagine if >> everyone needed a client certificate to send any mail. We'd have no spam. > Nonsense. We'd just restrict spam to owned machines, of which there > are only a few tens or hundreds of milliions, if we're lucky. only if no-one revoked their certificate. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From benl@google.com Sun Dec 19 13:48:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB043A6904 for ; Sun, 19 Dec 2010 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.371 X-Spam-Level: X-Spam-Status: No, score=-105.371 tagged_above=-999 required=5 tests=[AWL=-4.607, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_OBFU_MILLIONS=1.213, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyLpdyV5YU9u for ; Sun, 19 Dec 2010 13:48:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id ED1F63A68FD for ; Sun, 19 Dec 2010 13:48:06 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oBJLnve9001913 for ; Sun, 19 Dec 2010 13:49:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292795398; bh=uWfAZT2M3FpdI4YhLUhCaX5+M+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=OD1uee4PbeTNIzspa9tXpfqfld3OoNVEeo9VJpa48wXtODEiONuRIfoOimAhPwD/q YndRSlESn9E7uh84txA4A== Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by wpaz9.hot.corp.google.com with ESMTP id oBJLnuKT009879 for ; Sun, 19 Dec 2010 13:49:56 -0800 Received: by qwj8 with SMTP id 8so2364982qwj.10 for ; Sun, 19 Dec 2010 13:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MfXLHtS0HhUmrdwYRuE7bZ/eaVoK3BSZWCEkYhNpwsM=; b=RS5mloI+ufvR0ZaoyqZrPac8GNuGrEPoI57fwDihC+87Dj4AEkALfT8JXCW5yfAdIp ccynlurtA78G5JQuY/Ww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jEZ4eidTTY/ulcVKzn0G7Y5AUrzK1L8k2PDf1jp/J1txMZwtXuRzacanp9VZi89s0d NVl9hMudenCxuH3MfY+w== MIME-Version: 1.0 Received: by 10.229.81.12 with SMTP id v12mr3084026qck.35.1292795396286; Sun, 19 Dec 2010 13:49:56 -0800 (PST) Received: by 10.220.126.219 with HTTP; Sun, 19 Dec 2010 13:49:56 -0800 (PST) In-Reply-To: <4D0DE882.50201@qbik.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> Date: Sun, 19 Dec 2010 21:49:56 +0000 Message-ID: From: Ben Laurie To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Mon, 20 Dec 2010 08:30:38 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 21:48:08 -0000 On 19 December 2010 11:12, Adrien de Croy wrote: > Imagine if > everyone needed a client certificate to send any mail.=A0 We'd have no sp= am. Nonsense. We'd just restrict spam to owned machines, of which there are only a few tens or hundreds of milliions, if we're lucky. From benl@google.com Mon Dec 20 03:34:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA5C3A6A03 for ; Mon, 20 Dec 2010 03:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.482 X-Spam-Level: X-Spam-Status: No, score=-104.482 tagged_above=-999 required=5 tests=[AWL=-2.505, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy2cOqbRmjLt for ; Mon, 20 Dec 2010 03:34:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0801D3A6996 for ; Mon, 20 Dec 2010 03:34:09 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id oBKAoC4R015244 for ; Mon, 20 Dec 2010 02:50:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292842212; bh=bajceOOo7ZhkMfCRIoZ6DZTpuHM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wjs/qfOYP4SRFLXSpi5Qk4BY6dgSQE48/ETGb5ATcDra57cTTq3+EUGTZ6fs6MTJ3 S8OrcEjNnn0UmNWK0ZWIQ== Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by hpaq3.eem.corp.google.com with ESMTP id oBKAoAXT021017 for ; Mon, 20 Dec 2010 02:50:10 -0800 Received: by pvg2 with SMTP id 2so520470pvg.30 for ; Mon, 20 Dec 2010 02:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ytdwEhHK3ZyxYn4/Tw7dUnwqK5e/li/rp4GY+cOWS1Y=; b=NwEscFDea7GxAdpdBM9LRj0d9drGhPtj57XvxnrZ8oBd7anConpwUxY7Qdi+O0oYSZ 7RQN4TPnn7hM5T3ma/ZA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=INUMAT+lgNGZT4lrzj+jY88/zZA0u1jobDAgnFBvlf3alLonE+1EccK7OldJfqU4fx vVZlQ7N0EUpDOJqgte/w== MIME-Version: 1.0 Received: by 10.142.229.8 with SMTP id b8mr3240793wfh.20.1292842209794; Mon, 20 Dec 2010 02:50:09 -0800 (PST) Received: by 10.142.47.14 with HTTP; Mon, 20 Dec 2010 02:50:09 -0800 (PST) In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3046101@EXC001> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <55DC663C2F4F9F439F23543E0078E8B3046101@EXC001> Date: Mon, 20 Dec 2010 10:50:09 +0000 Message-ID: From: Ben Laurie To: Josh Howlett Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 20 Dec 2010 08:30:45 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:34:10 -0000 On 20 December 2010 09:25, Josh Howlett wrote: >> As Web sites discover that their account holders cannot remember their >> username, most have adopted email addresses as account identifiers. >> That is what we should use as the basis for federated web >> authentication. > > Unfortunately this approach transgresses the fourth Law of Identity: 'Directed Identity'. > > "A universal system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles" Of course these are not actually laws, just good ideas. However: the core failing seems to be the requirement that users should remember any more than their one "master identity" which is used to store all the others (see my Nigori work for how). > > Josh. > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From Josh.Howlett@ja.net Mon Dec 20 01:24:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86563A67C3; Mon, 20 Dec 2010 01:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FetjZtwnUIWE; Mon, 20 Dec 2010 01:24:14 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 135233A67C1; Mon, 20 Dec 2010 01:24:14 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E37B14A6B3C_D0F212DB; Mon, 20 Dec 2010 09:26:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id C569B4A6BAA_D0F2127F; Mon, 20 Dec 2010 09:25:59 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Mon, 20 Dec 2010 09:26:17 +0000 From: Josh Howlett To: Phillip Hallam-Baker , Common Authentication Technologies - Next Generation , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , General discussion of application-layer protocols , "http-auth@ietf.org" Thread-Topic: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation Thread-Index: AQHLn7/2OsTo+3NNpE6TpAWxmayn+pOpDfWQ Date: Mon, 20 Dec 2010 09:25:56 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B3046101@EXC001> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 20 Dec 2010 08:30:52 -0800 Cc: Josh Howlett Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 09:24:15 -0000 > As Web sites discover that their account holders cannot remember their > username, most have adopted email addresses as account identifiers. > That is what we should use as the basis for federated web > authentication. Unfortunately this approach transgresses the fourth Law of Identity: 'Direc= ted Identity'. "A universal system must support both omni-directional identifiers for use = by public entities and unidirectional identifiers for use by private entiti= es, thus facilitating discovery while preventing unnecessary release of cor= relation handles" Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From marsh@extendedsubset.com Sun Dec 19 14:02:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EF43A6911; Sun, 19 Dec 2010 14:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8qCV2TyjfYu; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A327C3A6910; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PURMA-000Jc4-IS; Sun, 19 Dec 2010 22:03:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A4FA360C7; Sun, 19 Dec 2010 22:03:52 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18timQ4um115qKSoyKjKv9Us5qWv7NZVf4= Message-ID: <4D0E8148.7060607@extendedsubset.com> Date: Sun, 19 Dec 2010 16:03:52 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 20 Dec 2010 08:33:23 -0800 Cc: General discussion of application-layer protocols , Adrien de Croy , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:02:03 -0000 On 12/19/2010 03:49 PM, Ben Laurie wrote: > On 19 December 2010 11:12, Adrien de Croy wrote: >> Imagine if >> everyone needed a client certificate to send any mail. We'd have no spam. > > Nonsense. We'd just restrict spam to owned machines, of which there > are only a few tens or hundreds of milliions, if we're lucky. Nonsense. We'd have no mail. Or rather some other store-and-forward messaging system would arise and not be called mail. Look back far enough and you'll find all kinds of "electronic mail" services implementing the full range of peer and end user authentication, and sender-pays models. There was no spam on those systems, or at least not enough that anyone felt like they needed a word for it. Guess why we use the one we use today. - Marsh From jhutz@cmu.edu Tue Dec 21 11:01:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30DA3A6AAA; Tue, 21 Dec 2010 11:01:48 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16h67Bq4jn5A; Tue, 21 Dec 2010 11:01:46 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 703D63A6AF1; Tue, 21 Dec 2010 11:01:46 -0800 (PST) Received: from [192.168.1.111] (cpe-174-100-233-109.neo.res.rr.com [174.100.233.109]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id oBLJ3ekW003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 14:03:40 -0500 (EST) From: Jeffrey Hutzelman To: Phillip Hallam-Baker In-Reply-To: <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Dec 2010 14:03:39 -0500 Message-ID: <1292958219.2800.22.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , jhutz@cmu.edu, "saag@ietf.org" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:01:48 -0000 On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote: > > As Web sites discover that their account holders cannot remember their > username, most have adopted email addresses as account identifiers. > That is what we should use as the basis for federated web > authentication. > > > > > So if the user account identifier looks like username@example.com, how > does an entity verify that a purported user has a valid claim to that > account? > > > The obvious mechanism in my view is to use DNS based discovery of an > authentication service. For example, we might use the ESRV scheme I > have been working on: > > > _auth._ws.example.com ESRV 0 prot "_saml._ws" > _auth._ws.example.com ESRV 0 prot "_xcat._ws" > > > Which declares that the SAML and 'XCAT' (presumably kitten in XML) > protocols may be used to resolve authentication requests. > I see two fundamental technical problems with this approach: 1) It relies on unsecured DNS to be secure. Particularly, you suggest that, in order to discover a means to securely authenticate users associated with some entity with which I have no prior relationship, I should look up information about that entity in the DNS. But DNSSEC is not widely-deployed enough (yet) for that to be realistic. Further, I'm generally opposed to schemes that rely on the integrity of the DNS to secure applications, because, at the enterprise level and below, the operators of the DNS are frequently not entrusted with the security of applications. I mistrust any system which insists on forcing that to change, while providing no recourse to those for whom such a policy is unacceptable (and no, "advertise in the DNS whether to use the DNS" is not such a recourse!). 2) It makes the assumption that my email service provider is interested in providing authentication services to me, and that I'm interested in giving them the ability to impersonate me to my bank. > > I'd be much happier to see a model wherein, at registration time, I tell a service my public key, and then it uses public-key cryptography to authenticate me in the future. Unfortunately, there are a number of practical problems there, such as dealing with multiple clients per user, kiosks, reinstalling machines, stolen credentials, etc., and it's really preferable to avoid having every service provider deal with those issues, rather than a much smaller number of authentication providers. From Claudio.Allocchio@garr.it Wed Dec 22 09:22:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314063A6B93; Wed, 22 Dec 2010 09:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDWh19coFosJ; Wed, 22 Dec 2010 09:22:30 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id C03B53A6B91; Wed, 22 Dec 2010 09:22:29 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oBMHOHLc001829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 18:24:17 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oBMHOHLc001829 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=roKPdmhQpHF81dShcG6jug9nCIiG1uJHA4qDeE/yLidzpQvZRcsXZLAuj83J1P/iE /xobSXJXNu1TnpF1LTnhB8U6GD6anCxXBZWa6h6+c9D0CgtHFkb6KOWd5DptoQ87NTy xL1MSfD127NKaQOdDrjmhfNaYeWd436MxOvJ04w= Date: Wed, 22 Dec 2010 18:24:11 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: apps-discuss@ietf.org, ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey.Melnikov@isode.com, SM Subject: [apps-discuss] apps-team review of draft-ietf-eai-rfc5336bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:22:33 -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-eai-rfc5336bis Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network) Review Date: 2010-12-22 IETF Last Call Date: N/A IESG Telechat Date: N/A Summary: The document specifies how to apply internationalization to some SMTP elements, and to some Header elements which depends from the SMTP elements. However there seem to be a discrepancy from what the abstract states, and what is elaborated into the document details: the document also deals with quite a number of elements which involve bodyparts, and affect the whole email legacy system, and beyond, such as logs, traces, and wherever email addresses are used (certificates, etc.). This seems thus to go beyond what the summary states, even this fact is not explicitly discussed. It is unclear thus if this "update" of RFC5321 and RFC5322 is only limited in scope or not. My reading of the document say it goes beyond, and implicitly affects also what is being transported into the email system. This is thus a serious issue to be solved before the document can go to the Standard Track. Another big issue is about blending the boundaries of servers in the transport system (MTAs), clients (UAs) and their roles, when the document specify that servers shall use guessing techniques from looking into bodyparts to understand if what they're transporting is internationalized according to this specification or not. This is IMHO a basic violation of the role distiction in the legacy email system, and affects the MIME model al well. The document quite often repeats rules from other specifications, AND re-describes these rules. This is dangerous (it makes very difficult to keep aligned documents, and will lead to different interpretations) and not needed. The full specification probably needs a serious "english language" revision, because the language issues which I specified in "Minor Issues" seems to be a non neglegible number. I'll try to identify as many as possible and suggest changes. Major Issues: This specification updates a number of SMTP and Headers fields from RFC5321 and RFC5322. However these fields are also used in Gatewaying to other email systems, which are still existing. Section 3.7 in RFC5321 describes specific cases. However this memo provides no clue on possible effect that internationalized fields can have in case gatewaying occurs. Gatewaying functions strongly rely on these values, and the introduction of these modification should describe this scenario, too. I suggest to include a specific section about these issues, and suggest at least a number of possible actions which Gateways can take to survive this change. The EAI WG charter states that in handling email message we shall be "consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers.". However a number of sections in the specification seem to contradict this, where they suggest actions, by exammining message elements (in the SMTP and in the Headers and in the Bodyparts) in order to try to deliver anyhow. This is a subtle line between maximising the service chance to deliver, and "fixing" things during the transaction, and it can encourage implementors to do many of these acions, instead of stiching to the idea "not supported --> non delivery". Major Issues by sections. Abstract: " This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information." "internationalized" is not defined here in details. Sections 1 and 1.2 try to do this, but the language is not crystal clear: "to permit internationalized email addresses in envelopes, and UNICODE characters (encoded in UTF-8) [RFC3629] in headers." Are addresses in envelopes (SMTP envelopes!) also via UNICODE characters encoded in UTF-8? The reference to "the framework document" seem to come too late in the text to ensure the reader fully understand the relationship. 3.2 The UTF8SMTPbis Extension "An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a mailbox can appear." s/mailbox// (it's a definition!). The specification does NOT suggest a preferred order among the 3 possible options when the SMTP server state it does not support UTF8SMTPbis. Having 3 "MAY" options at the same level can create a very uncertain email service behaviour, and a very bad user's experience! This is consistent with what happens in other cases for other "options" in the email system (like DSNs and MDNs), but there should be at least an informative document describing the various scenarios, and giving some guidance to implementors in order to avoid totally incosistent behaviours. If we do not specify a consistent procedure to try the 3 options, in many cases we will just in practice break the concept of universal email common service, creating islands which do not talk to each other. The 3.6.2 section gives some suggestions about this, but this is limited to MX listed servers for a single domain. My concern is more general. In 3.6.2 anyhow the language should be more precise. It states "orgnisations", which something totally undefined from a protocol point of view. MX records refer to "domains", not to "organisations". 3.3. Extended Mailbox Address Syntax The definition of uAtom = 1*ucharacter ; Replace Atom in RFC 5321, Section 4.1.2 ucharacter = atext / UTF8-non-ascii atext = permits that uAtom is either an atext OR an UTF8-non-ascii... which in the end allows a uMailbox to be a mixed contruction where some uAtom is in atext, while some other uAtom is in UTF8-non-ascii AT THE SAME TIME, e.g. a construct like some-ascii.some-UTF8-non-ascii@some-UTF8-non-ascii.some-ascii.tld is allowed. However the distinction here seems to be unneeded, as ASCII is a subset of UTF8. Section 3.6 tries to clarify that this is not allowed; owever there is normative language there apart on SHOULD for the domain name. I think this shold be fixed with a clearer normative specfication. This of course applies also to all other tokens where uAtom is used. 3.5 Body Parts and SMTP Extensions I have problems in understanding why an SMTP server should peek extensively into the message geing transfered to understand that it is handling an interationalzed message. "There is no ESMTP parameter to assert that a message is an internationalized message." in my opinion should be fixed in another way, by ADDING an appropriate ESMTP parameter to state this! This will solve already in the SMTP dialogue many isses which in this specification are handeled by guessing techinques. 3.6.1 "the server normally sends..." --> "the server sends" (sorry... we do not like ABnormal servers!) :-) Minor Issues: 1. Introduction The sentence "This document use this mechanism to support an internationalized email address." defintly needs a better form; if you do not know already know what we are talking about, it can be misleading. "This document uses this mechanism to allow internationalized email addresses support in SMTP elements." 3.1 Framework for the Internationalization Extension - bullet point 3. I do not see any need to state that clients MUST reject... and MUST be fully compliant... etc. This is implicit in any specification. If there is a specific need to add this detailed behaviour (to prevent wrong implementions? why?) either we shall ensure the text is clear and unambiguous, or we shall add an Implementers Note, as it was done in some other RFCs. 3.2 The UTF8SMTPbis Extension same general comment as per 3.1: in general the section states behaviours which do not need to be specified again, because they're alredy described seomewhere else. This might also become a Major issue if the specification of such behaviours are changed elsewhere. Just poit to extrnal references. (it seems editors are worried of implmentors which do not fully undesrtand or know the other email specifications... ) 3.3. Extended Mailbox Address Syntax What does the sentence "..., using the production for a mailbox and those productions on which it depends." mean? I assume you meant , is this correct? 5. Security Considerations there is one more issue: as internationalized items will also result into logs and traces, their presence may affects trouble ticket systems used by security operations teams (CERTs/CSIRTs). And they also can affect quick handling of incidents, has it may require more time to correctly read and understand logs and traces if they are not in current ascii form. This might even be a Major Issue. I propose adding this text in the section, besides pointing to the exteral reference: ---------------------- start of added text Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other scenarios, in particular: - the logging systems of SMTP transactions and other logs to monitor the email systems; - the trouble ticket systems used by Security Teams to manage security incidents, when an email address is involved This will likely require extending support for full UTF8 also into these systems, in order to avoid problems, which could cause also important loss of data, or require to provide an adequate mechanism to map non ASCII strings into them. Another Security aspect to consider is related to the ability by Security Team members to quickly understand/read and identify email addresses from the logs, when they are tracking an incident. Mechanims to automatically and quickly provide the origin or ownership of an internationalized email address shall implemented for use also by log readers which cannot read easily non-ASCII information. --------------------------- end of added text Also, in Security Consideration, there is no mention of the fact that we are changing VRFY/EXPN commands to include internationalized addresses. VRFY/EXPN commands can exist ALSO in an SMTP transaction which is not supoused to transfer an email messages between MTAs. And their use has also do to with Security. Here is an additional text for this: ---------------------- start of added text The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). RFC5321 section 3.5 and 7.3 give some detailed description of use and possible behaviours. Implementation of internationalized addrsses can affect also logs and actions by these tools. --------------------------- end of added text Nits: see http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-eai-rfc5336bis-07.txt Best Regards! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From dhc@dcrocker.net Wed Dec 22 10:03:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448D73A6925; Wed, 22 Dec 2010 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n2X7E2rjUvK; Wed, 22 Dec 2010 10:03:00 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 279EC3A6909; Wed, 22 Dec 2010 10:03:00 -0800 (PST) Received: from [192.168.1.43] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBMI4mYh013364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 10:04:53 -0800 Message-ID: <4D123DC0.2050501@dcrocker.net> Date: Wed, 22 Dec 2010 10:04:48 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Apps Discuss , ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org, SM , Alexey.Melnikov@isode.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, 22 Dec 2010 10:04:55 -0800 (PST) Subject: [apps-discuss] (private) draft review of: draft-ietf-eai-rfc5336bis-07.txt (v3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 22 Dec 2010 18:03:04 -0000 IETF Applications Review I have been selected as an Applications Area Review Team reviewer for this draft. For background on apps-review, please see: 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-eai-rfc5336bis-07.txt Reviewer: Dave Crocker, Brandenburg InternetWorking Review Date: 2010-12-22 BACKGROUND: The document is a specification for an email transport-time option that is described in its Abstract as declaring support for "internationalized email addresses or header information" and in the Introduction as being "to support an internationalized email address". The extension specifies changes both in the transfer protocol and in the message being transferred, including its Body. Legacy Internet Mail only supports classic "network ASCII" for data representation and for data transfer encoding. The charter for the current work cites previous work that was issued as Experimental, and summarizes it as having been "... based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers." This text appears also to serve as the statement of scope for the current working group. With respect to the mail header, the scope is specified as covering
and constructs. An is a means of mapping Unicode strings onto classic, network ASCII, although the working group focus was on binary, UTF-8 support. RECOMMENDATIONS: This work represents an extremely important enhancement to Internet mail. It has been clear for twenty years that Internet applications need to be able to present data in a form that is natural to the user. The current work benefits from providing a Framework document and from distinguishing changes to the email header from changes to the SMTP protocol. 0. The documents do raise distinctions between ASCII and Unicode, versus between ASCII and UTF-8. However they do not apply them rigorously in the documents. I suggest that the term "internationalization" be used only during introductory discussion and never as part of normative text. ASCII vs. Unicode is a distinction between the underlying range of data being represented. ASCII vs. UTF-8 is a distinction between encoding environments. Text should explicitly indicate whether it means data representation versus data encoding and it should use Unicode for the former and UTF-8 for the latter. 1. The Framework document is normative and needs to be completed along with the other two specifications, since they quite reasonably state a normative dependence on the Framework document. 2. The SMTP extension draft needs to focus on SMTP and the direct support of UTF-8 in the message header. It needs to move all discussion and specification of Unicode support in the Header to the Header draft. 3. There probably needs to be definition of MIME message/uni-rfc822, specifying Unicode support within a message contained in MIME. I'm less clear whether there needs to be a MIME Content-Transfer-Encoding form specific to UTF-8. 4. The SMTP extension needs to have the client use an explicit signal when it is sending a message encoded in UTF-8. This is easiest as a parameter to the MAIL command. The current specification creates a more complex and almost heuristic model for distinguishing ASCII from UTF-8 use. 5. The SMTP extension needs to remove all restrictions it imposes on MIME content-type. A major reason that MIME was successful was that it was transparent to the transfer infrastructure. The current SMTP extension specification changes this model, which actually increases the barrier to adoption of Unicode in email. It needs to be easy for two MUAs that support Unicode in the email header to exchange mail even when the infrastructure does not support UTF-8. SUMMARY COMMENTS: The document conforms to the conventions for defining SMTP options. There are a number of significant issues with the specification. These are covered in detail, below, and are summarized here: * Framework -- The Framework document[1] is (correctly) referenced as required reading. It supplies essential terminology and architecture for this specification. In fact it is a specification, complete with formally normative vocabulary. This means that it must be a normative reference by rfc5336bis. It therefore also means that the Framework document needs to be completed before the current specification can be standardized. * Scope -- the specification appears to go significantly beyond the scope of the working group's charter, including revisions to basic SMTP that have no obvious requirement for support of Unicode during transport. In fact, at least one change is likely to /restrict/ system-wide adoption, rather than encourage it! In particular, the specification restricts the conditions under which some MIME content is allowed to be sent. (See next bullet.) * Infrastructure Requirement -- Unless this option is in force, carrying internationalized email in a MIME part is prohibited. This is out of scope for the working group and it is a counter-productive rule. Imagine if the same type of rule had been specified when MIME was created, saying that MIME could only be sent when an "attachments-supported" option were in force. This would have prevented the early adoption of MIME use by individual MUAs until the entire infrastructure supported MIME. (As an example of the very high barrier this raises, note the difference in real-world support and use of MDN versus DSN.) While it is reasonable for the working group to define a new MIME content-type that modifies message/rfc822 to support internationalized addresses, it is not appropriate for the working group to modify the SMTP transfer model to constrain what types of message content can be sent. * Beyond -- The work, here, appears to have two goals. One is to add support for Unicode in a ; that is, support for internationalized addresses. However note that and already accomplish this in a way that is transparent to the existing email infrastructure; only the end-systems need to understand it. The second goal is to support Unicode in the more "native" form of UTF-8. (The quotation marks are because UTF-8 is not native Unicode, either; it is a highly encoded form of Unicode...) This creates some confusion in the specification. Given that the option for SMTP is "UTF8SMTPbis", then the binary encoding goal seems to dominate the work. This is a certainly a reasonable goal, but it will help the clarity of the specification to make these two different goals more clear within the document and to apply them more carefully. * Terminology confusion -- The Framework document carefully distinguishes between "ASCII addresses and non-ASCII addresses. It equates "internationalized" first with "non-ASCII", but then with "UTF8SMTPbis". A core problem is that ASCII is part of the actual internationalized set of Unicode characters. So, to say that "international" characters are non-ASCII is exclude part of Unicode from the term "international". In addition, equating the term "internationalization" with UTF-8 encourages confusion between underlying or "native" data -- that is, Unicode -- with the way it is represented over the wire. UTF-8 is merely one means of over-the-wire representation. So, for example, and are two other means of encoding. It's clear that this core distinction really is understood by the authors of this and the Framework documents. However the vocabulary choices and their usage create a problem in the details of the specification. "Internationalization" should mean Unicode, not a particular binary representation of it within 8-bit chunks. The problem, here, is in using the term "internationalization" to refer to a subset of Unicode, that is, the subset that is not ASCII. I strongly suggest saying "Unicode" when intending to refer to the richer set of characters that are the goal of this work, and "UTF-8" when referring to the particular binary encoding of Unicode that is the focus of the SMTP extension work. * Non-UTF-8 Unicode support -- Can a message support Unicode without UTF-8? The existence of and constructs makes clear that the answer is yes. Hence, it should be possible to support Unicode messages, without this SMTP extension. Perhaps this is out of scope for this SMTP extension and perhaps it is handled by the Email Header draft, but I think it worth having this document cite this alternative mode, if only to a) make clear that the alternative exists, and b) make more clear what the specific and strong benefit of this extension is. * Partial enforcement -- Since ASCII is a subset of Unicode, having this extension be in force means that /everything/ is Unicode AND, apparently, is encoded in UTF-8. If the environment created by this extension supports UTF-8, then it supports UTF-8, meaning both ASCII and non-ASCII. Defining rules that depend on having this extension be in force but then still distinguish between ASCII and non-ASCII does not seem to make sense. * Complexity and Heuristics -- In a number of places, the specification defines highly contingent action, where one side can use UTF-8 only if the other side has done so. This makes the enhancement much more complicated than necessary or appropriate. The enhancement needs to work with an all-or-nothing model in which UTF-8 is in force or it is not. And, yes, this appears to be a major change in the model of this specification. My understanding is that these issues were discussed in the working group, but I do not understand why and nearly-heuristic approach was preferred. Instead I recommend the client to signal explicitly when UTF8-encoded addresses are present, such as a option () to the MAIL command. * 5321 vs. 5322 -- The specification seems to confuse -- or at least to mix -- some rules from RFC 5321 versus some from RFC 5322. is the major example. * Since an RFC 5322 message can and often does exist outside of the SMTP environment, any changes to the RFC 5322 specification should be in a document that is separate from this extension specification. This specification can then cite it. I suggest moving all RFC 5322 changes to the Header document[2] and merely citing it here. * UTF8SMTPbis -- The draft uses the string "UTF8SMTPbis" when referencing the SMTP option. The Framework document explains the choice, but IANA Considerations in this document needs to provide explicit handling instructions for it, since this is certain NOT to be the actual string that is used. * Redundant Specification - in a number of places, normative language from other specifications is repeated. This invites divergent specification and is generally out of scope for the current work. To the extent that the current specification needs to refer to normative parts of other specifications, it should do only that: cite it; do not repeat it. For example to highlight an important normative item from another specification, the current specification might describe the "topic" the external language covers, without saying what it says. In other cases, the key point is that the current specification is not changing requirements from another specification; that is what should be said, rather than repeating what that requirement is. In general, these references to external, normative behaviors should be reviewed for relevance to the current work. How is internationalized addresses relevant to the normative detail? * Rule Meta-Naming -- The 'u' preface for revised rules is a reasonable idea, but appears to be problematic. These rules replace existing rules in other specifications. There needs to be an explicit and decision about the handling of this, and it needs to be applied consistently, either directly replacing the rules or else re-naming them consistently, in a fashion that can be parsed (similar to the naming template that was done with RFC5322 obs-* rules.) If an initial string is to be used, I suggest UTF-8-* rather than u*, in order to make it possible to parse this meta-label more reliably. DETAILED COMMENTS: { I have included text from the draft that provides context, but have skipped sequences of text from the draft that do not. } > 1. Introduction > > The Simple Mail Transfer Protocol [RFC5321] provides a negotiation mechanism > about service extension with which clients can discover with which -> by which { or } through which { Either of these would be my stylistic preference. } > server capabilities and make decisions for further processing. This > document use this mechanism to support an internationalized email use -> uses > address. An extended overview of the extension model for { The option enables use of UTF-8 in the email header, beyond just addresses, therefore: } to support...address -> to support internationalized email addresses and internationalized characters for the email header. > internationalized addresses and headers appears in [RFC4952bis], headers -> the email header > referred to as "the framework document" or just as "framework" elsewhere in > this specification. This document specifies an SMTP extension to permit > internationalized email addresses in envelopes, envelopes -> the SMTP envelope { 1. Although 'envelope' is almost certainly unambiguous, its use over the years has been confusing, so it is worth being particularly clear in a specification. 2. The use of plurals in a specification can be confusing. I suggest using the singular form wherever it can work, so that remaining use of plurals becomes more precise. Also note the particular confusion with the word "headers" in email. Since a single email has only a single header, the use of plural means each header from a set of messages... } > and UNICODE characters (encoded in UTF-8) [RFC3629] in headers. headers -> the header > 1.1. Role of This Specification > > The framework document specifies the requirements for, and describes > components of, full internationalization of the electronic mail. A thorough > understanding of the information in that document and in the base Internet > email specifications [RFC5321] [RFC5322] is necessary to understand and > implement this specification. { This means that the Framework document is normative; it needs to be cited as such. Since understanding it is a pre-condition of reading the specification, it also requires that the Framework document be completed before this document. } > This document specifies an element of the email internationalization work, > specifically the definition of an SMTP extension for internationalized email > address transport delivery. { Since it also declares support for internationalization in the message header, it covers more than delivery. In effect, it is a transport-time flag for declaring internationalization of the entire email "environment". I'm not quite sure what exact language change to suggest, however. I also note that it does more than declare support for internationalized addresses: It declares support for encoding them into UTF-8. This is a significant, additional requirement and should be stated explicitly. } > 1.2. Terminology ... > This specification defines only those Augmented BNF (ABNF) [RFC5234] syntax > rules that are different from those of the base email specifications and, > where the earlier rules are upgraded or extended, gives them new names. > When the new rule is a small modification to { The wording in the first part of this paragraph seems awkward. I think the following is clearer: } This specification uses Augmented BNF (ABNF) rules [RFC5234], with some modifications. The modified rules are defined here and the rest are simply imported from [RFC5234]. New names are used, for rules that are upgraded or enhanced. When the ... > the older one, it is typically given a name starting with "u". Rules { The use of "typically" makes the description of this convention problematic. It needs to be always true or else not mentioned. Or perhaps alternative phrasing: } When a new...with "u". -> When a new rule has a name starting with "u", it is a small modification to an older rule. { This asserts what is true and ignores what is not true, such as rules that qualify for the "u" but did not get it... However I now believe that it is important to have a consistent meta-rule for naming the revised rules and that it be applied consistently to all rules that qualify for it. Further, the naming convention should be easily parseable, and therefore more like what is used in RFC5322, to cover "obsolete" rules. I suggest that new rules, here, be named UTF-8-*. To repeat: I believe that /all/ rules that resolve to UTF-8 must be renamed, so that implementers know what they need to change. } > that are undefined here may be found in the base email specifications { The specifications should be cited here, explicitly, even though they have been cited elsewhere. It is important to leave no ambiguity for the reader. } here may be -> here can be {"may" is a reserved word for normative specification. Normative meaning is not based on the use of capitalization. } > 3.2. The UTF8SMTPbis Extension > An SMTP server that announces this extension MUST be prepared to > accept a UTF-8 string [RFC3629] in any position in which RFC 5321 > specifies that a mailbox can appear. That string MUST be parsed only > as specified in [RFC5321], i.e., by separating the mailbox into { The 'i.e.' clause is an example of repeating normative text from another specification. The current document is not empowered to give directives about basic SMTP parsing, nor is there any internationalization requirement that it do so. At most, it should say that the changes specified in this document do not change any other aspect of SMTP processing. } > Once isolated by this parsing process, the local part MUST be > treated as opaque unless the SMTP server is the final delivery Mail > Transfer Agent (MTA). { The statement about handling of is redundant with the base RFC 5321 specification. The statement, here, should be that the handling of is unchanged from the base specification. Again, it should not repeat the normative language, unless it is changing it. If it is changing it, the change needs to be essential for support of internationalized addresses. } > Any domain names that are to be > compared to local strings SHOULD be checked for validity and then > MUST be compared as specified in section 3 of [RFC5891]. { Dictating use of RFC5891 is within scope. Dictating validation seems not to be. So...} -> Any domain name that is to be compared to a local string MUST use Section 3 of [RFC5891] as the basis for comparison. > An SMTP client that receives the UTF8SMTPbis extension keyword in response > to the EHLO command MAY transmit mailbox names within SMTP commands as > internationalized strings in UTF-8 form. It MAY send a UTF-8 header > [RFC5335bis] (which may also include mailbox names in UTF-8). It MAY > transmit the domain parts of mailbox names within SMTP commands or the > message header as A-labels or U-labels { I believe that the use of "MAY" is not correct. This would mean that the receiver needs a means of distinguishing whether the data are UTF-8 or not. This would border on requiring support of a heuristic, but it certainly adds a significant processing overhead and additional software complexity. The only alternative is to specify use of a MAIL command option that declares that the message supports internationalized addresses. Given the approach in this specification, I believe the intent is also to have it mean that UTF-8 encoding is supported. The core issue here is specifying an option which declares a message to have an EAI context for all of the message. So the processing context is fully EAI/UTF-8 or it is legacy net-ASCII. This is considerably simpler to specify and to process, than would be requiring parsing the incoming string and looking for non-ASCII UTF-8. Hence: } An SMTP client...U-labels -> An SMTP client that receives the UTF8SMTPbis extension keyword, in response to the EHLO command, will transmit within SMTP commands as internationalized strings in UTF-8 form. It will send the email header in UTF-8 [RFC5335bis] (which can also include names in UTF-8.) It also will transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels { Note - the term "mailbox names" is not defined here or in RFC 5321. In RFC 5321 it appears to be used to mean local-part; however becasue its precise meaning is unclear, I strongly urge NOT using it here at all. Instead I suggest using whatever ABNF rulename is appropriate. This guarantees clarity. Note: I changed 'may' to 'can'. Also, when an ABNF rule is being cited within prose text, such as for , it should be distinguished so that the reader knows it is a formal term. I have used <> to bracket the term mailbox. } > All labels in domain parts of mailbox names which are IDN > forms of A-labels or U-labels MUST be valid. { This is strange. Either it is repeating a normative requirement from SMTP or it is expanding SMTP to require special validation for IDN forms of domain names that is not present for ASCII forms. Neither interpretation seems like the right thing to be doing here. Such a modification to SMTP seems out of scope. Also, the term has different semantic definitions in RFC 5321 and RFC 5322. A strict reading of the differences could be a problem. A loose reading would note that both definitions reduce to include and components that are common to both specifications. I encourage you to review this issue carefully and put a note at the beginning of the document stating explicitly how you have chosen to handle it. My best recommendation is that this document should only refer to RFC 5321 ABNF and that it should move /all/ RFC 5322 modifications or enhancements to the EAI Header document (draft-ietf-eai-rfc5335bis). } > When a Mail User > Agent(MUA) submits a message to a Message Submission Server > ("MSA")[RFC4409], it is the responsibility of the MSA to ensure that > all domain labels are valid. { Given that this specification creates broad systemic effects and given that it needs to refer to components other than an SMTP client or server, it should cite RFC 5598, to give the reader an integrated view of the email service. I'll note that citing 5598 has become common for email specifications; so this is not a controversial suggestion. } >The presence of the UTF8SMTPbis > extension does not change the requirement of RFC 5321 that servers > relaying mail MUST NOT attempt to parse, evaluate, or transform the > local part in any way. { This sentence replicates normative language from a different specification. This is a very bad thing to do, in case the original specification changes its language. I suggest: } The presence of...in any way -> The presence of the UTF8SMTPbis extension does not change RFC 5321 server relaying behaviors. { this retains some text as a flag to the reader, but does not provide the specific semantics, which might change in the original specification. } > If the UTF8SMTPbis SMTP extension is not offered by the server, the SMTP > client MUST NOT transmit an internationalized address and MUST NOT transmit { This appears to prohibit the sending of internationalized addresses that are encoded in ASCII, rather than in UTF-8. The purpose of ASCII encoding is to eliminate the need for infrastructure support for Unicode characters. However the language here appears to be imposing the barrier of infrastructure support. If the concern is sending UTF-8, then that's the language that needs to be used. Messages with ASCII-encoding of internationalized addresses need to be permitted to be sent, without first requiring infrastructure support. } > a mail message containing internationalized mail headers as described in > [RFC5335bis] at any level within its MIME structure [RFC2045] and [RFC2047]. { The prohibition of internationalized mail headers within a MIME structure -- "at any level within its MIME structure" -- is out of scope for the working group and is a /major/ change to SMTP. It is also a really terrible rule! In terms of protocol modeling, it would have been like saying that no one could use MIME until the infrastructure supported it! It is one thing to give the reader a reminder that UTF-8 is illegal in the email header of a message and quite another to attempt to prohibit it in attachments. Attachments already carry all sorts of data. UTF-8 is merely one more type. I believe that there currently no SMTP constraints on the carriage of MIME; I also believe it essential that there not be, since such constraints impede adoption. (That is why MDN support is good and DNS support is poor.) Also note that MIME objects exist outside of email transport and that directives about legal or illegal MIME ought to be separated from SMTP... Also, perhaps mail with UTF-8 in the header needs a different MIME type, such as text/UTF-8-message?... } > 2. It may either reject the message during the SMTP transaction or accept may -> MAY { However, I note that this concerns a SMTP client, not a server. > 3.3. Extended Mailbox Address Syntax > > RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in terms > of ASCII characters, using the production for a mailbox and those productions mailbox -> > on which it depends. > > The key changes made by this specification are, informally, to { I don't understand what it means to change RFC 5321 "informally". I think it is intended to mean that the list is not guaranteed to be complete. If so, I suggest wording such as: } -> The key changes made by this specification include: > o Change the definition of "Domain" to permit either the RFC 5321 definition > above or a UTF-8 string representing a DNS label that is conformant with > IDNA definitions [RFC5890]. { "either"??? That sounds completely ambiguous. } > o Change the definition of "Local-part" to permit either the definition > above or a UTF-8 string. That string MUST NOT contain any of the ASCII > characters (either graphics or controls) that are not permitted in "atext"; > it is otherwise unrestricted. { same concern as above. } > According to the description above, the syntax of an internationalized email > mailbox name (address) is defined in ABNF [RFC5234] as follows. > > uMailbox = uLocal-part "@" ( uDomain / address-literal ) ; Replace Mailbox > in RFC 5321, Section 4.1.2 { This implies that the option applies only to RFC5321 and not to RFC5322, but the later rules make clear that 5322 is also supposed to be covered. To repeat: I recommend that all RFC 5322 enhancements and ABNF should be moved to the EAI Header draft and that the SMTP extension should merely cite that draft. Note that RFC5322 is for an object that can and does exist outside of SMTP. Enhancements to RFC5322 well might need to apply when there is no SMTP, or at least long after it is relevant. } > UTF-8-non-ASCII = UTF-8-2 / UTF-8-3 / UTF-8-4 > > UTF-8-2 = > > UTF-8-3 = > > UTF-8-4 = { These rules are also defined in RFC5335 and draft-ietf-eai-rfc5335bis. Citing RFC 3629 is therefore confusing, and possibly can create specification divergence. I suspect that RFC 3629 is not the correct reference, here, since it would imply that RFC5335bis' definitions should be ignored... If RFC 3629 /is/ the correct reference, then I cannot guess why and I cannot guess why it will not create problems with divergent specification. } > The value of "uDomain" SHOULD be verified by IDNA definitions [RFC5890]. If { I do not understand what "SHOULD be verified by IDNA definitions" means. If it means that the uDomain "SHOULDbe verified" then it is out of scope for this specification. There is no reason that SMTP rules concerning verification of Unicode-based domains needs to be different from ASCII-based domains. In particular, verification of a Domain name is specified elsewhere. If it means that the uDomain "should be IDNA complaint" then I do not understand having the exceptions that a "should" allows. For this EAI work, I would think that when UTF8SMTPbis is in force, then IDNA compliance needs to be a MUST. } > that verification fails, the email address with that uDomain MUST NOT be > regarded as a valid email address. MUST NOT be regarded as a valid -> MUST BE regarded as an invalid { Stating this as an affirmative is stronger. } > 3.4. UTF-8 addresses and Response Codes > > An internationalized message MUST NOT be sent to an SMTP server that does > not support UTF8SMTPbis. Such a message should be rejected by a server if > it lacks the support of UTF8SMTPbis. { The first sentence is restating a normative rule already existing in other specifications. The second sentence is simply confusing. If the first sentence is applied, then the server does not support UTF8SMTPbis. I suspect what is actually meant in the second sentence is something like: } If a server receives email encoded in UTF-8, when UTF8SMTPbis is not in force, then the server SHOULD reject the message. { However, this means that the current specification is trying to dictate behavior in the legacy environment, and it cannot do that. I believe the rule that is actually intended is: } An SMTP client MUST only send a message containing UTF-8 to a server that supports UTF8SMTPbis. If the server does not support this option, then the client MUST terminate the delivery attempt with a permanent error, or else find another path. > The three-digit reply codes used in this section are consistent with their > meanings as defined in RFC 5321. { "consistent with"? I hope you actually mean that they are "the same"! Either they are the same as in 5321 or they are changed. } > When messages are rejected because the RCPT command requires an ASCII > address, the response code 553 is used with the meaning "mailbox name not used -> returned, > allowed". When messages are rejected for other reasons, such as the MAIL > command requiring an ASCII address, the response code 550 is used with the { RFC 5321 uses the terms "completion code", "reply code" and "response code" interchangeably. That probably makes the use of "response code" here legal. However the formal ABNF in RFC 5321 defines the rules: For clarity and precision, I strongly recommend using only those terms when referring to replies/responses/completion. Since the current document is cross-referencing a formal construct from another document, it will help the reader to resolve the reference by using only the most formal term.} > meaning "mailbox unavailable". When the server supports enhanced mail { "unavailable" sounds like a temporary error. More generally, the text here says that this set of rejections is "for other reasons". However it does not really mean all other rejections. Since there are many, different "other reasons" and some of them are temporary errors, this text needs to be revised. It needs to make clear the difference in handling temporary versus permanent errors and in particular it needs to define both types in terms that are specific to this enhancement, in order to distinguish them from all other SMTP reply-codes.} > system status codes [RFC3463], response code "X.6.7" [RFC5248] is used, > meaning that "UTF-8 addresses not permitted for that sender/recipient". > > If the response code is issued after the final "." of the DATA command, the > response code "554" is used with the meaning "Transaction failed". When the > server supports enhanced mail system status codes [RFC3463], response code > "X.6.9" [RFC5248] is used, meaning that "UTF-8 header message can not be > transferred to one or more recipient so the message must be rejected". > > 3.5. Body Parts and SMTP Extensions > > There is no ESMTP parameter to assert that a message is an internationalized > message. An SMTP server that requires accurate knowledge of whether a > message is internationalized is required to parse all message header fields > and MIME header fields [RFC2045] and [RFC2047] in the message body. { This is confusing. There is a rule against sending an internationalized message, unless UTF8SMTPbis is in force, but there is no requirement that the server be told explicitly when a message is internationalized??? As noted above, the simple and appropriate action to take is, instead, to have the MAIL command contain an that declares that the message supports internationalized addresses. My understanding is that this was discussed by the working group. Why was this not the choice of the working group? } > While this specification requires that servers support the 8BITMIME > extension [RFC1652] to ensure that servers have adequate handling capability > for 8-bit data and to avoid a number of complex encoding problems, the use > of internationalized addresses obviously does not require non-ASCII body > parts in the MIME message [RFC2045] and [RFC2047]. The UTF8SMTPbis extension > MAY be used with the BODY=8BITMIME parameter if that is appropriate given > the body content or, with the BODY=BINARYMIME parameter, if the server > advertises BINARYMIME [RFC3030] and that is appropriate. { This last sentence is either saying too much or too little. In general, this option does not specify MIME or Body details. Nor does there appear to be any reason that it should. As a consequence, I believe that any text about MIME or the Body needs to be non-normative. It's fine to provide a small amount of pedagogy about the carriage of MIME, but including normative language about it here merely invites confusion and possibly even divergent specifications. Also note that the reference to "BODY=" values does not explicitly cite RFC 1652. So the references require the reader to already know what is being referred to. This should be fixed.} > Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and > receives at least one non-ASCII address, the precise interpretation of > "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is: 1. If a { My reading of the current specification is that it does not change the handling of email Body or MIME mechanisms. Hence, DO NOT REPEAT NORMATIVE LANGUAGE FROM OTHER SPECIFICATIONS. It invites divergent specification. If the current specification is actually re-defining the semantics or syntax of RFC 1652, then it needs to say so. However my reading of the current specification is that it is quite independent of email Body issues. } > BODY=8BITMIME parameter is present, the header contains UTF-8 characters, > and some or all of the body parts contain 8-bit line-oriented data. 2. If a > BODY=BINARYMIME parameter is present, the header contains UTF-8 characters, > and some or all body parts contain binary data without restriction as to > line lengths or delimiters. { Also note that the items numbered 1 and 2 are not complete sentences. They only contain the conditional clause. "If...." is missing the "then". Hence, no actual "interpretation" is provided, contrary to the promise that is given.} > 3.6. Additional ESMTP Changes and Clarifications > > The information carried in the mail transport process involves addresses > ("mailboxes") and domain names in various contexts in addition to the MAIL > and RCPT commands and extended alternatives to them. In general, the rule > is that, when RFC 5321 specifies a mailbox, this specification expects UTF-8 this specification -> this SMTP extension { "this specification could be misread as meaning RFC 5321, since it is the most recent specification references...} > to be used for the entire string; when RFC 5321 specifies a domain name, the > name SHOULD be in the form of A-label if its raw form is non-ASCII. { the more serious problem is the continuing confusion about ASCII vs. non-ASCII and UTF-8 vs non-UTF-8. Again, I believe that having this extension be in force means that this data are /always/ UTF-8. Hence, it is not a matter of "expects". It is a matter of "requires".} > The following subsections list and discuss all of the relevant cases. > > 3.6.1. The Initial SMTP Exchange > > When an SMTP connection is opened, the server normally sends a "greeting" > response consisting of the 220 response code and some information. The { "normally"? what are the exceptions?} > client then sends the EHLO command. Since the client cannot know whether > the server supports UTF8SMTPbis until after it receives the response from > EHLO, the client must send only ASCII (LDH label [RFC5890] or A-label) > domains in the EHLO command and that, if the server provides domain names in > the EHLO response, they must be in the form of LDH labels or A-labels. > > 3.6.2. Mail eXchangers > > Organizations often authorize multiple servers to accept mail addressed to > them. For example, the organization may itself operate more than one may -> might or may -> can { normative vocabulary can only be used for normative statements. please do a global search and replace, where normative vocabulary are used in non-normative sentences.} > server, and may also or instead have an agreement with other organizations to > accept mail as a backup. Authorized servers are generally listed in MX > records as described in RFC 5321. When more than one server accepts mail for > the domain-part of a mailbox, it is strongly advised that either all or none > of them support the UTF8SMTPbis extension. { This last sentence sounds normative and I believe it should be. So... } it is strongly advised that either all or none of them support -> all or none of them SHOULD support > Otherwise, surprising rejections > can happen during temporary failures, which users might perceive as a serious { Probably not just temporary failures. Having services that are meant to be redundant with each other actually provide different semantic behavior is just plain dangerous. It is essentially guaranteed that they will cause problems.} > 3.6.3. Trace Information > > When an SMTP server receives a message for delivery or further > processing, RFC 5321 requires that it MUST insert trace ("time stamp" > or "Received") information at the beginning of the message content. > For the trace information, this memo updates the time stamp line and > the return path line [RFC5321] formally defined as follows: { Again, don't repeat normative language. I suggest simply deleting the first sentence. } > [RFC5321] formally defined as follows: > > uReturn-path-line = "Return-Path:" FWS uReverse-path ; Replaces > Return-path-line in Section 4.4 of RFC 5321 { On reflection, I think the "u" rule-naming convention is problematic. If the current specification is replacing a rule previously defined elsewhere, it needs to use the same rulename. This is simpler and clearer. Otherwise, all future references to the rule need to use the new name. Rather, where the draft is replacing a rule from another specification, the rule definition includes a comment that cites where the original rule is from; that should be sufficient. } > uReverse-path = uPath / "<>" ; Replace Reverse-path in RFC 5321, section > 4.1.2 > > uPath = "<" [ A-d-l ":" ] uMailbox ">" ; Replace Path in RFC 5321, section > 4.1.2 ; uMailbox is defined in section 3.3 of this document > > A-d-l = { Small improvement: Where a rule is defined elsewhere, I suggest having the descriptive text in the rule say rather than . } > 3.6.4. UTF-8 Strings in Replies > > 3.6.4.1. RCPT Commands > > If an SMTP client follows this specification and sends any RCPT commands > containing non-ASCII addresses, the SMTP server is permitted to use UTF-8 > characters in the email address associated with 251 and 551 response codes, > and the client MUST be able to accept and process them. { I assume that "follows this specification" means that the UTF8SMTPbis option is in force. If so, then say that, because it is simpler and more precise. But, then, it does require declaring /use/ of the option... However the meaning of the text here is odd. It implies that the server is not permitted to use UTF-8 unless it has already received UTF-8, even though the option is in force. I suspect that that is not the specification that is intended. Or, at least, I hope it is not. If it actually /is/ what is intended, it means that the enhanced environment is going to have all sorts of /additional/ conditional code, to check on whether a specific context in the state machine is allowed to act in one way or another. The simple and more reasonable model is that when the extension is in force, UTF-8 is allowed. Period. So... } If an SMTP session is using this extension, then the server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the client MUST be able to accept and process them. { I chose "SMTP session" to avoid the more complex discussion of the client/server 'negotiation' about using the extension. So, here it is either in force or it isn't and if it is in force, it is for client AND server. } > If a given RCPT > command does not include a non-ASCII envelope address, the server MUST NOT > return a 251 or 551 response containing a non-ASCII mailbox. Instead, it > MUST transform such responses into 250 or 550 responses that do not contain > non-ASCII addresses. { See above. I very strongly disagree with having the complexity this kind of conditional requirement creates. Or else there is a basic issue involved here that the document does not discuss but needs to, to justify the complexity. } > 3.6.4.2. VRFY and EXPN Commands and the UTF-8REPLY Parameter > > If the VRFY and EXPN commands are transmitted with the optional parameter > "UTF-8REPLY", it indicates the client can accept UTF-8 strings in replies to > those commands. This allows the server to use UTF-8 strings in mailbox { Is this extension trying to to say that a client might support UTF8SMTPbis but not be able to access UTF-8 replies??? Under what circumstance is this reasonable? } > names and full names that occur in replies without concern that the client > might be confused by them. An SMTP client that conforms to this { What does it mean to be "confused" by them? Because the extension is in force, we know that the client supports UTF-8. } > specification MUST accept and correctly process replies from the VRFY and > EXPN commands that contain UTF-8 strings. However, the SMTP server MUST NOT > use UTF-8 strings in replies if the SMTP client does not specifically allow > such replies by transmitting this parameter. Most replies do not require { Why is this constraint required? } > that a mailbox name be included in the returned text, and therefore UTF-8 is > not needed in them. Some replies, notably those resulting from successful > execution of the VRFY and EXPN commands, do include the mailbox, making the > provisions of this section important. > > VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: > > vrfy = "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF-8REPLY" ] CRLF ; > uLocal-part and uMailbox are defined in ; Section 3.3 of this document. > > expn = "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF-8REPLY" ] CRLF ; > uLocal-part and uMailbox are defined in ; Section 3.3 of this document. { Note that these rules only specify UTF-8 support, without any contingency on use. That is, they do not cover the variability that is described in the prose, and that disparity from the prose specification is an example of the complexity created by having the use of UTF-8 in replies be so contingent on the actual data sent by the client. } > If a normal success response (i.e., 250) is returned, the response MAY > include the full name of the user and MUST include the mailbox of the user. > It MUST be in either of the following forms: > > User Name ; uMailbox is defined in Section 3.3 of this document. > ; User Name can contain non-ASCII characters. > > uMailbox ; uMailbox is defined in Section 3.3 of this document. { "User Name" needs to be specified as an abnf rule. It isn't. This appears to be intended to invoke the RFC 5322 definition of rather than the RFC 5321 definition. In any event, it is creating a semantic change to the response, from RFC 5321, beyond merely allowing UTF-8 characters. } > If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in the > reply, and the server supports enhanced mail system status codes [RFC3463], > the enhanced response code is "X.6.8" [RFC5248], meaning "A reply containing > a UTF-8 string is required to show the mailbox name, but that form of > response is not permitted by the client". { "the mailbox name"? which string is that? } > If the SMTP client does not support the UTF8SMTPbisbis extension, but receives > a UTF-8 string in a reply, it may not be able to properly report the reply If a UTF-8 string is sent in a reply, when this extension is not in force, then it is a protocol violation. Period. > [RFC4952bis] Klensin, J. and Y. Ko, "Overview and Framework for > Internationalized Email", RFC 4952, July 2010. RFC4951 -> draft-ietf-eai-frmwrk-4952bis { It is not now, and never will be, RFC 4952; And RFC4952bis is currently dated September 2010. When it is an RFC, it will have a new number. Also, Internet Drafts, including -bis documents, usually follow a different citation labeling convention, such as I-D.rfc4952bis, to make clear that they are an I-D and not an RFC. } [1] draft-ietf-eai-frmwrk-4952bis-10 [2] draft-ietf-eai-rfc5335bis-03 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Wed Dec 22 10:09:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mgKG9c/gWb6yXrkNacHqTGcIIEx1fZwdJJ2oemn7EBE=; b=ouWRplaVcxdpWHtQknwuz/4RfsDgTv5PCyZYgV/Z0CrvuSBUxfEbCSs8pRscEu9eW7 IEyno24F4oT8WrMwQyUvldBSOKDnnd7XNxy8CgXOwzEZJs2TqNws4T4Y8/63HMEABJoC YGPtV2ct38z60i8WYDotABc42sBc2aAounMSo= 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=V2DkssJFO1EzI+GoRXLSjxB86w5n3uEIPiCbjDvXvrY+LuKGwndt4k2QGQs/lditlp HXviFBtABeaLsqWoEkDQPgB6Au503ToQdEGp1LZVRamJlJbNVmH/9aepavlxD/883VUV WPVKauUGDFpkeGle8otm8Z0snefpwPfQ16vgE= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> <1292958219.2800.22.camel@destiny> Date: Wed, 22 Dec 2010 18:11:47 +0000 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=0016e644caf0c57c01049803af96 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 18:09:52 -0000 --0016e644caf0c57c01049803af96 Content-Type: text/plain; charset=ISO-8859-1 [We seem to have dropped off the mailing lists, Jeffrey suggested I post this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelman wrote: > On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > > > No, there is no reliance on DNSSEC here, ideally the relationship is > > authenticated end-to-end using an EV cert. > > > > > > DNSSEC would be acceptable however. > > > > I don't follow. Your example shows an advertisement to service > providers that users from example.com can be authenticated to the SP by > using one of two authentication services. > Yes, it is assumed that there is some means of authenticating this binding, I did not specify what. > Unless I'm misunderstanding > you, this is about how the SP knows who to trust, and _not_ about how > the user's software talks to the user's identity provider. Thus EV is > really mostly irrelevant, since EV is about being able to make claims > that are really only meaningful when the relying party is controlled by > a human (the green bar is pretty, but I've yet to see an email server > that evaluates users' credentials on the basis of what color location > bar it sees). > You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the issuer applied validation practices that ensure a measure of accountability. > So, to accept a user's credentials, the SP needs to know two things: > 1) Is the assertion of user identity authentic? > 2) Does the assertion of user identity come from an authorized entity? > > The answer to (1) is provided by the authentication protocol in use, > which may well be public-key based. But that's not the part I'm worried > about. > > I am worried about (2). You show an example of one way to answer part > or all of (2). But you don't show how that answer is itself > authenticated. DNSSEC is certainly an acceptable answer to that, modulo > a whole bunch of conditions and issues that I'm willing to handwave > away, for now. But I don't think it can be the _only_ answer, for > reasons I've already raised. So, what's the other answer? > If there is a federated mechanism, there is going to have to be some registry of federation points available somewhere. We could use fred#facebook, jim#google and so on. But if there are friendly user identifiers and multiple auth providers there are going to be multiple repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to authenticate the in-zone data. How you authenticate the server when you arrive at it is another matter entirely. My view is that authentication providers should be considered to require substantial levels of infrastructure and planning. I totally reject the view floated in OpenID that it should be a design requirement that some fred in a shed can whack an authentication provider together from some Perl scripts without even bothering to upgrade to a recent version of perl. > > I'd be much happier to see a model wherein, at registration > > time, I tell > > a service my public key, and then it uses public-key > > cryptography to > > authenticate me in the future. Unfortunately, there are a > > number of > > practical problems there, such as dealing with multiple > > clients per > > user, kiosks, reinstalling machines, stolen credentials, etc., > > and it's > > really preferable to avoid having every service provider deal > > with those > > issues, rather than a much smaller number of authentication > > providers. > > > > Raw public keys work less well than people think here. > > > Raw public keys, usually wrapped in the completely unnecessary trappings > of a self-signed certificate, work surprisingly well in a wide variety > of circumstances. But they basically require first-order one-to-one > relationships between every client and every service provider, with all > the trappings required to deal with loss or compromise of the key, and > that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client to the authentication service. Less well as a means of federated authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds really convincing until you realize that they have not thought the problem through at all. > > To make a binding to a person you need infrastructure like I am > > describing here. > > > Not necessarily. I could imagine an infrastructure in which a user > authenticates to some key-management service, which then hands the user > his private key (the key belongs to the user, not the key-management > service, so revealing it to the user is OK). The user then uses that > key for authentication with whatever other services he wants. In fact, > to services other than the key-management service, this is > indistinguishable from the user having had the key all along. Of > course, it does involve the user handing his private key to some other > service, which has its own problems. > I don't like that approach because in my view a private key is something that should only ever exist in one place where it is created and later destroyed. I prefer an approach where the client-authentication provider authentication uses whatever tool is best and then the authentication provider supplies some form of token that can be used for authentication to at least one third party. That token could use public key, but symmetric is sufficient and more efficient. -- Website: http://hallambaker.com/ --0016e644caf0c57c01049803af96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[We seem to have dropp= ed off the mailing lists, Jeffrey suggested I post this which shows where w= e ended up.]

On Wed, Dec 22, 2010 at 3:02 AM, Jef= frey Hutzelman=A0<jhutz@cmu.edu>wrote:
On= Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote:

<= div class=3D"im" style=3D"color: rgb(80, 0, 80); ">> No, there is no rel= iance on DNSSEC here, ideally the relationship is
> authenticated end-to-end using an EV cert.
>
>
> DNS= SEC would be acceptable however.
>

I don't follow. =A0Your exam= ple shows an advertisement to service
providers that users from=A0example.com=A0can be authenticate= d to the SP by
using one of two authentication services.

Yes, it is assumed that there is some means of authenticatin= g this binding, I did not specify what.

=A0
=A0Unless I'm misunderstanding
you, this is about how the SP knows w= ho to trust, and _not_ about how
the user's software talks to the us= er's identity provider. =A0Thus EV is
really mostly irrelevant, sinc= e EV is about being able to make claims
that are really only meaningful when the relying party is controlled by
= a human (the green bar is pretty, but I've yet to see an email serverthat evaluates users' credentials on the basis of what color location=
bar it sees).

You do not understa= nd the purpose of EV then.=A0

EV is about accounta= bility. The green bar is displayed because the issuer applied validation pr= actices that ensure a measure of accountability.=A0

=A0=
So, to accept a user's credentials, the SP needs to know two things:1) Is the assertion of user identity authentic?
2) Does the assertion o= f user identity come from an authorized entity?

The answer to (1) is= provided by the authentication protocol in use,
which may well be public-key based. =A0But that's not the part I'm = worried
about.

I am worried about (2). =A0You show an example of = one way to answer part
or all of (2). =A0But you don't show how that= answer is itself
authenticated. =A0DNSSEC is certainly an acceptable answer to that, modulo<= br>a whole bunch of conditions and issues that I'm willing to handwave<= br>away, for now. =A0But I don't think it can be the _only_ answer, for=
reasons I've already raised. =A0So, what's the other answer?

If there is a federated mechanism, ther= e is going to have to be some registry of federation points available somew= here. We could use fred#facebook, jim#google and so on. But if there are fr= iendly user identifiers and multiple auth providers there are going to be m= ultiple repositories to disambiguate.

So there is going to be some PKI involved however you d= o it.


My preference is to use DNS f= or the signaling layer and DNSSEC to authenticate the in-zone data. How you= authenticate the server when you arrive at it is another matter entirely.= =A0

My view is that authentication providers should be cons= idered to require substantial levels of infrastructure and planning. I tota= lly reject the view floated in OpenID that it should be a design requiremen= t that some fred in a shed can whack an authentication provider together fr= om some Perl scripts without even bothering to upgrade to a recent version = of perl.

=A0=
> =A0 =A0 =A0 =A0 I'd be much happier to see a model wherein, a= t registration
> =A0 =A0 =A0 =A0 time, I tell
> =A0 =A0 =A0 =A0= a service my public key, and then it uses public-key
> =A0 =A0 =A0 = =A0 cryptography to
> =A0 =A0 =A0 =A0 authenticate me in the future. = =A0Unfortunately, there are a
> =A0 =A0 =A0 =A0 number of
> =A0 =A0 =A0 =A0 practical problems t= here, such as dealing with multiple
> =A0 =A0 =A0 =A0 clients per
= > =A0 =A0 =A0 =A0 user, kiosks, reinstalling machines, stolen credential= s, etc.,
> =A0 =A0 =A0 =A0 and it's
> =A0 =A0 =A0 =A0 really preferable to avoid having every service provid= er deal
> =A0 =A0 =A0 =A0 with those
> =A0 =A0 =A0 =A0 issues, = rather than a much smaller number of authentication
> =A0 =A0 =A0 =A0= providers.
>
> Raw public keys work less well than people thin= k here.
>
Raw public keys, usually wrapped in the completely unnecessar= y trappings
of a self-signed certificate, work surprisingly well in a wi= de variety
of circumstances. =A0But they basically require first-order o= ne-to-one
relationships between every client and every service provider, with all
= the trappings required to deal with loss or compromise of the key, and
t= hat simply doesn't scale to the Internet.

CardSpace works perfectly well as a method of authenticating the= client to the authentication service. Less well as a means of federated au= thentication.

Various people have proposed 'Ca= rdSpace' in the cloud. Which sounds really convincing until you realize= that they have not thought the problem through at all.

=A0=
> To make a binding to a person you need infrastructure like I am> describing here.
>
Not necessarily. =A0I could imagin= e an infrastructure in which a user
authenticates to some key-management= service, which then hands the user
his private key (the key belongs to the user, not the key-management
ser= vice, so revealing it to the user is OK). =A0The user then uses that
key= for authentication with whatever other services he wants. =A0In fact,
t= o services other than the key-management service, this is
indistinguishable from the user having had the key all along. =A0Of
cour= se, it does involve the user handing his private key to some other
servi= ce, which has its own problems.

I don't= like that approach because in my view a private key is something that shou= ld only ever exist in one place where it is created and later destroyed.
I prefer an approach where the client-authentication provider auth= entication uses whatever tool is best and then the authentication provider = supplies some form of token that can be used for authentication to at least= one third party.

That token could use public key, but symmetric is suffi= cient and more efficient.
--0016e644caf0c57c01049803af96-- From dhc@dcrocker.net Wed Dec 22 10:11:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889C93A6A58; Wed, 22 Dec 2010 10:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snNxGobXMIJz; Wed, 22 Dec 2010 10:11:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 99F6A3A6909; Wed, 22 Dec 2010 10:11:46 -0800 (PST) Received: from [192.168.1.43] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBMIDa0K013617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 10:13:42 -0800 Message-ID: <4D123FD1.2080906@dcrocker.net> Date: Wed, 22 Dec 2010 10:13:37 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ima@ietf.org References: <4D123DC0.2050501@dcrocker.net> In-Reply-To: <4D123DC0.2050501@dcrocker.net> 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, 22 Dec 2010 10:13:42 -0800 (PST) Cc: Alexey.Melnikov@isode.com, draft-ietf-eai-rfc5336bis@tools.ietf.org, Apps Discuss , SM Subject: Re: [apps-discuss] (private) draft review of: draft-ietf-eai-rfc5336bis-07.txt (v3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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, 22 Dec 2010 18:11:47 -0000 Folks -- Apologies for the pre-posting detritus on the subject line. Obviously it was (no longer) a private message. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Wed Dec 22 13:37:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB5B3A6B37; Wed, 22 Dec 2010 13:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehVB8lML9y+F; Wed, 22 Dec 2010 13:37:36 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D3FB93A68BE; Wed, 22 Dec 2010 13:37:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlomAIf+EU3GmAcF/2dsb2JhbACUVYE0jhAIc6klgQgCiGuHKC6IXIJyglcEiwSDHQYUh3s X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="51313747" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Dec 2010 16:39:27 -0500 X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="559921885" Received: from unknown (HELO 307622ANEX1.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2010 16:39:26 -0500 Received: from mail pickup service by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC; Wed, 22 Dec 2010 22:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBA220.9C973700" Received: from 307622ANEX2.global.avaya.com ([135.64.140.15]) by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:13:08 +0100 Received: from co300216-co-erhwest.avaya.com ([198.152.7.5]) by 307622ANEX2.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:11:58 +0100 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by co300216-co-erhwest.avaya.com with ESMTP; 22 Dec 2010 13:11:58 -0500 Received: from mail.ietf.org ([64.170.98.32]) by co300216-co-ierwest.avaya.com with ESMTP; 22 Dec 2010 13:11:57 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13843A6B37; Wed, 22 Dec 2010 10:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -0800 (PST) Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 22 Dec 2010 18:13:08.0215 (UTC) FILETIME=[E2B2A070:01CBA203] Date: Wed, 22 Dec 2010 19:11:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation Thread-Index: AcuiA7mTehF0T8iMSHeVmmOflr3UqQ== References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com><4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com><4D051731.1020400@isode.com> <4D054041.7010203@cisco.com><0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com><2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com><2229.1292239384.281779@puncture><96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org><2229.1292253372.639419@puncture><11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com><1292958219.2800.22.camel@destiny> From: "Phillip Hallam-Baker" Sender: To: "Jeffrey Hutzelman" Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 21:37:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA220.9C973700 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBA220.9C973700" ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [We seem to have dropped off the mailing lists, Jeffrey suggested I post = this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelmanwrote: On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > No, there is no reliance on DNSSEC here, ideally the relationship is > authenticated end-to-end using an EV cert. > > > DNSSEC would be acceptable however. > I don't follow. Your example shows an advertisement to service providers that users fromexample.com can be = authenticated to the SP by using one of two authentication services. Yes, it is assumed that there is some means of authenticating this = binding, I did not specify what. Unless I'm misunderstanding you, this is about how the SP knows who to trust, and _not_ about how the user's software talks to the user's identity provider. Thus EV is really mostly irrelevant, since EV is about being able to make claims that are really only meaningful when the relying party is controlled by a human (the green bar is pretty, but I've yet to see an email server that evaluates users' credentials on the basis of what color location bar it sees). You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the = issuer applied validation practices that ensure a measure of = accountability. So, to accept a user's credentials, the SP needs to know two things: 1) Is the assertion of user identity authentic? 2) Does the assertion of user identity come from an authorized entity? The answer to (1) is provided by the authentication protocol in use, which may well be public-key based. But that's not the part I'm worried about. I am worried about (2). You show an example of one way to answer part or all of (2). But you don't show how that answer is itself authenticated. DNSSEC is certainly an acceptable answer to that, modulo a whole bunch of conditions and issues that I'm willing to handwave away, for now. But I don't think it can be the _only_ answer, for reasons I've already raised. So, what's the other answer? If there is a federated mechanism, there is going to have to be some = registry of federation points available somewhere. We could use = fred#facebook, jim#google and so on. But if there are friendly user = identifiers and multiple auth providers there are going to be multiple = repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to = authenticate the in-zone data. How you authenticate the server when you = arrive at it is another matter entirely. My view is that authentication providers should be considered to require = substantial levels of infrastructure and planning. I totally reject the = view floated in OpenID that it should be a design requirement that some = fred in a shed can whack an authentication provider together from some = Perl scripts without even bothering to upgrade to a recent version of = perl. > I'd be much happier to see a model wherein, at registration > time, I tell > a service my public key, and then it uses public-key > cryptography to > authenticate me in the future. Unfortunately, there are a > number of > practical problems there, such as dealing with multiple > clients per > user, kiosks, reinstalling machines, stolen credentials, etc., > and it's > really preferable to avoid having every service provider deal > with those > issues, rather than a much smaller number of authentication > providers. > > Raw public keys work less well than people think here. > Raw public keys, usually wrapped in the completely unnecessary trappings of a self-signed certificate, work surprisingly well in a wide variety of circumstances. But they basically require first-order one-to-one relationships between every client and every service provider, with all the trappings required to deal with loss or compromise of the key, and that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client = to the authentication service. Less well as a means of federated = authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds = really convincing until you realize that they have not thought the = problem through at all. > To make a binding to a person you need infrastructure like I am > describing here. > Not necessarily. I could imagine an infrastructure in which a user authenticates to some key-management service, which then hands the user his private key (the key belongs to the user, not the key-management service, so revealing it to the user is OK). The user then uses that key for authentication with whatever other services he wants. In fact, to services other than the key-management service, this is indistinguishable from the user having had the key all along. Of course, it does involve the user handing his private key to some other service, which has its own problems. I don't like that approach because in my view a private key is something = that should only ever exist in one place where it is created and later = destroyed. I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party. That token could use public key, but symmetric is sufficient and more = efficient. -- Website:http://hallambaker.com/ ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[We seem to have dropped = off the mailing lists, Jeffrey suggested I post this which shows where = we ended up.]

On Wed, Dec 22, 2010 at = 3:02 AM, Jeffrey Hutzelman<jhutz@cmu.edu>wrote:
I don't follow. Your example shows = an advertisement to service
providers that users fromexample.comcan = be authenticated to the SP by
using one of two authentication = services.

Yes, it is assumed that there is some means of = authenticating this binding, I did not specify what.
Unless I'm misunderstanding
you, this is about how the SP knows = who to trust, and _not_ about how
the user's software talks to = the user's identity provider. Thus EV is
really mostly = irrelevant, since EV is about being able to make claims
that are really only meaningful when the relying party is controlled = by
a human (the green bar is pretty, but I've yet to see an email = server
that evaluates users' credentials on the basis of what = color location
bar it sees).

You do not = understand the purpose of EV then.

EV is about = accountability. The green bar is displayed because the issuer applied = validation practices that ensure a measure of accountability.
So, to accept a user's credentials, the SP needs to know two = things:
1) Is the assertion of user identity authentic?
2) Does = the assertion of user identity come from an authorized = entity?

The answer to (1) is provided by the authentication = protocol in use,
which may well be public-key based. But that's not the part I'm = worried
about.

I am worried about (2). You show an example of = one way to answer part
or all of (2). But you don't show how that = answer is itself
authenticated. DNSSEC is certainly an acceptable answer to that, = modulo
a whole bunch of conditions and issues that I'm willing to = handwave
away, for now. But I don't think it can be the _only_ = answer, for
reasons I've already raised. So, what's the other = answer?

If there is a = federated mechanism, there is going to have to be some registry of = federation points available somewhere. We could use fred#facebook, = jim#google and so on. But if there are friendly user identifiers and = multiple auth providers there are going to be multiple repositories to = disambiguate.

So there is going to be some PKI involved however = you do it.


My preference is to = use DNS for the signaling layer and DNSSEC to authenticate the in-zone = data. How you authenticate the server when you arrive at it is another = matter entirely.

My view is that authentication providers should be = considered to require substantial levels of infrastructure and planning. = I totally reject the view floated in OpenID that it should be a design = requirement that some fred in a shed can whack an authentication = provider together from some Perl scripts without even bothering to = upgrade to a recent version of perl.
> I'd be much happier to see a model wherein, at = registration
> time, I tell
> a service my public = key, and then it uses public-key
> cryptography to
> = authenticate me in the future. Unfortunately, there are a
> number of
> practical problems there, such as dealing = with multiple
> clients per
> user, kiosks, = reinstalling machines, stolen credentials, etc.,
> and = it's
> really preferable to avoid having every service provider = deal
> with those
> issues, rather than a much = smaller number of authentication
> providers.
>
> = Raw public keys work less well than people think here.
>
Raw public keys, usually wrapped in the completely = unnecessary trappings
of a self-signed certificate, work surprisingly = well in a wide variety
of circumstances. But they basically require = first-order one-to-one
relationships between every client and every service provider, with = all
the trappings required to deal with loss or compromise of the = key, and
that simply doesn't scale to the = Internet.

CardSpace works perfectly well as a method of authenticating = the client to the authentication service. Less well as a means of = federated authentication.

Various people have = proposed 'CardSpace' in the cloud. Which sounds really = convincing until you realize that they have not thought the problem = through at all.
> To make a binding to a person you need infrastructure like I = am
> describing here.
>
Not necessarily. I could = imagine an infrastructure in which a user
authenticates to some = key-management service, which then hands the user
his private key (the key belongs to the user, not the = key-management
service, so revealing it to the user is OK). The user = then uses that
key for authentication with whatever other services he = wants. In fact,
to services other than the key-management service, = this is
indistinguishable from the user having had the key all along. = Of
course, it does involve the user handing his private key to some = other
service, which has its own = problems.

I don't like that approach = because in my view a private key is something that should only ever = exist in one place where it is created and later destroyed.

I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party.

That token could use public key, but symmetric is = sufficient and more efficient.
 ------_=_NextPart_002_01CBA220.9C973700-- ------_=_NextPart_001_01CBA220.9C973700 Content-Type: text/plain; name="ATT2808037.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2808037.txt Content-Disposition: inline; filename="ATT2808037.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlz Y3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== ------_=_NextPart_001_01CBA220.9C973700-- From ned.freed@mrochek.com Wed Dec 22 18:00:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE9D3A6B73; Wed, 22 Dec 2010 18:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o94ZlK-EsVdQ; Wed, 22 Dec 2010 18:00:17 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 747FF3A6957; Wed, 22 Dec 2010 18:00:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVQAP22BVK00D8M6@mauve.mrochek.com>; Wed, 22 Dec 2010 18:02:13 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVQAMJ9A8W007CHU@mauve.mrochek.com>; Wed, 22 Dec 2010 18:02:10 -0800 (PST) Message-id: <01NVQAP0UQRU007CHU@mauve.mrochek.com> Date: Wed, 22 Dec 2010 18:01:15 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 22 Dec 2010 18:24:11 +0100 (CET)" Sender: Ned Freed MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: apps-discuss@ietf.org, ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org, Alexey.Melnikov@isode.com, SM DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1293066799; bh=Feemn/cXE+aVE7HLK0R4oHPQIAS3TSAWB9Mo5Lr55is=; h=Message-id:Date:From:Subject:In-reply-to:Sender:MIME-version: Content-type:References:To; b=jD8FPwA5C5AtLZlBdWz1kTY25Av4FQAqPbvUdY7U5+l7SQfRAa1HivY4eon38U4p2 oJ7zlpFucd4qwNXyiQeQbjDossE5uHwcY4tMbgj4AYaov0FMFe9O5nYHI27yHrrP5q lwGRGvyhw35vkV6VJ9hDj5uTfuWOO1b+HQ7YkdH0= X-Mailman-Approved-At: Thu, 23 Dec 2010 08:21:58 -0800 Subject: Re: [apps-discuss] [EAI] apps-team review of draft-ietf-eai-rfc5336bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 02:00:19 -0000 I was asked to review draft-ietf-eai-rfc5336bis-07.txt. I was also provided with a preliminary copy of the review Dave did, so these notes should be viewed as an addendum to Dave's review, not as a standalone critique. In particular, any failure to reiterate Dave's various points here should not be taken as disagreement with him; on the contrary, I am in agreement with almost all of his comments. Now for the specifics: (0) I cannot emphasize strongly enough how important it is to have a UTF8SMTP sort of parameter on the MAIL FROM to indicate that a message employing this extension is being submitted/relayed/delivered. This is especially important in the relay case - we do not want to require that relays grub through every message they receive looking for possible utf-8 so they can carry the negotiation of this extension forward, but that's exactly what the present proposal forces them to do. (1) 3.1 item 4 and 3.6.4.2 add an optional UTF8REPLY parameter to VRFY and EXPN. They do this by redefining the syntax to be: vrfy = "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF expn = "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF The original syntax for VRFY and EXPN given in RFC 5321 is: vrfy = "VRFY" SP String CRLF expn = "EXPN" SP String CRLF String = Atom / Quoted-string Atom = 1*atext It's not immediately obvious, but the new syntax is in fact a superset of the old. (uLocal-part subsumes local-part, which in turn allows atoms and quoted strings.) However, this change does much more than hang a parameter on the command; for the first time an entire address is permitted as an EXPN/VRFY argument. But no semantics are given for this significant syntax expansion, nor does this expansion appear to be within scope for EAI. A more reasonable syntax would be: vrfy = "VRFY" SP uString [ SP "UTF8REPLY" ] CRLF expn = "EXPN" SP uString [ SP "UTF8REPLY" ] CRLF uString = uAtom / uQuoted-string But this now fails along a different dimension: When adding a parameter capability to a command, it should be done in a general way, so that any future extensions can build on a cleanly specified foundation. Like so: vrfy = "VRFY" SP uString [ SP vrfy-parameters ] CRLF vrfy-parameters = esmtp-param *(SP esmtp-param) expn = "EXPN" SP uString [ SP expn-parameters ] CRLF expn-parameters = esmtp-param *(SP esmtp-param) uString = uAtom / uQuoted-string Of course this will add 555 as a possible response to VRFY/EXPN, and that needs to be noted. (2) In response to Dave's critique/query about why the parameter on VRFY and EXPN is needed, it's because these commands can appear outside of a transaction and thus there's not necessarily an indication that the client is prepared to accept UTF-8 responses. However, this brings up another issue, which is that a server that supports this extension needs a way to tell a client that doesn't that it cannot return a proper response to VRFY/EXPN without that parameter being specified. A new SMTP error status is needed, but the document only defines an extended status for this purpose; it doesn't specify a regular status code to use. (3) Section 3.2 says: 1. If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material to make them entirely ASCII and consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322 [RFC5322]. This is a bad idea no matter how you slice it. Such transformations depend on the availability of address mapping (from a UTF-8 address to an equivalent ASCII address) information; an agent being an MSA is neither necessary nor sufficient reason to have this information. But the bigger problem by far is defining what transformations are permissible. The present framework document is basically silent on what's allowed, so I for one have no idea what it means to be "consistent with the general provisions for changes by such servers" actually means. And unless you're willing to spell this out, I see this as practically guarnteeing a slew of interop problems. (4) Also from 3.2: 3. It may find an alternate route to the destination that permits UTF8SMTPbis. That route may be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 5321) or using other means available to the SMTP-sender. So you can use alternate MXes, but not alternate A records? I actually agree with this - an alternate A is presumably another address for the same host, so no point in trying it. But this needs to be spelled out. At an absolute minimum this needs to be accompanied by some security considerations text. The issue, I hope, is obvious: There are sites aplenty with large numbers of MX records and which won't support this extension any time soon. And all too often those MXes are *slow* to respond. So sending a message that causes them all to be tried is ... you get the idea. In fact I'm tempted to go one further and say that if an MX at a given priority is found not to support this extension, you SHOULD assume that MXes at lower priority don't either. (5) Consider this text from 3.5: Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and receives at least one non-ASCII address, the precise interpretation of "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is: Since when are the addresses in the envelope a predictor of the addresses that appear in the outermost header, let alone any enclosed message/rfc822 headers? Really, this could not be more fundamental: There's no requirement that envelope addresses appear in the outermost header or vice versa, and circumstances abound where the addresses in the header and envelope end up being partly or entirely disjoint. As such, while the use of UTF-8 in the envelope can be taken as an indication that this is an EAI message, the absence tells you nothing. Addrressing item (0) above and having a parameter on MAIL FROM addresses the technical side of this one, but the entire notion of coupling and confusion between envelope and header needs to be stamped out in this specification. (6) A bunch of the references are to bis-versions, but the actual cite is to the current RFC. One final comment. Several of the issues that have been raised are so fundamental that once they are addressed (point (0) especially), this document is almost certainly going to require another full review cycle. Ned From ned.freed@mrochek.com Wed Dec 22 18:07:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5AA3A6AA6; Wed, 22 Dec 2010 18:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBiGcP0j3C8I; Wed, 22 Dec 2010 18:07:34 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 93D233A6957; Wed, 22 Dec 2010 18:07:19 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVQAXTWAPC00FC49@mauve.mrochek.com>; Wed, 22 Dec 2010 18:09:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVQAMJ9A8W007CHU@mauve.mrochek.com>; Wed, 22 Dec 2010 18:09:15 -0800 (PST) Message-id: <01NVQAXSNK5E007CHU@mauve.mrochek.com> Date: Wed, 22 Dec 2010 18:03:33 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 22 Dec 2010 18:24:11 +0100 (CET)" Sender: Ned Freed MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: To: Claudio Allocchio DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1293067223; bh=hH6DXkCbJV6lEwbPJ3TFQPifXS5OfU0z3aN4i63hBUE=; h=Cc:Message-id:Date:From:Subject:In-reply-to:Sender:MIME-version: Content-type:References:To; b=e+BeQBALaRxEya6wlyokbn81pduiNeZPBuyLkoBgJpUQfUzYRnGPCDmZpZJT0HWMB xv+VfJPbASocH9RrHxVKObN+O9olfT668W27FPqEMuTQkudfgoufLxOqUdzgFPS+IS wECkM7fetEs4L1UH3JI4x6hJ8IrNwWB7/qM/Flt8= X-Mailman-Approved-At: Thu, 23 Dec 2010 08:22:04 -0800 Cc: Alexey.Melnikov@isode.com, draft-ietf-eai-rfc5336bis@tools.ietf.org, ima@ietf.org, apps-discuss@ietf.org, SM Subject: Re: [apps-discuss] [EAI] apps-team review of draft-ietf-eai-rfc5336bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 02:07:36 -0000 +1 to all of Claudio's points raised here. Ned > 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-eai-rfc5336bis > Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network) > Review Date: 2010-12-22 > IETF Last Call Date: N/A > IESG Telechat Date: N/A > Summary: > The document specifies how to apply internationalization to some SMTP > elements, and to some Header elements which depends from the SMTP elements. > However there seem to be a discrepancy from what the abstract states, and > what is elaborated into the document details: the document also deals with > quite a number of elements which involve bodyparts, and affect the whole > email legacy system, and beyond, such as logs, traces, and wherever email > addresses are used (certificates, etc.). This seems thus to go beyond what > the summary states, even this fact is not explicitly discussed. It is > unclear thus if this "update" of RFC5321 and RFC5322 is only limited in > scope or not. My reading of the document say it goes beyond, and implicitly > affects also what is being transported into the email system. This is thus a > serious issue to be solved before the document can go to the Standard Track. > Another big issue is about blending the boundaries of servers in the > transport system (MTAs), clients (UAs) and their roles, when the document > specify that servers shall use guessing techniques from looking into > bodyparts to understand if what they're transporting is internationalized > according to this specification or not. This is IMHO a basic violation of > the role distiction in the legacy email system, and affects the MIME model > al well. > The document quite often repeats rules from other specifications, AND > re-describes these rules. This is dangerous (it makes very difficult to keep > aligned documents, and will lead to different interpretations) and not > needed. > The full specification probably needs a serious "english language" revision, > because the language issues which I specified in "Minor Issues" seems to be > a non neglegible number. I'll try to identify as many as possible and > suggest changes. > Major Issues: > This specification updates a number of SMTP and Headers fields from RFC5321 > and RFC5322. However these fields are also used in Gatewaying to other email > systems, which are still existing. Section 3.7 in RFC5321 describes specific > cases. However this memo provides no clue on possible effect that > internationalized fields can have in case gatewaying occurs. Gatewaying > functions strongly rely on these values, and the introduction of these > modification should describe this scenario, too. I suggest to include a > specific section about these issues, and suggest at least a number of > possible actions which Gateways can take to survive this change. > The EAI WG charter states that in handling email message we shall be > "consistent with the long-term view that email with invalid addresses or > syntax should be rejected, rather than fixed up in transit between > submission servers and delivery servers.". However a number of sections in > the specification seem to contradict this, where they suggest actions, by > exammining message elements (in the SMTP and in the Headers and in the > Bodyparts) in order to try to deliver anyhow. This is a subtle line between > maximising the service chance to deliver, and "fixing" things during the > transaction, and it can encourage implementors to do many of these acions, > instead of stiching to the idea "not supported --> non delivery". > Major Issues by sections. > Abstract: > " This document specifies an SMTP extension for transport and delivery > of email messages with internationalized email addresses or header > information." > "internationalized" is not defined here in details. Sections 1 and 1.2 try > to do this, but the language is not crystal clear: "to permit > internationalized email addresses in envelopes, and UNICODE characters > (encoded in UTF-8) [RFC3629] in headers." Are addresses in envelopes (SMTP > envelopes!) also via UNICODE characters encoded in UTF-8? The reference to > "the framework document" seem to come too late in the text to ensure the > reader fully understand the relationship. > 3.2 The UTF8SMTPbis Extension > "An SMTP server that announces this extension MUST be prepared to > accept a UTF-8 string [RFC3629] in any position in which RFC 5321 > specifies that a mailbox can appear." > s/mailbox// (it's a definition!). > The specification does NOT suggest a preferred order among the 3 possible > options when the SMTP server state it does not support UTF8SMTPbis. Having 3 > "MAY" options at the same level can create a very uncertain email service > behaviour, and a very bad user's experience! This is consistent with what > happens in other cases for other "options" in the email system (like DSNs > and MDNs), but there should be at least an informative document describing > the various scenarios, and giving some guidance to implementors in order to > avoid totally incosistent behaviours. > If we do not specify a consistent procedure to try the 3 options, in many > cases we will just in practice break the concept of universal email common > service, creating islands which do not talk to each other. The 3.6.2 section > gives some suggestions about this, but this is limited to MX listed servers > for a single domain. My concern is more general. In 3.6.2 anyhow the > language should be more precise. It states "orgnisations", which something > totally undefined from a protocol point of view. MX records refer to > "domains", not to "organisations". > 3.3. Extended Mailbox Address Syntax > The definition of > uAtom = 1*ucharacter > ; Replace Atom in RFC 5321, Section 4.1.2 > ucharacter = atext / UTF8-non-ascii > atext = > permits that uAtom is either an atext OR an UTF8-non-ascii... which in the > end allows a uMailbox to be a mixed contruction where some uAtom is in > atext, while some other uAtom is in UTF8-non-ascii AT THE SAME TIME, e.g. a > construct like > some-ascii.some-UTF8-non-ascii@some-UTF8-non-ascii.some-ascii.tld > is allowed. However the distinction here seems to be unneeded, as ASCII is a > subset of UTF8. > Section 3.6 tries to clarify that this is not allowed; owever there is > normative language there apart on SHOULD for the domain name. I think this > shold be fixed with a clearer normative specfication. > This of course applies also to all other tokens where uAtom is used. > 3.5 Body Parts and SMTP Extensions > I have problems in understanding why an SMTP server should peek extensively > into the message geing transfered to understand that it is handling an > interationalzed message. "There is no ESMTP parameter to assert that a > message is an internationalized message." in my opinion should be fixed in > another way, by ADDING an appropriate ESMTP parameter to state this! This > will solve already in the SMTP dialogue many isses which in this > specification are handeled by guessing techinques. > 3.6.1 "the server normally sends..." --> "the server sends" (sorry... we do > not like ABnormal servers!) :-) > Minor Issues: > 1. Introduction > The sentence "This document use this mechanism to support an > internationalized email address." defintly needs a better form; if you do > not know already know what we are talking about, it can be misleading. > "This document uses this mechanism to allow internationalized email > addresses support in SMTP elements." > 3.1 Framework for the Internationalization Extension > - bullet point 3. I do not see any need to state that clients MUST reject... > and MUST be fully compliant... etc. This is implicit in any specification. > If there is a specific need to add this detailed behaviour (to prevent wrong > implementions? why?) either we shall ensure the text is clear and > unambiguous, or we shall add an Implementers Note, as it was done in some > other RFCs. > 3.2 The UTF8SMTPbis Extension > same general comment as per 3.1: in general the section states behaviours > which do not need to be specified again, because they're alredy described > seomewhere else. This might also become a Major issue if the specification > of such behaviours are changed elsewhere. Just poit to extrnal references. > (it seems editors are worried of implmentors which do not fully undesrtand > or know the other email specifications... ) > 3.3. Extended Mailbox Address Syntax > What does the sentence "..., using the production for a mailbox and those > productions on which it depends." mean? I assume you meant , is > this correct? > 5. Security Considerations > there is one more issue: as internationalized items will also result into > logs and traces, their presence may affects trouble ticket systems used by > security operations teams (CERTs/CSIRTs). And they also can affect quick > handling of incidents, has it may require more time to correctly read and > understand logs and traces if they are not in current ascii form. This might > even be a Major Issue. I propose adding this text in the section, besides > pointing to the exteral reference: > ---------------------- start of added text > Beyond the use inside the email global system (in SMTP envelopes and message > headers), internationalized email addresses will also show up inside other > scenarios, in particular: > - the logging systems of SMTP transactions and other logs to monitor > the email systems; > - the trouble ticket systems used by Security Teams to manage security > incidents, when an email address is involved > This will likely require extending support for full UTF8 also into these > systems, in order to avoid problems, which could cause also important loss > of data, or require to provide an adequate mechanism to map non ASCII > strings into them. > Another Security aspect to consider is related to the ability by Security > Team members to quickly understand/read and identify email addresses from > the logs, when they are tracking an incident. Mechanims to automatically and > quickly provide the origin or ownership of an internationalized email > address shall implemented for use also by log readers which cannot read > easily non-ASCII information. > --------------------------- end of added text > Also, in Security Consideration, there is no mention of the fact that we are > changing VRFY/EXPN commands to include internationalized addresses. > VRFY/EXPN commands can exist ALSO in an SMTP transaction which is not > supoused to transfer an email messages between MTAs. And their use has also > do to with Security. Here is an additional text for this: > ---------------------- start of added text > The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions > where there is no message to transfer (by tools used to take automated > actions in case potential spam messages are identified). RFC5321 section 3.5 > and 7.3 give some detailed description of use and possible behaviours. > Implementation of internationalized addrsses can affect also logs and > actions by these tools. > --------------------------- end of added text > Nits: > see > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-eai-rfc5336bis-07.txt > Best Regards! > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From aaron@serendipity.cx Thu Dec 23 21:08:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92C33A68E7; Thu, 23 Dec 2010 21:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.643 X-Spam-Level: X-Spam-Status: No, score=-101.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLMF42jHQdVm; Thu, 23 Dec 2010 21:08:45 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id EF0433A68E0; Thu, 23 Dec 2010 21:08:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id DB3C6110196; Thu, 23 Dec 2010 21:17:21 -0800 (PST) Received: by vws7 with SMTP id 7so2622349vws.31 for ; Thu, 23 Dec 2010 21:10:45 -0800 (PST) Received: by 10.220.177.7 with SMTP id bg7mr992655vcb.124.1293167445259; Thu, 23 Dec 2010 21:10:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.179.129 with HTTP; Thu, 23 Dec 2010 21:10:25 -0800 (PST) From: Aaron Stone Date: Thu, 23 Dec 2010 21:10:25 -0800 Message-ID: To: akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, ishibashi.keisuke@lab.ntt.co.jp, ipfix-chairs@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org, dromasca@avaya.com, quittek@neclab.eu Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] apps-team review of draft-ietf-ipfix-mediators-framework-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 05:08:46 -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-ipfix-mediators-framework-09 Title: IPFIX Mediation: Framework Reviewer: Aaron Stone Review Date: 2010-12-18 IETF Last Call Date: unknown IESG Telechat Date: unknown Summary: This is a very well-written document, with truly excellent ASCII art, that appears ready for publication. Its intended status as Informational seems mandatory, given that the document does not use RFC 2119 keywords to directly specify behaviors. Major issues: I would say not using RFC 2119 is a major issue, but since the intended status is Informational, I don't see a problem. Minor issues: Section 2: -- I suggest making three subsections, at the paragraphs that begin: "The following terms are used in this document to describe the architectural entities used by IPFIX Mediation." "Specific Intermediate Processes are described below." Section 2: -- The definition of "IPFIX Mediator" is core to this document, so it seems like it should be at the top of the section, and probably in the introduction. Section 3: -- Is the term "documents" understood in a particular way in IPFIX that a familiar reader would understand that you don't mean "RFC document"? Or do you actually mean RFC documents, and you're listing off which other RFCs one should read in order to better understand what's going on here? If the latter, consider a text change to directly state that you are listing other RFCs that the reader should also read. Section 5.3.2.3: -- under "Temporal composition", perhaps replace "Flow duration" with simply "duration"? If "Flow Duration" is a specific term, it should be defined earlier. Section 6: -- should "Collector input" be "Collector Input"? Or is it maybe "Collector's input"? I found the complex string of terms to be confusing. Section 9: -- Please flip the first sentence around: "As IPFIX Mediators act as both IPFIX Collection Processes and Exporting Processes, the Security Considerations for IPFIX Files [RFC5655] apply to IPFix Mediators that write IPFIX Files or use them for internal storage." -- What are the specific considerations? Is that what the next paragraph is about? ...oh, I see, the third paragraph / sentence by itself here. Consider rephrasing this so that the reader is not confused for a few minutes, as this reviewer has been :) Section 9.4: -- Why is this a security consideration and not a fundamental part of the specification, and explained in Section 3 or 4? Nits: Section 5.1: -- Should "Sampling parameters" be "Sampling Parameters"? Section 5.2: -- add a colon after "following" before the list. Section 5.2: -- rewrite the last sentence of the first bullet item as "...become invalid (e.g., due to incoming session failure)." Section 5.3.2.1: -- second to last paragraph, last sentence, remove the comma in "outgoing side, only". Section 5.3.2.4: -- add a colon after "following" before the list. Section 5.3.2.5: -- In "Correlation between Data Record and other meta data", use either a single word, "metadata" or a hyphenated word, "meta-data" (the RFC Editor probably has a preferred usage). Section 6: -- add a color after "ways" before the list. Cheers, Aaron From klensin@jck.com Sat Dec 25 12:18:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA0D3A696B; Sat, 25 Dec 2010 12:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icONbDRawxMl; Sat, 25 Dec 2010 12:18:11 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 549B13A6863; Sat, 25 Dec 2010 12:18:10 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PWab2-000FG7-9B; Sat, 25 Dec 2010 15:20:08 -0500 Date: Sat, 25 Dec 2010 15:20:07 -0500 From: John C Klensin To: Ned Freed Message-ID: <227C2506194609988B81BE4F@PST.JCK.COM> In-Reply-To: <01NVQAP0UQRU007CHU@mauve.mrochek.com> References: <01NVQAP0UQRU007CHU@mauve.mrochek.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: Alexey.Melnikov@isode.com, draft-ietf-eai-rfc5336bis@tools.ietf.org, ima@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] RFC5336 and VRFY/EXPN (was: Re: [EAI] apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 20:18:13 -0000 (writing as a personal opinion, not speaking for the WG. Shawn and others have already addressed parts of this, but, for completeness...) --On Wednesday, December 22, 2010 18:01 -0800 Ned Freed wrote: >... > (1) 3.1 item 4 and 3.6.4.2 add an optional UTF8REPLY parameter > to VRFY and EXPN. They do this by redefining the syntax to > be: > > vrfy = "VRFY" SP ( uLocal-part / uMailbox ) > [ SP "UTF8REPLY" ] CRLF > > expn = "EXPN" SP ( uLocal-part / uMailbox ) > [ SP "UTF8REPLY" ] CRLF > > The original syntax for VRFY and EXPN given in RFC 5321 is: > > vrfy = "VRFY" SP String CRLF > expn = "EXPN" SP String CRLF > String = Atom / Quoted-string > Atom = 1*atext > > It's not immediately obvious, but the new syntax is in > fact a superset of the old. (uLocal-part subsumes > local-part, which in turn allows atoms and quoted > strings.) However, this change does much more than hang a > parameter on the command; for the first time an entire address > is permitted as an EXPN/VRFY argument. But no semantics > are given for this significant syntax expansion, nor does > this expansion appear to be within scope for EAI. > > A more reasonable syntax would be: > > vrfy = "VRFY" SP uString [ SP "UTF8REPLY" ] CRLF > > expn = "EXPN" SP uString [ SP "UTF8REPLY" ] CRLF > > uString = uAtom / uQuoted-string Yes. I don't think the above mess was intentional. In fairness to the authors, the ABNF has been changed too many times by too many people and I think the situation above is a side-effect. As you point out, the syntax changes may not be adequate (see below). > But this now fails along a different dimension: When > adding a parameter capability to a command, it should be > done in a general way, so that any future extensions can > build on a cleanly specified foundation. Like so: > > vrfy = "VRFY" SP uString [ SP vrfy-parameters ] CRLF > vrfy-parameters = esmtp-param *(SP esmtp-param) > > expn = "EXPN" SP uString [ SP expn-parameters ] CRLF > expn-parameters = esmtp-param *(SP esmtp-param) > > uString = uAtom / uQuoted-string > > Of course this will add 555 as a possible response to > VRFY/EXPN, and that needs to be noted. Right. See below. In addition, one must have a session for which mail transactions are permitted (i.e., EHLO must have been sent) in order to use any parameters at all. RFC 5321, Section 4.1.4, explicitly permits sending VRFY or EXPN without first having EHLO in the session. So there is another implicit requirement in all of this that should almost certainly be made explicit. (I think this is the topic about handshaking that Dave and Shawn have been circling around, but I'm not sure). > (2) In response to Dave's critique/query about why the > parameter on VRFY and EXPN is needed, it's because these > commands can appear outside of a transaction and thus > there's not necessarily an indication that the client is > prepared to accept UTF-8 responses. Yes, exactly. > However, this brings up > another issue, which is that a server that supports this > extension needs a way to tell a client that doesn't that > it cannot return a proper response to VRFY/EXPN without > that parameter being specified. A new SMTP error status is > needed, but the document only defines an extended status > for this purpose; it doesn't specify a regular status code to > use. If we go down this path, the WG clearly needs to reexamine whether such a code is necessary. I think you have made a persuasive case, but I can't speak for the WG. Indeed, this has all gotten sufficiently complex that I think perhaps the WG should reexamine its decision to handle the "VRFY and EXPN with possible non-ASCII responses" situation by parameterizing those commands rather than introducing new commands, say VRF8 and EXP8. IIR, the WG did consider that alternative (long ago) and conclude that adding a parameter was the more straightforward option. But, perhaps, given the various complexities that have emerged, that was not the right decision. With other commands, such as MAIL and RCPT, we've already got a history of parameters and the base (821/5321) syntax is very clearly delimited. By contrast, I certainly remember seeing VRFY followed by unquoted strings with blanks in them in the wild (e.g., arrangements like VRFY Ned Freed ) and some servers tolerating them in the name of robustness or in memory of 821, which had VRFY ::= | ::= | "\" ::= any one of the 128 ASCII characters, but not any or ::= any one of the 128 ASCII characters (no exceptions) which makes VRFY Dave\ Crocker perfectly valid. I don't know if similar examples still occur and with what frequency, but... In addition, if we handle EAI-extended VRFY and EXPN with parameters, we end up in the odd situation in which the no-parameter versions can be issued without mail session initialization (the EHLO command) but the extended, parameterized ones require a previously-initialized session. The MAIL and RCPT commands dn't have an issue because they require session initialization anyway. That restriction on extended VRFY and EXPN certainly works technically, but isn't going to be the easiest thing to explain and might cause some "interesting" behavior if implementations screw it up or clients, having not sent EHLO, assume that they are talking with legacy 821 servers. By contrast, a rule that requires session initialization prior to using a new command is a no-brainer to specify and implement cleanly, with no excuses about, e.g., ancient legacy environments. I would welcome your thoughts on this tradeoff between adding new commands (whose syntax would be identical to 5321 VRFY/EXPN but expanded to UTF-8 input and/or output) and the current proposal for a parameterized multiple-case situation, presumably fixed up more or less as you have suggested. john From ned.freed@mrochek.com Sun Dec 26 15:31:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FA23A681D for ; Sun, 26 Dec 2010 15:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4bUWAf5JhFy for ; Sun, 26 Dec 2010 15:31:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id A73BC3A6810 for ; Sun, 26 Dec 2010 15:31:21 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVVQNUOXPS00EQ3W@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 26 Dec 2010 15:33:20 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVRNC53SM8007CHU@mauve.mrochek.com>; Sun, 26 Dec 2010 15:33:17 -0800 (PST) Message-id: <01NVVQNSWU7U007CHU@mauve.mrochek.com> Date: Sun, 26 Dec 2010 14:53:46 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 25 Dec 2010 15:20:07 -0500" <227C2506194609988B81BE4F@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01NVQAP0UQRU007CHU@mauve.mrochek.com> <227C2506194609988B81BE4F@PST.JCK.COM> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1293403441; bh=jZMmTMwLMswKSme1ZsJUrxMcukzd836HaXPmIEY3dtY=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=jEGod2A0Qvo+KJtQv0ayd7dtrXoWs6Aue+4DjZw4+3dOoeUuCsMZerTC3ioi0NpsZ Ubi0gLkXV3wPakR4cvy0JNIA47/UsFDc9zGYwTEv8hY1BWuMM5OrHb6v2aXigbk4Cj DPS+O8mY8gJTVR2Q9U1QrZwrE0SW/O+HO4OzlCOw= Cc: Alexey.Melnikov@isode.com, apps-discuss@ietf.org, Ned Freed , ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 23:31:25 -0000 > In addition, one must have a session for which mail transactions > are permitted (i.e., EHLO must have been sent) in order to use > any parameters at all. You certainly need to send an EHLO and process the result to find out what extensions are allowed - guessing what combination of extensions will work most certainly is not a sound operational policy. And implementations are certainly free to only offer the extensions that have been returned in an EHLO repsonse. That said, I don't see an actual requirement in section 2.2 stating that EHLO must be issued before any parameters can be used. (Maybe it's somewhere else, but a cursory search didn't find it.) Our MTA certainly doesn't enforce this and AFAIK neither does sendmail, PostFix, Apache James, or qmail. (Exim, OTOH, appears to.) > RFC 5321, Section 4.1.4, explicitly > permits sending VRFY or EXPN without first having EHLO in the > session. So there is another implicit requirement in all of > this that should almost certainly be made explicit. There certainly should be a note saying that you need to issue an EHLO and check the response before attaching any parameters to VRFY/EXPN. I don't think a requirement that parameters not be accepted before an EHLO has been issued is needed. > (I think > this is the topic about handshaking that Dave and Shawn have > been circling around, but I'm not sure). It's part of it, I think. > > However, this brings up > > another issue, which is that a server that supports this > > extension needs a way to tell a client that doesn't that > > it cannot return a proper response to VRFY/EXPN without > > that parameter being specified. A new SMTP error status is > > needed, but the document only defines an extended status > > for this purpose; it doesn't specify a regular status code to > > use. > If we go down this path, the WG clearly needs to reexamine > whether such a code is necessary. I think you have made a > persuasive case, but I can't speak for the WG. It doesn't have to be a new code. OTOH, it needs to be a code that EXPN/VRFY don't return for other purposes, and I think if you look at the list of available codes a new code is needed. > Indeed, this has all gotten sufficiently complex that I think > perhaps the WG should reexamine its decision to handle the "VRFY > and EXPN with possible non-ASCII responses" situation by > parameterizing those commands rather than introducing new > commands, say VRF8 and EXP8. IIR, the WG did consider that > alternative (long ago) and conclude that adding a parameter was > the more straightforward option. But, perhaps, given the > various complexities that have emerged, that was not the right > decision. I considered suggesting new commands, but given the need to specify syntax for the new commands I don't see this as any simplier specification-wise. In terms of implementation, a new command is actually a somewhat more complex - the code changes are less localized, and I suspect other implementations will be comparable in this regard. But the minute you need some other variant on EXPN and VRFY, the alternate command appraoch becomes the far more complex way to do it. Now, we haven't had a specification come along that needed additional EXPN/VRFY parameters before this one, but these things have a way of showing up once you open the door and get people thinking about them. So I'm strongly inclined to stick with the parameter approach. > With other commands, such as MAIL and RCPT, we've > already got a history of parameters and the base (821/5321) > syntax is very clearly delimited. By contrast, I certainly > remember seeing VRFY followed by unquoted strings with blanks in > them in the wild (e.g., arrangements like > VRFY Ned Freed > ) and some servers tolerating them in the name of robustness or > in memory of 821, which had > VRFY > ::= | > ::= | "\" > ::= any one of the 128 ASCII characters, > but not any or > ::= any one of the 128 ASCII characters > (no exceptions) > which makes > VRFY Dave\ Crocker > perfectly valid. I don't know if similar examples still occur > and with what frequency, but... OTOH, a lot of servers back in the days prior to RFC 2821 didn't support the 821 thing of allowing literal spances with a \ and no enclosing quotes. So this never could be said to have interoperated. And I think the time has come to abandon it (although I note that if you really want to continue supporting it, the added parameter doesn't prevent you from doing so). Ned From al@akc.com Sun Dec 26 20:58:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32773A6848; Sun, 26 Dec 2010 20:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwFKJzrJ4FkN; Sun, 26 Dec 2010 20:58:35 -0800 (PST) Received: from imail.akc.com (mail.akc.com [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id 35BC93A6832; Sun, 26 Dec 2010 20:58:34 -0800 (PST) Received: from upstairs (upstairs.akc.com [64.253.39.242]) by imail.akc.com with SMTP; Mon, 27 Dec 2010 00:00:13 -0500 Message-ID: <3F5293BF906846C89013734B3D6262D9@upstairs> From: "Al Costanzo" To: "Ned Freed" References: <01NVQAP0UQRU007CHU@mauve.mrochek.com><227C2506194609988B81BE4F@PST.JCK.COM> <01NVVQNSWU7U007CHU@mauve.mrochek.com> Date: Mon, 27 Dec 2010 00:00:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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.5994 Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 04:58:37 -0000 > OTOH, a lot of servers back in the days prior to RFC 2821 didn't support > the > 821 thing of allowing literal spances with a \ and no enclosing quotes. So > this > never could be said to have interoperated. And I think the time has come > to > abandon it (although I note that if you really want to continue supporting > it, > the added parameter doesn't prevent you from doing so). > Ned, If my memory servers me, (and it may not), There were good reasons why VRFY supported this. I dont know if any are valid anymore but one idea was that you could send the persons name, not the email address, to find out if that person had an email address on that system. Was this not the reason Ned to allow blanks (whitespace) and unquoted strings? If you remove this from the spec, this functionality would be lost, I don't really see a reason to lose something that works. >> RFC 5321, Section 4.1.4, explicitly >> permits sending VRFY or EXPN without first having EHLO in the >> session. So there is another implicit requirement in all of >> this that should almost certainly be made explicit. I do not remember VRFY command requiring the EHELO, there are a number of mailing list verifiers that do not send the EHELO first. Verifiers, since they do not actually send email, usually dont send the EHELO first. (our application does) and I think requiring the EHELO first as part of a handshake it the proper way to do this. Only my humble opinon. -Al Costanzo ----- Original Message ----- From: "Ned Freed" To: "John C Klensin" Cc: ; ; "Ned Freed" ; ; Sent: Sunday, December 26, 2010 5:53 PM Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) >> In addition, one must have a session for which mail transactions >> are permitted (i.e., EHLO must have been sent) in order to use >> any parameters at all. > > You certainly need to send an EHLO and process the result to find out what > extensions are allowed - guessing what combination of extensions will work > most > certainly is not a sound operational policy. And implementations are > certainly > free to only offer the extensions that have been returned in an EHLO > repsonse. > > That said, I don't see an actual requirement in section 2.2 stating that > EHLO > must be issued before any parameters can be used. (Maybe it's somewhere > else, > but a cursory search didn't find it.) Our MTA certainly doesn't enforce > this > and AFAIK neither does sendmail, PostFix, Apache James, or qmail. (Exim, > OTOH, > appears to.) > >> RFC 5321, Section 4.1.4, explicitly >> permits sending VRFY or EXPN without first having EHLO in the >> session. So there is another implicit requirement in all of >> this that should almost certainly be made explicit. > > There certainly should be a note saying that you need to issue an EHLO > and check the response before attaching any parameters to VRFY/EXPN. I > don't > think a requirement that parameters not be accepted before an EHLO > has been issued is needed. > >> (I think >> this is the topic about handshaking that Dave and Shawn have >> been circling around, but I'm not sure). > > It's part of it, I think. > >> > However, this brings up >> > another issue, which is that a server that supports this >> > extension needs a way to tell a client that doesn't that >> > it cannot return a proper response to VRFY/EXPN without >> > that parameter being specified. A new SMTP error status is >> > needed, but the document only defines an extended status >> > for this purpose; it doesn't specify a regular status code to >> > use. > >> If we go down this path, the WG clearly needs to reexamine >> whether such a code is necessary. I think you have made a >> persuasive case, but I can't speak for the WG. > > It doesn't have to be a new code. OTOH, it needs to be a code that > EXPN/VRFY > don't return for other purposes, and I think if you look at the list of > available codes a new code is needed. > >> Indeed, this has all gotten sufficiently complex that I think >> perhaps the WG should reexamine its decision to handle the "VRFY >> and EXPN with possible non-ASCII responses" situation by >> parameterizing those commands rather than introducing new >> commands, say VRF8 and EXP8. IIR, the WG did consider that >> alternative (long ago) and conclude that adding a parameter was >> the more straightforward option. But, perhaps, given the >> various complexities that have emerged, that was not the right >> decision. > > I considered suggesting new commands, but given the need to specify > syntax for the new commands I don't see this as any simplier > specification-wise. In terms of implementation, a new command is actually > a somewhat more complex - the code changes are less localized, and I > suspect > other implementations will be comparable in this regard. > > But the minute you need some other variant on EXPN and VRFY, the alternate > command appraoch becomes the far more complex way to do it. Now, we > haven't had > a specification come along that needed additional EXPN/VRFY parameters > before > this one, but these things have a way of showing up once you open the door > and > get people thinking about them. So I'm strongly inclined to stick with the > parameter approach. > >> With other commands, such as MAIL and RCPT, we've >> already got a history of parameters and the base (821/5321) >> syntax is very clearly delimited. By contrast, I certainly >> remember seeing VRFY followed by unquoted strings with blanks in >> them in the wild (e.g., arrangements like >> VRFY Ned Freed >> ) and some servers tolerating them in the name of robustness or >> in memory of 821, which had >> VRFY >> ::= | >> ::= | "\" >> ::= any one of the 128 ASCII characters, >> but not any or >> ::= any one of the 128 ASCII characters >> (no exceptions) >> which makes >> VRFY Dave\ Crocker >> perfectly valid. I don't know if similar examples still occur >> and with what frequency, but... > > OTOH, a lot of servers back in the days prior to RFC 2821 didn't support > the > 821 thing of allowing literal spances with a \ and no enclosing quotes. So > this > never could be said to have interoperated. And I think the time has come > to > abandon it (although I note that if you really want to continue supporting > it, > the added parameter doesn't prevent you from doing so). > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ned.freed@mrochek.com Mon Dec 27 08:45:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA403A68B6 for ; Mon, 27 Dec 2010 08:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M30CXpjYlipG for ; Mon, 27 Dec 2010 08:45:05 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 69E463A68A8 for ; Mon, 27 Dec 2010 08:45:01 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVWQRGOOVK00C4HV@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 27 Dec 2010 08:47:02 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NVWPGUXYTC007CHU@mauve.mrochek.com>; Mon, 27 Dec 2010 08:47:00 -0800 (PST) Message-id: <01NVWQRFHQDG007CHU@mauve.mrochek.com> Date: Mon, 27 Dec 2010 08:17:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 27 Dec 2010 00:00:09 -0500" <3F5293BF906846C89013734B3D6262D9@upstairs> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; reply-type=original References: <01NVQAP0UQRU007CHU@mauve.mrochek.com> <227C2506194609988B81BE4F@PST.JCK.COM> <01NVVQNSWU7U007CHU@mauve.mrochek.com> <3F5293BF906846C89013734B3D6262D9@upstairs> To: Al Costanzo DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1293465461; bh=NtcswdL9eOWJxQ702QR++JhHHorkGtXZyhQpLcjq1Xk=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=XxqePbhmm3m23lTG+5rFmcmFXhClMQN5zt/RhYx69iy0zH+YY4HADuMobyUNWbnaV 6VL2MgSSgOI0/iPDPwzO6QS6i7XNIfqreC0IvW7G7shuvG3z7CL7idrxhVT1SztJBb FwTiv2ZcO/b0xg2FblGCtBqwRtUctamR3qxNQYbY= Cc: Ned Freed , ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 16:45:07 -0000 > > OTOH, a lot of servers back in the days prior to RFC 2821 didn't support > > the > > 821 thing of allowing literal spances with a \ and no enclosing quotes. So > > this > > never could be said to have interoperated. And I think the time has come > > to > > abandon it (although I note that if you really want to continue supporting > > it, > > the added parameter doesn't prevent you from doing so). > > > Ned, > If my memory servers me, (and it may not), > There were good reasons why VRFY supported this. I dont know if any are > valid anymore but one idea was that you could send the persons name, not the > email address, to find out if that person had an email address on that > system. You've gotten this exactly backwards. Yes, VRFY and EXPN accept names as arguments, not addresses. The problem is this specification changes them to accept addresses as well, which is both unnecessary and out of scope. > Was this not the reason Ned to allow blanks (whitespace) and unquoted > strings? Sure, but it doesn't change the fact that the only changes this WG is supposed to be making is to add support for UTF-8. Even if it were a good idea to change the syntax of VRFY or EXPN from what's in RFC 5321 either to accept addresses or to go back to the syntaxes that were allowed in RFC 821, doing so is not in scope. If you want to argue about changes in that area, the place for that is the ietf-smtp list. > If you remove this from the spec, this functionality would be > lost, I don't really see a reason to lose something that works. Please reread my original message. Again, you have this exactly backwards - currently the EAI specification makes an unnecessary and out of scope syntax change change from what's in RFC 5321 that goes far beyond supporting utf-8. Either form of alternative ABNF I proposed returns us to RFC 5321 syntax plus utf-8. > >> RFC 5321, Section 4.1.4, explicitly > >> permits sending VRFY or EXPN without first having EHLO in the > >> session. So there is another implicit requirement in all of > >> this that should almost certainly be made explicit. > I do not remember VRFY command requiring the EHELO, there are a number of > mailing list verifiers that do not send the EHELO first. That's exactly what John is saying. The problem is you can't send a new parameter on VRFY/EXPN and expect it to work until you know it's safe to do so. And the way to know that is to look at the EHLO response. > Verifiers, since > they do not actually send email, usually dont send the EHELO first. (our > application does) and I think requiring the EHELO first as part of a > handshake it the proper way to do this. Which is what is being proposed, and AFAICT is entirely noncontroversial. The specific issue being discussed is whether or not a server MUST refuse to allow the extended form if it hasn't gotten an EHLO. I see no point in containing servers in this fashion. Ned From klensin@jck.com Mon Dec 27 10:47:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A2B3A67B4; Mon, 27 Dec 2010 10:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFz-GYd4n9EG; Mon, 27 Dec 2010 10:47:07 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8EF5E3A67A7; Mon, 27 Dec 2010 10:47:06 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PXI83-000Njv-Hx; Mon, 27 Dec 2010 13:49:07 -0500 X-Vipre-Scanned: 058133FB001DEB05813548-TDI Date: Mon, 27 Dec 2010 13:49:06 -0500 From: John C Klensin To: Al Costanzo , Ned Freed Message-ID: <7C0660F7DFFE9C1990252217@[192.168.1.128]> In-Reply-To: <3F5293BF906846C89013734B3D6262D9@upstairs> References: <01NVQAP0UQRU007CHU@mauve.mrochek.com> <227C2506194609988B81BE4F@PST.JCK.COM> <01NVVQNSWU7U007CHU@mauve.mrochek.com> <3F5293BF906846C89013734B3D6262D9@upstairs> 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: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 18:47:08 -0000 --On Monday, December 27, 2010 12:00 AM -0500 Al Costanzo wrote: >... > Ned, > > If my memory servers me, (and it may not), > > There were good reasons why VRFY supported this. I dont know > if any are valid anymore but one idea was that you could send > the persons name, not the email address, to find out if that > person had an email address on that system. and what that address was, of course. This was heavily used for a while with both VRFY and, separately with finger, to get from name to email address. The advantage of the VRFY approach was that it would permit a user to enter an address that might look like "John Klensin@example.com" at which point the MUA would send VRFY John Klensin to the mail server at example.com, get back an address, and then open a mail session. Of course, Ned's observations about lousy support (with which I agree) notwithstanding, the variation of VRFY "John\ Klensin" would have been fully 821-compliant. I vaguely remember one MUA that would send the first (escape-less) version and then send the second if the reply from the first was "no 'John; here" or "syntax error" rather than "no 'John Klensin' here". The heuristic is pretty trivial. That use of VRFY became less popular as MUAs became more separate from first-hop full service MTA (aka submission servers) because that sort of use of VRFY pretty much requires at least some SMTP capability (including domain name lookups, coping with MXs, etc.) in the MUAs, ability to use port 25 connections from just about anywhere, etc. I don't know whether the usage is gone entirely, but it is certainly a lot less common than it appeared to be many years ago. > Was this not the reason Ned to allow blanks (whitespace) and > unquoted strings? If you remove this from the spec, this > functionality would be lost, I don't really see a reason to > lose something that works. Especially if the clock could be turned back, one could allow only the single form VRFY "John Klensin" just getting rid of the bare, unquoted, backslash escape that was permitted by 821 but that 5321 already excludes. >>> RFC 5321, Section 4.1.4, explicitly >>> permits sending VRFY or EXPN without first having EHLO in the >>> session. So there is another implicit requirement in all of >>> this that should almost certainly be made explicit. > I do not remember VRFY command requiring the EHELO, there are > a number of mailing list verifiers that do not send the EHELO > first. It never has been a requirement although sending EHLO (or HELO) first has always been harmless. Either 5321 or 2821 simply made it very clear that there was no such requirement. > Verifiers, since they do not actually send email, > usually dont send the EHELO first. (our application does) and > I think requiring the EHELO first as part of a handshake it > the proper way to do this. That is one issue on the side of "new command". If one now decides to require EHLO first, then all existing uses of VRFY without it (which conform perfectly well to 5321 and all of its predecessors) become invalid, That is pretty uncomfortable to me. By contrast, if one creates the new command, then, if the response to EHLO includes some sort of EXTENDED-VRFY capability (see below), one could have: -- VRFY without EHLO as requesting the 5321 behavior (with or without non-conforming extensions or flexibility and with responses limited to ASCII). -- EHLO, then VRFY as requesting the 5321 behavior, identical to that above. -- EHLO, then New-VRFY as requiring a strict Atom or Quoted-string optionally followed by a parameter list. Note that, if the non-conforming client behavior we know is out there is used, then VRFY Costanzo 8BITREPLIES-OK or equivalent could be interpreted by the server as either of VRFY "Constanzo\ 8BITREPLIES-OK" or as coming with a parameter, or as a syntax error, in either VRFY case. Not really a good idea, IMO, and at least one reason we have not permitted the use of extended parameters with older SMTP commands with EHLO and capability permission. Note too that the last paragraph of RFC 5321 Section 3.5.1 is, in part and while not explicit, a caution against treating the standard syntax too literally or narrowly. We could, in principle, do a completely new command without involving the extension mechanism at all, thereby allowing sending it before or without EHLO, but that strikes me as a really scary idea. > Only my humble opinon. Only mine also -- I really don't have my mind made up about this and am just trying to get the various arguments in front of the WG. john p.s. I agree with what I take to be at least a corollary to Ned's remarks: having EAI create special-purpose commands that are not very narrowly tied to i18n issues would be a bad idea. If there is any perceived need for a new command, we ought to define in a separate I-D, as (impossible keyword is deliberate to clarify that this is not a proposal) NewVRFY String *(SP esmtp-param) with String given only the 5321 interpretation, not the 821 one, and then process that command through the SMTP list, etc. If that appeals to anyone, I might generate a strawman just to facilitate the discussion. From klensin@jck.com Mon Dec 27 11:37:23 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB0C3A68CC for ; Mon, 27 Dec 2010 11:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leBLA7xf2h0V for ; Mon, 27 Dec 2010 11:37:19 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 15B193A67BD for ; Mon, 27 Dec 2010 11:37:17 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PXIuc-000OMF-Kz for apps-discuss@ietf.org; Mon, 27 Dec 2010 14:39:21 -0500 X-Vipre-Scanned: 05AF2620001DEB05AF276D-TDI Date: Mon, 27 Dec 2010 14:39:15 -0500 From: John C Klensin To: apps-discuss@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [apps-discuss] Analysis of comments on 5336bis (was: Re: apps-team review of draft-ietf-eai-rfc5336bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 19:37:23 -0000 Hi. Long, careful, and thoughtful reviews deserve long --and I hope careful and thoughtful-- responses. This note attempts to identify the main substantive points in the reviews and react to them. Some may consider it a special case of no good deed going unpunished; if so, I'm sorry. I'm sending the note separately to the EAI WG mailing list (ima@ietf.org) and the Apps Discuss one. I hope that we can move discussion to the WG list. Put differently, please do not respond to this note on the apps-discuss list -- if anyone has additional comments, please take them to the WG list. My apologies to those who will get it twice -- there seemed no better way to avoid, or at least reduce, multiple threads of discussions that were not visible to WG participants. Writing only as a participant in the WG and co-author of the "EAI framework" document, I have several comments on the various Applications Area Review Team comments (my co-chair helped a bit with part of this note but I'll take the blame as needed). To be certain we all start with the same background assumptions, please remember that the original form of the "EAI Framework" supported the Experimental version of these protocols document was published in July 2007 as RFC 4952. Its replacement, draft-ietf-eai-frmwrk-4952bis-10, is more to the point today. That draft is intended to be aligned with the documents that are now under consideration (or to have them aligned with it), has completed IETF Last Call, was approved for publication by the IESG in late September, and has been in the RFC Editor queue awaiting normative references to the current set of documents and resolution of a naming issue that the WG decided to leave until after the approval process completed (more on that below). Speaking very personally because I don't know whether the WG participants will agree, I think these specifications are important enough that I'd rather have them right than stand on any sort of procedural argument. However, I think the community also needs to consider when, newly-discovered showstoppers aside, it becomes too late to raise fundamental design issues that were reviewed extensively by the WG prior to forwarding the first-round documents to the IESG, went through IETF Last Call in 2007 and 2008, have been implemented and tested experimentally, and where the basic framework and changes from the 2007-2008 specs were reviewed by the WG, passed through IETF Last Call, and were approved by the IESG in September of this year. There are places in the comments below where I've tried to summarize what I believe is WG opinion or WG consensus, but even those remarks should be taken as personal opinion rather than the formal opinion of the WG. The WG has deliberately not been given a preview of these notes and is seeing them for the first time at the same time as reviewers and others. I do hope that some of the notes will act as a basis for discussion. For convenience, I'm going to try to consider the review comments by topic (there is some overlap among reviews) rather than responding to each review comment separately. When it seems useful to identify particular comments, I've used the first name of the author of the comments and the date of the posting. To avoid a hugely long note, this one is strictly about 5336bis (the SMTP extensions); a separate note will be posted about each of the other relevant documents. Note that, again speaking personally, I agree with some of the comments even though WG consensus, as reflected in the current drafts, does not. I have not commented on, or even listed, specific issues whose consequences appear to be entirely editorial, even if the editorial issues are quite broad. I'll leave those comments to the authors/editors (subject, as usual, to WG approval). I have also omitted most issues that seem to have been more than adequately covered in mailing list discussions. The balance of this note is about the reviews and on-list comments about draft-ietf-eai-rfc5336bis. It does not include comments that appeared to be redundant unless listing different versions seemed to add perspective or other information. While I've commented briefly on the VRFY and EXPN issues below, those are being much better covered in the discussions between Dave and Shawn, Ned's analysis, and the subsequent than I could do or have attempted here. Separate notes about the other reviews will follow. (1) Overview, scope, and summary: Claudio Allocchio 2010-12-22 wrote: > The document specifies how to apply internationalization to > some SMTP elements, and to some Header elements which > depends from the SMTP elements. However there seem to be a > discrepancy from what the abstract states, and what is > elaborated into the document details: the document also > deals with quite a number of elements which involve > bodyparts, and affect the whole email legacy system, and > beyond, such as logs, traces, and wherever email addresses > are used (certificates, etc.). This seems thus to go beyond > what the summary states, even this fact is not explicitly > discussed. It is unclear thus if this "update" of RFC5321 > and RFC5322 is only limited in scope or not. My reading of > the document say it goes beyond, and implicitly affects also > what is being transported into the email system. This is > thus a serious issue to be solved before the document can go > to the Standard Track. With the understanding that the abstract, and several other editorial issues with the text, could certainly be improved, please note that specifications for header fields that contain trace-related information (and that are inserted by MTAs) have appeared in all of RFCs 821/ 2821/ 5321. The trend over time, starting with some explicit DRUMS decisions, has been to move more of that information into the x21 member of the pair rather than having it split between x21 and x22. So the choice with this document is between updating information that appears in 5321 and creating a split between envelope and header information that is different than the base email documents. The WG concluded that tracking the organization and information content of 5321 would be less confusing than trying to create a new model. By contrast, the information about certificates, etc., was introduced into the predecessor of this document at the insistence of the community and the IESG during Last Call on RFC 5336. We could take it out of here, possibly by reopening the Framework document and inserting additional "other consequences for email and the Internet" sections there. FWIW, my personal opinion is that doing so would not add significantly to either document comprehensibility or protocol quality, but that is a matter for WG and community consensus. Dave Crocker 2010-12-22 wrote: > * Beyond -- The work, here, appears to have > two goals. One is to add support for Unicode in a > ; that is, support for internationalized > addresses. However note that and > already accomplish this in a way that is transparent to the > existing email infrastructure; only the end-systems need to > understand it. When the discussions that led to the establishment of the EAI WG started, the goal was seen as expanding the syntax of , as you suggest. It turns out that doing that is not really feasible, at least without leading to horrible kludges, so the WG was chartered (now four or five years ago) to extend header fields as well. As mentioned elsewhere, the IETF has had repeated opportunities to review those decisions and has formally approved them. Even mapping back and forth between A-labels and U-labels is, in the real world, not as transparent as one would like (or obtain if one knew that everything that looks like a domain name is a domain name in the public DNS -- see draft-iab-idn-encoding or review the slides from the Hiroshima technical plenary for more details on that issue). Curiously, if the WG had not been constrained by very old (and necessary) rules about how the email environment works, its job might have been much more simple and more in line with at least one extrapolation from the comment above: if we had standardized local-part formats sufficiently to avoid having to prohibit interpreting or tampering with those fields enroute, the WG could, in principle, have written extremely short specifications allowing encoded-words (possibly restricted to encoded UTF-8) in local-parts and essentially been done. While I doubt that solution would have been acceptable to many implementers and user constituencies (in part because "only the end-systems need to understand it" has never worked as well as we often hope it does), it would have been much easier in terms of specification simplicity. In case it is useful for understanding the WG's choices in this area, the WG in principle had a choice between adopting a minimal change --relying as much as possible on trick encodings and dependencies on endpoint handling as possible -- and moving in the direction of relatively comprehensive use of natively-encoded (see below) Unicode in email with some transition provisions that would gradually atrophy. In practice, there was no choice at all: internal discussions made it clear that a standard based on the former approach would simply be ignored and localized or proprietary solutions adopted and only one based on the latter had an reasonable chance of implementation and global deployment. Extrapolation from the independent-of-EAI work reflected in draft-iab-idn-encoding -- work that originated in the concerns of a couple of operating systems that dominate the network today-- also suggests that more dependency on exotic, IETF-specific encodings is not a direction we should be going in unless it is absolutely necessary. > The second goal is to support Unicode in the > more "native" form of UTF-8. (The quotation marks are > because UTF-8 is not native Unicode, either; it is a highly > encoded form of Unicode...) As others have commented on the mailing list, the above and some of the comments that followed in the review demonstrate a fairly profound misunderstanding of Unicode and Unicode terminology. The only encoding form more "native" than UTF-8 (or UTF-16 or UTF-32) is a set of abstract integers that have no intrinsic computer encoding form. The IETF has established a number of "non-native" encoding forms, including UTF-7 and the Punycode-derived ACE form, but they are avoided where possible in these specifications. See the comments under #7 below for an additional aspect of the ASCII-versus-Unicode distinctions. (2) Explicitness versus discovery in MIME and related topics, including a possible parameter on the MAIL command. Claudio Allocchio 2010-12-22 wrote: > Another big issue is about blending the boundaries of > servers in the transport system (MTAs), clients (UAs) and > their roles, when the document specify that servers shall > use guessing techniques from looking into bodyparts to > understand if what they're transporting is internationalized > according to this specification or not. This is IMHO a > basic violation of the role distiction in the legacy email > system, and affects the MIME model al well. Yes, except that this "blending" already occurs with MIME and other SMTP extensions. Over the years, we have made some decisions to be very explicit about parameters and pre-identification of content and other decisions to force systems to inspect or parse content because we did not believe that such parameters could be trusted (or that any sensible implementer would trust them). I hope we have gotten most of those historical decisions right although I have some doubts, at least in retrospect, about some of them. Given that history, I don't think it is appropriate to assume that the EAI effort is leading us into a role distinction sin or not because we are already there. The question is what the right choice is for this particular situation. The WG considered that choice at great length (albeit in the 2006-2008 period rather than more recently, but that part of the specification has not changed) and came to the conclusion that forcing inspection was the better plan. Testing with the Experimental versions of the protocols did not expose serious problems with that choice. I am sure that the WG would be happy to reconsider this topic is appropriate, but some solid evidence that there is a problem and that the current decision is wrong would be far more helpful in that regard than assertions based on a philosophy of email that IETF protocols have already violated. That assertion, and some evidence, have been made for a MAIL command parameter: Claudio Allocchio 2010-12-22 wrote: > 3.5 Body Parts and SMTP Extensions > I have problems in understanding why an SMTP server should > peek extensively into the message geing transferred to > understand that it is handling an interationalzed message. > "There is no ESMTP parameter to assert that a message is an > internationalized message." in my opinion should be fixed in > another way, by ADDING an appropriate ESMTP parameter to >... Dave Crocker 2010-12-22 wrote: > 4. The SMTP extension needs to have the client use an > explicit signal when it is sending a message encoded in > UTF-8. This is easiest as a parameter to the MAIL command. > The current specification creates a more complex and almost > heuristic model for distinguishing ASCII from UTF-8 use. Ned Freed 2010-12-22 wrote: > (0) I cannot emphasize strongly enough how important it is > to have a UTF8SMTP sort of parameter on the MAIL FROM to > indicate that a message employing this extension is being > submitted/relayed/delivered. >... Ned Freed 2010-12-23 wrote (small excerpt): > Again, headers don't have the proper semantics. A MAIL FROM > parameter, OTOH, does. The working group did consider the tradeoffs between (i) forcing a server (really relay) to do a complete MIME parse if it received an extended message and had to decide what to do if the next hop did not support the extensions and (ii) putting in a parameter whose presence or absence might not be trustworthy given a history of, e.g., text/plain body parts being sent with distinctly non-ASCII content but without charset parameters, misuse of "name extensions" in lieu of adherence to Content-Type, etc. The decision of the WG was reflected in RFC 5336 (after IETF Last Call, etc.) and I note that none of the known implementers of the RFC 5336 spec are objecting to that decision now. The consensus of the reviewers now seems to be that the WG got it wrong. The WG needs to review this again; the change is certainly easy to make should it be appropriate. (3) Fundamentals of handling syntax changes from other specifications (especially 5321/5322): Claudio Allocchio 2010-12-22 wrote: > The document quite often repeats rules from other > specifications, AND re-describes these rules. This is > dangerous (it makes very difficult to keep aligned > documents, and will lead to different interpretations) and > not needed. The tradeoff, I hope obviously, is with the reader having to flip back and forth repeatedly between documents to have any hope of understanding the specification accurately. I'm personally sympathetic to your concern, but many WG participants disagree. Specific suggestions that could be used as a model would be helpful to the WG and the editors. Claudio Allocchio 2010-12-22 wrote: > 3.6.1 "the server normally sends..." --"the server sends" > (sorry... we do not like ABnormal servers!) :-) This is another example of a narrative/ informative comment. We know about exceptions. Perhaps the sentence would be better stated as "an RFC 5321-conforming server sends...". (4) Gateways and related boundary systems Claudio Allocchio 2010-12-22 wrote: > This specification updates a number of SMTP and Headers > fields from RFC5321 and RFC5322. However these fields are > also used in Gatewaying to other email systems, which are > still existing. Section 3.7 in RFC5321 describes specific > cases. However this memo provides no clue on possible effect > that internationalized fields can have in case gatewaying > occurs. Gatewaying functions strongly rely on these values, > and the introduction of these modification should describe > this scenario, too. I suggest to include a specific section > about these issues, and suggest at least a number of > possible actions which Gateways can take to survive this > change. I'm not sure I understand why Gateways are different from anything else. If a gateway doesn't advertise the extension, then it should never see a message that contains either non-ASCII envelope addresses or non-ASCII content in the headers (other than as encoded-words, of course). The WG does have some placeholder benchmarks for advice of various sorts; IMO it would be quite useful to supply some of that advice for gateways once sufficient operational experience had accumulated. But the only really hard gateway problem I see is if a given gateway MTA interfaces to two back-end systems, one of which is ASCII-only and one of which is broadly UTF-8 capable. It will either need to be reconfigured into two virtual gateways, one of which advertises the extensions and one of which does not, or it will simply have to reject mail with UTF-8 header fields that is addressed to a system that can't handle it. I note, however, that such a gateway already has a problem that it presumably has some mechanism to deal with: if it receives mail with UTF-8 (or other non-ASCII) headers from one of its i18n-capable systems with an Internet destination, it already has to reject the message or perform some sort of conversions that are, necessarily, not described in IETF specifications. (5) The legacy of the Experimental protocols Claudio Allocchio 2010-12-22 wrote: > The EAI WG charter states that in handling email message we > shall be "consistent with the long-term view that email with > invalid addresses or syntax should be rejected, rather than > fixed up in transit between submission servers and delivery > servers.". However a number of sections in the specification > seem to contradict this, where they suggest actions, by > exammining message elements (in the SMTP and in the Headers > and in the Bodyparts) in order to try to deliver anyhow. > This is a subtle line between maximising the service chance > to deliver, and "fixing" things during the transaction, and > it can encourage implementors to do many of these acions, > instead of stiching to the idea "not supported --non > delivery". The experimental protocols described in RFC 5336 and elsewhere included a rather complex mechanism for in-transit downgrading. I'd encourage you to go look it up if you are interested, but the general design was based on the 8BITMIME model -- a sender discovering that the next-hop server wouldn't accept the option could either reject the message or engage in a downgrading process that was distinctly not lightweight. The conclusion from implementations and experiments was that it was too heavyweight, too hard to get right, and that the number of cases in which the downgrade procedure could not be applied would be very confusing to users. All vestiges of that machinery should have been removed from the current versions of the documents. But I found some in an earlier review and it may well be that some of the other review comments have identified others. If so, they clearly need to come out; the editors may need help in identifying specific examples. (6) Server actions when UTF8SMTP[bis] is not supported (and Section 3.6.2). Claudio Allocchio 2010-12-22 wrote: > The specification does NOT suggest a preferred order among > the 3 possible options when the SMTP server state it does > not support UTF8SMTPbis. Having 3 "MAY" options at the same > level can create a very uncertain email service behaviour, > and a very bad user's experience! This is consistent with > what happens in other cases for other "options" in the email > system (like DSNs and MDNs), but there should be at least an > informative document describing the various scenarios, and > giving some guidance to implementors in order to avoid > totally incosistent behaviours. Small bit of calibration about this: remember that the EAI specs cannot do anything to dictate the behavior of an SMTP server that does not support the EAI extensions and may have never heard of them. There is also a general design assumptions, shared with other [E]SMTP assumption, that the specification should not make any changes to general email behavior that are not necessary consequences of what the extension is trying to accomplish. On rereading the document after going through these comments, it is clear to me that the document would be improved by being much more clear about what text is a change with EAI and normative, what is a necessary consequence of provisions in RFC 5321 or other applicable standards, and what is just informative narrative. I don't know whether the WG shares that point of view, nor whether it is desirable to try to rewrite the document along those lines at this stage (in general, these are not "known technical defects" so, if we could be assured that Draft Standard versions of the documents would appear on a timely basis, it might make sense to let them go for the present). These three options are simple extrapolations of rules that already exist in RFC 5321: SMTP-senders must not send invalid messages into the public Internet and must reject or bounce such messages if they cannot be fixed up; only Submission servers (and gateways) are permitted to make significant changes to fix things up; and, implicitly, if mail is not deliverable along the normal path and one knows a legitimate path that would work, one is permitted to use it. Note that the first (MSA) option is useful for non-ASCII address local-parts iff the MSA has an external source of information that permits substituting ASCII-only addresses for non-ASCII ones. For address domain-parts and miscellaneous header fields, there are typically encoded-word (or A-label) options available. Perhaps the document should be more explicit about that. If that flexibility "just in practice break[s] the concept of universal email common service, creating islands which do not talk to each other", then we would already have seen that problem. For example, the specification of 8BITMIME can lead to the same situation without EAI: if a relay receives a message with C-T-E 8bit or binary, and the first-preference reachable MX doesn't support that option, it can downgrade the message, reject it, or, IIR, try other servers at the same preference level to see if one of them will provide support for the extension. Ned Freed 20101222 wrote: >> 1. If and only if the SMTP client (sender) is a Message >> Submission Server ("MSA") [RFC4409], it MAY, consistent >> with the general provisions for changes by such servers, >> rewrite the envelope, headers, or message material to >> make them entirely ASCII and consistent with the >> provisions of RFC 5321 [RFC5321] and RFC 5322 [RFC5322]. > This is a bad idea no matter how you slice it. Such > transformations depend on the availability of address > mapping (from a UTF-8 address to an equivalent ASCII > address) information; an agent being an MSA is neither > necessary nor sufficient reason to have this information. However, RFC 5321 already requires that an MSA not inject a message into the public Internet until/unless it is valid. And it (and RFC 4409) effectively give the MSA permission to do anything an MUA can do in order to accomplish that. There is no (intentional at least) assertion in 5336bis that the MSA (or the MUA, for that matter) must have access to address mapping information, just no requirement that it not use that information if it has access to it. If it doesn't have the needed information, then there are clearly a lot of things it cannot do; the quoted statement above is then just a reiteration of the 5321 prohibition on passing trash into the network (whether it is worth reiterating is a separate matter). Of course, if a message is transferred from an MUA to the MSA that contains non-ASCII header information in UTF-8 form but no non-ASCII addresses, the above provisions don't imply the MSA doing anything more than mapping that header information into encoded words. Again, there is no requirement that the MSA do that mapping; the statement simply reiterates, in an i18n context, the general permission for the MSA to take something that works in a user->MUA->MSA environment and fix it to conform to public Internet specifications. It is worth noting that, during WG discussions, several strong claims were made about intentions to implement both UTF-8 to encoded word mappings and tables to support precisely the type of address mapping suggested above in selected MSAs. Assuming people were telling the truth (and I certainly assume they were), the conditions specified above, including address mapping, are going to be exercised. > But the bigger problem by far is defining what > transformations are permissible. The present framework > document is basically silent on what's allowed, so I for one > have no idea what it means to be "consistent with the > general provisions for changes by such servers" actually > means. And unless you're willing to spell this out, I see > this as practically guarnteeing a slew of interop problems. With the understanding that my comments above go much further than the existing text, that the WG hasn't agreed to any expansion, and that Dave seems to be arguing for less text that is just repetition of existing rules in 5321/5322, how much further would you suggest going in spelling things out? (7) Suboptimal use of ABNF and ABNF constructions Dave Crocker 2010-12-22 wrote: > * Rule Meta-Naming -- The 'u' preface for revised rules is a > reasonable idea, but appears to be problematic. These rules > replace existing rules in other specifications. There needs > to be an explicit and decision about the handling of this, > and it needs to be applied consistently, either directly > replacing the rules or else re-naming them consistently, >... > { On reflection, I think the "u" rule-naming convention is > problematic. If the current specification is replacing a > rule previously defined elsewhere, it needs to use the same > rulename. This is simpler and clearer. (and several comments by others, noting that Dave's second recommendation appears to contradict Claudio's) As I commented at more length in a note to Dave, Claudio, and the EAI list on 2010-12-24 14:20 -0500, we've had a lot of trouble getting ABNF for these documents right, much less optimal. A significant part of the optimality problem is that that there seems to be no established good way to update one specification by extending its syntax -- a problem that the IETF community will almost certainly have to deal with again as we internationalize more protocols. In the particular case of ASCII and UTF-8 constructions, even though ASCII is a compatible proper subset of UTF-8, there is often a need to distinguish the two because plain-ASCII works in legacy protocols (and does not require special normalization or comparison rules that might, themselves, be controversial) while UTF-8 does not work in the legacy cases and raises more complex normalization, comparison, and collation issues. FWIW, we had the same problem in the IDNA2008 specs because it was necessary to distinguish between a traditional DNS "preferred syntax" name (aka "LDH") that did not start with an ACE prefix and one that did use that prefixed form, in spite of the fact that the latter, by design, would be treated as a traditional "LDH" name by any application that was not aware of the special IDNA constructions. For the particular case of EAI, the WG decided to go with the "u" prefix on new rules that superseded 5321 or 5322 rules. The WG tried to be consistent with that prefix on new rules, and preserve most of the original rules. All rules were extended rather than overwritten. The WG had discussed, somewhat earlier, the possibility of simply coping the entire ABNF collection from RFC5321/5322 and then extending or modifying rules as needed. That would have eliminated the need to reference back to those documents for ABNF but the idea was rejected, largely to avoid exactly the problem with updating that several reviewers commented on. Again, this is a general problem: if the community has a clear preference as to how it should be dealt with, I'm nearly sure that the EAI WG will conform. In the absence of a general solution, my personal guess is that the "u" convention (applied accurately and consistently) may turn out to be the best we can do. (8) MIME restrictions and nested encodings Dave Crocker 2010-12-22 wrote: > 5. The SMTP extension needs to remove all restrictions it > imposes on MIME content-type. A major reason that MIME was > successful was that it was transparent to the transfer > infrastructure. The current SMTP extension specification > changes this model, which actually increases the barrier to > adoption of Unicode in email. It needs to be easy for two > MUAs that support Unicode in the email header to exchange > mail even when the infrastructure does not support UTF-8. Right. Unfortunately, there is already a restriction in MIME that links Content-Type to Content-Transfer-Encoding, the "no nested encodings" rule. That rule is imposed primarily as a restriction on message/ subtypes. And it works because MIME assumed that all header information was going to be ASCII and hence able to be transmitted in C-T-E: 7bit. So now we have a little problem: MIME is designed to permit forwarding messages in encapsulated form using message/rfc822. But message/rfc822 uses ASCII headers only and has to obey the "no nested encodings" rule. One would like to be able to encapsulate an EAI-conformant message and even forward it into a legacy environment. There are actually a number of options for doing that, including deciding that a message with non-ASCII headers cannot be forwarded into a 5321/5322 environment (pretty obviously a bad idea to prohibit that), creating a new top-level MIME type with different rules (the transition issues and implications for legacy MUAs are pretty astonishing), or creating a new "message/" subtype with different rules and what may be seen as an additional Content-Type/ Content-Transfer-Encoding entanglement. After considerable discussion, the WG selected the latter (see #13 below) and got IETF signoff in RFC 5336. (9) Strong conformance language Claudio Allocchio 2010-12-22 wrote: > 3.1 Framework for the Internationalization Extension > - bullet point 3. I do not see any need to state that > clients MUST reject... and MUST be fully compliant... etc. > This is implicit in any specification. If there is a > specific need to add this detailed behaviour (to prevent >... Our general practice with email specifications has been to specify conforming behavior and simply leave non-conforming behavior "outside the scope of the specification". That doesn't work in this case because, according to the WG's analysis, a partial implementation --whether outside the spec or otherwise-- would be bad news for interoperability. So it seemed necessary to be very clear about what clients were expected to do and what servers could reasonably expect. Whether that was better done with this text, with an "Implementer's Note" (which has no normative status), or with an extended explanation of the problems and a threat or two would seem to me to be largely matters of editorial taste, especially for a Proposed Standard. (10) Security-related issues Claudio Allocchio 2010-12-22 wrote: > 5. Security Considerations > there is one more issue: as internationalized items will > also result into logs and traces, their presence may affects > trouble ticket systems used by security operations teams > (CERTs/CSIRTs). And they also can affect quick handling of > incidents, has it may require more time to correctly read >.... Agreed. I assume the editors will consider your proposed text. (11) Editorial issues with significant substantive implications. Dave Crocker 2010-12-22 wrote: > { Note - the term "mailbox names" is not defined here or in > RFC 5321. In RFC 5321 it appears to be used to mean > local-part; however because its precise meaning is unclear, > I strongly urge NOT using it here at all. Instead I suggest > using whatever ABNF rulename is appropriate. This > guarantees clarity. Well, while getting rid of "mailbox name" or defining it very precisely, would probably be an improvement, there is no ANBF rulename that would really be appropriate, at least without additional decoration. As you and others have pointed out recently, rules for appear in both 5321 (where it refers to the mailbox name (sic) itself, e.g., local-part@domain-part) and in 5322 (where it refers to something that might include a display name and assorted spacing). I have no doubt that this document should be as clear and precise as possible, but its authors should not be blamed for trying to work around the errors of the authors of 5321, 5322, and their predecessors. Dave Crocker 2010-12-22 wrote: >> The value of "uDomain" SHOULD be verified by IDNA >> definitions [RFC5890]. If > { I do not understand what "SHOULD be verified by IDNA > definitions" means. > If it means that the uDomain "SHOULDbe verified" then it is > out of scope for this specification. There is no reason that > SMTP rules concerning verification of Unicode-based domains > needs to be different from ASCII-based domains. In > particular, verification of a Domain name is specified > elsewhere. >... Editorial issues aside, 5321 contains some very carefully-written language whose intent is to require that domain-parts be validated lexically but to avoid requiring that they be looked up in the DNS until/unless that is necessary for some other reason. The "lookup" side of IDNA2008 (in RFC 5392) makes more or less the same circle around this issue but with the understanding that lexical validation of U-labels is a somewhat more complex process than checking against a short list of characters, positions, and lengths. I believe that is what the author was trying to capture. Certainly it could have been expressed differently. Dave Crocker 2010-12-22 wrote: >> Otherwise, surprising rejections >> can happen during temporary failures, which users might >> perceive as a serious > { Probably not just temporary failures. Having services > that are meant to be redundant with each other actually > provide different semantic behavior is just plain dangerous. > It is essentially guaranteed that they will cause problems.} Sure. But you argued extensively elsewhere for not duplicating text that appears elsewhere and, IMO, more important, for not making statements that go beyond a rather narrow reading of the requirements for internationalized email. Ned Freed 20101222 wrote: > So you can use alternate MXes, but not alternate A records? > I actually agree with this - an alternate A is presumably > another address for the same host, so no point in trying it. > But this needs to be spelled out. > At an absolute minimum this needs to be accompanied by some > security considerations text. The issue, I hope, is obvious: > There are sites aplenty with large numbers of MX records and > which won't support this extension any time soon. And all > too often those MXes are *slow* to respond. So sending a > message that causes them all to be tried is ... you get the > idea. > In fact I'm tempted to go one further and say that if an MX > at a given priority is found not to support this extension, > you SHOULD assume that MXes at lower priority don't either. And this is where we descend into a situation that extends far beyond EAI. The problem, as Ned's note almost suggests, is actually quite general. For example, if we had foo.example.com. MX 0 foomail0.example.com. foo.example.com. MX 10 foomail1.example.com. foo.example.com. MX 10 foomail2.example.com. and "foomail1" supported 8BITMIME with downgrading and "foomail2" did not, a system sending a message containing C-T-E: 8bit that reached foomail1 would have the message go through with downgrading if needed but would get a rejection or option not supported condition if it happened to get to foomail2. Or it might get lucky and hit foomail0 and find out what it actually supported. Similar situations could apply --at least wrt rejection versus bounces-- if foomail1 supported a different set of antispam provisions than foomail2, or, for that matter, if both deferred antispam processing to foomail0. As far as I can tell after a very brief scan, there is no current normative IETF specification that discusses this situation and gives guidance about it. In retrospect, we probably should have at least described the issues with non-identity of services in RFC 1425, but we didn't do that, much less make specific recommendations. I agree with Ned that it would make a lot of sense to explicitly say "no alternate A records because, if they don't represent the same host, you should be using MXs" and "if the first MX you try doesn't support the extension, assume the others don't either and stop". But, because of the generality of the problem, this document doesn't seem to me to be the right place to say that. 5321bis probably would be a reasonable if we think it is a clarification, but especially with YAM in a coma and no mention of this topic in the pre-approval document, the odds of my getting to 5321bis before this EAI work is closed out are in the "low to none" range. Worse, while someone could quickly cons up an I-D to specify this behavior and try to push it through as a Proposed Standard that 5336bis could reference, processing of such a document would essentially constitute a claim that the spec is new and not a clarification to 5321, precluding folding it into 5321bis later, at least without marching that document along the standards track to Draft Standard first. Suggestions about how to get out of that mess are welcome, but I don't think it is an EAI problem (even though 5336bis might plausibly be modified --or the Framework document reopened and modified -- to explain just how ambiguous the whole situation is). For RFC 5336, it was important to call the issue out because the "downgrade or not" behavior is even more complicated than the potential behavior variations with 8BITMIME (remembering that one can offer the option but, if the next hop doesn't support 8bit transport, one can either downgrade or reject) and other extensions.. Whether it is necessary to say anything at all in 5336bis, given how little we have said in places that perhaps establish precedents, is debatable. But please let's not suggest expanding on this case in this document to cover other email environments, especially in the context of urging the the spec keep its scope and assertions narrow. Dave Crocker 2010-12-22 wrote: >> 3.6.4.2. VRFY and EXPN Commands and the UTF-8REPLY >>Parameter >> If the VRFY and EXPN commands are transmitted with the >> optional parameter "UTF-8REPLY", it indicates the client >> can accept UTF-8 strings in replies to those commands. >> This allows the server to use UTF-8 strings in mailbox > { Is this extension trying to to say that a client might > support UTF8SMTPbis but not be able to access UTF-8 > replies??? Under what circumstance is this reasonable? } >... Not what it is intending to say (could have been expressed better). Consider the following scenario: Client sends EHLO, server offers UTF8SMTPbis. Client sends VRFY as its next command, using an ASCII-only argument and no parameter. The server has no clue as to whether or not the client is EAI-compliant or otherwise has any idea what to with a reply containing a non-ASCII address. For the server to return a non-ASCII string under those circumstances would be in violation of 5321. (12) The keyword denoted as "UTF8SMTPbis" in the drafts. While the changes between the Experimental protocols and the present draft are not large, they are also not trivial. After fairly extensive discussion, the WG concluded that these new specifications should be denoted by a different SMTP Extension keyword than the "UTF8SMTP" that was used by the Experimental version (RFC 5336). In large part because of concerns that some implementation would be deployed in advance of the specification becoming final, the WG concluded that the new/ final keyword should be assigned only as part of the IESG approval process. "UTF8SMTPbis" is only a placeholder and will not be that final keyword. It may be worth noting that, if the protocol is changed to require a MAIL command parameter, that WG decision will have turned out to be quite important. Anyone who strongly believes that some variation on the "UTF8SMTP" theme misrepresents what is actually happening in these specifications is welcome to suggest other keywords to the IESG. (13) New content types for embedded messages. Dave Crocker 2010-12-22 wrote: > 3. There probably needs to be definition of MIME > message/uni-rfc822, specifying Unicode support within a > message contained in MIME. I'm less clear whether there > needs to be a MIME Content-Transfer-Encoding form specific > to UTF-8. See message/global in draft-ietf-eai-rfc5335bis. This is an area where the WG's decisions about what material belonged in which document followed the advice to keep header and body part discussions in 5335bis rather than 5336bis. (14) Procedural and quasi-procedural issues Dave Crocker 2010-12-22 wrote: > 1. The Framework document is normative and needs to be > completed along with the other two specifications, since > they quite reasonably state a normative dependence on the > Framework document. >... > * Framework -- The Framework document[1] is (correctly) > referenced as required reading. It supplies essential > terminology and architecture for this specification. In > fact it is a specification, complete with formally normative > vocabulary. This means that it must be a normative > reference by rfc5336bis. It therefore also means that the > Framework document needs to be completed before the current > specification can be standardized. Note that the Framework document went through IETF Last Call and was approved by the IESG last September for publication as Informational. The WG was agnostic on whether it should be Informational or Standards Track. Since it is still in the RFC Editor queue awaiting references to the documents now under review, I assume that, if there were sufficient consensus that it is normative and should be on the Standards Track, the IESG could be persuaded to revisit that decision. In addition, while I don't believe that anything in these reviews requires doing so, the document could, in principle, be recalled by the IESG and material changed or altered. Dave Crocker 2010-12-22 wrote: > * Infrastructure Requirement -- Unless this option is in > force, carrying internationalized email in a MIME part is > prohibited. This is out of scope for the working group and > it is a counter-productive rule. Imagine if the same type >... There may well be an editorial problem with how this is written up or even with how "internationalized mail" is defined. But I see nothing that supports the apparent hyperbole in the comments above. Remember that 5322 and the base MIME specs prohibit non-ASCII headers, so messages containing such headers (as the message header or MIME headers) are prohibited by those specs without some new extension(s). There is no (intentional) prohibition in these documents against carrying non-ASCII text in mail messages. And, if one wanted to pseudo-encapsulate a message and its headers by treating it as, e.g., text/plain with charset=utf8, rather than as message/rfc822 (or message/global), these specifications don't prohibit that either (might not be a good idea because of the loss of recognition and handling of boundary markers and internal Content-Types and Content-Transfer-Encoddings, but that is not a problem for this specification). So, unless the comment above is just the result of confusion brought on by an editorial problem, I don't see where you are going with it. (15) Future of rfc5336bis. Ned Freed, 20101222 wrote: > One final comment. Several of the issues that have been raised > are so fundamental that once they are addressed (point (0) > especially), this document is almost certainly going to > require another full review cycle. Sadly, I agree. I even believe that, were none of these fundamental issues present, the number of editorial corrections (including ABNF matters) that are required will be sufficiently extensive that the risk of introducing new problems would require such a review cycle. john From alexey.melnikov@isode.com Tue Dec 28 14:20:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98ED3A695B; Tue, 28 Dec 2010 14:20:07 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbkoR3uOz-G1; Tue, 28 Dec 2010 14:20:06 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ECE4F3A68E8; Tue, 28 Dec 2010 14:20:05 -0800 (PST) Received: from [188.28.189.65] (188.28.189.65.threembb.co.uk [188.28.189.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 28 Dec 2010 22:22:06 +0000 Message-ID: <4D1A4414.5060103@isode.com> Date: Tue, 28 Dec 2010 20:09:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed References: <01NVQAP0UQRU007CHU@mauve.mrochek.com> <227C2506194609988B81BE4F@PST.JCK.COM> <01NVVQNSWU7U007CHU@mauve.mrochek.com> In-Reply-To: <01NVVQNSWU7U007CHU@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , apps-discuss@ietf.org, John C Klensin , ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org Subject: Re: [apps-discuss] [EAI] RFC5336 and VRFY/EXPN X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 22:20:07 -0000 [With my MTA server developer hat on, not speaking as an AD] Ned Freed wrote: >>In addition, one must have a session for which mail transactions >>are permitted (i.e., EHLO must have been sent) in order to use >>any parameters at all. >> >> > >You certainly need to send an EHLO and process the result to find out what >extensions are allowed - guessing what combination of extensions will work most >certainly is not a sound operational policy. And implementations are certainly >free to only offer the extensions that have been returned in an EHLO repsonse. > >That said, I don't see an actual requirement in section 2.2 stating that EHLO >must be issued before any parameters can be used. (Maybe it's somewhere else, >but a cursory search didn't find it.) Our MTA certainly doesn't enforce this >and AFAIK neither does sendmail, PostFix, Apache James, or qmail. > Isode M-Switch doesn't enforce this either. >(Exim, OTOH, appears to.) > > >>RFC 5321, Section 4.1.4, explicitly >>permits sending VRFY or EXPN without first having EHLO in the >>session. So there is another implicit requirement in all of >>this that should almost certainly be made explicit. >> >> >There certainly should be a note saying that you need to issue an EHLO >and check the response before attaching any parameters to VRFY/EXPN. I don't >think a requirement that parameters not be accepted before an EHLO >has been issued is needed. > > +1. Maybe the client has cached EHLO response from a previous connection. >>(I think >>this is the topic about handshaking that Dave and Shawn have >>been circling around, but I'm not sure). >> >> >It's part of it, I think. > > >>>However, this brings up >>>another issue, which is that a server that supports this >>>extension needs a way to tell a client that doesn't that >>>it cannot return a proper response to VRFY/EXPN without >>>that parameter being specified. A new SMTP error status is >>>needed, but the document only defines an extended status >>>for this purpose; it doesn't specify a regular status code to >>>use. >>> >>> >>If we go down this path, the WG clearly needs to reexamine >>whether such a code is necessary. I think you have made a >>persuasive case, but I can't speak for the WG. >> >> >*It doesn't have to be a new code. OTOH, it needs to be a code that EXPN/VRFY >don't return for other purposes, and I think if you look at the list of >available codes a new code is needed. >* > >>Indeed, this has all gotten sufficiently complex that I think >>perhaps the WG should reexamine its decision to handle the "VRFY >>and EXPN with possible non-ASCII responses" situation by >>parameterizing those commands rather than introducing new >>commands, say VRF8 and EXP8. IIR, the WG did consider that >>alternative (long ago) and conclude that adding a parameter was >>the more straightforward option. But, perhaps, given the >>various complexities that have emerged, that was not the right >>decision. >> >> >I considered suggesting new commands, but given the need to specify >syntax for the new commands I don't see this as any simplier >specification-wise. In terms of implementation, a new command is actually >a somewhat more complex - the code changes are less localized, and I suspect >other implementations will be comparable in this regard. > > +1. >But the minute you need some other variant on EXPN and VRFY, the alternate >command appraoch becomes the far more complex way to do it. Now, we haven't had >a specification come along that needed additional EXPN/VRFY parameters before >this one, but these things have a way of showing up once you open the door and >get people thinking about them. So I'm strongly inclined to stick with the >parameter approach. > > +1. From McQuilWP@pobox.com Thu Dec 30 22:51:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2903A68D9 for ; Thu, 30 Dec 2010 22:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo2kWsq8qHHB for ; Thu, 30 Dec 2010 22:51:20 -0800 (PST) Received: from sasl.smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by core3.amsl.com (Postfix) with ESMTP id 638013A68CC for ; Thu, 30 Dec 2010 22:51:12 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id AD3669BE2; Fri, 31 Dec 2010 01:53:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:mime-version:content-type :content-transfer-encoding; s=sasl; bh=r9qYQLnTUBosv9AkYe19N+6Ou OQ=; b=f46Ecsf+dH9ZaQDvpTLNXrumZSg9kri5IbFvg7aZYuO6h7WDP+kjfGFhM OihMdlzM2sOBIob/7sn2MMFrrK/3Tnk5P21Qi4Ral5Ww/Nw1+7AV96GWrjjUfKvN 90ST+aJLm++0uQrjfdPLgP1R+hpLFTzZnU9lnkK69aRi1nbgKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=N/K3Pdzr4ZmA48B6P6O EpK2OgBHlH/ttpvzA7ddf6i2woLRVAE3IPme2u8jxCUmwGfRyUU/7owP6eP571qI R9uVo9BcZZ/U/aZtHACEUu+/V3J34L5gVOrTdaZyazEgKkskvtNqp9KHouoxHL+w 0G23lgKCpZCILf6UJfXwDBKA= Received: from b-pb-sasl-quonix. (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 88D6E9BE1; Fri, 31 Dec 2010 01:53:15 -0500 (EST) Received: from [192.168.0.2] (unknown [68.107.61.33]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id E9D269BE0; Fri, 31 Dec 2010 01:53:12 -0500 (EST) Date: Thu, 30 Dec 2010 22:53:11 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <638765034.20101230225311@pobox.com> To: Apps-Discusssion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A456878C-14AA-11E0-B840-9C677F325826-02871704!b-pb-sasl-quonix.pobox.com Subject: [apps-discuss] Comments on draft-ietf-websec-origin-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 06:51:48 -0000 My comments on draft-ietf-websec-origin-00. 2.2. Syntax Notation The use of allows for header fields containing lines with nothing but spaces and tabs. Does http handle this? -------------------- 4. Comparing Origins Although Section 3 discusses an "implementation-defined value" and '"sandbox" bits', the comparison algorithm does not mention how these are to be handled. -------------------- 5. Serializing Origins The "implementation-defined value" and '"sandbox" bits' are not discussed in the serialization algorithm. ----- In step 5 of each algorithm the port is omitted if it is not "different than the default port". This could be problem since it requires three different algorithms to agree on that default. 1 - At the point where the resource is fetched from the "origin" and the default port MUST be known if the correct connection is to be made. 2 - At the serialization point. 3 - At the server receiving the "Origin:" header field. Instead I recommend that the actual port always be included in the serialization to avoid ambiguity. After all it's mainly for machine consumption. -------------------- 6. The HTTP Origin header 6.2. Semantics It is not clear what the meaning of multiple origins is. Should the client issuing a request include all of the origins that it knows about? This might make it more likely that the server receiving the request would find an origin it "likes". Or it might make it more likely that the server would find an objectionable origin. What "meaning" is the client trying to communicate to the server? ----- 6.3. User Agent Requirements The rule about "two consecutive serialized-origin productions" not being identical implies that there is some semantics in the ordering of the serialized origins in an Origin header field. Also the mention of the way that the "ascii-serialization of the origin of previous-uri" is appended to the previous request Origin header field implies an ordering. Does ordering have any semantics in the Origin header field? -- Bill McQuillan From barryleiba.mailing.lists@gmail.com Fri Dec 31 05:40:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BC23A6915 for ; Fri, 31 Dec 2010 05:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=0.336, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7G6mDX8ZGZg for ; Fri, 31 Dec 2010 05:40:51 -0800 (PST) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.214.177]) by core3.amsl.com (Postfix) with ESMTP id C6B5B3A6809 for ; Fri, 31 Dec 2010 05:40:51 -0800 (PST) Received: by iwn38 with SMTP id 38so14297746iwn.22 for ; Fri, 31 Dec 2010 05:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=eRlBDE6vKoAjwMtwxH8SV/+mu9SJX/qv0rUdQALRrug=; b=ARZKrSzpo2OBLwoYiZADBeAdbFGnZ9ReyssJoKjvhk7xyYza86WMBaDYAV09oHOyJj l4jdlCt3fGP0ono+y5Ra25Uy1e1MbVBbyaKdkIut2bwG3MTmgQeVlE7WY7oEIjGZQ+jv JW4agiGz43yjIbQPC+TKuOIGF862sJl47UtMQ= 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=U4CmZNWXOgmpE6e/6YwTb3Hh0gQmNWMe6ZfOvMSy/q0ByngYlT7adcPbHQh30AjCiZ X9oBzr4POzJS6enTvaQHb2nQSKXN5m6njA6/Xl7+l0YksTxDJG6EVVi0YqDSFNpLpIJs NL0w4OF45pnVleZsyyj/FXg/s2+17QQHJUFAA= MIME-Version: 1.0 Received: by 10.42.171.137 with SMTP id j9mr17930892icz.80.1293802977612; Fri, 31 Dec 2010 05:42:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.240.2 with HTTP; Fri, 31 Dec 2010 05:42:57 -0800 (PST) In-Reply-To: <638765034.20101230225311@pobox.com> References: <638765034.20101230225311@pobox.com> Date: Fri, 31 Dec 2010 08:42:57 -0500 X-Google-Sender-Auth: 0ndjZJGozQrKVrUoHS8Pn_Cg6kU Message-ID: From: Barry Leiba To: Bill McQuillan Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps-Discusssion Subject: Re: [apps-discuss] Comments on draft-ietf-websec-origin-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 13:40:52 -0000 On Fri, Dec 31, 2010 at 1:53 AM, Bill McQuillan wrote: > My comments on draft-ietf-websec-origin-00. You should post these, along with any other comments you have on the websec work, to the websec WG mailing list, . Barry
On 12/6/2010 2:36 AM, Mykyta Yevstifeyev wrote:
2010/12/6, Tony Hansen<tony@att.com>:
     n              = 0*DIGIT    ;minimum amount of elements
     m              = 0*DIGIT    ;maximum amount of elements
Will be taken into consideration.
Or, maybe, just *DIGIT .

*DIGIT is fine