From cyrus@daboo.name Mon Jan 2 10:42:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7CB21F84FC; Mon, 2 Jan 2012 10:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMVHhNnxRGYF; Mon, 2 Jan 2012 10:42:14 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id A060121F84C9; Mon, 2 Jan 2012 10:42:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CFD5F1F9346F; Mon, 2 Jan 2012 13:42:12 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnmqNuWXzxYu; Mon, 2 Jan 2012 13:42:11 -0500 (EST) Received: from [10.0.1.8] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 8F0421F9345D; Mon, 2 Jan 2012 13:42:10 -0500 (EST) Date: Mon, 02 Jan 2012 13:42:04 -0500 From: Cyrus Daboo To: Salvatore Loreto , apps-discuss@ietf.org, draft-daboo-webdav-sync.all@tools.ietf.org Message-ID: In-Reply-To: <4EEE4026.7050108@ericsson.com> References: <4EEE4026.7050108@ericsson.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1162 Cc: The IESG Subject: Re: [apps-discuss] Apps Dir review for: draft-daboo-webdav-sync-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 18:42:15 -0000 Hi Salvatore, Thank you for your review. Comments inline: --On December 18, 2011 9:33:58 PM +0200 Salvatore Loreto wrote: > Minor Issues: > > > Abstract: > > > expand the WebDAV acronym on the first use. Fixed for -07. > Preconditions: > > (DAV:valid-sync-token): The DAV:sync-token element value MUST be a > valid token previously returned by the server. > > > please clarify that the token is collection specific, so it needs to be > originated > from the same collection. Fixed in -07. Now reads: The DAV:sync-token element value MUST be a valid token previously returned by the server for the collection targeted by the request-URI. > sync-token?) > > > > > > remove the DAV: prefix. Fixed in -07. > > > Nits: > > > References: > > - draft-ietf-vcarddav-carddav has been published as RFC 6352 Fixed in -07. > - the nits tools also report the following error: > Downref: Normative reference to an Experimental RFC: RFC 5842 AD is aware that a Downref occurs. -- Cyrus Daboo From msk@cloudmark.com Tue Jan 3 14:46:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9367E11E80FF for ; Tue, 3 Jan 2012 14:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDV-SiBVQia2 for ; Tue, 3 Jan 2012 14:46:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2369511E80FC for ; Tue, 3 Jan 2012 14:46:22 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 14:46:16 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 3 Jan 2012 14:46:21 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 3 Jan 2012 14:46:20 -0800 Thread-Topic: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKaTAdZqWFlE64QsWaJN4GvBcx2AAAE7NA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5833273385BB34F99288B3648C4F06F19C6C156DFEXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:46:22 -0000 --_002_F5833273385BB34F99288B3648C4F06F19C6C156DFEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've started this individual submission to correct the SPF entry in the Aut= hentication-Results result name table from "hardfail" to "fail", to match w= hat RFC4408 (and presumably RFC4408bis) says. This corrects an approved er= ratum against RFC5451. I suggested this as a first-tier work item for spfbis but there was resista= nce to doing so for the sake of keeping its charter lean; since it's really= a lightweight effort, I decided to move ahead with it on my own. Please give it a once over and a thumbs-up if I haven't missed anything. Thanks, -MSK --_002_F5833273385BB34F99288B3648C4F06F19C6C156DFEXCHC2corpclo_ Content-Type: message/rfc822 Received: from EXCH-HTCAS902.corp.cloudmark.com (172.22.10.74) by spite.corp.cloudmark.com (172.22.10.72) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Jan 2012 14:44:01 -0800 Received: from mail.cloudmark.com (208.83.136.59) by ht2.cloudmark.com (172.22.10.81) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 14:44:00 -0800 Received: from mail.ietf.org ?(mail.ietf.org [12.22.58.30]) by mail.cloudmark.com (8.14.3/8.14.3) with ESMTP id q03Mi0LO002856 for ; Tue, 3 Jan 2012 14:44:00 -0800 (envelope-from i-d-announce-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348CF1F0C3E; Tue, 3 Jan 2012 14:43:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3997111E80FF for ; Tue, 3 Jan 2012 14:43:52 -0800 (PST) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAFad9o2i+pt for ; Tue, 3 Jan 2012 14:43:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124D11E80CE for ; Tue, 3 Jan 2012 14:43:51 -0800 (PST) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Tue, 3 Jan 2012 14:43:51 -0800 Subject: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Topic: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKaTAdZqWFlE64QsWaJN4GvBcx2A== Message-ID: <20120103224351.24172.59587.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: exch-htcas902.corp.cloudmark.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Pass X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-PRD: ietf.org X-MS-TNEF-Correlator: received-spf: Pass (exch-htcas902.corp.cloudmark.com: domain of i-d-announce-bounces@ietf.org designates 12.22.58.30 as permitted sender) receiver=exch-htcas902.corp.cloudmark.com; client-ip=12.22.58.30; helo=mail.cloudmark.com; dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325630634; bh=hE9+aW5JP72WN5+in+cevhvU5MPcfUu6s/rlUqyue2E=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=F70l3eAnrHIN1vAAHs5oF6exHQ5ZCArti9tPo9jOI++kzzV3zfbbGiK+KFxEggfI2 bO3ACrf75/McJKsiEAH/i1kfG8xQY17FEWlxfDvR+/Bo+5nUDKA+wwcZk4IYpUMLdR ED/8hZAaJvr1+b9q6NyUzJwMNSuG0e4dFxwZNVRg= errors-to: i-d-announce-bounces@ietf.org delivered-to: i-d-announce@ietfa.amsl.com x-spam-flag: NO x-virus-scanned: amavisd-new at amsl.com x-spam-score: -102.582 x-spam-level: x-spam-status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-original-to: i-d-announce@ietfa.amsl.com x-beenthere: i-d-announce@ietf.org x-mailman-version: 2.1.12 list-id: Internet Draft Announcements only list-archive: list-post: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Authentication-Results Registration Update for SPF Resul= ts Author(s) : Murray S. Kucherawy Filename : draft-kucherawy-authres-spf-erratum-00.txt Pages : 5 Date : 2012-01-03 This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SPF specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.t= xt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_002_F5833273385BB34F99288B3648C4F06F19C6C156DFEXCHC2corpclo_-- From sm@resistor.net Tue Jan 3 15:18:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E696E11E8079 for ; Tue, 3 Jan 2012 15:18:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrWto6+cqgTZ for ; Tue, 3 Jan 2012 15:18:45 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40811E8072 for ; Tue, 3 Jan 2012 15:18:45 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q03NIe22002634 for ; Tue, 3 Jan 2012 15:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325632724; i=@resistor.net; bh=iD3Gur3n4VSfXJ42cyFdoCC1+oeEdg13Vm+oVNa9n4o=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=YVOiBLi6Wl3XdAjAhAZnIbMsq0xptDPL8Fd1bgZjKlrjK4Br61pHhN3ZtOX+nxEzZ gX2cuasmI1g8RlFKpAsQdq3HpDu3TUrEzI92pqFf9N0OoX0cqbNZxKaIPQv6dpPuht Mq9AHEAjvxf+pyAor9XbtwjxQltGjicDgR+mfWoQ= Message-Id: <6.2.5.6.2.20120103145134.099ad970@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 15:11:34 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:18:47 -0000 Hi Murray, At 14:46 03-01-2012, Murray S. Kucherawy wrote: >I've started this individual submission to correct the SPF entry in >the Authentication-Results result name table from "hardfail" to >"fail", to match what RFC4408 (and presumably RFC4408bis) >says. This corrects an approved erratum against RFC5451. > >I suggested this as a first-tier work item for spfbis but there was >resistance to doing so for the sake of keeping its charter lean; >since it's really a lightweight effort, I decided to move ahead with >it on my own. May I suggest that you consider a few points: 1. If this work is dependent upon 4408bis, the author has an incentive to see 4408bis published. :-) 2. There is an assumption about what 4408bis will conclude. 3. 5451bis will likely be published this year. The erratum could be folded into it. Regards, -sm From internet-drafts@ietf.org Tue Jan 3 15:56:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC21F0C5B; Tue, 3 Jan 2012 15:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e4b-tBmL3xf; Tue, 3 Jan 2012 15:56:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82D11F0C56; Tue, 3 Jan 2012 15:56:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103235637.12510.62467.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 15:56:37 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:56:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Filename : draft-ietf-appsawg-json-pointer-00.txt Pages : 7 Date : 2012-01-03 JSON Pointer defines a string syntax for identifying a specific value within a JSON document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt From msk@cloudmark.com Tue Jan 3 15:59:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15A91F0C5D for ; Tue, 3 Jan 2012 15:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDwBoukMc5P5 for ; Tue, 3 Jan 2012 15:59:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 13E651F0C50 for ; Tue, 3 Jan 2012 15:59:01 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 15:58:55 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 3 Jan 2012 15:59:00 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 3 Jan 2012 15:58:59 -0800 Thread-Topic: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKbhKf0ayHWLVWS8+HGnlvsCz8RwABXvlw Message-ID: References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> In-Reply-To: <6.2.5.6.2.20120103145134.099ad970@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:59:01 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Tuesday, January 03, 2012 3:12 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres- > spf-erratum-00.txt >=20 > May I suggest that you consider a few points: >=20 > 1. If this work is dependent upon 4408bis, the author has an > incentive to see > 4408bis published. :-) It is not dependent on 4408bis. The update is correct whether or not that = ever publishes. > 2. There is an assumption about what 4408bis will conclude. Where? > 3. 5451bis will likely be published this year. The erratum could be fo= lded > into it. There's no 5451bis effort afoot that I know of. -MSK From internet-drafts@ietf.org Tue Jan 3 15:59:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A431F0C67; Tue, 3 Jan 2012 15:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy00Z3jMqnrG; Tue, 3 Jan 2012 15:59:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095B01F0C61; Tue, 3 Jan 2012 15:59:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103235905.13595.45789.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 15:59:05 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:59:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Filename : draft-ietf-appsawg-json-patch-00.txt Pages : 12 Date : 2012-01-03 JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-00.txt From sm@resistor.net Tue Jan 3 16:35:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941CA11E8093 for ; Tue, 3 Jan 2012 16:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJkeffidUUGJ for ; Tue, 3 Jan 2012 16:35:32 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1911E808D for ; Tue, 3 Jan 2012 16:35:32 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q040ZRec028597 for ; Tue, 3 Jan 2012 16:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325637331; i=@resistor.net; bh=M/8xZ4gRwZvm8SesRf8zFtg5xWlQ5XJxxITINFMpuG4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GsIIp0Ki5oXXS2fgwpC5Nr1exIM2LysHnDVkyF9atTuXCbV6rzEn5xE0wNUJ9qO1w ODWCzGjdL05bQc3ZvNzDO8j2bNkVOEG/OMvHgDGZQYYld7CWU2Xv7BLn0PVpnGjuBp jyhM7vR7L1mdxYDrlyodp6/sYoMqc1zj85LD2Md8= Message-Id: <6.2.5.6.2.20120103161311.08dfa958@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 16:23:02 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:35:35 -0000 Hi Murray, At 15:58 03-01-2012, Murray S. Kucherawy wrote: >It is not dependent on 4408bis. The update is correct whether or >not that ever publishes. Could the update wait until 4408bis is done? >Where? There is an existing effort to revise RFC 4408. >There's no 5451bis effort afoot that I know of. Don't tempt me. :-) Regards, -sm From scott@kitterman.com Tue Jan 3 19:28:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1721F84B6 for ; Tue, 3 Jan 2012 19:28:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoYu3FatIaeX for ; Tue, 3 Jan 2012 19:28:31 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9084321F84B5 for ; Tue, 3 Jan 2012 19:28:31 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1E2BF20E4100; Tue, 3 Jan 2012 22:28:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325647711; bh=bdxxn8gJUgGZzUs9ipYuXxRt3aL3Zf5S7aXlz87ve9k=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=OarNeFk879EElccgd1LXq1y350vPrIbDihPLz3BshNeyMWmBNvSzh9SYQW/ohsVw2 qNSUEUa8dbeTwazNWhQWatuLVs6TMJ9GlpvthVHJNWJiV4NVwDoAvDjGGrPJvCXWtm QIu8TE7d64PKnpNCx2TqNAHskfeJ1TeUdUTORE3s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F40EF20E409F; Tue, 3 Jan 2012 22:28:30 -0500 (EST) From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 03 Jan 2012 22:28:30 -0500 Message-ID: <1626891.r5HM3dHTq5@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20120103145134.099ad970@resistor.net> References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:28:32 -0000 On Tuesday, January 03, 2012 03:11:34 PM SM wrote: > Hi Murray, > > At 14:46 03-01-2012, Murray S. Kucherawy wrote: > >I've started this individual submission to correct the SPF entry in > >the Authentication-Results result name table from "hardfail" to > >"fail", to match what RFC4408 (and presumably RFC4408bis) > >says. This corrects an approved erratum against RFC5451. > > > >I suggested this as a first-tier work item for spfbis but there was > >resistance to doing so for the sake of keeping its charter lean; > >since it's really a lightweight effort, I decided to move ahead with > >it on my own. > > May I suggest that you consider a few points: > > 1. If this work is dependent upon 4408bis, the author has an incentive to > see 4408bis published. :-) This work is not dependent on 4408bis. This is a defect in 5451 that exists relative to 4408. IIRC I even brought it up in the working group, but didn't prevail at the time. I have some opinions about other issues that might be addressed, but I think this is just a plain bug in 5451 that ought to be fixed. Scott K From msk@cloudmark.com Tue Jan 3 19:33:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1F21F84D5 for ; Tue, 3 Jan 2012 19:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A50ke5VJEdYj for ; Tue, 3 Jan 2012 19:33:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A143421F84D4 for ; Tue, 3 Jan 2012 19:33:44 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 19:33:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 3 Jan 2012 19:33:43 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 3 Jan 2012 19:33:42 -0800 Thread-Topic: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKeMqQVeY0jKzOSIC8yr9bXpkdKQAGKv2g Message-ID: References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> <6.2.5.6.2.20120103161311.08dfa958@resistor.net> In-Reply-To: <6.2.5.6.2.20120103161311.08dfa958@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:33:45 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Tuesday, January 03, 2012 4:23 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-e= rratum-00.txt >=20 > Could the update wait until 4408bis is done? Yes, that's one option. But why wait? 4408bis is not likely to change the= name of "fail" as it would seriously impact backward compatibility, someth= ing its charter says they will be avoiding. -MSK From duerst@it.aoyama.ac.jp Tue Jan 3 22:24:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9121F85EE for ; Tue, 3 Jan 2012 22:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.58 X-Spam-Level: X-Spam-Status: No, score=-97.58 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jG2UhzYDvYE for ; Tue, 3 Jan 2012 22:24:30 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 221B621F85F0 for ; Tue, 3 Jan 2012 22:24:29 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q046O7nC002746 for ; Wed, 4 Jan 2012 15:24:13 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 50de_1c6d_b4fab0ee_369c_11e1_a663_001d096c566a; Wed, 04 Jan 2012 15:24:07 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36904) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 4 Jan 2012 15:24:12 +0900 Message-ID: <4F03F081.3060803@it.aoyama.ac.jp> Date: Wed, 04 Jan 2012 15:24:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 CC: apps-discuss@ietf.org References: <20120103235637.12510.62467.idtracker@ietfa.amsl.com> In-Reply-To: <20120103235637.12510.62467.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 06:24:31 -0000 A small nit: OLD: this is performed by simply the '\' (escape) NEW: this is performed by simply removing the '\' (escape) More major stuff: If a reference token is being evaluated against a concrete JSON document... Are there JSON documents that are not concrete? How do they look? And immediately preceding that sentence, what happens if the currently referenced value is neither a JSON object nor a JSON array? I guess it should say that this is an error condition. Choice of escape character: I think choosing "\" as the escape character is the right thing to do. There were other proposals such as U+FFFD or a character in the U+0000-001F range, but while they look clever in the spec, they are actually too clever: they may not be visible, and are difficult to type. If such characters were really a good idea as escape characters, then they would already be used that way :-(. Section 5, JSON String Representation: As far as I understand, this will lead to quadruple escaping. That's fine with me, but it would be good to have an example. What about: >>>> For the following JSON object: { "ab\\cd" : { "ef/gh" : 127 } } the JSON Pointer pointing to 127 is "ab\\cd/ef\/gh", consisting of the two reference tokens "ab\cd" and "ef/gh". Please note that in the above JSON object, there are two backslashes in "ab\\cd", but no backslash in "ef/gh", because JSON requires escaping for backslashes, but not for forward slashes, in strings. The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when written as a JSON string: "ab\\\\cd/ef\\\/gh". >>>> If I got it wrong, please correct. But please in any case add an example with explanations. Section 6, URI Fragment Identifier Representation A JSON Pointer MAY be represented in a URI fragment identifier. The JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in the URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], section 2.5. Having to percent-encode the octets in the "unreserved" set would be hopelessly counterproductive. For the above example, it would produce something like: "%61%62%5C%5C%63%64%2F%65%66%5C%2F%67%68" The unreserved set is: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" These are the most 'harmless' characters that never need escaping. (They can be escaped, but it's rarely, rarely done.) Here's how I would rewrite section 6: When a JSON Pointer is used as a fragment identifier in an URI [RFC3986], any characters in a reference token that cannot appear literally in a fragment identifier, as well as a slash when appearing as part of a reference token, has to be escaped by converting it to a sequence of octets using UTF-8 [RFC3629] and percent-encoding [RFC3986] each octet. As an example, the JSON Pointer "ab\\cd/ef\/gh" becomes "ab%5Ccd/ef%2Fgh" as a fragment identifier. Please note that the URI syntax can distinguish between slashes used inside a reference token (written "%2F") and slashes used as reference token separators (written "/"); as a consequence, a backslash in a reference token only has to be escaped as "%5C" (and not "%5C%5C") because the backslash isn't needed as an escape character. Again, if I got this wrong, please correct, but please include actual examples and explanations. Regards, Martin. On 2012/01/04 8:56, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : JSON Pointer > Author(s) : Paul C. Bryan > Kris Zyp > Filename : draft-ietf-appsawg-json-pointer-00.txt > Pages : 7 > Date : 2012-01-03 > > JSON Pointer defines a string syntax for identifying a specific value > within a JSON document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-00.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From paul.bryan@forgerock.com Tue Jan 3 23:11:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7F21F8600 for ; Tue, 3 Jan 2012 23:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXaco0a6a6Q6 for ; Tue, 3 Jan 2012 23:11:45 -0800 (PST) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) by ietfa.amsl.com (Postfix) with SMTP id C05D121F85E4 for ; Tue, 3 Jan 2012 23:11:43 -0800 (PST) Received: from mail-iy0-f179.google.com ([209.85.210.179]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKTwP7oU5Dl4E9qIUw+auzLDj2fzkXJDB3@postini.com; Wed, 04 Jan 2012 07:11:43 UTC Received: by iaae16 with SMTP id e16so30985437iaa.10 for ; Tue, 03 Jan 2012 23:11:28 -0800 (PST) Received: by 10.50.195.129 with SMTP id ie1mr65136709igc.29.1325661087958; Tue, 03 Jan 2012 23:11:27 -0800 (PST) Received: from [192.168.1.5] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id gh7sm91413352igb.1.2012.01.03.23.11.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 23:11:26 -0800 (PST) Message-ID: <1325661084.2902.28.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 03 Jan 2012 23:11:24 -0800 In-Reply-To: <4F03F081.3060803@it.aoyama.ac.jp> References: <20120103235637.12510.62467.idtracker@ietfa.amsl.com> <4F03F081.3060803@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="=-lBR/pAGS0PHiFM8DO2yR" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 07:11:46 -0000 --=-lBR/pAGS0PHiFM8DO2yR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2012-01-04 at 15:24 +0900, "Martin J. Dürst" wrote: > > A small nit: > > OLD: > this is performed by simply the '\' (escape) > NEW: > this is performed by simply removing the '\' (escape) Thanks. I removed "removed" instead of "simply" in a last-minute revision. Fixed. > More major stuff: > > If a reference token is being evaluated against a concrete JSON > document... > > Are there JSON documents that are not concrete? How do they look? Good point. > And immediately preceding that sentence, what happens if the > currently > referenced value is neither a JSON object nor a JSON array? I guess > it > should say that this is an error condition. +1. > Choice of escape character: I think choosing "\" as the escape > character > is the right thing to do. There were other proposals such as U+FFFD or > a > character in the U+0000-001F range, but while they look clever in the > spec, they are actually too clever: they may not be visible, and are > difficult to type. If such characters were really a good idea as > escape > characters, then they would already be used that way :-(. Yes, this one took some thought. Ultimately I wasn't thrilled with the use of exotic Unicode characters for a number of reasons, including avoiding inventing exotic solutions; most developers are familiar with how to use backslash, and it's on every modern keyboard. > Section 5, JSON String Representation: > > As far as I understand, this will lead to quadruple escaping. That's > fine with me, but it would be good to have an example. What about: > > >>>> > For the following JSON object: > > { "ab\\cd" : { "ef/gh" : 127 } } > > the JSON Pointer pointing to 127 is "ab\\cd/ef\/gh", consisting of > the > two reference tokens "ab\cd" and "ef/gh". Please note that in the > above > JSON object, there are two backslashes in "ab\\cd", but no backslash > in > "ef/gh", because JSON requires escaping for backslashes, but not for > forward slashes, in strings. > > The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when > written as a JSON string: "ab\\\\cd/ef\\\/gh". > >>>> > > If I got it wrong, please correct. But please in any case add an > example > with explanations. Okay. > Section 6, URI Fragment Identifier Representation > > A JSON Pointer MAY be represented in a URI fragment identifier. > The > JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in > the > URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], > section 2.5. > > Having to percent-encode the octets in the "unreserved" set would be > hopelessly counterproductive. For the above example, it would produce > something like: > > "%61%62%5C%5C%63%64%2F%65%66%5C%2F%67%68" Thanks for catching this mistake. I (again!) misquoted RFC 3986, missing the double negative. Fixing. > The unreserved set is: > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > These are the most 'harmless' characters that never need escaping. > (They > can be escaped, but it's rarely, rarely done.) > > Here's how I would rewrite section 6: > > When a JSON Pointer is used as a fragment identifier in an URI > [RFC3986], any characters in a reference token that cannot > appear literally in a fragment identifier, as well as a slash when > appearing as part of a reference token, has to be escaped by > converting it to a sequence of octets using UTF-8 [RFC3629] and > percent-encoding [RFC3986] each octet. > > As an example, the JSON Pointer "ab\\cd/ef\/gh" becomes > "ab%5Ccd/ef%2Fgh" as a fragment identifier. Please note that the > URI syntax can distinguish between slashes used inside a reference > token (written "%2F") and slashes used as reference token > separators > (written "/"); as a consequence, a backslash in a reference token > only has to be escaped as "%5C" (and not "%5C%5C") because the > backslash isn't needed as an escape character. So while indeed it seems URIs do allow for the reserved character "/" to be used as a subcomponent delimiter and %2F to be treated as a data, having a different string syntax for representation in JSON string values and fragment identifiers will almost certainly lead to implementation complexity (and implementation errors). This is in fact one reason we drove toward pure Unicode strings and only require URI percent-encoding when encoding in a URI. This topic seems debatable though. > Again, if I got this wrong, please correct, but please include actual > examples and explanations. > > Regards, Martin. Thanks! Paul --=-lBR/pAGS0PHiFM8DO2yR Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-01-04 at 15:24 +0900, "Martin J. Dürst" wrote:

A small nit:

OLD:
this is performed by simply the '\' (escape)
NEW:
             this is performed by simply removing the '\' (escape)

Thanks. I removed "removed" instead of "simply" in a last-minute revision. Fixed.

More major stuff:

If a reference token is being evaluated against a concrete JSON
document...

Are there JSON documents that are not concrete? How do they look?

Good point.

And immediately preceding that sentence, what happens if the currently
referenced value is neither a JSON object nor a JSON array? I guess it
should say that this is an error condition.

+1.

Choice of escape character: I think choosing "\" as the escape character
is the right thing to do. There were other proposals such as U+FFFD or a
character in the U+0000-001F range, but while they look clever in the
spec, they are actually too clever: they may not be visible, and are
difficult to type. If such characters were really a good idea as escape
characters, then they would already be used that way :-(.

Yes, this one took some thought. Ultimately I wasn't thrilled with the use of exotic Unicode characters for a number of reasons, including avoiding inventing exotic solutions; most developers are familiar with how to use backslash, and it's on every modern keyboard.

Section 5, JSON String Representation:

As far as I understand, this will lead to quadruple escaping. That's
fine with me, but it would be good to have an example. What about:

>>>>
For the following JSON object:

{ "ab\\cd" : { "ef/gh" : 127 } }

the JSON Pointer pointing to 127 is "ab\\cd/ef\/gh", consisting of the
two reference tokens "ab\cd" and "ef/gh". Please note that in the above
JSON object, there are two backslashes in "ab\\cd", but no backslash in
"ef/gh", because JSON requires escaping for backslashes, but not for
forward slashes, in strings.

The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when
written as a JSON string: "ab\\\\cd/ef\\\/gh".
>>>>

If I got it wrong, please correct. But please in any case add an example
with explanations.

Okay.

Section 6, URI Fragment Identifier Representation

A JSON Pointer MAY be represented in a URI fragment identifier. The
JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in the
URI "unreserved" set SHOULD be percent-encoded, per [RFC3986],
section 2.5.

Having to percent-encode the octets in the "unreserved" set would be
hopelessly counterproductive. For the above example, it would produce
something like:

"%61%62%5C%5C%63%64%2F%65%66%5C%2F%67%68"

Thanks for catching this mistake. I (again!) misquoted RFC 3986, missing the double negative. Fixing.

The unreserved set is:
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
These are the most 'harmless' characters that never need escaping. (They
can be escaped, but it's rarely, rarely done.)

Here's how I would rewrite section 6:

When a JSON Pointer is used as a fragment identifier in an URI
[RFC3986], any characters in a reference token that cannot
appear literally in a fragment identifier, as well as a slash when
appearing as part of a reference token, has to be escaped by
converting it to a sequence of octets using UTF-8 [RFC3629] and
percent-encoding [RFC3986] each octet.

As an example, the JSON Pointer "ab\\cd/ef\/gh" becomes
"ab%5Ccd/ef%2Fgh" as a fragment identifier. Please note that the
URI syntax can distinguish between slashes used inside a reference
token (written "%2F") and slashes used as reference token separators
(written "/"); as a consequence, a backslash in a reference token
only has to be escaped as "%5C" (and not "%5C%5C") because the
    backslash isn't needed as an escape character.

So while indeed it seems URIs do allow for the reserved character "/" to be used as a subcomponent delimiter and %2F to be treated as a data, having a different string syntax for representation in JSON string values and fragment identifiers will almost certainly lead to implementation complexity (and implementation errors). This is in fact one reason we drove toward pure Unicode strings and only require URI percent-encoding when encoding in a URI. This topic seems debatable though.

Again, if I got this wrong, please correct, but please include actual
examples and explanations.

Regards,     Martin.

Thanks!

Paul --=-lBR/pAGS0PHiFM8DO2yR-- From evnikita2@gmail.com Tue Jan 3 23:22:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2BB21F85D7; Tue, 3 Jan 2012 23:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBBSc6aSJp+R; Tue, 3 Jan 2012 23:22:33 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2936821F85BE; Tue, 3 Jan 2012 23:22:33 -0800 (PST) Received: by mail-tul01m020-f172.google.com with SMTP id uz6so15436097obc.31 for ; Tue, 03 Jan 2012 23:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UPU82IJYU4fsGp66+H2pG9fvDJPN95oosgQ+Ma8BUZc=; b=pXtjXTj3gG0UVWtHrFtb+qXnWEBvpVAR+22gH6NMNJBh+i5X5b2++9dt4XE87ZJ/dg 1pIojjdKOa3dPr/h8YlIsd+cOSLs1iBTqhhxati1cMACiUjlgv02JMhRj2SMyEcjaB3v Tl2b41CwyIcLE6eZNK4c05Bo4bmAy50XR64Cc= MIME-Version: 1.0 Received: by 10.182.15.104 with SMTP id w8mr47526399obc.20.1325661753018; Tue, 03 Jan 2012 23:22:33 -0800 (PST) Received: by 10.182.30.167 with HTTP; Tue, 3 Jan 2012 23:22:32 -0800 (PST) In-Reply-To: <20120103235905.13595.45789.idtracker@ietfa.amsl.com> References: <20120103235905.13595.45789.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2012 09:22:32 +0200 Message-ID: From: Mykyta Yevstifeyev To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 07:22:33 -0000 Hello, I wonder why these two docs (JSON Patch and JSON Pointer) both have the Intended status 'Standards Track' whereas RFC 4627, that specifies JSON and is the core specification is Informational. Or do we want 'standardize' JSON - than we could produce 4627bis as PS, and include these proposals in such a document. Mykyta Yevstifeyev 2012/1/4 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Applications Area Working Group Wor= king Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : JSON Patch > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Paul C. Bryan > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-json-patch-00= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-03 From sm@resistor.net Wed Jan 4 03:14:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5CE21F8682 for ; Wed, 4 Jan 2012 03:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBJQ8EhUL4tl for ; Wed, 4 Jan 2012 03:14:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452D21F8676 for ; Wed, 4 Jan 2012 03:14:19 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q04BED7u007534 for ; Wed, 4 Jan 2012 03:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325675657; i=@resistor.net; bh=mZXgdDIdnFopnmhO/Vo5EMfj6AR5FJola0R6osn3Hgc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=qs6zqvnjMLtvHJL/QKq0+kxMbeTbBlegK9VCFYxDhIGhH2nKEcXiweKvdQYzOywBa PH0GvHjESfecmygRbDYh5K8bgu5RXIrs3vbnmd1Xiv2Gp0mzClAeWu0r7Ayd1kliNK VOgGTnTEOOuCVpckhsIeGZk17++oPPivgg6MIve0= Message-Id: <6.2.5.6.2.20120104001935.0a997af8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jan 2012 02:28:56 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> <6.2.5.6.2.20120103161311.08dfa958@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:14:21 -0000 Hi Murray, At 19:33 03-01-2012, Murray S. Kucherawy wrote: >Yes, that's one option. But why wait? 4408bis is not likely to >change the name of "fail" as it would seriously impact backward >compatibility, something its charter says they will be avoiding. It's a question of prioritizing work. If I were to object on the Last Call (and you know that I won't), I would adapt some arguments from draft-arkko-iesg-crossarea-00. For example: "The essence of most work is getting the right expertise to the room and to the list. This does not happen through mere organizational forms, people have to be interested about the problem." "expertise is brought through the right people actually reading the specifications." "The best examples of successful work involve combining pieces of expertise, with the parties having an incentive to complete the work." Obviously, none of the above is an adequate basis to prevent publication. It would be easier for me to say that this draft should be published quickly as it is a minor fix that doesn't require too much effort. The decision rests with the Sponsoring AD anyway and whatever I say won't have any effect on it. And by demonstrating support, I end up looking good. Regards, -sm From julian.reschke@gmx.de Wed Jan 4 04:49:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28921F863C for ; Wed, 4 Jan 2012 04:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.856 X-Spam-Level: X-Spam-Status: No, score=-103.856 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76reyUJPh+7M for ; Wed, 4 Jan 2012 04:49:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2611B21F8624 for ; Wed, 4 Jan 2012 04:49:53 -0800 (PST) Received: (qmail invoked by alias); 04 Jan 2012 12:49:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 04 Jan 2012 13:49:52 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19FT5YUj2NFQ8Hssx8mWlSn4W5v6G61/AXUeH8DUV vH+sS8m8EB0VdU Message-ID: <4F044AEE.2080205@gmx.de> Date: Wed, 04 Jan 2012 13:49:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:49:55 -0000 Hi Paul, below some feedback: Section 3: > ABNF syntax: > > json-pointer = *( "/" reference-token ) > reference-token = *( unescaped / escaped ) > unescaped = %x00-2E / %x30-5B / %x5D-10FFFF Is 0 really allowed? (I see JSON allows this as well; maybe that's something that needs to be discussed in the security considerations). > escaped = "\" ( "/" / "\" ) > > It is an error condition if a JSON Pointer value does not conform to > this syntax. I'm fine with this because it allows using \ to escape more values in the future. Section 4: > If the currently referenced value is a JSON array, the reference > token MUST contain an unsigned base-10 integer value, and the new > referenced value is the array element with the zero-based index > identified by the token. Do we want to say something about leading zeroes in index values? I assume they are allowed? Section 5: > A JSON Pointer MAY be represented in a JSON string value. Per > [RFC4627], section 2.5, all instances of quotation mark '"' (%x22), > reverse solidus '\' (%x5C) and control (%x00-1F) characters MUST be > escaped. The MAY is a statement of fact, not a normative requirement. Just say "can". Section 6: > A JSON Pointer MAY be represented in a URI fragment identifier. The > JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in the > URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], > section 2.5. See above. Appendix A: The semantics of fragment identifiers depends on the media type. You need to be clear whether you're trying to define the fragid semantics for application/json (which as far as I recall doesn't define any), or something else. That being said: > http://example.com/example.json# > Resolves to the object value at the root of the JSON text > document. The same would be true for http://example.com/example.json#/ right? I think we should stay away from empty fragment identifiers if we can. (There MAY be dragons here). Best regards, Julian From julian.reschke@gmx.de Wed Jan 4 05:16:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015A21F8716 for ; Wed, 4 Jan 2012 05:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.772 X-Spam-Level: X-Spam-Status: No, score=-103.772 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tlgwmoyhXVh for ; Wed, 4 Jan 2012 05:16:25 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6639B21F85BA for ; Wed, 4 Jan 2012 05:16:25 -0800 (PST) Received: (qmail invoked by alias); 04 Jan 2012 13:09:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp067) with SMTP; 04 Jan 2012 14:09:43 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18+PAAuolE+DBjsEgWxXVMDaKi72xGGm3YCb52Yv8 0iaOefT5GpJsJ1 Message-ID: <4F044F93.9020307@gmx.de> Date: Wed, 04 Jan 2012 14:09:39 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4ED64A26.5030003@gmx.de> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron> In-Reply-To: <1325222688.18477.25.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:16:26 -0000 On 2011-12-30 06:24, Paul C. Bryan wrote: > ... >> 2) The ability to *copy* (not *move*) objects around. > > This is another example of something trivial for the patch > implementation to perform, so I'm inclined to add it to the next draft. > ... ...but you did not :-). Did you decide against it, or is this still on your TODO list? Best regards, Julian From James.H.Manger@team.telstra.com Wed Jan 4 05:34:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52C21F8746 for ; Wed, 4 Jan 2012 05:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud0TaJ7u9PH1 for ; Wed, 4 Jan 2012 05:34:06 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 177C721F8742 for ; Wed, 4 Jan 2012 05:34:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,456,1320584400"; d="scan'208";a="59571939" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 05 Jan 2012 00:34:05 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6578"; a="46849511" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 05 Jan 2012 00:34:04 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 5 Jan 2012 00:34:03 +1100 From: "Manger, James H" To: "duerst@it.aoyama.ac.jp" Date: Thu, 5 Jan 2012 00:34:02 +1100 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt Thread-Index: AczK5YWvsvSi+5BkRgOs5ovwvO1xzg== Message-ID: <5690A6A7-15B9-4F5A-AE85-FCE50894BA88@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:34:07 -0000 PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGlzIHdpbGwgbGVhZCB0byBxdWFkcnVwbGUgZXNj YXBpbmcuIFRoYXQncyBmaW5lIHdpdGggbWUsDQoNClF1YWRydXBsZSBlc2NhcGluZyBpcyBmaW5l ISENCg0KPiBJZiBJIGdvdCBpdCB3cm9uZywgcGxlYXNlIGNvcnJlY3QuDQoNCldoeSBub3QgcGlj ayBhbiBlc2NhcGluZyBtZWNoYW5pc20gd2hlcmUgaXQgaXNuJ3Qgc28gaGFyZCB0byB0ZWxsIGlm IGFuIGV4YW1wbGUgaXMgd3JvbmcuDQoNCj4gVGhlIGFib3ZlIEpTT04gUG9pbnRlciwgImFiXFxj ZC9lZlwvZ2giLCBoYXMgdG8gYmUgZXNjYXBlZCBhZ2FpbiB3aGVuIHdyaXR0ZW4gYXMgYSBKU09O IHN0cmluZzogImFiXFxcXGNkL2VmXFxcL2doIi4NCg0KVGhpcyBpcyBoYWxmIHdyb25nLiBJdCBp cyBhY3R1YWxseSB2YWxpZCwgYnV0IEpTT04tZXNjYXBpbmcgb25seSAxIG9mIHRoZSAyIGZvcndh cmQgc2xhc2hlcyBpcyBzaWxseSwgaGVuY2UgY29uZnVzaW5nLg0KDQo+IHRoZSBKU09OIFBvaW50 ZXIgImFiXFxjZC9lZlwvZ2giIGJlY29tZXMgImFiJTVDY2QvZWYlMkZnaCIgYXMgYSBmcmFnbWVu dCBpZGVudGlmaWVyLg0KDQpUaGlzIGlzIHdyb25nLiBJdCBiYWRseSBtaXhlcyBsYXllcnMuDQoN Ci0tDQpKYW1lcyBNYW5nZXINCg== From stpeter@stpeter.im Wed Jan 4 10:25:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5C221F877A for ; Wed, 4 Jan 2012 10:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VWt7Fv-HyCy for ; Wed, 4 Jan 2012 10:25:04 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 19E5421F8773 for ; Wed, 4 Jan 2012 10:25:04 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C66654009B; Wed, 4 Jan 2012 11:33:42 -0700 (MST) Message-ID: <4F04997E.7090008@stpeter.im> Date: Wed, 04 Jan 2012 11:25:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120103145134.099ad970@resistor.net> <6.2.5.6.2.20120103161311.08dfa958@resistor.net> <6.2.5.6.2.20120104001935.0a997af8@resistor.net> In-Reply-To: <6.2.5.6.2.20120104001935.0a997af8@resistor.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:25:04 -0000 On 1/4/12 3:28 AM, SM wrote: > Hi Murray, > At 19:33 03-01-2012, Murray S. Kucherawy wrote: >> Yes, that's one option. But why wait? 4408bis is not likely to >> change the name of "fail" as it would seriously impact backward >> compatibility, something its charter says they will be avoiding. > > It's a question of prioritizing work. If I were to object on the Last > Call (and you know that I won't), I would adapt some arguments from > draft-arkko-iesg-crossarea-00. For example: > > "The essence of most work is getting the right expertise to the room > and to the list. This does not happen through mere organizational > forms, people have to be interested about the problem." > > "expertise is brought through the right people actually reading the > specifications." > > "The best examples of successful work involve combining pieces of > expertise, with the parties having an incentive to complete the work." > > Obviously, none of the above is an adequate basis to prevent > publication. It would be easier for me to say that this draft should be > published quickly as it is a minor fix that doesn't require too much > effort. The decision rests with the Sponsoring AD anyway and whatever I > say won't have any effect on it. And by demonstrating support, I end up > looking good. I've agreed to sponsor this document. It's a simple bug fix, and bug fixes are good. Yes, it will require cycles from various people (IESG, IANA, RFC Editor), but I hope not too many. Peter -- Peter Saint-Andre http://stpeter.im/ From sm@elandsys.com Wed Jan 4 12:59:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BA111E80B5 for ; Wed, 4 Jan 2012 12:59:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYAiGaaP0snN for ; Wed, 4 Jan 2012 12:59:09 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA811E809F for ; Wed, 4 Jan 2012 12:59:08 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q04Kwrc7008223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jan 2012 12:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325710745; i=@elandsys.com; bh=4qpgPNCYRDdawB8PAnCOWrKKRCT+HzmhrHm7DosFl3g=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=G1ww4N5zDUoLv3mn0Amaq/E1CA5nCKepV/sAb7hk9/LvZ5A7KZkFnVSti0Ez1Pgrb OX9Ao356Qz8kf8BqigFOQv7VfG9Rk8VYCSO68iSZ+BjgaiO7/NqxPIQp82rfcDTP9I iUXImBQeMhfNz+3T4Sj4XxBaLcCC80QHrf35JRIE= Message-Id: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jan 2012 12:18:06 -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] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:59:12 -0000 Hello, I would appreciate some feedback on draft-moonesamy-rfc2369bis-01 [1] and draft-moonesamy-rfc2919bis-01 [2]. The I-Ds are about the List- header fields. The changes from RFC 2369 are: o URL changed to URI o Replaced MTAs with mailing list managers in the sentence: "MTAs generating the header fields SHOULD". o Replaced MTAs with mailing list managers in the sentence: "MTAs MUST NOT insert whitespace within the brackets" in Section 2 o In Section 2, client application SHOULD ignore whitespace within brackets o Updated references o Added informative reference to RFC 5064 o Editorial changes o Removed Background Discussion The changes from RFC 2919 are: o Removed text about the domain name system and domain ownership in Section 2 o "localhost" replaced with "invalid" o Replaced MTAs with mailing list managers in the sentence: "MTAs MUST NOT insert whitespace within the brackets" in Section 3 o Case independence in Section 6 changed to case insensitivity for ASCII o Added a paragraph in the appendix about subject tags o Updated references o Editorial changes Regards, S. Moonesamy [1] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2369bis-01.txt [2] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2919bis-01.txt From duerst@it.aoyama.ac.jp Wed Jan 4 17:43:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7810721F8545 for ; Wed, 4 Jan 2012 17:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.71 X-Spam-Level: X-Spam-Status: No, score=-99.71 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Uxcj73OcT0 for ; Wed, 4 Jan 2012 17:43:28 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBF21F853E for ; Wed, 4 Jan 2012 17:43:27 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q051h56P018143 for ; Thu, 5 Jan 2012 10:43:09 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 67ea_1144_9c9a71f4_373e_11e1_8a77_001d096c5782; Thu, 05 Jan 2012 10:43:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44940) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Jan 2012 10:43:09 +0900 Message-ID: <4F050020.2000104@it.aoyama.ac.jp> Date: Thu, 05 Jan 2012 10:42:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <4F044AEE.2080205@gmx.de> In-Reply-To: <4F044AEE.2080205@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:43:28 -0000 On 2012/01/04 21:49, Julian Reschke wrote: > Hi Paul, > > below some feedback: > > Section 3: > >> ABNF syntax: >> >> json-pointer = *( "/" reference-token ) >> reference-token = *( unescaped / escaped ) >> unescaped = %x00-2E / %x30-5B / %x5D-10FFFF > > Is 0 really allowed? (I see JSON allows this as well; maybe that's > something that needs to be discussed in the security considerations). So a JSON pointer like /// would mean there are four empty reference tokens. And that would actually work (pointing to 127) for a document like this: { "": { "": { "": { "": 127 } } } } >> escaped = "\" ( "/" / "\" ) >> >> It is an error condition if a JSON Pointer value does not conform to >> this syntax. > > I'm fine with this because it allows using \ to escape more values in > the future. Anything needed to make this "more values in the future" work? > Section 4: > >> If the currently referenced value is a JSON array, the reference >> token MUST contain an unsigned base-10 integer value, and the new >> referenced value is the array element with the zero-based index >> identified by the token. > > Do we want to say something about leading zeroes in index values? I > assume they are allowed? If they are, probably better to point out that it still means decimal. Some scripting languages might take leading zeroes to mean octal if an implementer isn't careful. > Appendix A: > > The semantics of fragment identifiers depends on the media type. You > need to be clear whether you're trying to define the fragid semantics > for application/json (which as far as I recall doesn't define any), or > something else. Yes. I'd propose that you just say you do, and then add a line at the top saying that your RFC-to-be will update the JSON definition. You'll also have to note that in an IANA section. > That being said: > >> http://example.com/example.json# >> Resolves to the object value at the root of the JSON text >> document. > > The same would be true for > > http://example.com/example.json#/ > > right? If an empty reference token is allowed, then http://example.com/example.json# would point to the data identified by the first "" object key. And http://example.com/example.json#/ would be two empty reference tokens, so it would point to one level down. If we have a document of { "": { "": 127 } } then http://example.com/example.json# would point to { "": 127 } and http://example.com/example.json#/ would point to 127. The question then is what to use to denote the whole document/object. The absence of a fragment identifier (i.e. just http://example.com/example.json) might work just fine. On the other hand, if empty reference tokens are disallowed, http://example.com/example.json#/ is illegal and http://example.com/example.json# is illegal too, unless we add it to the grammar with a special meaning. > I think we should stay away from empty fragment identifiers if we > can. (There MAY be dragons here). At least, we have to define them in a consistent way. Regards, Martin. From evnikita2@gmail.com Wed Jan 4 23:00:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF041F0C43 for ; Wed, 4 Jan 2012 23:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzNvimSy-8oC for ; Wed, 4 Jan 2012 22:59:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFD51F0C38 for ; Wed, 4 Jan 2012 22:59:59 -0800 (PST) Received: by obcuz6 with SMTP id uz6so257654obc.31 for ; Wed, 04 Jan 2012 22:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=TPKvhJv2EwxHTOGOuQ6R2Sn8uYUGc8nxBOKJw/jTE5I=; b=O0wZbe3KA+dIL2FjKffTLMEU1b3IbbI1mwX2XpTm2pqA2wXKZzaIVIkt+fXPftTILn D2Q3WS3C4xqc7VFqumw7gBxTitMWF8P4mHvqa8X1xYcsQe+S5pOTkKerfkSSqZ08oErd GUBRMWeootNc8tNvTRLrhZolSAbAOC4NP1u0U= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr601258obw.10.1325746799194; Wed, 04 Jan 2012 22:59:59 -0800 (PST) Received: by 10.182.30.167 with HTTP; Wed, 4 Jan 2012 22:59:59 -0800 (PST) Date: Thu, 5 Jan 2012 08:59:59 +0200 Message-ID: From: Mykyta Yevstifeyev To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: [apps-discuss] draft-moonesamy-rfc2369bis-01 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 07:00:00 -0000 Hello, Here are some comments on 2369bis draft. Major/non-editorial issues: In Abstract and Introduction, you only mention those List- header fields that were specified in original RFC 2369 but not the introduced 'List-Sequence'. While you define 8 header fields, you provide ABNF for only one of them. Whereas the syntax is clear from Section 2, at least one header field ('List-Post') may contain a value different from the URI (I mean "NO"), so there is a need to define formal syntax here. I think it's a rather simple thing to do: List-Help = "List-Help:" [ CFWS ] Uri-List [ CFWS ] CRLF List-Subscribe = "List-Subscribe:" Uri-List [ CFWS ] CRLF List-Unsubscribe = "List-Unsubscribe:" [ CFWS ] Uri-List [ CFWS ] CRLF List-Post = "List-Post:" [ CFWS ] ( Uri-List / "NO" ) [ CFWS ] CRLF List-Owner = "List-Owner:" [ CFWS ] Uri-List [ CFWS ] CRLF List-Archive = "List-Archive:" [ CFWS ] Uri-List [ CFWS ] CRLF Uri-List = "<" URI ">" *("," [ FWS ] "<" URI ">") ; whereas is defined in RFC 3986 and and in RFC 5322 List-Sequence = "List-Sequence:" seq-id ; already defined I tried to follows those recommendation you set in Section 2; and of course this in no way is meant to be a perfect choice for definition. You could provide a wider description of 'List-Sequence' and how it is different from 'Message-ID'. Section 6: why you don't register the newly introduced 'List-Sequence' as required by RFC 3864 by only asking IANA to update the existing registrations? Editorial issues: In Abstract and Introduction, please distinguish the scheme name 'mailto', probably s/mailto/'mailto'/. Section 2: By this mechanism, protocols like http may be specified while still providing the basic mailto support for those clients who do not have access to non-mail protocols. Did you mean "URI scheme" under "protocol" here? These are not synonymous, as there may be different scheme names for one protocol ot one scheme may use different protocols. This should be corrected, I think. Ibid, para 5: "mailto" protocol -> "mailto" URI scheme. All the best, Mykyta Yevstifeyev From paul.bryan@forgerock.com Thu Jan 5 00:10:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70421F865C for ; Thu, 5 Jan 2012 00:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSeENFILNXS4 for ; Thu, 5 Jan 2012 00:10:54 -0800 (PST) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) by ietfa.amsl.com (Postfix) with SMTP id 4B29521F858D for ; Thu, 5 Jan 2012 00:10:52 -0800 (PST) Received: from mail-iy0-f181.google.com ([209.85.210.181]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKTwVa+9tX6vvWtYFPVw84JWNY1KODC/OS@postini.com; Thu, 05 Jan 2012 08:10:53 UTC Received: by mail-iy0-f181.google.com with SMTP id k12so607139iak.12 for ; Thu, 05 Jan 2012 00:10:35 -0800 (PST) Received: by 10.50.188.132 with SMTP id ga4mr2014525igc.4.1325751035310; Thu, 05 Jan 2012 00:10:35 -0800 (PST) Received: from [192.168.1.5] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id aq5sm122002724igc.5.2012.01.05.00.10.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 00:10:33 -0800 (PST) Message-ID: <1325751031.10587.1.camel@neutron> From: "Paul C. Bryan" To: IETF Apps Discuss Date: Thu, 05 Jan 2012 00:10:31 -0800 In-Reply-To: <4F044F93.9020307@gmx.de> References: <4ED64A26.5030003@gmx.de> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron> <4F044F93.9020307@gmx.de> Content-Type: multipart/alternative; boundary="=-GdTK2VZthCsOw8Kz1FN9" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:10:54 -0000 --=-GdTK2VZthCsOw8Kz1FN9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sorry, I'll be addin it in -01 tomorrow. Paul On Wed, 2012-01-04 at 14:09 +0100, Julian Reschke wrote: > On 2011-12-30 06:24, Paul C. Bryan wrote: > > ... > >> 2) The ability to *copy* (not *move*) objects around. > > > > This is another example of something trivial for the patch > > implementation to perform, so I'm inclined to add it to the next draft. > > ... > > ...but you did not :-). Did you decide against it, or is this still on > your TODO list? > > Best regards, Julian --=-GdTK2VZthCsOw8Kz1FN9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Sorry, I'll be addin it in -01 tomorrow.

Paul

On Wed, 2012-01-04 at 14:09 +0100, Julian Reschke wrote: 
On 2011-12-30 06:24, Paul C. Bryan wrote:
> ...
>> 2) The ability to *copy* (not *move*) objects around.
>
> This is another example of something trivial for the patch
> implementation to perform, so I'm inclined to add it to the next draft.
> ...

...but you did not :-). Did you decide against it, or is this still on 
your TODO list?

Best regards, Julian

--=-GdTK2VZthCsOw8Kz1FN9-- From sm@elandsys.com Thu Jan 5 01:01:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776BA21F875B for ; Thu, 5 Jan 2012 01:01:19 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avJyLRiJv4jW for ; Thu, 5 Jan 2012 01:01:18 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3157421F876E for ; Thu, 5 Jan 2012 01:01:18 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.173]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0590wIK011792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 01:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325754071; i=@elandsys.com; bh=yQEpm6T0RyRS/Bsiat25/Zah6us2v0dGrTsu/Sy9sOw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=b62ych4od3L0VRbLMhvGRcaYQkl217x45nQD5sFUCdvCl72fCwiwQtSsqiSBXUrF6 jDaN1PsVj/1f+f4P9haSyx4UL4bVBBeTw1CYuiZ9cJD/lmDzCzOVlB2ypDVNmQwKU2 fI17s+fDGhbjoN58eR+ER+NRyg5sWOwq4szBp8hA= Message-Id: <6.2.5.6.2.20120104230355.0ab50340@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2012 00:28:17 -0800 To: Mykyta Yevstifeyev From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-moonesamy-rfc2369bis-01 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:01:19 -0000 Hi Mykyta, At 22:59 04-01-2012, Mykyta Yevstifeyev wrote: >Here are some comments on 2369bis draft. Thanks for the feedback. >Major/non-editorial issues: > >In Abstract and Introduction, you only mention those List- header >fields that were specified in original RFC 2369 but not the introduced >'List-Sequence'. I'll add that to the next revision. >While you define 8 header fields, you provide ABNF for only one of >them. Whereas the syntax is clear from Section 2, at least one header >field ('List-Post') may contain a value different from the URI (I mean >"NO"), so there is a need to define formal syntax here. I think it's >a rather simple thing to do: > >List-Help = "List-Help:" [ CFWS ] Uri-List [ CFWS ] CRLF >List-Subscribe = "List-Subscribe:" Uri-List [ CFWS ] CRLF >List-Unsubscribe = "List-Unsubscribe:" [ CFWS ] Uri-List [ CFWS ] CRLF >List-Post = "List-Post:" [ CFWS ] ( Uri-List / "NO" ) [ CFWS ] CRLF >List-Owner = "List-Owner:" [ CFWS ] Uri-List [ CFWS ] CRLF >List-Archive = "List-Archive:" [ CFWS ] Uri-List [ CFWS ] CRLF >Uri-List = "<" URI ">" *("," [ FWS ] "<" URI ">") > ; whereas is defined in RFC 3986 and and > in RFC 5322 >List-Sequence = "List-Sequence:" seq-id > ; already defined > >I tried to follows those recommendation you set in Section 2; and of >course this in no way is meant to be a perfect choice for definition. I understand that a lot of folks will want to see ABNF definitions for the header fields specified in RFC 2369. As I viewed it as a significant change, I preferred to be cautious by leaving it out. I'll wait for more feedback on this. >You could provide a wider description of 'List-Sequence' and how it is >different from 'Message-ID'. A Message-ID is not a Sequence Identifier. seq-id is sometimes used to denote the position of a message in an archive or it might be used as a (internal) message counter. A Message-ID cannot be used for that. >Section 6: why you don't register the newly introduced 'List-Sequence' >as required by RFC 3864 by only asking IANA to update the existing >registrations? That was a last minute change. >Editorial issues: > >In Abstract and Introduction, please distinguish the scheme name >'mailto', probably s/mailto/'mailto'/. Ok. >Section 2: > > By this mechanism, protocols like http may be > specified while still providing the basic mailto support for those > clients who do not have access to non-mail protocols. > >Did you mean "URI scheme" under "protocol" here? These are not >synonymous, as there may be different scheme names for one protocol ot >one scheme may use different protocols. This should be corrected, I >think. Good catch, it should have been scheme. >Ibid, para 5: "mailto" protocol -> "mailto" URI scheme. Ok. Regards, S. Moonesamy From julian.reschke@gmx.de Thu Jan 5 02:08:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA7621F86BD for ; Thu, 5 Jan 2012 02:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HQTha6XGH85 for ; Thu, 5 Jan 2012 02:08:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 05A8821F8661 for ; Thu, 5 Jan 2012 02:08:45 -0800 (PST) Received: (qmail invoked by alias); 05 Jan 2012 10:08:41 -0000 Received: from p5DCC2522.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.37.34] by mail.gmx.net (mp028) with SMTP; 05 Jan 2012 11:08:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+KtR1zXCmK+Syo2MKoseMrJ5eTNpI4FX61354ifm RTvNPaM1h+3VlC Message-ID: <4F0576A3.9030800@gmx.de> Date: Thu, 05 Jan 2012 11:08:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4F044AEE.2080205@gmx.de> <4F050020.2000104@it.aoyama.ac.jp> In-Reply-To: <4F050020.2000104@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:08:47 -0000 On 2012-01-05 02:42, "Martin J. Dürst" wrote: > ... >> Appendix A: >> >> The semantics of fragment identifiers depends on the media type. You >> need to be clear whether you're trying to define the fragid semantics >> for application/json (which as far as I recall doesn't define any), or >> something else. > > Yes. I'd propose that you just say you do, and then add a line at the > top saying that your RFC-to-be will update the JSON definition. You'll > also have to note that in an IANA section. > ... I have to say that I'm getting nervous about this. 1) When this WG adopted this as a work item, was it clear that JSON pointer isn't "a pointer syntax" but "*the* pointer syntax"? 2) Also, declaring this the one and only fragment identifier syntax for application/json means that we're closing the door for any future syntax that offers more expressiveness. In XML, people tried to handle this problem with a whole framework (XPointer), which doesn't seem to work too well. Maybe in this case the solution would be to reserve more delimiter characters that we'll likely need in the future (such as "[", "]", "(", ")", double quotes, single quotes etc). Best regards, Julian From duerst@it.aoyama.ac.jp Thu Jan 5 02:19:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B01021F8757 for ; Thu, 5 Jan 2012 02:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.726 X-Spam-Level: X-Spam-Status: No, score=-99.726 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yc0nzkRZAgH for ; Thu, 5 Jan 2012 02:19:45 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3E821F8751 for ; Thu, 5 Jan 2012 02:19:44 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q05AJXdf009154 for ; Thu, 5 Jan 2012 19:19:33 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 67f0_8ff5_c3248268_3786_11e1_8a77_001d096c5782; Thu, 05 Jan 2012 19:19:33 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37353) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Jan 2012 19:19:37 +0900 Message-ID: <4F05792C.3080201@it.aoyama.ac.jp> Date: Thu, 05 Jan 2012 19:19:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <5690A6A7-15B9-4F5A-AE85-FCE50894BA88@team.telstra.com> In-Reply-To: <5690A6A7-15B9-4F5A-AE85-FCE50894BA88@team.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:19:46 -0000 On 2012/01/04 22:34, Manger, James H wrote: >> As far as I understand, this will lead to quadruple escaping. That's fine with me, > > Quadruple escaping is fine!! Great!!!! >> If I got it wrong, please correct. > > Why not pick an escaping mechanism where it isn't so hard to tell if an example is wrong. XPointer uses ^ somewhere, as far as I remember. That would give us things such as "ab^^cd/ef^/gh", and the JSON string would simply be the same "ab^^cd/ef^/gh". And the URI fragment id would be "ab%5E%5Ecd/ef%5E/gh". >> The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when written as a JSON string: "ab\\\\cd/ef\\\/gh". > > This is half wrong. It is actually valid, but JSON-escaping only 1 of the 2 forward slashes is silly, hence confusing. Ah, okay. So "ab\\\\cd/ef\\/gh" or "ab\\\\cd\/ef\\\/gh" would be consistent. And "ab\\\\cd\/ef\\/gh" would be another silly variant, yes? >> the JSON Pointer "ab\\cd/ef\/gh" becomes "ab%5Ccd/ef%2Fgh" as a fragment identifier. > > This is wrong. It badly mixes layers. Yes indeed. After I sent my mail, I was thinking about this a bit more, and the more I thought about it, the less I liked it. The layers should be: tokens -> pointer -> fragment That means that the JSON Pointer "ab\\cd/ef\/gh" has to become "ab%5C%5Ccd/ef%5C/gh" as a fragment identifier. But the more I think about it, the more I like the idea to use a third character (not \ and not %) for escaping in the JSON Pointer syntax (as long as it won't be a character that's difficult to print or type). Regards, Martin. From paul.bryan@forgerock.com Thu Jan 5 07:29:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2721F873E for ; Thu, 5 Jan 2012 07:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6P+7X-cfy9v for ; Thu, 5 Jan 2012 07:29:45 -0800 (PST) Received: from eu1sys200aog111.obsmtp.com (eu1sys200aog111.obsmtp.com [207.126.144.131]) by ietfa.amsl.com (Postfix) with SMTP id D9A7C21F8734 for ; Thu, 5 Jan 2012 07:29:44 -0800 (PST) Received: from mail-iy0-f173.google.com ([209.85.210.173]) (using TLSv1) by eu1sys200aob111.postini.com ([207.126.147.11]) with SMTP ID DSNKTwXB2MAnZFV/HP1ieXI2dsuRCMQS5U0Q@postini.com; Thu, 05 Jan 2012 15:29:45 UTC Received: by mail-iy0-f173.google.com with SMTP id j37so1232291iag.32 for ; Thu, 05 Jan 2012 07:29:28 -0800 (PST) Received: by 10.50.77.227 with SMTP id v3mr3071311igw.8.1325777368249; Thu, 05 Jan 2012 07:29:28 -0800 (PST) Received: from [192.168.1.5] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id gh7sm99878768igb.1.2012.01.05.07.29.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 07:29:27 -0800 (PST) Message-ID: <1325777365.10587.15.camel@neutron> From: "Paul C. Bryan" To: "apps-discuss@ietf.org" Date: Thu, 05 Jan 2012 07:29:25 -0800 In-Reply-To: <4F05792C.3080201@it.aoyama.ac.jp> References: <5690A6A7-15B9-4F5A-AE85-FCE50894BA88@team.telstra.com> <4F05792C.3080201@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="=-Ke2J6uZGyr0fJQIkqGnA" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:29:46 -0000 --=-Ke2J6uZGyr0fJQIkqGnA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 2012-01-05 at 19:19 +0900, "Martin J. Dürst" wrote: > On 2012/01/04 22:34, Manger, James H wrote: > >> As far as I understand, this will lead to quadruple escaping. That's fine with me, > > > > Quadruple escaping is fine!! > > Great!!!! I'm now imagining an RFC coming this April entitled, Compact ASCII Notation for Denoting Your Sarcasm (CANDYS), and the use of explanation marks play a key role!!!! > >> If I got it wrong, please correct. > > > > Why not pick an escaping mechanism where it isn't so hard to tell if an example is wrong. > > XPointer uses ^ somewhere, as far as I remember. > > That would give us things such as "ab^^cd/ef^/gh", and the JSON string > would simply be the same "ab^^cd/ef^/gh". And the URI fragment id would > be "ab%5E%5Ecd/ef%5E/gh". I'm not attached to a particular escape character; I'm resigned to the fact it's just a necessary evil. At least there's precedent for using carat in a parallel specification. > >> The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when written as a JSON string: "ab\\\\cd/ef\\\/gh". > > > > This is half wrong. It is actually valid, but JSON-escaping only 1 of the 2 forward slashes is silly, hence confusing. > > Ah, okay. So "ab\\\\cd/ef\\/gh" or "ab\\\\cd\/ef\\\/gh" would be > consistent. And "ab\\\\cd\/ef\\/gh" would be another silly variant, yes? > > >> the JSON Pointer "ab\\cd/ef\/gh" becomes "ab%5Ccd/ef%2Fgh" as a fragment identifier. > > > > This is wrong. It badly mixes layers. > > Yes indeed. After I sent my mail, I was thinking about this a bit more, > and the more I thought about it, the less I liked it. The layers should be: > > tokens -> pointer -> fragment > > That means that the JSON Pointer "ab\\cd/ef\/gh" has to become > "ab%5C%5Ccd/ef%5C/gh" as a fragment identifier. > > But the more I think about it, the more I like the idea to use a third > character (not \ and not %) for escaping in the JSON Pointer syntax (as > long as it won't be a character that's difficult to print or type). I agree. Paul --=-Ke2J6uZGyr0fJQIkqGnA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-01-05 at 19:19 +0900, "Martin J. Dürst" wrote: 
On 2012/01/04 22:34, Manger, James H wrote:
>> As far as I understand, this will lead to quadruple escaping. That's fine with me,
>
> Quadruple escaping is fine!!

Great!!!!

I'm now imagining an RFC coming this April entitled, Compact ASCII Notation for Denoting Your Sarcasm (CANDYS), and the use of explanation marks play a key role!!!! 


>> If I got it wrong, please correct.
>
> Why not pick an escaping mechanism where it isn't so hard to tell if an example is wrong.

XPointer uses ^ somewhere, as far as I remember.

That would give us things such as "ab^^cd/ef^/gh", and the JSON string 
would simply be the same "ab^^cd/ef^/gh". And the URI fragment id would 
be "ab%5E%5Ecd/ef%5E/gh".

I'm not attached to a particular escape character; I'm resigned to the fact it's just a necessary evil. At least there's precedent for using carat in a parallel specification. 

>> The above JSON Pointer, "ab\\cd/ef\/gh", has to be escaped again when written as a JSON string: "ab\\\\cd/ef\\\/gh".
>
> This is half wrong. It is actually valid, but JSON-escaping only 1 of the 2 forward slashes is silly, hence confusing.

Ah, okay. So "ab\\\\cd/ef\\/gh" or "ab\\\\cd\/ef\\\/gh" would be 
consistent. And "ab\\\\cd\/ef\\/gh" would be another silly variant, yes?

>> the JSON Pointer "ab\\cd/ef\/gh" becomes "ab%5Ccd/ef%2Fgh" as a fragment identifier.
>
> This is wrong. It badly mixes layers.

Yes indeed. After I sent my mail, I was thinking about this a bit more, 
and the more I thought about it, the less I liked it. The layers should be:

tokens -> pointer -> fragment

That means that the JSON Pointer "ab\\cd/ef\/gh" has to become
"ab%5C%5Ccd/ef%5C/gh" as a fragment identifier.

But the more I think about it, the more I like the idea to use a third 
character (not \ and not %) for escaping in the JSON Pointer syntax (as 
long as it won't be a character that's difficult to print or type).

I agree.

Paul --=-Ke2J6uZGyr0fJQIkqGnA-- From alexey.melnikov@isode.com Thu Jan 5 08:48:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A219A21F875F for ; Thu, 5 Jan 2012 08:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.87 X-Spam-Level: X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asbsQM3Q5un4 for ; Thu, 5 Jan 2012 08:48:08 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E7D2221F8679 for ; Thu, 5 Jan 2012 08:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1325782086; d=isode.com; s=selector; i=@isode.com; bh=Kw9fVr69GIAIpA1uG5I7LM5c8ECAobP0WaY2p05NoCE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MQpOIViGRZVeztx3hvGXETkMse+YWHueAyVrbgJiIw+6CqxwQ4CrKuQtAyPaxlCeq6LFNd nLYAXfOHvbbggD+KVLjme8ozzfaquUTmC6B4fdIZFDncZaMIadNLb1TpAIyI2wKB88c0lh qMG1jw61dbRImEku5s4Qvwc6hnusbVU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 5 Jan 2012 16:48:06 +0000 Message-ID: <4F04CA59.9020600@isode.com> Date: Wed, 04 Jan 2012 21:53:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Mykyta Yevstifeyev References: <20120103235905.13595.45789.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:48:08 -0000 On 04/01/2012 07:22, Mykyta Yevstifeyev wrote: > Hello, Hi Mykyta, > I wonder why these two docs (JSON Patch and JSON Pointer) both have > the Intended status 'Standards Track' whereas RFC 4627, that specifies > JSON and is the core specification is Informational. Or do we want > 'standardize' JSON - than we could produce 4627bis as PS, and include > these proposals in such a document. I don't think there is any effort to republish JSON on Standards Track, as it was standardized outside of IETF. However JSON is an allowed DownRef and is already marked as such in the registry of allowed DownRefs maintained by IESG. From msk@cloudmark.com Thu Jan 5 16:10:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25D11E807A for ; Thu, 5 Jan 2012 16:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPjt0vHKrOz8 for ; Thu, 5 Jan 2012 16:10:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75711E8083 for ; Thu, 5 Jan 2012 16:10:55 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 16:10:48 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 5 Jan 2012 16:10:54 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 5 Jan 2012 16:10:53 -0800 Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 Thread-Index: AczLI7r9X3B/btEuQF28o2tl3JS9jAA30WFQ Message-ID: References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.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 Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:10:56 -0000 Hi SM, First, I suggest this be sent to the "ietf-822" list as well as the lists o= f MLM package developers, such as Mailman. I'm on both already and can for= ward it if you like. A few cursory review points based on a diff of the old ones to the new ones= (and apologies for jumping back and forth between documents as I go here): 0) What's the rationale for doing this work now? 1) Have the original authors of these documents been contacted to see if th= ey want to participate in the update? Has their permission been secured to= republish substantial chunks of their original text? The IPR statement in= your draft should reflect this either way. 2) It seems to me both of these would be helped (in the "can't hurt" sense)= by an informative reference to RFC5598 just so there's a handy illustratio= n of how all these components fit together. 3) The deletion of Appendix A from RFC2369 is conspicuous. Why remove all = of that supporting discussion? I suppose since this stuff has been out the= re for a while now it'd be sufficient to mention in later sections that suc= h discussion exists in the original document. 4) The language at the top of 3.1 sounds vaguely like a minimum compliance = statement. I suggest it be reworked to something simpler, like striking ev= erything from "is the most" up to and including "by definition it". 5) Adding ABNF for each of the header fields would be good. Right now the= re's only ABNF for List-Sequence. 6) The various URI constructions might benefit from being enabled by what's= specified in draft-gregorio-uritemplate (now in IESG Evaluation, so it mig= ht be an RFC soonish), which would allow the defined header fields to conta= in values expanded by the MUA, something like: List-Help: ...and then just define that when expanding such templates, "user" is the e= mail address the MUA is using. 7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no need" sen= tence seems odd. If the MUA is supposed to use "postmaster" to contact the= owner in the case of a list that doesn't add this, what domain name should= it use? 8) There's normative language in the Client Implementation appendix, carrie= d over from the previous version. I think this should be softened, or it s= hould become a non-appendix normative section on its own. You might, howev= er, get some resistance from people about putting normative guidance to MUA= s in a document since it's often said that the IETF the-opposite-of-expert = at user interface concerns. 9) There's a mix of SHOULD and should in here. Since you're citing 2119 th= ey all mean the same thing, but the mixed case will leave some people wonde= ring. I suggest using SHOULD everywhere that you mean it, and alternatives= elsewhere ("might", "are advised to", etc.). 10) List-ID uses the domain name space, even if the domains don't actually = exist. Do we need to talk about IDNA at all here? 11) Kudos for moving a SHOULD out of the Introduction in RFC2369bis. 12) There's a place in Security Considerations where it makes a normative a= ssertion that user-generated List-* fields need to be deleted by the MLM. = I think that should be in a normative part of the document rather than Secu= rity Considerations. Rather, Security Considerations might talk about the = risks created if an MLM doesn't comply. 13) The change from "localhost" (which might actually resolve, if that matt= ers) to "invalid" makes sense, but I'm somehow worried about backward-compa= tibility issues. 14) Section 6 in RFC2919bis seems needlessly verbose about case-insensitive= string comparison. Simply using that term is quite sufficient. 15) Appendix A.1 in RFC2919bis seems way off topic. I suggest striking it,= or adding text to explain why it's not off topic. 16) There's stuff in RFC2369bis Appendix A that recommends MUA application = of these fields which uses normative language. This should probably also b= e adjusted, or it should become a normative section rather than appendix. I think that's enough for now. I'll have more as the work evolves. -MSK From sm@elandsys.com Thu Jan 5 21:56:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2902F11E8089 for ; Thu, 5 Jan 2012 21:56:00 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4YAmoxJQTYs for ; Thu, 5 Jan 2012 21:55:59 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E43E921F87E4 for ; Thu, 5 Jan 2012 21:55:57 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.156]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q065tdEU018982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2012 21:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325829353; i=@elandsys.com; bh=PDV61teUlBJefNjnFCrEfiFP3Ge4AfegEadiRYPzg60=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=aDX5sHSW6VBT9EtuTEDjgorQmUSGR0fYSb5bHH5Av74ThtEIxLmwWGH1NocsdiHvB hUcBDWk/+stWnhYhF81yMdilYzrGthVm3N8IhH543kh2iATFU0ybSLrskIVTbfbee9 Ws8Xb2gwdjEB3lz8+IjMNDSN6SY/ucwB8CmhNweU= Message-Id: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2012 21:38:12 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 05:56:00 -0000 Hi Murray, At 16:10 05-01-2012, Murray S. Kucherawy wrote: >First, I suggest this be sent to the "ietf-822" list as well as the >lists of MLM package developers, such as Mailman. I'm on both >already and can forward it if you like. Thanks for the feedback. Can you forward it to those lists? I asked for feedback from a mailman developer and other MLM implementors. >A few cursory review points based on a diff of the old ones to the >new ones (and apologies for jumping back and forth between documents >as I go here): > >0) What's the rationale for doing this work now? RFC 2369 was published over ten years ago. The major change since then is the use of URI schemes. I was reusing some old code and had to figure out which up-to-date RFCs to use. I added the odds and ends I found to the drafts. >1) Have the original authors of these documents been contacted to >see if they want to I emailed to the original authors. If anyone has an up to date contact for them, please email me. BTW, I am listed as an editor and not the author. There is a "most of the text in this document" sentence in the Acknowledgement section. >participate in the update? Has their permission been secured to >republish substantial chunks of their original text? The IPR >statement in your draft should reflect this either way. The "Status of this Memo" Section mentions that: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79." I don't think there is any issue about that. >2) It seems to me both of these would be helped (in the "can't hurt" >sense) by an informative reference to RFC5598 just so there's a >handy illustration of how all these components fit together. I kept the References section lightweight by only adding what is necessary for someone to understand what is in the document and to implement it. I prefer not to add more informative references. >3) The deletion of Appendix A from RFC2369 is conspicuous. Why >remove all of that supporting discussion? I suppose since this >stuff has been out there for a while now it'd be sufficient to >mention in later sections that such discussion exists in the original document. There is an informative reference to RFC 2369 in the draft. As such, people who are interested in why RFC 2369 was written in such a way will find the supporting discussion. I am going to leave this comment open (whether it is worth explicitly pointing out). >4) The language at the top of 3.1 sounds vaguely like a minimum >compliance statement. I suggest it be reworked to something >simpler, like striking everything from "is the most" up to and >including "by definition it". The language is similar to what was in RFC 2369. I'll change it to the following: The List-Help header field can direct the user to complete instructions for all other commands. Typically, the URI specified would request the help file, perhaps incorporating an HTML form for list commands, for the list, and alternatively provide access to an instructive website. BTW, most subscribers find web forms more accessible then interacting with a MLM by email. >5) Adding ABNF for each of the header fields would be good. Right >now there's only ABNF for List-Sequence. Ok. >6) The various URI constructions might benefit from being enabled by >what's specified in draft-gregorio-uritemplate (now in IESG >Evaluation, so it might be an RFC soonish), which would allow the >defined header fields to contain values expanded by the MUA, something like: > > List-Help: > >...and then just define that when expanding such templates, "user" >is the email address the MUA is using. There is a discussion about variable substitution in Appendix A.5 of RFC 2369. It explains why that was not added. I'll leave this comment open. >7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no >need" sentence seems odd. If the MUA is supposed to use >"postmaster" to contact the owner in the case of a list that doesn't >add this, what domain name should it use? The List-Owner may not necessarily be the postmaster. For example, in a hosted environment, the administrative role may be delegated to the person running the mailing list as it is easier to have them answer questions about how to unsubscribe or to act as a first point of contact for mailing list issues. Using this mailing list as an example, there isn't a List-Owner header field. Some of the subscribers know that they can contact ietf-action if there is a problem. As the email has ietf.org in the return-path, the contact address would be postmaster@ietf.org. "There is no need" could be read as "we know that the postmaster is the human contact if there is a mail problem". If you look at this from a different angle, the users contact their postmaster and the latter figures out how to reach a human contact at the other end. >8) There's normative language in the Client Implementation appendix, >carried over from the previous version. I think this should be >softened, or it should become a non-appendix normative section on >its own. You might, however, get some resistance from people about >putting normative guidance to MUAs in a document since it's often >said that the IETF the-opposite-of-expert at user interface concerns. Did you mean normative language in Appendix B? It is often said that the IETF does not have the expertise to make UI recommendations. I usually read that as a code word. :-) FWIW, as the appendix is about guidelines, it should be read as informative. >9) There's a mix of SHOULD and should in here. Since you're citing >2119 they all mean the same thing, but the mixed case will leave >some people wondering. I suggest using SHOULD everywhere that you >mean it, and alternatives elsewhere ("might", "are advised to", etc.). Ah, I see, you mean the lowercase "should"? I'll replace the should with non-normative words. >10) List-ID uses the domain name space, even if the domains don't >actually exist. Do we need to talk about IDNA at all here? If I had to describe 2919bis in a few words, I would use "in most cases, appear like a host name in a domain of the list owner" (Section 2). List-ID is borrows the syntax from an established namespace to get some form of uniqueness. I would have to ask the EAI WG if I introduce IDNA in 2919bis as they have been doing some work in this area. It is possible to internationalize 2369bis and 2919bis but that won't address the issues as they occur at 5335bis and 5336bis "layers". I restate your question as "can we get away with not talking about IDNA" and I think that the answer is yes. FWIW, it would not be that much of an additional effort to use IDNA without discussing about the issues. >11) Kudos for moving a SHOULD out of the Introduction in RFC2369bis. Thanks. >12) There's a place in Security Considerations where it makes a >normative assertion that user-generated List-* fields need to be >deleted by the MLM. I think that should be in a normative part of >the document rather than Security Considerations. Rather, Security >Considerations might talk about the risks created if an MLM doesn't comply. That would be: "Mailing list managers should not allow any user-originated list header fields to pass through to the mailing lists, lest they confuse the user and have the potential to create security problems." It looks more like a security consideration. In Section 3, there is: "There MUST be no more than one of each header field present in any given message." and: "These header fields MUST only be generated by mailing list managers, not by MUAs." I have not tested whether existing implementations bounce user generated messages which contain List- headers. >13) The change from "localhost" (which might actually resolve, if >that matters) to "invalid" makes sense, but I'm somehow worried >about backward-compatibility issues. Me too. I haven't seen a case where "localhost" is used. I assume that the fallback is "localhost.localdomain" in environments where a valid domain name is not available. That's incorrect though. One of the arguments in RFC 2919 was "users unable to afford domain name registration fees". That is less of a barrier nowadays. BTW, we could sneak in a new TLD by using 2919bis to reserve it (draft-cheshire-dnsext-special-names-02). :-) >14) Section 6 in RFC2919bis seems needlessly verbose about >case-insensitive string comparison. Simply using that term is quite >sufficient. I can drop that. RFC 2919 uses "CASE INDEPENDENCE" from RFC 822. That text is not in RFC 5322. I used some (verbose) text as there isn't any such text in the mail-related RFCs. Let's wait for more feedback about this. >15) Appendix A.1 in RFC2919bis seems way off topic. I suggest >striking it, or adding text to explain why it's not off topic. Subject tags are commonly used as list identifiers (this mailing list uses them). Appendix A.1 explains the difference between a List Identifier and a subject tag in terms of uniqueness. If I have to provide an explanation, I would have to get into mail filtering, e.g. why use List-ID instead of subject tags to move messages from this mailing list into a separate mailbox. >16) There's stuff in RFC2369bis Appendix A that recommends MUA >application of these fields which uses normative language. This >should probably also be adjusted, or it should become a normative >section rather than appendix. Ok but please see my response to point 8. Regards, S. Moonesamy From vesely@tana.it Fri Jan 6 04:55:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C01C21F88C8 for ; Fri, 6 Jan 2012 04:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=1.307, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA8jRfScaUxd for ; Fri, 6 Jan 2012 04:55:10 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C0CF221F88D0 for ; Fri, 6 Jan 2012 04:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325854508; bh=YTkPbEo0VuZBsEvvHXwqXToSErkwJEN9uOBhMGp41OY=; l=1602; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=UZKy35PI4U4BkQzQ4irqUVDfIULdpHKaRjhifDqFZAwWRW2rPQ+ybB1CKM8Az9vMX 0q8NlIevccdfaF07/ggZp0jZNXxacd8V0AztmwsPrf6fxCzWQ8MHn4EUGNNky8WUdK n669LKzcjoFbQBDM0yKa4oFGjgp4wkDpJBoQfoOU= Received: from [109.113.224.229] (softdnserr [109.113.224.229]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 06 Jan 2012 13:55:03 +0100 id 00000000005DC039.000000004F06EF28.0000551B Message-ID: <4F06EEFD.1060707@tana.it> Date: Fri, 06 Jan 2012 13:54:21 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:55:17 -0000 Hi SM, hope you don't mind my taking this occasion to ask some questions. On 04.01.2012 21:18, S Moonesamy wrote: > > I would appreciate some feedback on draft-moonesamy-rfc2369bis-01 (I'd only s/e-mail/email/ in Section 3.8, per http://www.rfc-editor.org/rfc-style-guide/terms-online.txt) > The changes from RFC 2919 are: > [...] > > o Added a paragraph in the appendix about subject tags Nice addition. Would it make sense to promote that from appendix to a new "Definitions" section? (I don't dare suggesting that it should match the list-label...) Defining what is a /list/ that a List-Id identifies would be another candidate addition. And also what is a /nested list/, maybe. The point is that it is not clear whether this header field should be used also for commercial newsletters and similar stuff. I'm not aware of the deployment of "list-id" as suggested in the paragraph of Section 5: It is suggested, but not required, that List Identifiers be created under a subdomain of "list-id" within any given domain. This can help to reduce internal conflicts between the administrators of the subdomains of large organizations. For example, List Identifiers at "example.com" are generated in the subdomain of "list- id.example.com". Is it actually used or is it merely an example? Instead, I found no normative statement that matches the authority on a given domain that is mentioned in Section 2. Should there be a SOA under list-id-namespace? I wonder whether there is a claim of responsibility implied in adding List-Id to a bulk message. From msk@cloudmark.com Fri Jan 6 13:28:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EAC21F87AD for ; Fri, 6 Jan 2012 13:28:30 -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.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KMpSRmeAxnG for ; Fri, 6 Jan 2012 13:28:29 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C8CF021F873C for ; Fri, 6 Jan 2012 13:28:29 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 6 Jan 2012 13:28:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 6 Jan 2012 13:28:29 -0800 From: "Murray S. Kucherawy" To: Goix Laurent Walter , "Tschofenig, Hannes (NSN - FI/Espoo)" , "apps-discuss@ietf.org" Date: Fri, 6 Jan 2012 13:28:28 -0800 Thread-Topic: [apps-discuss] FW: Liason statement from OMA CD WG to IETF-Mobile Social Networking Thread-Index: Acy8iZk7F0JaJG4gTVmVDtFClyoZuwAOmlSgAB6d/1AACvv0AAAzCWdgA6DgqGA= Message-ID: References: <34966E97BE8AD64EAE9D3D6E4DEE36F2D32985@szxeml525-mbs.china.huawei.com><6.2.5.6.2.20111216223107.09c637c8@resistor.net><999913AB42CC9341B05A99BBF358718DE38025@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DE3806A@FIESEXC035.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] FW: Liason statement from OMA CD WG to IETF-Mobile Social Networking X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:28:30 -0000 It's been a few weeks since this thread died. Does APPSAWG have any respon= se they'd like me to send back to OMA? -MSK From sm@elandsys.com Fri Jan 6 13:48:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667881F0C36 for ; Fri, 6 Jan 2012 13:48:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80fD7qTf38AX for ; Fri, 6 Jan 2012 13:48:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3E21F842D for ; Fri, 6 Jan 2012 13:48:51 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.119]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q06LmZDA017053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 13:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325886528; i=@elandsys.com; bh=KssF7waIyB5Hzb6RyoVTQP3Y5QmXMUvc62SF0soUd/Y=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jlAyNDdK4+pv7UK1098eD45CsQLwS8D0Ih1Y5pfjTMIWzrjOurgfLu/dApqIf0oPy NXpB4mHFigO7STrhO28XZhQ9w4SQN1CP8m77kkbDq9rkK3JOofo+Bldop1VrYUJK18 xxZiJXsDt+QQR/r9bBRDJ6hz9HMH6wq6E9x2W3yw= Message-Id: <6.2.5.6.2.20120106125010.0a439be8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2012 13:41:24 -0800 To: John Levine From: S Moonesamy In-Reply-To: <20120106063934.80082.qmail@joyce.lan> References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:48:52 -0000 Hi John, Thanks for the feedback. BTW, your message was copied to appsdir ( http://www.ietf.org/mail-archive/web/appsdir/current/msg00687.html ). At 22:39 05-01-2012, John Levine wrote: >Hi. I guess I'm a defacto mj2 implementer. It's very useful to get input from implementers. >Josh Baer is easy enough to find, once you know he's the one in Austin, >not the art critic. Could you send me his email address off-list? >General comments on 2369bis: > >It's basically fine, but I have a few suggestions. As an editorial >matter, the constant harping to use mailto: everywhere gets old. I'd >suggest saying it up front and noting that mail users aren't >necessarily able to use any other kind of URI, then drop it. The >other 99.9% of mail users, of course, find a web page a lot easier >than trying to send mail and hope for a response. That would be the following from Section 2 (it does not include changes made in my internal version): "Additionally, the use of URIs provides access to multiple transport protocols (such as ftp and http) although it is expected that the "mailto" protocol [RFC6068] will be the focus of most use of the list header fields. Use of non-mailto protocols should be considered in light of those users who do not have access to the specified mechanism (those who only have email - with no web access). I would like to keep a reference to RFC 6068 as "mailto" is commonly used. I'll make the following change: Additionally, the use of URIs provides access to multiple URI schemes. >Section 4 seems obsolete. Does anyone use nested lists any more, at >least nested lists visible to the users? The idea used to be to save >bandwidth by sending one copy of a list message to an exploder closer >to the users, but I don't know anyone who still does that. You can >get pretty much the same effect by sorting the deliveries by target >MX, and then send one copy per MX with multiple MAIL TO. The exploders I know of disappeared a couple of years ago. Section 4 discusses about nested list and does not mention a union of lists. I planned to implement that feature. It's useful for cases such as IETF mailing lists as most of us are subscribed to several lists and end up with an administrative hassle as we have to go through each of them to set our preference. draft-sparks-genarea-mailarch-03 does not discuss about such functionality. I vaguely recall some comments during discussions about datatracker enhancements. I'll suggest leaving this section as it is. >Appendix B strikes me as MUA user interface design advice by people >who know nothing about UI design. I'd just drop it, or replace it >with a short note that the plan is for MUAs to recognize and interpret >the list headers and use them to present a list management interface >to the user that matches the rest of the MUA's interface. As Murray pointed that out too, I'll replace that appendix with a note. >Because it's not very interesting any more. I suppose you could put >in a sentence saying that the design discussion in RFC 2369 may >be useful to help understand the design of list headers. Thanks, I'll add that. >I agree that's wrong. Just add the fripping header, please. I'll remove the following sentence: "There is no need to specify List-Owner if it is the same person as the mail system administrator (postmaster)." >Comments on 2919bis: > >In sec 2, the list ID is typically a hostname in the domain of the >list itself, not of the list owner. I run lists with addresses like >listname@lists.gurus.org, but I as the owner have an address in >another domain. Ok. >In sec 3, most of the places it refers to the MUA are at least as >applicable to the MDA. I do all of my list sorting at delivery time, >not in the MUA, and I suspect a lot of SIEVE users do the same. SIEVE would be implicit here. I'll leave the section as it is unless there is further feedback. >Sec 7, I still think nested lists are dead. If I remove the sections about nested lists in both drafts and leave it to the existing RFCs, List-Sequence won't be covered. >I'd just point out that the subject is associated with the message, >not the list. As a concrete example, if I send a personal reply >to the author of a list message, the subject will still have the >list tag, but it won't have a list-ID. That's a good point. I'll leave this comment open. Regards, S. Moonesamy From sm@elandsys.com Fri Jan 6 15:55:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFC621F875B for ; Fri, 6 Jan 2012 15:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2um0jCN3lm-M for ; Fri, 6 Jan 2012 15:55:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4536121F875A for ; Fri, 6 Jan 2012 15:55:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.119]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q06Nt9Bo000866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 15:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325894125; i=@elandsys.com; bh=ZMCsqSAUy8MlKZsyDbqGgMlhssNotubVbteSDbtpo8M=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=HESHi2K7rYEmSQYn8GISAmVbxQSVN/GhZkv0i5d0p1rNyPMYycCgT8+Ve6OK9z0Kc tpPVZGl3iRjZSvkQ5TRFAraHs7H3+hX2bT9pk7Cr2D7GIvugD1LIYNDOGIon18OIyT TGPVasoKmK00qmlgLZSj/sMiMkoLI2bocE8aMYC4= Message-Id: <6.2.5.6.2.20120106140451.09c30c18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2012 15:55:02 -0800 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F06EEFD.1060707@tana.it> References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 23:55:28 -0000 Hi Alessandro, At 04:54 06-01-2012, Alessandro Vesely wrote: >hope you don't mind my taking this occasion to ask some questions. Ask. :-) >Nice addition. Would it make sense to promote that from appendix to a new >"Definitions" section? (I don't dare suggesting that it should match the >list-label...) No, that would end up being controversial. Please see the comments from Murray and John about subject tags. The problem with using a subject tag which matches list-id is that it takes more space. The List-id for this mailing list is 21 characters. That's a little more than half of the display, assuming a 40 character width. >Defining what is a /list/ that a List-Id identifies would be another I don't fully understand this comment. You could view the List-Id as an opaque identifier. Basically, apps-discuss.ietf.org is a unique string attached to messages from this mailing list (John explained that better). It could have been foo.invalid if that can be considered as unique. Although we would say that the string does not convey anything meaningful, in practice, it would be something which the average subscriber would recognize. >candidate addition. And also what is a /nested list/, maybe. The point is See John's comment. :-) A nested list can be viewed as a list which has one or more mailing lists as a subset. Mailman uses the term Umbrella list. It's part of these mail features which are forgotten as mail turned into a legacy application. The use cases might be as follows: (i) You have 1,000 users subscribed to an external mailing list. To reduce mail traffic, you run an internal mailing list with one subscription to the external mailing list. (ii) In your organization, employees must be subscribed to several mailing lists. You create one mailing list which is subscribed to those mailing lists. When an employee joins, you add them to the mailing list. When they quit, you unsubscribe them. This approach has less administrative overhead and you don't have to worry about forgetting to add the person to one of the sublists. >that it is not clear whether this header field should be used also for >commercial newsletters and similar stuff. The drafts do not specify whether the List- header fields should only be used for discussion lists. Commercial newsletters generally require functionality where the user can unsubscribe. If they find the List- headers useful, they will support it no matter what the drafts say. It's easier to explain the functionality and avoid getting into discussions about content. >I'm not aware of the deployment of "list-id" as suggested in the paragraph of >Section 5: > > It is suggested, but not required, that List Identifiers be created > under a subdomain of "list-id" within any given domain. This can > help to reduce internal conflicts between the administrators of the > subdomains of large organizations. For example, List Identifiers at > "example.com" are generated in the subdomain of "list- > id.example.com". > >Is it actually used or is it merely an example? I don't recall seeing "list-id" in use. It's a suggestion; you can pick any other label in your namespace as long as it does not conflict with your subdomains. >Instead, I found no normative statement that matches the authority on a given >domain that is mentioned in Section 2. Should there be a SOA under >list-id-namespace? I wonder whether there is a claim of responsibility >implied in adding List-Id to a bulk message. There isn't any normative statement. I removed the text from RFC 2919 about authority structure. You can put any domain, even ietf.org. However, if you do that, people will figure out how to block messages from your mailing list. I haven't seen any visible traffic in DNS for "list-id" (monitoring NXDOMAIN). I'd say not to worry about the SOA while pointing you to RFC 2308 for you to decide about the better approach. Your last question is one which a regulator might ask. From a technical angle, the List-Id is for software to have a reliable way to identify messages from a mailing list. The specification does not discuss about responsibility as that might depend on the legal jurisdiction. If you were to point out that it is a dishonest argument, I will agree with you. Regards, S. Moonesamy From vesely@tana.it Sat Jan 7 11:03:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6773921F84EF for ; Sat, 7 Jan 2012 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.294 X-Spam-Level: X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpoyATFO70mw for ; Sat, 7 Jan 2012 11:03:00 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1921F84D3 for ; Sat, 7 Jan 2012 11:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325962979; bh=hWvDmi354InIrFncPhtDqOUtauBxb+Y5yVvAKj10aw0=; l=5773; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=BNP9onLWY8506WnQnj5Yr1wy9OIScd+haL212ZRwq1oNRgZnV6cteKNPSGF8/o5Yd BQ+82b55VNwr8SHax8gE3ucnfPJCk2bo3xj9FGeoo/oSVD6ivhd63TkX7DoM/IPe7K 1q59F3XRuDW8zFdsXt39kjszzdDdyDV/mN1+Lwgk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 07 Jan 2012 20:02:58 +0100 id 00000000005DC039.000000004F0896E2.00006D1F Message-ID: <4F0896E2.7040303@tana.it> Date: Sat, 07 Jan 2012 20:02:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> In-Reply-To: <6.2.5.6.2.20120106140451.09c30c18@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 19:03:01 -0000 On 07/Jan/12 00:55, S Moonesamy wrote: > At 04:54 06-01-2012, Alessandro Vesely wrote: > >> Nice addition. Would it make sense to promote that from appendix >> to a new "Definitions" section? (I don't dare suggesting that it >> should match the list-label...) > > No, that would end up being controversial. Is "that" the new section or the matching? > Please see the comments from Murray and John about subject tags. I agree with what John notes, that after putting the tag in the Subject it is going to stick there independently of List-Id. I, for one, wouldn't like a MUA to remove subject tags on replying. > The problem with using a subject tag which matches list-id is that > it takes more space. I never suggested that. It would match the /list-label/, where list-id = list-label "." list-id-namespace. This list complies. In case the majority of lists comply too, noting such behavior may explain why it's not off topic. >> Defining what is a /list/ that a List-Id identifies would be another > > I don't fully understand this comment. You could view the List-Id as > an opaque identifier. Basically, apps-discuss.ietf.org is a unique > string attached to messages from this mailing list (John explained > that better). John said "the list ID is typically a hostname in the domain of the list itself, not of the list owner." List-Owner, defined in 2369bis, can indeed refer to any address, independently of the list's domain. Please let me quote, for informative purposes only, part of the EU definitions [1] (just mentally s/personal data/a list/): (d) 'controller' shall mean the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; (e) 'processor' shall mean a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller; I would consider a list administrator a processor, in that sense. Thus the question is whether the list-id could be used to identify the controller. If I `dig apps-discuss.ietf.org`, I get the correct SOA in the authority section. That way I'd be able to tell the list-id-namespace even if the list-label were, say, apps.discuss. > Although we would say that the string does not convey anything > meaningful, in practice, it would be something which the average > subscriber would recognize. What's the advantage of having it opaque, since it's structured? >> And also what is a /nested list/, maybe. > > See John's comment. :-) A nested list can be viewed as a list which > has one or more mailing lists as a subset. Mailman uses the term > Umbrella list. I'd propose this: When one or more addresses in a list are in turn the posting address of other mailing lists, the latter are called nested lists, a.k.a. umbrella lists. I, for one, wasn't clear on what that meant before reading your reply. The fact that nested lists almost disappeared makes a definition even more needed, for comprehensibility. > The drafts do not specify whether the List- header fields should only > be used for discussion lists. Commercial newsletters generally > require functionality where the user can unsubscribe. If they find > the List- headers useful, they will support it no matter what the > drafts say. It's easier to explain the functionality and avoid > getting into discussions about content. List-Id seems different from the other List-* fields in this respect, also because of the fact that it lives in its own RFC. However, the abstract and the introduction don't seem to be worded so as to catch the attention of newsletters developers. > I don't recall seeing "list-id" in use. It's a suggestion; you can > pick any other label in your namespace as long as it does not conflict > with your subdomains. In that case, wouldn't it be better to relegate (part of) that paragraph to a description of the second example in Section 3? I think it was in Section 5 as a means to stress that a list-id must univocally identify a list. That is, to guarantee uniqueness even in the absence of any list-id-specific DNS record, rather than to prevent conflicts with other DNS records. For example, if the IETF had a mailing list about the world wide web, it could legitimately use www.ietf.org as the list-id. Correct? > There isn't any normative statement. I removed the text from RFC 2919 > about authority structure. Yup, there was a MUST NOT in Section 2. What's the advantage of relaxing that requirement? > You can put any domain, even ietf.org. However, if you do that, > people will figure out how to block messages from your mailing > list. I think I would be abusing someone else's domain name if I did that. How would people recognize a fake List-Id and block messages? And why would they want to do so, given that generating list-ids in different domains is going to be legitimate? > Your last question is one which a regulator might ask. From a > technical angle, the List-Id is for software to have a reliable way to > identify messages from a mailing list. The specification does not > discuss about responsibility as that might depend on the legal > jurisdiction. If you were to point out that it is a dishonest > argument, I will agree with you. IMHO, technical specifications should provide grips and holds for law makers and regulators. The fact that they are usually such assholes as to be unable to use them is not a justification for omitting them, lest be accused of being equally foolish. -- [1] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML From sm@elandsys.com Sat Jan 7 14:21:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA26F21F84F5 for ; Sat, 7 Jan 2012 14:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sA16rsSZQoh for ; Sat, 7 Jan 2012 14:21:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E3A21F84E4 for ; Sat, 7 Jan 2012 14:21:51 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.235.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q07MLUVO008090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jan 2012 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325974908; i=@elandsys.com; bh=+YrjlhRYD1TRuz5R4ff7a5Ojah40h4Bgw+HMzDvAohk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GQWow3JD8DTy9LTizsR3mEYDQzk5VsKp3M5lPAYI7YhlAjoMZ9ipqP+iQeJCn2K8N d6BhJ8ySVHoIALTJKyOS/zEUq6sGLL047BC5vfMp8pXp9v9muqZddzzQiRjxqiqcMj i8rgnsSJKLZEmdAHsSug06lksAQzwMpMEskNK+JU= Message-Id: <6.2.5.6.2.20120107114742.0ba21628@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jan 2012 14:00:36 -0800 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <4F0896E2.7040303@tana.it> References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 22:21:53 -0000 Hi Alessandro, At 11:02 07-01-2012, Alessandro Vesely wrote: >Is "that" the new section or the matching? The would be new section. >In case the majority of lists comply too, noting such behavior may >explain why it's not off topic. There were comments to drop the entire paragraph. >I would consider a list administrator a processor, in that sense. >Thus the question is whether the list-id could be used to identify the >controller. If I `dig apps-discuss.ietf.org`, I get the correct SOA >in the authority section. That way I'd be able to tell the >list-id-namespace even if the list-label were, say, apps.discuss. From Section 2: "Using the domain name space as a basis for the List Identifier namespace, it is intended to leverage an existing name space structure to generate a unique identifier." It means that it looks like DNS but it is not DNS. See comments below. >What's the advantage of having it opaque, since it's structured? This email is addressed to vesely@tana.it. Only that domain knows who or what "vesely" is for. From my side, it is opaque. I can guess that it is the local-part for me to reach you by email as we have exchanged a few emails. >I'd propose this: > > When one or more addresses in a list are in turn the posting > address of other mailing lists, the latter are called nested > lists, a.k.a. umbrella lists. I thought that you were asking questions and not arguing for a change. >I, for one, wasn't clear on what that meant before reading your reply. >The fact that nested lists almost disappeared makes a definition even >more needed, for comprehensibility. Nested lists did not disappear because of a definition. It is because people do not know about it, that they prefer simple things, or that the sites that used it no longer have a need for it. The people configuring the mailing list manager read the MLM documentation and not the RFC. >List-Id seems different from the other List-* fields in this respect, >also because of the fact that it lives in its own RFC. However, the >abstract and the introduction don't seem to be worded so as to catch >the attention of newsletters developers. RFC 2369 was published in 1998 and RFC 2919 was published in 2001. They were not written by the same people. That may be why List-Id is in its own RFC. >In that case, wouldn't it be better to relegate (part of) that >paragraph to a description of the second example in Section 3? I don't think so. >I think it was in Section 5 as a means to stress that a list-id must >univocally identify a list. That is, to guarantee uniqueness even in >the absence of any list-id-specific DNS record, rather than to prevent >conflicts with other DNS records. For example, if the IETF had a >mailing list about the world wide web, it could legitimately use >www.ietf.org as the list-id. Correct? There isn't any conflict as nothing in draft-moonesamy-rfc2919bis-01 or RFC 2919 says that List-ID is to be resolved in DNS. Yes, the IETF could do that. People can legitimately do anything they want. It is up to them to assess whether there are negative consequences or not. >Yup, there was a MUST NOT in Section 2. What's the advantage of >relaxing that requirement? It avoids DNS wars. >I think I would be abusing someone else's domain name if I did that. >How would people recognize a fake List-Id and block messages? And why As this is an antispam question, the answer is not free. :-) >would they want to do so, given that generating list-ids in different >domains is going to be legitimate? See above. >IMHO, technical specifications should provide grips and holds for law I would have to find a lawyer in the E.U. for legal advice about the text to add. As it is going to be expensive, please do not ask me to pay for that. Regards, S. Moonesamy From msk@cloudmark.com Sat Jan 7 22:10:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660EA21F846B for ; Sat, 7 Jan 2012 22:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTw8cUAtTD45 for ; Sat, 7 Jan 2012 22:10:26 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 910BA21F84A3 for ; Sat, 7 Jan 2012 22:10:26 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 7 Jan 2012 22:10:10 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 7 Jan 2012 22:10:16 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Sat, 7 Jan 2012 22:10:18 -0800 Thread-Topic: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 Thread-Index: AczMPhD2HwUGi076Thajh9wvor6wlABjToeQ Message-ID: References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> In-Reply-To: <20120106063934.80082.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 06:10:27 -0000 [moving to apps-discuss from appsdir] > -----Original Message----- > From: appsdir-bounces@ietf.org [mailto:appsdir-bounces@ietf.org] On Behal= f Of John Levine > Sent: Thursday, January 05, 2012 10:40 PM > To: appsdir@ietf.org > Cc: sm+ietf@elandsys.com > Subject: Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369= bis-01 and draft-moonesamy-rfc2919bis-01 >=20 > It's basically fine, but I have a few suggestions. As an editorial > matter, the constant harping to use mailto: everywhere gets old. I'd > suggest saying it up front and noting that mail users aren't > necessarily able to use any other kind of URI, then drop it. The other > 99.9% of mail users, of course, find a web page a lot easier than > trying to send mail and hope for a response. +1 about mailto. But as the common thing is to have MUAs that are able to = deference both kinds of links, maybe that base set should include mailto an= d http. > Section 4 seems obsolete. Does anyone use nested lists any more, at > least nested lists visible to the users? The idea used to be to save > bandwidth by sending one copy of a list message to an exploder closer > to the users, but I don't know anyone who still does that. You can get > pretty much the same effect by sorting the deliveries by target MX, and > then send one copy per MX with multiple MAIL TO. I've written software that accommodates such configurations, but I haven't = seen it in active use in a long time. People just subscribe to multiple li= sts these days. > Appendix B strikes me as MUA user interface design advice by people who > know nothing about UI design. I'd just drop it, or replace it with a > short note that the plan is for MUAs to recognize and interpret the > list headers and use them to present a list management interface to the > user that matches the rest of the MUA's interface. I agree, simpler is better when it comes to MUA design. > >>3) The deletion of Appendix A from RFC2369 is conspicuous. Why remove > >>all of that supporting discussion? >=20 > Because it's not very interesting any more. I suppose you could put in > a sentence saying that the design discussion in RFC 2369 may be useful > to help understand the design of list headers. I'd be happy with such a back-reference. > >>7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no > >>need" sentence seems odd. If the MUA is supposed to use "postmaster" > >>to contact the owner in the case of a list that doesn't add this, what > >>domain name should it use? >=20 > I agree that's wrong. Just add the fripping header, please. Well, either that, or have some simple heuristic for extracting a domain na= me to append to "postmaster@" when presenting some list management knobs in= an MUA. As written right now, it seems like an incomplete mechanism. > Comments on 2919bis: >=20 > >Subject tags are commonly used as list identifiers (this mailing list > >uses them). Appendix A.1 explains the difference between a List > >Identifier and a subject tag in terms of uniqueness. If I have to > >provide an explanation, I would have to get into mail filtering, e.g. > >why use List-ID instead of subject tags to move messages from this > >mailing list into a separate mailbox. >=20 > I'd just point out that the subject is associated with the message, not > the list. As a concrete example, if I send a personal reply to the > author of a list message, the subject will still have the list tag, but > it won't have a list-ID. I still don't understand why it's there. I know what it's telling me and I= believe it's correct, but I don't understand how someone using this docume= nt (to write an MLM or a compliant MUA) would apply this information. That= is: "OK, so subject tags and List-ID have different uniqueness properties.= Now what?" From msk@cloudmark.com Sat Jan 7 22:16:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8207621F84D2 for ; Sat, 7 Jan 2012 22:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W69CKUgk41CT for ; Sat, 7 Jan 2012 22:16:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2209E21F84B5 for ; Sat, 7 Jan 2012 22:16:48 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 7 Jan 2012 22:16:41 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 7 Jan 2012 22:16:47 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Sat, 7 Jan 2012 22:16:48 -0800 Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 Thread-Index: AczNbv/gElzVJ4PHQuSnO4+K7vYxVQAXaT1w Message-ID: References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> In-Reply-To: <4F0896E2.7040303@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 06:16:48 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Alessandro Vesely > Sent: Saturday, January 07, 2012 11:03 AM > To: S Moonesamy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and= draft-moonesamy-rfc2919bis-01 >=20 > > Although we would say that the string does not convey anything > > meaningful, in practice, it would be something which the average > > subscriber would recognize. >=20 > What's the advantage of having it opaque, since it's structured? Any structure in the local-part is known only to the domain that will recei= ve it. That's what we mean by opaque here. It's like a pointer into that = domain's address space; you don't know how to dereference it from outside t= hat domain, though if you see it twice, it's reasonable to conclude it's th= e same thing both times. From msk@cloudmark.com Sat Jan 7 23:20:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050C921F852B for ; Sat, 7 Jan 2012 23:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfZq4Blo4OOS for ; Sat, 7 Jan 2012 23:20:25 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F03CF21F8529 for ; Sat, 7 Jan 2012 23:20:24 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 7 Jan 2012 23:20:12 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 7 Jan 2012 23:20:18 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Sat, 7 Jan 2012 23:20:19 -0800 Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 Thread-Index: AczMN+WD3pnks5pzS7eA67iZ5T0m7QBlUwtg Message-ID: References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> In-Reply-To: <6.2.5.6.2.20120105165019.063fa0a8@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 07:20:26 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of S Moonesamy > Sent: Thursday, January 05, 2012 9:38 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and= draft-moonesamy-rfc2919bis-01 >=20 > Thanks for the feedback. Can you forward it to those lists? I asked > for feedback from a mailman developer and other MLM implementors. I sent it to the mailman developers list. I suggest ietf-822 as well. > RFC 2369 was published over ten years ago. The major change since then > is the use of URI schemes. I was reusing some old code and had to > figure out which up-to-date RFCs to use. I added the odds and ends I > found to the drafts. Fair enough, though have URI schemes changed a lot since the RFCs you're up= dating? > >1) Have the original authors of these documents been contacted to see > >if they want to >=20 > I emailed to the original authors. If anyone has an up to date contact > for them, please email me. BTW, I am listed as an editor and not the > author. There is a "most of the text in this document" > sentence in the Acknowledgement section. Also fair enough. I got asked the same thing for a recent "bis" draft I di= d, so I figured you should face this question sooner rather than later. :-= ) But you should probably expect the IESG to double-check. > >2) It seems to me both of these would be helped (in the "can't hurt" > >sense) by an informative reference to RFC5598 just so there's a handy > >illustration of how all these components fit together. >=20 > I kept the References section lightweight by only adding what is > necessary for someone to understand what is in the document and to > implement it. I prefer not to add more informative references. I still think it would be a good idea. The role an MLM plays in the handli= ng of a message can be complicated, and RFC5598 does a nice job of laying i= t all out. I think this is especially important given the fact that we're = talking in these RFCs about substantial message alteration that ultimately = is meant to change MUA behaviour. > >3) The deletion of Appendix A from RFC2369 is conspicuous. Why remove > >all of that supporting discussion? I suppose since this stuff has been > >out there for a while now it'd be sufficient to mention in later > >sections that such discussion exists in the original document. >=20 > There is an informative reference to RFC 2369 in the draft. As such, > people who are interested in why RFC 2369 was written in such a way > will find the supporting discussion. I am going to leave this > comment open (whether it is worth explicitly pointing out). I wouldn't have made the suggestion if not for the very size of Appendix A = in RFC2369. There's a lot of good material in there, and someone finding t= he -bis version for the first time might end up with a lot of questions tha= t are answered there, but not think to follow informative references. Ther= e's a lot to read already. :-) > >4) The language at the top of 3.1 sounds vaguely like a minimum > >compliance statement. I suggest it be reworked to something simpler, > >like striking everything from "is the most" up to and including "by > >definition it". >=20 > The language is similar to what was in RFC 2369. I'll change it to the > following: >=20 > The List-Help header field can direct the user to complete > instructions for all other commands. Typically, the URI > specified would request the help file, perhaps incorporating > an HTML form for list commands, for the list, and alternatively > provide access to an instructive website. Much better. > BTW, most subscribers find web forms more accessible then interacting > with a MLM by email. That might be an argument for making "http" the URI scheme of choice rather= than "mailto". > >6) The various URI constructions might benefit from being enabled by > >what's specified in draft-gregorio-uritemplate (now in IESG Evaluation, > >so it might be an RFC soonish), which would allow the defined header > >fields to contain values expanded by the MUA, something like: > > > > List-Help: > > > > > >...and then just define that when expanding such templates, "user" > >is the email address the MUA is using. >=20 > There is a discussion about variable substitution in Appendix A.5 of > RFC 2369. It explains why that was not added. I'll leave this comment > open. It could well be that there isn't any demand for being able to do this (or = as John mentioned in REPUTE, Apache mod_rewrite makes this kind of thing un= necessary). It was just a suggestion to make things more flexible. Part o= f my motivation was the fact that most "unsubscribe" links have "href" tags= that do include the unsubscribing user's address as part of the URI; this = provides a means for doing that. > >7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no need" > >sentence seems odd. If the MUA is supposed to use "postmaster" to > >contact the owner in the case of a list that doesn't add this, what > >domain name should it use? >=20 > The List-Owner may not necessarily be the postmaster. For example, in > a hosted environment, the administrative role may be delegated to the > person running the mailing list as it is easier to have them answer > questions about how to unsubscribe or to act as a first point of > contact for mailing list issues. >=20 > Using this mailing list as an example, there isn't a List-Owner header > field. Some of the subscribers know that they can contact ietf-action > if there is a problem. As the email has ietf.org in the return-path, > the contact address would be postmaster@ietf.org. My concern is that the advice that's there is dangling. It gives a default= local-part to contact the owner, but no method for selecting a domain. If= we don't like the idea of saying List-Owner needs to be added in all cases= , then the default local-part should go as well. > "There is no need" could be read as "we know that the postmaster is the > human contact if there is a mail problem". If you look at this from a > different angle, the users contact their postmaster and the latter > figures out how to reach a human contact at the other end. You still need to know which domain to contact somehow. > It is often said that the IETF does not have the expertise to make UI > recommendations. I usually read that as a code word. :-) FWIW, as the > appendix is about guidelines, it should be read as informative. I think it's fine to say that the goal of these header fields is to make av= ailable specific additional information to users via MUAs, should the MUAs = wish to support them, and then let the MUAs decide how to do that. Any det= ail beyond that and, as you mention, we're tinkering in space we don't unde= rstand well enough to do so. > >10) List-ID uses the domain name space, even if the domains don't > >actually exist. Do we need to talk about IDNA at all here? >=20 > If I had to describe 2919bis in a few words, I would use "in most > cases, appear like a host name in a domain of the list owner" > (Section 2). List-ID is borrows the syntax from an established > namespace to get some form of uniqueness. >=20 > I would have to ask the EAI WG if I introduce IDNA in 2919bis as they > have been doing some work in this area. It is possible to > internationalize 2369bis and 2919bis but that won't address the issues > as they occur at 5335bis and 5336bis "layers". I restate your question > as "can we get away with not talking about IDNA" and I think that the > answer is yes. >=20 > FWIW, it would not be that much of an additional effort to use IDNA > without discussing about the issues. I guess I'm just of the mindset recently that anything using DNS name synta= x automatically draws the "What about IDNA?" question, so I thought I'd get= us thinking about it sooner rather than later. If it doesn't apply here, = that's fine, as long as we considered it. > >12) There's a place in Security Considerations where it makes a > >normative assertion that user-generated List-* fields need to be > >deleted by the MLM. I think that should be in a normative part of the > >document rather than Security Considerations. Rather, Security > >Considerations might talk about the risks created if an MLM doesn't > comply. >=20 > That would be: >=20 > "Mailing list managers should not allow any user-originated list > header fields to pass through to the mailing lists, lest they confuse > the user and have the potential to create security problems." >=20 > It looks more like a security consideration. In Section 3, there is: >=20 > "There MUST be no more than one of each header field present in > any given message." >=20 > and: >=20 > "These header fields MUST only be generated by mailing list managers, > not by MUAs." >=20 > I have not tested whether existing implementations bounce user > generated messages which contain List- headers. It definitely is a security consideration, but I would go so far as to say = that this should be made normative. Allowing external instances of these f= ields to pass through can confound MUAs or even get users to click on thing= s that have nothing to do with list postings. In RFC5451 this was made a MUST/SHOULD depending on the circumstances. I t= hink the same applies here. > >13) The change from "localhost" (which might actually resolve, if that > >matters) to "invalid" makes sense, but I'm somehow worried about > >backward-compatibility issues. >=20 > Me too. I haven't seen a case where "localhost" is used. I assume > that the fallback is "localhost.localdomain" in environments where a > valid domain name is not available. That's incorrect though. One of > the arguments in RFC 2919 was "users unable to afford domain name > registration fees". That is less of a barrier nowadays. >=20 > BTW, we could sneak in a new TLD by using 2919bis to reserve it (draft- > cheshire-dnsext-special-names-02). :-) Not a bad idea, actually. > >14) Section 6 in RFC2919bis seems needlessly verbose about > >case-insensitive string comparison. Simply using that term is quite > >sufficient. >=20 > I can drop that. RFC 2919 uses "CASE INDEPENDENCE" from RFC 822. That > text is not in RFC 5322. I used some (verbose) text as there isn't any > such text in the mail-related RFCs. Let's wait for more feedback about > this. I think since we're using DNS syntax here, whatever language RFC1034/1035 u= se to describe label comparison would suffice here. > >15) Appendix A.1 in RFC2919bis seems way off topic. I suggest striking > >it, or adding text to explain why it's not off topic. >=20 > Subject tags are commonly used as list identifiers (this mailing list > uses them). Appendix A.1 explains the difference between a List > Identifier and a subject tag in terms of uniqueness. If I have to > provide an explanation, I would have to get into mail filtering, e.g. > why use List-ID instead of subject tags to move messages from this > mailing list into a separate mailbox. Ah, that seems reasonable. I suggest you add such comments to the draft so= the reader is not left wondering why this is there. Thanks, -MSK From sm@elandsys.com Sun Jan 8 03:00:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704F721F84FE for ; Sun, 8 Jan 2012 03:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFnm5t2mHhrC for ; Sun, 8 Jan 2012 03:00:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891C421F84FA for ; Sun, 8 Jan 2012 03:00:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.235.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q08B04jS027610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jan 2012 03:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326020417; i=@elandsys.com; bh=eh+dAMYAAupBnI4905kBAHHukMwhLmnKzwkAY+Ux830=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=4uyTQLJENCsQl/VGAG8GpDccQ1n1oAwublp2Xolqe9EA86oLLqUd/V3Wyxsn5bS8O EVJOsd9WgXnEAgQ3eZY8ihP4wA5pa8tuiw9ZdBtIeT2+d3NtKNh9rJBOCIMGI5PoW+ bqbSqxSLr51fGmIPmSUL+v06Jq6zZaA5tW+W2hDU= Message-Id: <6.2.5.6.2.20120108011725.0bfaf2b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jan 2012 02:18:57 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 11:00:21 -0000 Hi Murray, At 22:10 07-01-2012, Murray S. Kucherawy wrote: >[moving to apps-discuss from appsdir] Thanks. >+1 about mailto. But as the common thing is to have MUAs that are >able to deference both kinds of links, maybe that base set should >include mailto and http. There is such an example at the end of Section 3.2 of draft-moonesamy-rfc2369bis-01 >Well, either that, or have some simple heuristic for extracting a >domain name to append to "postmaster@" when presenting some list >management knobs in an MUA. As written right now, it seems like an >incomplete mechanism. Agreed. I'll remove the text. At 23:20 07-01-2012, Murray S. Kucherawy wrote: >I sent it to the mailman developers list. I suggest ietf-822 as well. Ok. >Fair enough, though have URI schemes changed a lot since the RFCs >you're updating? It's less of an effort when moving from URI to IRI. >Also fair enough. I got asked the same thing for a recent "bis" >draft I did, so I figured you should face this question sooner >rather than later. :-) But you should probably expect the IESG to >double-check. Thanks for the clarification. Other people may find the information useful. >I wouldn't have made the suggestion if not for the very size of >Appendix A in RFC2369. There's a lot of good material in there, and >someone finding the -bis version for the first time might end up >with a lot of questions that are answered there, but not think to >follow informative references. There's a lot to read already. :-) I'll change the text to a pointer to RFC 2369. >It could well be that there isn't any demand for being able to do >this (or as John mentioned in REPUTE, Apache mod_rewrite makes this >kind of thing unnecessary). It was just a suggestion to make things >more flexible. Part of my motivation was the fact that most >"unsubscribe" links have "href" tags that do include the >unsubscribing user's address as part of the URI; this provides a >means for doing that. Let me try and come up with some text to reference draft-gregorio-uritemplate-07 informatively. >My concern is that the advice that's there is dangling. It gives a >default local-part to contact the owner, but no method for selecting >a domain. If we don't like the idea of saying List-Owner needs to >be added in all cases, then the default local-part should go as well. Agreed. >I think it's fine to say that the goal of these header fields is to >make available specific additional information to users via MUAs, >should the MUAs wish to support them, and then let the MUAs decide >how to do that. Any detail beyond that and, as you mention, we're >tinkering in space we don't understand well enough to do so. I strongly agree. >I guess I'm just of the mindset recently that anything using DNS >name syntax automatically draws the "What about IDNA?" question, so >I thought I'd get us thinking about it sooner rather than later. If >it doesn't apply here, that's fine, as long as we considered it. Ok. >It definitely is a security consideration, but I would go so far as >to say that this should be made normative. Allowing external >instances of these fields to pass through can confound MUAs or even >get users to click on things that have nothing to do with list postings. I might use your last sentence as part of Security Considerations. >In RFC5451 this was made a MUST/SHOULD depending on the >circumstances. I think the same applies here. I generally use MUST and SHOULD where interoperability is needed. I'll discuss about this point off-list. >I think since we're using DNS syntax here, whatever language >RFC1034/1035 use to describe label comparison would suffice here. I'll remove that text. >Ah, that seems reasonable. I suggest you add such comments to the >draft so the reader is not left wondering why this is there. Ok. Thanks for the review. Regards, S. Moonesamy From vesely@tana.it Mon Jan 9 02:54:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D51221F846C for ; Mon, 9 Jan 2012 02:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XRcs181XCw4 for ; Mon, 9 Jan 2012 02:54:24 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F021F846B for ; Mon, 9 Jan 2012 02:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326106462; bh=RA5XLKGZm++1oQDJE/zYh8+SDW/1P5+dBvwqdB2y96w=; l=2111; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=FXsiLNyjDrcSx+n7tNXIIehOPmjyhsLwxcK3CRxxayKVenvWAf2sy8m8i9QI//a6V IjzvACJU2wBQ/twrMCq98FziqeR+tg+m5j4NofiQ417T0a1gtF53zUpwTrQd9hvF/E yrBvn9TSTUn36/dSmQBnEFgAuHq/sdry04uY0vGM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 09 Jan 2012 11:54:22 +0100 id 00000000005DC039.000000004F0AC75E.000078E1 Message-ID: <4F0AC75E.3030709@tana.it> Date: Mon, 09 Jan 2012 11:54:22 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> <6.2.5.6.2.20120107114742.0ba21628@resistor.net> In-Reply-To: <6.2.5.6.2.20120107114742.0ba21628@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:54:29 -0000 On 07/Jan/12 23:00, S Moonesamy wrote: > At 11:02 07-01-2012, Alessandro Vesely wrote: > > From Section 2: > > "Using the domain name space as a basis for the List > Identifier namespace, it is intended to leverage an > existing name space structure to generate a unique > identifier." > > It means that it looks like DNS but it is not DNS. See comments below. If it doesn't have to be a real DNS name, the reason to treat ".invalid" as a special case becomes rather obscure. > Nested lists did not disappear because of a definition. It is because > people do not know about it, that they prefer simple things, or that > the sites that used it no longer have a need for it. So there is an implied "if you don't know what a nested list is, you may safely skip this section." > RFC 2369 was published in 1998 and RFC 2919 was published in 2001. > They were not written by the same people. That may be why List-Id is > in its own RFC. Since you are somewhat diluting the spec, you might as well have merged it with 2369bis. Why not? >> Yup, there was a MUST NOT in Section 2. What's the advantage of >> relaxing that requirement? > > It avoids DNS wars. Whazzat? I thought DNS was developed for civilian purposes only... In any case, I'd substitute "recommended" with either "RECOMMENDED" or a synonym like "suggested", in the third line below: While it is perfectly acceptable for a List Identifier to be completely independent of the domain name of the host machine servicing the mailing list, it is recommended that the owner of a mailing list avoids generating List Identifiers in any domain name space for which they do not have authority. >> IMHO, technical specifications should provide grips and holds for law > > I would have to find a lawyer in the E.U. for legal advice about the > text to add. As it is going to be expensive, please do not ask me to > pay for that. Quite the opposite way around: It is the EU (or Canada) who will pay you a consultancy when they'll need to legally nail who is in control of a list's operations :^) From msk@cloudmark.com Mon Jan 9 10:50:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1DE21F873E for ; Mon, 9 Jan 2012 10:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHwQfWABKPAi for ; Mon, 9 Jan 2012 10:50:53 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E11FD21F8734 for ; Mon, 9 Jan 2012 10:50:53 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 10:50:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 10:50:53 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 9 Jan 2012 10:50:51 -0800 Thread-Topic: Spam reporting over IMAP Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C157A4EXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:50:55 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C157A4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In September the OMA sent a notice to the IETF that it had submitted draft-= ordogh-spam-reporting-using-imap for our consideration as they need it (or = something like it) to complete work of their Enhanced Visual Voice Mail wor= king group. It has since then failed to get any IETF attention. It was submitted to the Messaging Abuse Reporting Format (MARF) working gro= up but they are not chartered to handle this work, nor is there any apparen= t interest or momentum to recharter to do so. Is there any interest among those of us following APPSAWG to do this kind o= f work? I can't think of any current working groups where it might otherwi= se fit. I can suggest they present in Paris if they want to gauge interest if peopl= e would be interested in hearing something about it. Otherwise, I believe = I should reply to them that the IETF is not currently doing work in this ar= ea so their options include an ISE submission or something AD-sponsored tha= t goes for Experimental status or suchlike. I'd be happy if someone (or a few of us) here could review it and make some= suggestions about next steps. Thanks, M. Kucherawy --_000_F5833273385BB34F99288B3648C4F06F19C6C157A4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In September the= OMA sent a notice to the IETF that it had submitted draft-ordogh-spam-repo= rting-using-imap for our consideration as they need it (or something like i= t) to complete work of their Enhanced Visual Voice Mail working group. = ; It has since then failed to get any IETF attention.


It was submitted to the Messaging Abuse Reporting Format = (MARF) working group but they are not chartered to handle this work, nor is= there any apparent interest or momentum to recharter to do so.<= /p>

 

Is there = any interest among those of us following APPSAWG to do this kind of work?&n= bsp; I can’t think of any current working groups where it might other= wise fit.

 

I can suggest they present in Paris if they want to gauge inte= rest if people would be interested in hearing something about it.  Oth= erwise, I believe I should reply to them that the IETF is not currently doi= ng work in this area so their options include an ISE submission or somethin= g AD-sponsored that goes for Experimental status or suchlike.

 

I’d b= e happy if someone (or a few of us) here could review it and make some sugg= estions about next steps.

 

Thanks,

 

M. Kucherawy

<hat-type=3D’OMA-Liaison’/>

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C157A4EXCHC2corpclo_-- From johnl@iecc.com Mon Jan 9 13:06:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDD711E8075 for ; Mon, 9 Jan 2012 13:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.14 X-Spam-Level: X-Spam-Status: No, score=-104.14 tagged_above=-999 required=5 tests=[AWL=-3.030, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-0H5P5RWYFV for ; Mon, 9 Jan 2012 13:06:25 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EDF3021F8704 for ; Mon, 9 Jan 2012 13:06:24 -0800 (PST) Received: (qmail 72173 invoked from network); 9 Jan 2012 21:06:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Jan 2012 21:06:19 -0000 Date: 9 Jan 2012 21:05:57 -0000 Message-ID: <20120109210557.4950.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:06:26 -0000 > Is there any interest among those of us following APPSAWG to do this > kind of work? I can't think of any current working groups where it > might otherwise fit. I think it's a fine idea, but I wouldn't want to invest time in this proposal unless there were some indication that large IMAP operators were interested in doing something with it. Do we know anyone at AOL, Yahoo, or Gmail to ask? I can probably ask Tucows. R's, John From msk@cloudmark.com Mon Jan 9 14:51:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69F221F8605 for ; Mon, 9 Jan 2012 14:51:40 -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.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNpxz9feWPam for ; Mon, 9 Jan 2012 14:51:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60F21F84A3 for ; Mon, 9 Jan 2012 14:51:40 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 14:51:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 14:51:39 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 9 Jan 2012 14:51:39 -0800 Thread-Topic: draft-kucherawy-received-state Thread-Index: AczPIT9QGS1HD3P+QOqbeqR0Yizx3Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C157BDEXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:51:40 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C157BDEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Over on ietf-smtp, https://datatracker.ietf.org/doc/draft-kucherawy-receive= d-state/ was developed late last year. This is an optional tweak to email = Received fields allowing annotation of entry into special states of mail ha= ndling, such as quarantines or hold-for-moderation MLM actions that would h= elp to explain large gaps in timestamp sequences. I'm looking for a wider audience of reviewers and (hopefully supporters). = If this sort of thing seems like a good (or terrible) idea, please do follo= w up and comment. How much and what kind of support is evident will guide the choice of what = its next steps are (if any). Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C157BDEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Over o= n ietf-smtp, https://datatracker.ietf.org/doc/draft-kucherawy-received-st= ate/ was developed late last year.  This is an optional tweak to e= mail Received fields allowing annotation of entry into special states of ma= il handling, such as quarantines or hold-for-moderation MLM actions that wo= uld help to explain large gaps in timestamp sequences.

 

I’m looking = for a wider audience of reviewers and (hopefully supporters).  If this= sort of thing seems like a good (or terrible) idea, please do follow up an= d comment.

 

How much and what kind of support is evident will guide the ch= oice of what its next steps are (if any).

 

Thanks,

-MSK

 

<= /div>= --_000_F5833273385BB34F99288B3648C4F06F19C6C157BDEXCHC2corpclo_-- From john-ietf@jck.com Mon Jan 9 15:37:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59C21F85A0 for ; Mon, 9 Jan 2012 15:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ5ouX7MvN4X for ; Mon, 9 Jan 2012 15:37:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10B11E80B1 for ; Mon, 9 Jan 2012 15:37:49 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RkOmh-000PVO-Na; Mon, 09 Jan 2012 18:37:48 -0500 Date: Mon, 09 Jan 2012 18:37:46 -0500 From: John C Klensin To: "Murray S. Kucherawy" 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 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:37:50 -0000 --On Monday, January 09, 2012 10:50 -0800 "Murray S. Kucherawy" wrote: > In September the OMA sent a notice to the IETF that it had > submitted draft-ordogh-spam-reporting-using-imap for our > consideration as they need it (or something like it) to > complete work of their Enhanced Visual Voice Mail working > group. It has since then failed to get any IETF attention. > > It was submitted to the Messaging Abuse Reporting Format > (MARF) working group but they are not chartered to handle this > work, nor is there any apparent interest or momentum to > recharter to do so. > > Is there any interest among those of us following APPSAWG to > do this kind of work? I can't think of any current working > groups where it might otherwise fit. > > I can suggest they present in Paris if they want to gauge > interest if people would be interested in hearing something > about it. Otherwise, I believe I should reply to them that > the IETF is not currently doing work in this area so their > options include an ISE submission or something AD-sponsored > that goes for Experimental status or suchlike. > > I'd be happy if someone (or a few of us) here could review it > and make some suggestions about next steps. Murray, I have taken a _very_ quick look at this (I have not read all the way through it). Procedurally, if they want this processed in the IETF, it would be good if it conformed to requirements for I-Ds (e.g., the RFC Editor will not consider a document with a page-long abstract, much less one that has a "Conventions Used..." section apparently in the middle of it). More substantively, -- they are assuming a whole serious of functions, capabilities, and relationships that may not exist in a typical IMAP server, at least one that is not also SIEVE-enabled (see below) -- someone needs to tell them about current trends in specifications like this. In particular, while I remain in the (apparently small) minority who still see value in "X-" and "X" constructions even though I also favor adjusting registration rules to make them _much_ less useful, it seems to me that this specification should not be encouraging entirely new sets of uses of them. -- they posit the existence of "spam aggregator services" but never really define those or explain how an IMAP server is supposed to find one with the right capabilities except by an putative informative reference to [OMA-SPAMREP]. First of all, if they say something like "such as an aggregator service based on [OMA-SPAMREP]" as the only definition of what such a thing might be, then it is a normative reference -- certainly an IMAP server would need to understand what a spam aggregator service is in order to organize handing off work to one of them. I can't find the document referenced in the "Publicly Available Documents" list on the OMA web site (http://www.openmobilealliance.org/Technical/PublicMaterial.aspx). Granted I didn't spend a huge amount of time poking around but, even for an informative reference --much less for a reference that is critical for understanding the spec-- being able to find documents easily is usually a good idea. I've heard that something called a "URL" was invented for that purpose. -- As a general rule, IMAP servers are not, in general, designed to communicate with anything or any one, other than users via the IMAP protocol and maybe (statistically or otherwise) with the mail store about the status of messages and user opinion of them. Asking them to do so, via a "spam aggregator services" or otherwise, seems to me to require far more understanding of trust and privacy relationships than are covered by the near-hand-waving in the Security Considerations section of this document. It might also require fairly significantly re-architecting several of the IMAP servers of my acquaintance. -- As a very high level architectural observation, someone might think about whether it would be helpful to graft something of this nature onto a SIEVE server. Because such a server (possibly in conjunction with other delivery MTA-components) is responsible for processing messages before they disappear into a mail store, they could, in principle, ensure appropriately-unique message identifiers (which an IMAP server, especially a distributed one, may not be able to do). Because they can specify and handle (or get something else to handle) message rejections, they might also be in a better position to handle some of the requirements here. In any event, a document of this sort needs to go much further to explain what functions and interfaces an IMAP server would actually need to add to support something like this. The document leaves that to the imagination and this is a sufficient departure from the classic IMAP architectural and functional assumptions that imagination really isn't adequate. Conclusion: Not ready from prime time. Not even ready for a careful and comprehensive review. You asked. john From msk@cloudmark.com Mon Jan 9 15:48:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4321F84FB for ; Mon, 9 Jan 2012 15:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu0gt2zBu6os for ; Mon, 9 Jan 2012 15:48:47 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14921F8469 for ; Mon, 9 Jan 2012 15:48:47 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 15:48:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 9 Jan 2012 15:48:46 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 9 Jan 2012 15:48:45 -0800 Thread-Topic: [apps-discuss] Spam reporting over IMAP Thread-Index: AczPJ7ag7X4CqF/4RMSvQwcUFektggAAPUYQ 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 Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:48:47 -0000 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Monday, January 09, 2012 3:38 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Spam reporting over IMAP >=20 > Conclusion: >=20 > Not ready from prime time. Not even ready for a careful and > comprehensive review. >=20 > You asked. I did, and thanks for that. I think at this point perhaps a higher-level question is in order: Are we (= either IETF in general, or APPSAWG specifically) interested in or willing t= o put time into developing this in conjunction with OMA? Would this be som= ething ultimately beneficial to have, and have it come from us? I suppose I'm also concerned with the idea of an external SDO, on getting a= "no" from us, deciding they want to do this anyway so they publish their o= wn (unsanctioned, of course) IMAP extension only to have it see some level = of ubiquity as a result. Indeed it may be possible that this is coming to = us only because some OMA member organizations have already developed and ar= e deploying this, at least experimentally. There's friction between geopri= v and OMA's LOC WG of this nature already which I'd just as soon resolve so= oner rather than later somehow. -MSK From sm@elandsys.com Mon Jan 9 16:01:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C9011E80B1 for ; Mon, 9 Jan 2012 16:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.707 X-Spam-Level: X-Spam-Status: No, score=-102.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRPzqGnvIMDn for ; Mon, 9 Jan 2012 16:01:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A73A621F85D5 for ; Mon, 9 Jan 2012 16:01:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.103]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0A01G4j009195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jan 2012 16:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326153694; i=@elandsys.com; bh=+k0xJb0AlYlDsFAO3f9TddPD6RBlDGPrIbqUtcPGqDU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=cO0sUOzsKUx3e87R3aMvwvmP1ROhMA3iYLQOv+ogz5sJdX4T2quhqCJdPVW4gduvH Hw9IeLNFKfjwgZWXKH1+NxQXEBwN0ineITd8PJTiz/vFt5NTdxvm7evnUwG4aPTZVj SXdzBIE+TGNGtQBfG6Zx67sG7lHfaUHeTII2DrVA= Message-Id: <6.2.5.6.2.20120109133139.08d63218@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 14:02:04 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <4F0AC75E.3030709@tana.it> References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> <6.2.5.6.2.20120107114742.0ba21628@resistor.net> <4F0AC75E.3030709@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:01:38 -0000 At 02:54 09-01-2012, Alessandro Vesely wrote: >If it doesn't have to be a real DNS name, the reason to treat >".invalid" as a special case becomes rather obscure. It's to avoid localhost.com, etc. >So there is an implied "if you don't know what a nested list is, you >may safely skip this section." If you are not implementing nested list, you can skip the section. >Since you are somewhat diluting the spec, you might as well have >merged it with 2369bis. Why not? 2369bis is more about list commands whereas 2919bis is about list identifiers. Keeping the them as two separate documents makes it easier to compare changes. >Whazzat? I thought DNS was developed for civilian purposes only... Some parts of DNS are about policy. "Several people expressed considerable scepticism about the chances of success in response to domain name registry issues." >In any case, I'd substitute "recommended" with either "RECOMMENDED" or >a synonym like "suggested", in the third line below: > > While it is perfectly acceptable for a List Identifier to be > completely independent of the domain name of the host machine > servicing the mailing list, it is recommended that the owner of a > mailing list avoids generating List Identifiers in any domain name > space for which they do not have authority. Ok. >Quite the opposite way around: It is the EU (or Canada) who will pay >you a consultancy when they'll need to legally nail who is in control >of a list's operations :^) I'll use that as the rationale for the work. :-) Regards, S. Moonesamy P.S. As all messages from this mailing list are DKIM signed, you can use some heuristics to detect misuse of the list-id. From lyndon@orthanc.ca Mon Jan 9 16:15:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6D11E80B1 for ; Mon, 9 Jan 2012 16:15: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M78cz-LsIeIg for ; Mon, 9 Jan 2012 16:15:36 -0800 (PST) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by ietfa.amsl.com (Postfix) with ESMTP id EC5BD11E8080 for ; Mon, 9 Jan 2012 16:15:35 -0800 (PST) Received: from peregrin.orthanc.ca ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q0A0FIhR088796; Mon, 9 Jan 2012 16:15:18 -0800 (PST) (envelope-from lyndon@orthanc.ca) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_781FAB94-7E93-410A-8220-2EE01B13FC61"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Lyndon Nerenberg In-Reply-To: Date: Mon, 9 Jan 2012 16:15:13 -0800 Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1251.1) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:15:36 -0000 --Apple-Mail=_781FAB94-7E93-410A-8220-2EE01B13FC61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-01-09, at 15:48 PM, Murray S. Kucherawy wrote: > I think at this point perhaps a higher-level question is in order: Are = we (either IETF in general, or APPSAWG specifically) interested in or = willing to put time into developing this in conjunction with OMA? Would = this be something ultimately beneficial to have, and have it come from = us? I'm sure many people would like to see something like SREP, but IMAP is = absolutely the wrong place to put it. IMAP servers store messages. An = IMAP server doesn't decide whether something is spam, and is in no way = capable of doing anything about it. SPAM filtering happens further up the delivery chain, usually within the = MDA, or a preceding MTA, typically one that borders the recipient's = site. For an SREP-like system to have value, it needs to be able to = provide feedback to the appropriate location in the delivery chain. A = generic reporting protocol might be a way of doing this, but it needs to = be agnostic of the message stores and transport agents if it's to be = useful. So while I applaud the concept, the proposed solution isn't even close = to baked. --lyndon= --Apple-Mail=_781FAB94-7E93-410A-8220-2EE01B13FC61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPC4MUAAoJEG8PnXiV/JnU2QoQAJh1Uyq6W0cGVVevFP0pqT/0 jX2UgljlahXUUkuPDakbnA6BNvflq9F30LHunD7ziU9h8nyIO4B1X7XZnO0U5GFl m2WNdp6OKF+Vnn5ZB6bsfQgg9KwuBHfUXFykwmoQwaKz3PxYo/rpIlst7oCTWnmJ k4KKcz0WCO7mfMrZOwiyjDPSy2lo2Jfh5vMuG6hTx42HeCyuV0vs2HBQ/fVqEQZ/ XlUkNrnkmCTv+Hy+LMQKundPp8oX0SoDY7ZlowQwQC8SU2E8gmsUqDH+7RqPTHJW 7GJ1F6lzqJP0zPuTgdURHankReFYYOahOV0PcSmSzDxWcaZS0lHGq1Hf91YgXnjA /+YEiPzZbspwhJRc4yjZrMejSwRC68B/lFdP/pVQoTUYnsstn1LpG+jmOI/8XbBf R93EZ8utxjN1VEnSEINXy/+TNGWH5JUYRvEJmH8zjKDwk5iWwHHyUNY+pee6LDx3 oyhjLq2gkFZnpHAPBOTf7B/U9NOmn8Wel+vEpG09ty6W8Sp83MtFxaVSUTlmuhgr FUX9SHCt68poh4OwHKv8pR3CqKrQhQKMkD1IUTKZ+eSFhf9UK/jjsbnN7I85UwMc j4J9R8BLoIsmtnKv2IJlgGRuJRiVaKsCMEHdjrPG7m0NtrrfthlxP0A2e3e2cVBw DsiiMaQwUImh8w0KCteq =XEk6 -----END PGP SIGNATURE----- --Apple-Mail=_781FAB94-7E93-410A-8220-2EE01B13FC61-- From sm@resistor.net Mon Jan 9 16:22:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B9711E80C8 for ; Mon, 9 Jan 2012 16:22:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn78ox7eYcT8 for ; Mon, 9 Jan 2012 16:22:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB10C11E8080 for ; Mon, 9 Jan 2012 16:22:19 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0A0MExq024758 for ; Mon, 9 Jan 2012 16:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326154938; i=@resistor.net; bh=KO/ODfW+FoBse+g7hZapts8osqNcWIZJSlPw74PlN7w=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=3wlQ8RSAjZqM5ruLuWzzDx4HHPICO5dLCnZ1DM/VSMZ9fKtMXsczVBooI4D5dDeQk 62LF5DymWOPh9z2YSe3EB9h4JeB2G0QCqpHJB5Wn8QOiJYTFkgDUDeTaQ0d+crgMku gglOOxEz5ZrBoZqigLKHr/6p++DTVnLnhpJwamCk= Message-Id: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 16:21:42 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:22:29 -0000 Hi Murray, At 10:50 09-01-2012, Murray S. Kucherawy wrote: >interested in hearing something about it. Otherwise, I believe I >should reply to them that the IETF is not currently doing work in >this area so their options include an ISE submission or something >AD-sponsored that goes for Experimental status or suchlike. I don't think that the ISE will not take a draft with such a boilerplate. There is also an IPR disclosure. The draft needs a lot of work. Regards, -sm From msk@cloudmark.com Mon Jan 9 16:30:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403D221F852C for ; Mon, 9 Jan 2012 16:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQCZkofZ1rUu for ; Mon, 9 Jan 2012 16:29:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 759D821F851C for ; Mon, 9 Jan 2012 16:29:59 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 16:29:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 16:29:58 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 9 Jan 2012 16:29:57 -0800 Thread-Topic: [apps-discuss] Spam reporting over IMAP Thread-Index: AczPLfIcGv8m5kO9QGOwyLdfWNjzJQAAJ+wg Message-ID: References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> In-Reply-To: <6.2.5.6.2.20120109155713.0b022fe0@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:30:00 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Monday, January 09, 2012 4:22 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Spam reporting over IMAP >=20 > I don't think that the ISE will not take a draft with such a > boilerplate. There is also an IPR disclosure. The draft needs a lot > of work. There's no doubt it's far from submission-ready and needs some developmemt.= The larger question, I believe, is whether or not this is even the right = path for this kind of technical work to take (is it a reasonable architectu= re, for example), and do we want to work with them on this? -MSK From johnl@iecc.com Mon Jan 9 17:47:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D9521F8494 for ; Mon, 9 Jan 2012 17:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.725 X-Spam-Level: X-Spam-Status: No, score=-104.725 tagged_above=-999 required=5 tests=[AWL=-2.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72qZYGnWQ6yR for ; Mon, 9 Jan 2012 17:47:49 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30321F8487 for ; Mon, 9 Jan 2012 17:47:49 -0800 (PST) Received: (qmail 74657 invoked from network); 10 Jan 2012 01:47:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 01:47:48 -0000 Date: 10 Jan 2012 01:47:26 -0000 Message-ID: <20120110014726.81797.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 01:47:50 -0000 I agree this draft needs a lot of work, but for the purposes of argument, I'm assuming it gets rewritten to be a reasonable spec, removing irrelevant stuff like the speculation about spam aggregation services. This is basically a way to provide a spam button in MUAs that works like the spam button in web mail, for systems that are prepared to handle user spam reports. It's something we need, for reasons that will shortly become apparent. > I'm sure many people would like to see something like SREP, but IMAP > is absolutely the wrong place to put it. IMAP servers store messages. > An IMAP server doesn't decide whether something is spam, and is in no > way capable of doing anything about it. That may be the way your IMAP server works, but it is not the way everyone's IMAP servers work. AOL provides IMAP access to their mail system. Each user has a folder called Spam. Moving a message into the Spam folder is the equivalent of pushing the spam button in web mail. Gmail also provides IMAP access. Their system is a little peculiar because of the way they map message tags to IMAP folders, but there's a folder called Gmail/Spam which works the same way. This is, needless to say, a gross kludge, but until there's some better way to handle spam reporting in IMAP clients, it's what people will do. Don't take my word for it -- sign up for a free account at either or both, and try it out. > SPAM filtering happens further up the delivery chain, usually within > the MDA, or a preceding MTA, ... Really, it's a bad idea to assume that everyone's mail software works the way that yours does. R's, John From lyndon@orthanc.ca Mon Jan 9 17:56:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49B1F0C3C for ; Mon, 9 Jan 2012 17:56:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzsmBxKitq7t for ; Mon, 9 Jan 2012 17:56:24 -0800 (PST) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by ietfa.amsl.com (Postfix) with ESMTP id 920261F0C36 for ; Mon, 9 Jan 2012 17:56:24 -0800 (PST) Received: from pippin.orthanc.ca ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q0A1uNdN089200; Mon, 9 Jan 2012 17:56:23 -0800 (PST) (envelope-from lyndon@orthanc.ca) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_66AA2BEC-67B4-41B7-8F8C-EADC8CBF4017"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Lyndon Nerenberg In-Reply-To: <20120110014726.81797.qmail@joyce.lan> Date: Mon, 9 Jan 2012 17:56:16 -0800 Message-Id: <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> References: <20120110014726.81797.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1251.1) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 01:56:25 -0000 --Apple-Mail=_66AA2BEC-67B4-41B7-8F8C-EADC8CBF4017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-01-09, at 17:47 PM, John Levine wrote: > AOL provides IMAP access to their mail system. Each user has a folder > called Spam. Moving a message into the Spam folder is the equivalent > of pushing the spam button in web mail. No doubt. But only, as you say, in *your* IMAP server. SREP demands a ubiquitous solution. One that will outlive AOL and = Google's missions to destroy IMAP. It's an autonomous service; let's = give it an autonomous protocol. --lyndon --Apple-Mail=_66AA2BEC-67B4-41B7-8F8C-EADC8CBF4017 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPC5rGAAoJEG8PnXiV/JnUy/kQALXMYQyvCsloYsHKpHKF9Dct crcT+V/q/2AtcpAwSQS2erYvBif9OG3mnRsHWsol+tb6HpSWKqB/tiZVyH1OOBje JWyiAOKp2LRFF5OnvscrrETLD+8Y4+JggU2e4f1NWI3wnD4KxLXMlgGgs6r4EZEu FAP9AQZzcrpsSdKqSSdLZd1iIoS7MK5b3385tpJ83S+n5b4uqnkhpM0r3ZTLV43C 1N0wBXb5LWPdPXVEWubX82l5FYbHyQgZiKdxADaX0D0U9ERQVM0xVOmGIX4NyOqu g4uWkCe0uTb05XdhtUxO4uaomcpN4sHfA5ez9xMLTpjOvflgMww4AKMZm9SNy6wo kdCaCBf4RHsAooaHS3+orny7fHQvg5md30AsUIg4cQUPtkf7GMTd+68lxv1eXSq2 3kSkJ+ScD81t79NCg0C28IefjgO5nyCd60mIPfTDwKMguy1zDKv8KdXk/dDtTtQe rwf+sBVftn/u1FDKpaJz0WIjwzIBb+Rlj2Z3lXTjyXD1MyhWjxFYhqvRwpsSraOz m/qlfUu/hpaGn3qmFKv+r4VMp/4DmD5K/TOiCBWpVa+RoyDI0HCn0HVi9vVOZUc6 pHfrKv2bduZy2Hwr0hDWX9kMSBRvAhoR7doFkcTHbYKMa1HaUZWjyWX6GCQQR6LJ olWbYNlK62RxMqLPyy0v =V2/D -----END PGP SIGNATURE----- --Apple-Mail=_66AA2BEC-67B4-41B7-8F8C-EADC8CBF4017-- From sm@resistor.net Mon Jan 9 18:23:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2201F0C3C for ; Mon, 9 Jan 2012 18:23:24 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnwuMxBOV3QF for ; Mon, 9 Jan 2012 18:23:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA1C21F861D for ; Mon, 9 Jan 2012 18:23:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0A2N7En019766; Mon, 9 Jan 2012 18:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326162197; i=@resistor.net; bh=4CvfQI4rb/dp7CbAb3v7f9wPeyHdXhQkkhJMeLX+b48=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=capjYvIZkbNqteLWyMi6+LMynAHnNgqWUGwBnZTmeOX3cfYDHlvvonUZSLtmqURp4 Iby/+RCTff50EQZElsKLZ6yaObK1V0ckroaq0VPPXvgVib3wm6y6zkNcW+OWpxsOgn 3JOOQL+vS1t0R3XKwTzuzOdf2hYny1/JnaXB4RnU= Message-Id: <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 18:22:17 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 02:23:24 -0000 Hi Murray, At 16:29 09-01-2012, Murray S. Kucherawy wrote: >There's no doubt it's far from submission-ready and needs some >developmemt. The larger question, I believe, is whether or not this >is even the right path for this kind of technical work to take (is >it a reasonable architecture, for example), and do we want to work >with them on this? I don't think that IMAP folks would say that it is a reasonable architecture. I would not spend too much time working on an IMAP draft if the author has not understood RFC 3501. John Klensin already commented about the Abstract Section. The draft needs a lot of development. I suggest that the author finds someone to work with him on the draft before asking the IETF to consider it. Regards, -sm From johnl@iecc.com Mon Jan 9 19:49:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2335111E809B for ; Mon, 9 Jan 2012 19:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8C2EgY1Z-zu for ; Mon, 9 Jan 2012 19:49:00 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5682C11E8087 for ; Mon, 9 Jan 2012 19:49:00 -0800 (PST) Received: (qmail 21882 invoked from network); 10 Jan 2012 03:48:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=5579.4f0bb529.k1201; bh=Bap11ZdFygVnwx/O4wa0LI41j6DJlpzoGxqKHu0Xbsk=; b=UdVMSMVL95W+sKjHi7pGOmxVhK7qZiUSE1/YU20w/+tcwlkaA83QPBYpKyy9S7XXYkeq1r5Eb2xYHTQfA79tEwPR85zCYz6SH6buqpiwQNzWoGrB/dDZ2Bczat3XcZIW+coowU+YWwhrM3jJb9scPnzH7U0KqKlSwhCLm8+9hnM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jan 2012 03:48:35 -0000 Date: 9 Jan 2012 22:48:55 -0500 Message-ID: From: "John R. Levine" To: "Lyndon Nerenberg" In-Reply-To: <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> References: <20120110014726.81797.qmail@joyce.lan> <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 03:49:01 -0000 > SREP demands a ubiquitous solution. One that will outlive AOL and > Google's missions to destroy IMAP. It's an autonomous service; let's > give it an autonomous protocol. Oh, I forgot to mention, Yahoo does the same thing but their folder is called Bulk Mail. AOL, Google, and Yahoo probably provide IMAP to more people than all the other IMAP providers in the world combined, so I'd think a standards organization would prefer to try engage with them and try to come up with something better than the existing kludge that's well on its way to becoming an ugly de-facto standard than to call them names. But maybe that's just me. > SREP demands a ubiquitous solution. We argued about this at some length in ASRG, and it's not an autonomous service. You need an authenticated channel back to the mail provider, and a naming convention that the MUA can use to tell the provider what messages it's reporting. If you have those, spam reporting is trivial. Otherwise it's pretty much impossible. Web mail and IMAP are the only environments that do that. (POP doesn't, by the time the user sees a message, the provider has forgotten about it.) So if we provide it in IMAP, we are for all practical purposes done. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From lyndon@orthanc.ca Mon Jan 9 19:57:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F5F21F8526 for ; Mon, 9 Jan 2012 19:57:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAzw9hjMawQs for ; Mon, 9 Jan 2012 19:57:20 -0800 (PST) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by ietfa.amsl.com (Postfix) with ESMTP id 7870321F84FC for ; Mon, 9 Jan 2012 19:57:20 -0800 (PST) Received: from peregrin.orthanc.ca ([96.54.172.165]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q0A3vGxt089625; Mon, 9 Jan 2012 19:57:17 -0800 (PST) (envelope-from lyndon@orthanc.ca) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_7E72A178-CDEB-4B4B-B602-7A81280A61B8"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Lyndon Nerenberg In-Reply-To: Date: Mon, 9 Jan 2012 19:57:14 -0800 Message-Id: References: <20120110014726.81797.qmail@joyce.lan> <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> To: "John R. Levine" X-Mailer: Apple Mail (2.1251.1) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 03:57:21 -0000 --Apple-Mail=_7E72A178-CDEB-4B4B-B602-7A81280A61B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-01-09, at 19:48 PM, John R. Levine wrote: > Oh, I forgot to mention, Yahoo does the same thing but their folder is = called Bulk Mail And Myspace called it?= --Apple-Mail=_7E72A178-CDEB-4B4B-B602-7A81280A61B8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPC7cbAAoJEG8PnXiV/JnUmksQAKe1T+08z7S1ICVsT6VarOnj ygYByMnd5RvhRfyCXe+goTG6g+/xkwgUYpTLOd5mto3tsiGpk0j9sEY8Y427YISl OMpWffeJM5SDbzCWotFaejPv7lEkvKZTJKGdhUKyvXST90aUB6ogW7+uPfKoP7V8 8wH6uupHOQwMMjMSRYm8XGyqpdmS6539R0YZH6xkz6MZbACaSsUmOxZ5f0HywS/J xGS2kDY520yhWyUj6plMB1Bcnh9FnNoRDCyq4YOwTl86tc7uV1Yi/BmYUk4aXhhu FUXT0RCbVmTBzivmf1niJmQJGeDh8weBBEIPYKsOunbk5XtTNR8ARZAKMiDxG31a iBu6evlOTJhFUmnbZApOHV3Pxt8Zfj81ShQaesj8ST7TRmzVAQKTbhY+7PtGjnjU ru3UJsukcctXn+VE84BwktDzu3Git9pYsqY8ng+fS47abWz5nQzKXFVJNGnLkFPq z6gJoShCxiyYt8pLRy1CvsyZZdEcpPKiptyC+TSH1Faan/ko26f2yAJWHmxequdp M4moAP+ICjDzdEZaHTKO1kK9Ny0KcgKr6lWN/nV+cSk+ozZlPkIJZJu3kECGzEon de5ZV4PHB3VBI6gzcAsHToq3suFsuAUBaFEnaQV0C3Vv9TRKrERc/x8Jm150vWSU YBWprjrYD2xoBeTAbHXM =yJR7 -----END PGP SIGNATURE----- --Apple-Mail=_7E72A178-CDEB-4B4B-B602-7A81280A61B8-- From johnl@iecc.com Mon Jan 9 21:21:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CAF11E80DC for ; Mon, 9 Jan 2012 21:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.619 X-Spam-Level: X-Spam-Status: No, score=-104.619 tagged_above=-999 required=5 tests=[AWL=-2.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk1h2cw985ok for ; Mon, 9 Jan 2012 21:21:05 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3763311E80DA for ; Mon, 9 Jan 2012 21:21:05 -0800 (PST) Received: (qmail 70675 invoked from network); 10 Jan 2012 05:21:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 05:21:02 -0000 Date: 10 Jan 2012 05:20:40 -0000 Message-ID: <20120110052040.7850.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 05:21:06 -0000 >Is there any interest among those of us following APPSAWG to do this >kind of work? I can't think of any current working groups where it >might otherwise fit. If we detect interest in this from any of the large IMAP providers (and, I suppose the usual MUA providers, although that's usually doable with an extension), I'd be willing to help cleaning it up into a something that lets an MUA communicate to an IMAP server that the user considers a message to be spam or not, perhaps with a little extra optional info to describe the nature of its spamitude. My IMAP-fu is not fabulous, so it would be nice to have someone with more IMAP background to help. R's, John From evnikita2@gmail.com Mon Jan 9 23:03:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859921F87A8 for ; Mon, 9 Jan 2012 23:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTHI222dfYVg for ; Mon, 9 Jan 2012 23:03:11 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4EBD21F879F for ; Mon, 9 Jan 2012 23:03:10 -0800 (PST) Received: by obcuz6 with SMTP id uz6so5702981obc.31 for ; Mon, 09 Jan 2012 23:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AUIuvEyVLpGPuVLYIdb8JKeAx05bQ9mGAFz0WibmR7Q=; b=getZNJ68nbJ/0YFl7HB9+Me8uRPrJNVAa7gD7zpj2w+Cd18WEL1wjQOm3AgEzgU10u jJvHwmfYag157pKnZplMExuhGuXyMFl37eT/ZZ2DNYU2VF/tUQroQgz1Q4YflxTl1rAh Hg5h7Aq8XnTeeVUf+T7KYcEOn/G5DMb2IclCw= MIME-Version: 1.0 Received: by 10.182.193.41 with SMTP id hl9mr17604590obc.44.1326178990301; Mon, 09 Jan 2012 23:03:10 -0800 (PST) Received: by 10.182.213.71 with HTTP; Mon, 9 Jan 2012 23:03:10 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 09:03:10 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 07:03:12 -0000 Hi Murray, This seems to be an interesting document (as for me). You only have made two mistakes in ABNF block: State =3D "state" queue-state-keyword should be State =3D "state" FWS queue-state-keyword ; defined in [RFC5322] Additionally, this: A transfer agent making use of this extension MAY also include header field comments to provide additional information. doesn't suit ABNF as well. RFC 5321 defined as follows: Stamp =3D From-domain By-domain Opt-info [CFWS] ";" FWS date-time ; where "date-time" is as defined in RFC 5322 [4] ; but the "obs-" forms, especially two-digit ; years, are prohibited in SMTP and MUST NOT be used. and this means that comments should be used after all the clauses, whereas you allow the comment after each 'state' clause. You can fix this by adding : State =3D "state" FWS queue-state-keyword [CFWS] ; , defined in [RFC5322] And, finally, in Section 4.2: Name: The name of the state keyword being defined or updated I would change this to: Name: The name of the state keyword Generally, I support this document either as WG document (should it be adopted by the WG) or Individual submission on IETF stream. All the best, Mykyta Yevstifeyev 2012/1/10 Murray S. Kucherawy : > Hi all, > > > > Over on ietf-smtp, > https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ was > developed late last year.=A0 This is an optional tweak to email Received > fields allowing annotation of entry into special states of mail handling, > such as quarantines or hold-for-moderation MLM actions that would help to > explain large gaps in timestamp sequences. > > > > I=92m looking for a wider audience of reviewers and (hopefully supporters= ). > If this sort of thing seems like a good (or terrible) idea, please do fol= low > up and comment. > > > > How much and what kind of support is evident will guide the choice of wha= t > its next steps are (if any). > > > > Thanks, > > -MSK > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From msk@cloudmark.com Mon Jan 9 23:25:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2321F8623 for ; Mon, 9 Jan 2012 23:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDNofY6iM2uu for ; Mon, 9 Jan 2012 23:25:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 003A621F84F8 for ; Mon, 9 Jan 2012 23:25:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 23:25:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 23:25:32 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 9 Jan 2012 23:25:29 -0800 Thread-Topic: [apps-discuss] draft-kucherawy-received-state Thread-Index: AczPZepDQtjsKVrhQmmZzWnGmN837wAAoQhw 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 Subject: Re: [apps-discuss] draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 07:25:35 -0000 > -----Original Message----- > From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com] > Sent: Monday, January 09, 2012 11:03 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] draft-kucherawy-received-state >=20 > Hi Murray, Hello Mykyta, > This seems to be an interesting document (as for me). You only have > made two mistakes in ABNF block: >=20 > State =3D "state" queue-state-keyword >=20 > should be >=20 > State =3D "state" FWS queue-state-keyword > ; defined in [RFC5322] >=20 > Additionally, this: >=20 > A transfer agent making use of this extension MAY also include header > field comments to provide additional information. >=20 > doesn't suit ABNF as well. RFC 5321 defined as follows: Actually "state" is covered by this, from RFC5322: Additional-Registered-Clauses =3D CFWS Atom FWS String We're defining a new Atom and String in this context. So really we want: State =3D CFWS "state" FWS queue-state-keyword ; FWS and CFWS are defined in [MAIL] ...which matches the trace information clauses defined in RFC5322. I've up= dated it to match this. Thanks, -MSK From evnikita2@gmail.com Mon Jan 9 23:33:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1221F8507 for ; Mon, 9 Jan 2012 23:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHJl6mmxUDpm for ; Mon, 9 Jan 2012 23:33:37 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6404821F8504 for ; Mon, 9 Jan 2012 23:33:37 -0800 (PST) Received: by obcuz6 with SMTP id uz6so5734871obc.31 for ; Mon, 09 Jan 2012 23:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xl39nGVsDBCUJ/SjOamOXE1f7frpYk0+NnyO67vNqUc=; b=v+VjRWjjS+3sglECP4gWFFHdUnWGaIYlYJFu5omExw2e+fro9GofA8xdMKYf1Vxr2Y GXAhMx0p6NHY3e5Wn97f+0OvevFQpVKvUC8koTnxYYH8YvmzfvcOW+Pbir6IFCp5VERD QpeDbaDU5DO7TrTiJkbtGrWNEv4vK9gXr+7b0= MIME-Version: 1.0 Received: by 10.182.47.100 with SMTP id c4mr17674798obn.54.1326180817034; Mon, 09 Jan 2012 23:33:37 -0800 (PST) Received: by 10.182.213.71 with HTTP; Mon, 9 Jan 2012 23:33:36 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 09:33:36 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 07:33:38 -0000 2012/1/10 Murray S. Kucherawy : >> -----Original Message----- >> From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com] >> Sent: Monday, January 09, 2012 11:03 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] draft-kucherawy-received-state >> >> Hi Murray, > > Hello Mykyta, > >> This seems to be an interesting document (as for me). =A0You only have >> made two mistakes in ABNF block: >> >> =A0 =A0 =A0 State =3D "state" queue-state-keyword >> >> should be >> >> =A0 =A0 =A0 State =3D "state" FWS queue-state-keyword >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; defined in [RFC5322] >> >> Additionally, this: >> >> =A0 =A0A transfer agent making use of this extension MAY also include he= ader >> =A0 =A0field comments to provide additional information. >> >> doesn't suit ABNF as well. =A0RFC 5321 defined as follows: > > Actually "state" is covered by this, from RFC5322: > > =A0 =A0 =A0 =A0Additional-Registered-Clauses =A0=3D CFWS Atom FWS String > > We're defining a new Atom and String in this context. =A0So really we wan= t: > > =A0 =A0 =A0 =A0State =3D CFWS "state" FWS queue-state-keyword > =A0 =A0 =A0 =A0 =A0 =A0; FWS and CFWS are defined in [MAIL] > > ...which matches the trace information clauses defined in RFC5322. =A0I'v= e updated it to match this. Yes, this is better. And with respect to allowing comments after separate 'state' clauses? Mykyta > > Thanks, > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From vesely@tana.it Tue Jan 10 07:29:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F374521F848B for ; Tue, 10 Jan 2012 07:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an3kj+vCWaF2 for ; Tue, 10 Jan 2012 07:29:34 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56C21F8486 for ; Tue, 10 Jan 2012 07:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326209372; bh=gEXPPpN2oyAzz1jLQiMeG7NcWDBympsHeJocT+f6QXc=; l=2184; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WLiKJR/s9FXW4+QEM6GZACkcqWbUR+gMT9E/x8riveubk5CAwt5gV9Y3rNQEG3gTz Ys62C2kGmYF8yKaz/m31wdqbjkZOAL7PnpdkiUwcHCxnee7+30iUQGk6VqKqgTPrcW baShF19nXGtr9AvGG00pqbtcH76yUJggA2wEaabU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 10 Jan 2012 16:29:32 +0100 id 00000000005DC035.000000004F0C595C.00000DBE Message-ID: <4F0C595B.2020909@tana.it> Date: Tue, 10 Jan 2012 16:29:31 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> <6.2.5.6.2.20120107114742.0ba21628@resistor.net> <4F0AC75E.3030709@tana.it> <6.2.5.6.2.20120109133139.08d63218@resistor.net> In-Reply-To: <6.2.5.6.2.20120109133139.08d63218@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:29:36 -0000 On 09/Jan/12 23:02, S Moonesamy wrote: > At 02:54 09-01-2012, Alessandro Vesely wrote: >> If it doesn't have to be a real DNS name, the reason to treat >> ".invalid" as a special case becomes rather obscure. > > It's to avoid localhost.com, etc. Since you said one doesn't have to be the registrant of localhost.com in order to use it as a list-id, it's still not clear. Does the spec mandate that list-id-namespace MUST be an existing domain name? >> Since you are somewhat diluting the spec, you might as well have >> merged it with 2369bis. Why not? > > 2369bis is more about list commands whereas 2919bis is about list > identifiers. Nevertheless, BCP 167 proposes List-Post as a candidate domain identifier. Accordingly, DKIM driven heuristics should use that field rather than List-Id. > Keeping the them as two separate documents makes it easier to > compare changes. It is better to rely on the purposely provided appendixes. By keeping them separate, you turn this state of affairs into a tradition. I mean that more stiffness will be needed to merge them in the future, assuming they will happen to be rewritten simultaneously again. > Some parts of DNS are about policy. > > "Several people expressed considerable scepticism about the > chances of success in response to domain name registry issues." Yeah, it is curious that we consider number databases more solid in that respect. (Is it because we only have five?) To ease the transition to IPv6 we should use names instead. For DNS, one can certainly blame the ADMD for any bad settings, so DNS might be considered more consistent than registries. One side effect of merging 2919 into 2369 is to corroborate the idea that List-Id is tailored for discussion lists. You may have alternative ideas to express the same concept without merging. In any case, since the possibility to use it as a policy element of bulk commercial messaging is not fully supported, it may make sense to tell it. > P.S. As all messages from this mailing list are DKIM signed, you can > use some heuristics to detect misuse of the list-id. BTW, isn't it worth to reference BCP 167? From fanf2@hermes.cam.ac.uk Tue Jan 10 08:30:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D2121F8569 for ; Tue, 10 Jan 2012 08:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWLyAiOwYIQB for ; Tue, 10 Jan 2012 08:30:37 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1B21F8533 for ; Tue, 10 Jan 2012 08:30:37 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48136) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Rkeaf-0001FX-Ey (Exim 4.72) (return-path ); Tue, 10 Jan 2012 16:30:25 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rkeaf-0008WB-AW (Exim 4.67) (return-path ); Tue, 10 Jan 2012 16:30:25 +0000 Date: Tue, 10 Jan 2012 16:30:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Lyndon Nerenberg In-Reply-To: <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> Message-ID: References: <20120110014726.81797.qmail@joyce.lan> <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:30:38 -0000 I agree with John Levine that this is heading in the right direction even though it neads a lot of tidying up. Lyndon Nerenberg wrote: > > SREP demands a ubiquitous solution. One that will outlive AOL and > Google's missions to destroy IMAP. It's an autonomous service; let's > give it an autonomous protocol. Why do you say this is an autonomous service? All the existing user-oriented spam feedback systems are are an integrated part of the user's email service provider's offering. Users really don't want to have to type in yet another hostname and username and password just to provide feedback to their provider's spam filters. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire: Westerly or southwesterly, veering northwesterly for a time later, 5 to 7, occasionally gale 8 in Viking. Rough or very rough, occasionally high later in north. Rain then wintry showers. Moderate or good, occasionally poor later. From sm@elandsys.com Tue Jan 10 09:29:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B321F84E7 for ; Tue, 10 Jan 2012 09:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7t-DEwJ1tPq for ; Tue, 10 Jan 2012 09:29:37 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7521F8495 for ; Tue, 10 Jan 2012 09:29:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.250]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0AHTEx8020196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 09:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326216575; i=@elandsys.com; bh=ROdREfGssGUnhugD3baCkja8EWrcJTlfgWlec0won6c=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0bFkuPyF6QGwE9PTxWLtECLEM4SgLRreIA5L67ObkBjTjJDrX53olk8ybE+P9pl/T cm2ETVNj3iB5YqRG03ZEfHwjJ6EnxwNEVP65RfE/mtsw2mo4MddlUknpU1WO7CvQFW EaP9VqFktoc5Ofgf0wsgRA+9STYp9BHWYP4u0NFM= Message-Id: <6.2.5.6.2.20120110084205.0cee1da8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2012 09:12:30 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <4F0C595B.2020909@tana.it> References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com> <4F06EEFD.1060707@tana.it> <6.2.5.6.2.20120106140451.09c30c18@resistor.net> <4F0896E2.7040303@tana.it> <6.2.5.6.2.20120107114742.0ba21628@resistor.net> <4F0AC75E.3030709@tana.it> <6.2.5.6.2.20120109133139.08d63218@resistor.net> <4F0C595B.2020909@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:29:41 -0000 At 07:29 10-01-2012, Alessandro Vesely wrote: >Since you said one doesn't have to be the registrant of localhost.com >in order to use it as a list-id, it's still not clear. Does the spec >mandate that list-id-namespace MUST be an existing domain name? No, but it can still discuss about how to avoid namespace collisions. >Nevertheless, BCP 167 proposes List-Post as a candidate domain >identifier. Accordingly, DKIM driven heuristics should use that field >rather than List-Id. That BCP is about DKIM. >By keeping them separate, you turn this state of affairs into a >tradition. I mean that more stiffness will be needed to merge them in >the future, assuming they will happen to be rewritten simultaneously >again. Ok. >Yeah, it is curious that we consider number databases more solid in >that respect. (Is it because we only have five?) To ease the Sorry, I cannot comment about this. >One side effect of merging 2919 into 2369 is to corroborate the idea >that List-Id is tailored for discussion lists. You may have >alternative ideas to express the same concept without merging. In any >case, since the possibility to use it as a policy element of bulk >commercial messaging is not fully supported, it may make sense to tell it. The drafts are about interoperability. If commercial messaging causes interoperability issues, it can be discussed in the draft. >BTW, isn't it worth to reference BCP 167? No. Thanks for the comments. Regards, S. Moonesamy From msk@cloudmark.com Tue Jan 10 10:06:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A561821F87CF for ; Tue, 10 Jan 2012 10:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Kt3MxBF+Wv for ; Tue, 10 Jan 2012 10:06:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEE521F8795 for ; Tue, 10 Jan 2012 10:06:27 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 10:06:19 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 10:06:26 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 10 Jan 2012 10:06:25 -0800 Thread-Topic: [apps-discuss] draft-kucherawy-received-state Thread-Index: AczPaiskpH9CYn1oQlOHSav5APxy9gAWEqWw 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 Subject: Re: [apps-discuss] draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:06:30 -0000 > -----Original Message----- > From: Mykyta Yevstifeyev [mailto:evnikita2@gmail.com] > Sent: Monday, January 09, 2012 11:34 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] draft-kucherawy-received-state >=20 > Yes, this is better. And with respect to allowing comments after > separate 'state' clauses? The [CFWS] at the end of the ABNF for "Stamp" (RFC5321, Section 4.4) allows= this. -MSK From alexey.melnikov@isode.com Tue Jan 10 11:07:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498CA21F868A for ; Tue, 10 Jan 2012 11:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp3LNpw9hltk for ; Tue, 10 Jan 2012 11:07:48 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 589F821F8655 for ; Tue, 10 Jan 2012 11:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326222467; d=isode.com; s=selector; i=@isode.com; bh=jZG9maQFGpttr/O/XQVwsfyvhlSfbWxD5ZWEJUJMxI8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kl2ls6rjVShmpjLpKcu3rvxlGtcuWEpLlLk/fabrVeA/8+bMrvDT/4yWiIv5uLXkbk6Hds OXOYy1geahg4lq1qGc21gr+X80ee+Cj+Ua+LULACykCG2UI53jULkDbdT3YEUO4zyZ/7Qv tYp58S3xpHAdcoUyRvgwITixjGtRVrI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Jan 2012 19:07:47 +0000 Message-ID: <4F0C8C94.9090906@isode.com> Date: Tue, 10 Jan 2012 19:08:04 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: John Levine References: <20120109210557.4950.qmail@joyce.lan> In-Reply-To: <20120109210557.4950.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:07:51 -0000 On 09/01/2012 21:05, John Levine wrote: >> Is there any interest among those of us following APPSAWG to do this >> kind of work? I can't think of any current working groups where it >> might otherwise fit. > I think it's a fine idea, but I wouldn't want to invest time in this > proposal unless there were some indication that large IMAP operators > were interested in doing something with it. > > Do we know anyone at AOL, Yahoo, or Gmail to ask? I can ask some people at Google. > I can probably ask > Tucows. > From vesely@tana.it Tue Jan 10 11:20:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B844421F881C for ; Tue, 10 Jan 2012 11:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.645 X-Spam-Level: X-Spam-Status: No, score=-4.645 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2pf0+QP3FOk for ; Tue, 10 Jan 2012 11:20:33 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DA81221F881A for ; Tue, 10 Jan 2012 11:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326223230; bh=LmIKLexJ0EwihTR39AXJIOGKO/ocqZd8Uo5a6wNDib8=; l=944; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=hC5Hwx9QyfaXsChk8F4b2XgTkMYikCL8YY2ZSdiGTFyedjFV3I0o9hpLOB0RJSYa3 X/3hHVs3UKu6lXnIhu4eMdHukrb+yZXbFJ63GLKmk+FCs5egenH6r4bJjlwnohGlkx oS8/OcX25Iw9pm/Te328cxCCEJwXIWY9zYTShZdI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 10 Jan 2012 20:20:30 +0100 id 00000000005DC035.000000004F0C8F7E.000044E2 Message-ID: <4F0C8F7E.4070809@tana.it> Date: Tue, 10 Jan 2012 20:20:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> In-Reply-To: <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:20:33 -0000 On 10/Jan/12 03:22, SM wrote: > > I don't think that IMAP folks would say that it is a reasonable > architecture. I would not spend too much time working on an IMAP > draft if the author has not understood RFC 3501. John Klensin already > commented about the Abstract Section. The draft needs a lot of > development. I suggest that the author finds someone to work with him > on the draft before asking the IETF to consider it. I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00 with some of the cleanup John mentioned. I'm unable to understand some other comments he made, e.g. about sieve, but I hope this version is easier to read anyway. I've made some arbitrary changes, including IPR, as explained in the appendix. If that's not correct, please delete my post. The doc is not to be used directly anyway: Zoltan can reuse any xml parts that he likes and repost the result as version -01 of its draft. hth From alexey.melnikov@isode.com Tue Jan 10 11:31:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FD621F8723 for ; Tue, 10 Jan 2012 11:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nl5DFua3wK9 for ; Tue, 10 Jan 2012 11:31:30 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BA57C21F86FF for ; Tue, 10 Jan 2012 11:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326223888; d=isode.com; s=selector; i=@isode.com; bh=SByEQ55Ur7HkSpYJpngBYTqFfM8+hb7nJnyqAG/Vsds=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uwzn5u0iUGLQvvm3NJPmNEWrfF2yZZY0/wXyspXKugX2FGLGLQDgLNlNxRK40ZtU4Lk2m6 I1E5LIGdzOUf7oA76Fsx0cYqFBvqEV3Qx6RbAyrc90D99qSIhOr8lx0GkSxTlRZBqK3M3N yfmbn0wUBW+rVQUjf2O4yyxnn4zALUE=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Jan 2012 19:31:28 +0000 Message-ID: <4F0C921C.8010402@isode.com> Date: Tue, 10 Jan 2012 19:31:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:31:30 -0000 On 09/01/2012 23:48, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: John C Klensin [mailto:john-ietf@jck.com] >> Sent: Monday, January 09, 2012 3:38 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Spam reporting over IMAP >> >> Conclusion: >> >> Not ready from prime time. Not even ready for a careful and >> comprehensive review. >> >> You asked. > I did, and thanks for that. > > I think at this point perhaps a higher-level question is in order: Are we (either IETF in general, or APPSAWG specifically) interested in or willing to put time into developing this in conjunction with OMA? Would this be something ultimately beneficial to have, and have it come from us? > > I suppose I'm also concerned with the idea of an external SDO, on getting a "no" from us, deciding they want to do this anyway so they publish their own (unsanctioned, of course) IMAP extension only to have it see some level of ubiquity as a result. Indeed it may be possible that this is coming to us only because some OMA member organizations have already developed and are deploying this, at least experimentally. There's friction between geopriv and OMA's LOC WG of this nature already which I'd just as soon resolve sooner rather than later somehow. As an individual participant: I don't think this is yet deployed, but there is a need in something like that and yes, there is a risk that OMA will do the job if IETF says "no", but does so badly. (Not a strong argument to do anything, but if we (IETF) want to help, I think we should.) I am happy to work on something in this space. But I am not going to do that if nobody else is interested. (I don't have an opinion yet on whether this belongs to APPSAWG, but I am happy to help out either way.) From lyndon@orthanc.ca Tue Jan 10 11:57:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1A121F8821 for ; Tue, 10 Jan 2012 11:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBrbBnwvsRNM for ; Tue, 10 Jan 2012 11:57:12 -0800 (PST) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9921F881F for ; Tue, 10 Jan 2012 11:57:12 -0800 (PST) Received: from [2604:8800:137::21c:b3ff:feb5:20cf] ([IPv6:2604:8800:137:0:21c:b3ff:feb5:20cf]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q0AJuufX075943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:57:07 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Tue, 10 Jan 2012 11:56:55 -0800 (PST) From: Lyndon Nerenberg To: Tony Finch In-Reply-To: Message-ID: References: <20120110014726.81797.qmail@joyce.lan> <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:57:13 -0000 > Why do you say this is an autonomous service? All the existing > user-oriented spam feedback systems are are an integrated part of the > user's email service provider's offering. Users really don't want to have > to type in yet another hostname and username and password just to provide > feedback to their provider's spam filters. I agree it's part of an integrated system, but what I'm trying to get at is that it's a standalone component within the whole. While the service presents itself as a part of the MUA, it's not part of the message store itself (any more than the MUA's SMTP client functionlity is). As for configuration, I'm reasonably confident this can be managed with SRV records, and would expect many implementations would share the same authentication credentials with the message store, so it should be possible to roll this out in many cases with no extra configuration required by the end user. --lyndon From johnl@iecc.com Tue Jan 10 12:35:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A55821F854E for ; Tue, 10 Jan 2012 12:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o92op4cAu5go for ; Tue, 10 Jan 2012 12:35:03 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFDA21F8715 for ; Tue, 10 Jan 2012 12:35:02 -0800 (PST) Received: (qmail 7026 invoked from network); 10 Jan 2012 20:34:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1b71.4f0ca0f0.k1201; bh=NxqARVaCpupEkEq84LI3S32YULcpGfXJeLoCFwhAE7Q=; b=HIrAiO7e5rHzLmQ01BPory4b1LNaijYi7Nr15h//wLfaTS56iD7esGAw6qGJiO4m1fEPs55JX0jGynrrNpQUoC/svdSv/rFZ19hsa/KrbvFQ28fKoRdOZ8t2gQdHmdZGp9MISb5yFFLx+WEwDHHHSPmnBh0EV3NOMXgO4ViN5vk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jan 2012 20:34:34 -0000 Date: 10 Jan 2012 15:34:55 -0500 Message-ID: From: "John R. Levine" To: "Lyndon Nerenberg" In-Reply-To: References: <20120110014726.81797.qmail@joyce.lan> <6D355995-85F3-4209-AED6-C6BD85D3CC8B@orthanc.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:35:04 -0000 > that it's a standalone component within the whole. While the service > presents itself as a part of the MUA, it's not part of the message store > itself (any more than the MUA's SMTP client functionlity is). Sorry, that's just plain wrong. Look at any web mail. The spam button identifies a message in the mailbox as being spam or not-spam. If the spam button isn't part of the message store, neither is marking a message as already read. > As for configuration, I'm reasonably confident this can be managed with > SRV records, ... We debated this at length in ASRG. Your confidence appears to be misplaced. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From sm@resistor.net Tue Jan 10 13:07:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6371F0C3E for ; Tue, 10 Jan 2012 13:07:51 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZdSQJihnqZu for ; Tue, 10 Jan 2012 13:07:48 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02061F0C38 for ; Tue, 10 Jan 2012 13:07:48 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0AL7g0p016655 for ; Tue, 10 Jan 2012 13:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326229667; i=@resistor.net; bh=AV5fo6S22s0wCvJjgnDy/nOxaroqo6aWQSuPZeH0Rf4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VeqfjW0N42L2ilGWDTkE0Q6SxZK7capJK3+okNPeRWhklDHQrD30t0Wn9sp6V0b8N 1S6rCG1P/1M/Kldqlw6hEjEZ2CBiCqn+bUfZOHxxFUs81PlND7JrUb44hZjaxD7cV8 /RlYPkZ2ANDkCCrNdKtw8l6fnj/KES7C6SXU5U50= Message-Id: <6.2.5.6.2.20120110124010.0968e868@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2012 12:57:04 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: <4F0C8F7E.4070809@tana.it> References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> <4F0C8F7E.4070809@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:07:51 -0000 At 11:20 10-01-2012, Alessandro Vesely wrote: >I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00 with In my opinion, this is not a good idea. >I've made some arbitrary changes, including IPR, as explained in the >appendix. If that's not correct, please delete my post. The doc is >not to be used directly anyway: Zoltan can reuse any xml parts that he >likes and repost the result as version -01 of its draft Zoltan Ordogh and Alessandro Vesely are listed as the author/editor of draft-ordogh-spam-reporting-using-imap-kleansed-00. Are they stating on behalf of Research In Motion Limited that IPR disclosure #1609 is not applicable for draft-ordogh-spam-reporting-using-imap-kleansed-00? Regards, -sm From glenn.parsons@ericsson.com Tue Jan 10 13:11:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA81421F85FC; Tue, 10 Jan 2012 13:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.343 X-Spam-Level: X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZN9E96-ApbE; Tue, 10 Jan 2012 13:10:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45221F85F4; Tue, 10 Jan 2012 13:10:54 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0ALAbow017097; Tue, 10 Jan 2012 15:10:40 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.96]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 10 Jan 2012 16:10:31 -0500 From: Glenn Parsons To: "apps-discuss@ietf.org" , "draft-melnikov-smtp-priority.all@tools.ietf.org" Date: Tue, 10 Jan 2012 16:10:30 -0500 Thread-Topic: Review of draft-melnikov-smtp-priority-04 Thread-Index: AczP3Eif5ovw7p/HQ361wftFZGD5/A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_" MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:11:03 -0000 --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_ Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_" --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-melnikov-smtp-priority-04 Title: Simple Mail Transfer Protocol extension for Message Priorities Reviewer: Glenn Parsons Review Date: January 10, 2012 Summary: This draft is not ready for publication as a Proposed Standard and should b= e revised before publication Major Issues: 3. in item #7 I presume this should be LMTP, but my concern is that it say= s this is being defined for LMTP. Since LMTP is informational, I don't thi= nk that is appropriate. Instead, I would suggest that it is defined for Me= ssage Submission and as a result may also be used for LMTP. I would prefe= r this to be noted in an Appendix (along with the LMTP advice in section 7)= -- but if you would prefer it to remain in the main body, it needs to be r= eworded. In either case, I would move LMTP to the informative references. 3. the too long example in 3.1 is apparently justified by item #6 here ...= but you can't have a line longer than 72 chars in an RFC... but more impor= tantly, how do you guarantee that this does not accidentally blow something= up. This is a HUGE change that is mentioned in passing without justificat= ion. This seems like a large hurdle for an implementation to be able to ad= d support for this. The use for this appears to be to fit in message size = parameters for each priority (and I presume the message size is in bytes as= it does not say). So why not use Kb instead of bytes? Or render the numb= ers in hex? Or split it over two lines? I think any of these would be bet= ter than increasing the line length. 5. The priority level definition is not clear. There are 200 possible valu= es. But there MUST be at least 6 supported. OK that seems like overkill -= - why can't it be from -9 to 9 then? Anyway, is that 6 distinct numbers, 6= distinct numbers from the range shown, or any number for the range shown? = Further I would suggest that a default value should be specified for thes= e 6 levels and the default mapping ranges -- all in a table. 6 & 8. You need to pick something and be consistent. I would suggest it is= not necessary for them to be the same. So the EHLO one could be short "PR= I" and the header long "Message Transfer Priority". In any case, the termi= nology then needs alignment throughout the document. A definition of the Priority message header field is missing. It should be= after section 3. Minor Issues: Title: I would change "Message Priorities " to "Message Transfer Priority" 6. The units for "message size" need to be indicated at some point in the d= ocument, at least in the syntax of section 6. 3. I would suggest to replace "The following service extension is defined:"= with "The Priorty SMTP service extension is defined as follows:" 5.1.x I am somewhat concerned about informative implementation details -- I= presume that is why this is informative? Or is it because this is not exh= austive? In any case, I think this should be in the appendix. 6. It is confusing to have both specifications for the ESMTP and Header fie= ld in the same place. I would suggest separate appropriatley titled sub-s= ections of section 6 7. I would suggest adding an example fo the message header field in this c= lause. 9. What are the "anchor" placeholders for? 9. Presumably the TBD items need to be filled in... Nits: 3.1 the example is too long ** There is 1 instance of too long lines in the document, the longest one b= eing 12 characters in excess of 72. ...but I could not find this one: =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in th= e document. GLENN PARSONS Standards Advisor Ericsson Canada 3500 Carling Avenue Ottawa, ON K2H 8E9, Canada Phone +1 613 667 1569 Mobile +1 613 796 9407 glenn.parsons@ericsson.com www.ericsson.com --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been selected a= s the Applications Area Directorate reviewer for this draft (for background= on appsdir, please see http://trac.t= ools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ).
Please resolve these c= omments along with any other Last Call comments you may receive. Please wai= t for direction from your document shepherd or AD before posting a new vers= ion of the draft.
Document: draft-melnikov-smtp-priority-04
Title: Simple Mail Transfer Protocol extension for Message Prioritie= s
Reviewer: Glenn Parsons
Review Date:  January 10, 2012
Summary:
This draft is not read= y for publication as a Proposed Standard and should be revised before publi= cation
Major Issues:
3.  in item #7 I = presume this should be LMTP, but my concern is that it says this is being d= efined for LMTP.  Since LMTP is informational, I don't think that is a= ppropriate.  Instead, I would suggest that it is defined for Message Submission and as a result may also be used for LMTP= .   I would prefer this to be noted in an Appendix (along with th= e LMTP advice in section 7) -- but if you would prefer it to remain in the = main body, it needs to be reworded.  In either case, I would move LMTP to the informative references.
3.  the too long = example in 3.1 is apparently justified by item #6 here … but you can'= t have a line longer than 72 chars in an RFC… but more importantly, h= ow do you guarantee that this does not accidentally blow something up.  This is a HUGE change that is mentioned in passing= without justification.  This seems like a large hurdle for an impleme= ntation to be able to add support for this.  The use for this appears = to be to fit in message size parameters for each priority (and I presume the message size is in bytes as it does not say).&n= bsp; So why not use Kb instead of bytes?  Or render the numbers in hex= ?  Or split it over two lines?  I think any of these would be bet= ter than increasing the line length.
5. The priority level = definition is not clear.  There are 200 possible values.  But the= re MUST be at least 6 supported.  OK that seems like overkill -- why c= an't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number fo= r the range shown?  Further I would  suggest that a default value= should be specified for these 6 levels and the default mapping ranges -- a= ll in a table.
6 & 8. You need to= pick something and be consistent.  I would suggest it is not necessar= y for them to be the same.  So the EHLO one could be short "PRI&q= uot; and the header long "Message Transfer Priority".  In any case, the terminology then needs alignment throughout the document.
A definition of the Pr= iority message header field is missing.  It should be after section 3.=
 
Minor Issues:
Title:  I would c= hange "Message Priorities " to "Message Transfer Priority&qu= ot;
6. The units for "= ;message size" need to be indicated at some point in the document, at = least in the syntax of section 6.
3. I would suggest to = replace "The following service extension is defined:" with "= The Priorty SMTP service extension is defined as follows:"
5.1.x I am somewhat co= ncerned about informative implementation details -- I presume that is why t= his is informative?  Or is it because this is not exhaustive?  In= any case, I think this should be in the appendix.
6. It is confusing to = have both specifications for the ESMTP and Header field in the same place.&= nbsp;  I would suggest separate appropriatley titled sub-sections of s= ection 6
7.  I would sugge= st adding an example fo the message header field in this clause.
9.  What are the = "anchor" placeholders for?
9. Presumably the TBD = items need to be filled in...
 
Nits: 
 
3.1 the example is too lon= g
** There is 1 instance= of too long lines in the document, the longest one being 12 characters in = excess of 72.
…but I could not= find this one:
=3D=3D There are 1 ins= tance of lines with non-RFC2606-compliant FQDNs in the document.
 
 



GLENN PARSONS <= /b>
Standards Advis= or =

Ericsson Canada
3500 Carling Avenue
Ottawa, ON K2H 8E9, Canada
Phone +1 613 667 1569
Mobile +1 613 796 9407
glenn.parsons@ericsson.com
www.ericsson.com




 
 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_-- --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Tue, 10 Jan 2012 21:10:31 GMT"; modification-date="Tue, 10 Jan 2012 21:10:31 GMT" Content-ID: <881a37c8-359f-426b-98c1-e01a66d0bb63> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 2.jpg" Content-Description: Picture (Device Independent Bitmap) 2.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 2.jpg"; creation-date="Tue, 10 Jan 2012 21:10:31 GMT"; modification-date="Tue, 10 Jan 2012 21:10:31 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2EUSAACMS0714e_-- From sm@elandsys.com Tue Jan 10 14:41:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE27521F8670 for ; Tue, 10 Jan 2012 14:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Y11He6S3sw for ; Tue, 10 Jan 2012 14:41:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C340F21F85F4 for ; Tue, 10 Jan 2012 14:41:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.250]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0AMf6rM010030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 14:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326235278; i=@elandsys.com; bh=jHYihJ7D31ESAW2oyTkob5dHz8yZnNKvb7i104rF3/Q=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=IWSbBxsnTQDw69zbubTG8joDp6abSlK4KKQ8NUsy7mV6TjYerizxOKhsKxhEf31ax DzyEKCIRAcPGTHYgNyGu5busl66+bivAwqIGvqgRtmBiYrfz5STSaO8x+AD0oEoy0H sGRRv9L4CSe0lLZQ6KQ2R4hDFecA5JT1bTSQqINg= Message-Id: <6.2.5.6.2.20120110143727.0e131250@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2012 14:40:54 -0800 To: apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Incorrect email address in last batch of assignments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 22:41:21 -0000 Hello, I apologize for providing an incorrect email in the last batch of assignments. Please use addresses such as: draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org instead of: draft-ietf-v6ops-ipv6-discard-prefix-02.all@tools.ietf.org as the email alias will not work when the version number is included after the name of the draft. Best regards, -sm From sm@elandsys.com Tue Jan 10 15:32:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5B21F85F7; Tue, 10 Jan 2012 15:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6epIoaTyDn3z; Tue, 10 Jan 2012 15:32:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9721F85EF; Tue, 10 Jan 2012 15:32:17 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.250]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0ANVtpi022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 15:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326238330; i=@elandsys.com; bh=6vJmhyd2FaYH9aGVl89UeFza84YYmh1dWsskElhf+dA=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=xJKn92x08w5yBTfKtZ0LWqL01UsYCLkm3e7bBpNSty+W85m3DTANh9H7NVilN2tbR 7FbUCjVPEPzu6OvI5AT7LnVLw3Fa0h7FMuLog8eov512MFtzGtfwhQ5l3hoGXDDh0f LsFHKGNZNgKQDfbxYx9LHorjdjfZCllCX3qbMOHs= Message-Id: <6.2.5.6.2.20120110143618.09180b88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2012 15:31:03 -0800 To: apps-discuss@ietf.org, draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-v6ops-ipv6-discard-prefix X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 23:32:27 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). 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-v6ops-ipv6-discard-prefix Title: A Discard Prefix for IPv6 Reviewer: S. Moonesamy Review Date: January 10, 2012 Summary: This draft is ready for publication as an Informational RFC. Major issues: None. Minor issues: None. Nits: In the Introduction Section: "This document updates [RFC5156]." It is not clear what is being updated as RFC 5156 is a compilation of special IPv6 addresses defined in other RFCs. Regards, S. Moonesamy From vesely@tana.it Wed Jan 11 01:34:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE96121F8539 for ; Wed, 11 Jan 2012 01:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRa+dZHQN+Kf for ; Wed, 11 Jan 2012 01:34:33 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C57B321F8537 for ; Wed, 11 Jan 2012 01:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326274471; bh=mmRtukEpiv0mCA2kxneZbyxxcuaGyO5fEFz2Glern3U=; l=1752; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=e6ZByGqlhae6rNWSa8YCbvhvbDow1wID5c92KY0SJiIA2QyMPpjor6/AR7WB8UEcS fhwy/PcRmOvYnPY/VRkVkFsks7UCCdn3Pz+9P7dRmfhgrLi0aJYxJ/jbDkzUFukLYk oyowWq4tBCTxx8Xxl6aRc/gmwn6D2aRHKKL/j598= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 11 Jan 2012 10:34:30 +0100 id 00000000005DC044.000000004F0D57A6.00000510 Message-ID: <4F0D57A6.70508@tana.it> Date: Wed, 11 Jan 2012 10:34:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, "Jon M. Jurgovan" References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> <4F0C8F7E.4070809@tana.it> <6.2.5.6.2.20120110124010.0968e868@resistor.net> In-Reply-To: <6.2.5.6.2.20120110124010.0968e868@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Sarah Guichard Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 09:34:33 -0000 On 10/Jan/12 21:57, SM wrote: > At 11:20 10-01-2012, Alessandro Vesely wrote: >> I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00 > > In my opinion, this is not a good idea. Agreed, but after a short mumbling I thought this attempt at least wouldn't be harmful. I have the (hopefully wrong) feeling that the bureaucratically correct path would take decades before a "Spam" button can be enjoyed on mobile and desktop IMAP devices alike. A simple and unencumbered IMAP command can be standardized and implemented rather quickly, and satisfactorily for all involved parties --except spammers, maybe. >> I've made some arbitrary changes, including IPR, as explained in the >> appendix. If that's not correct, please delete my post. The doc is >> not to be used directly anyway: Zoltan can reuse any xml parts that he >> likes and repost the result as version -01 of its draft > > Zoltan Ordogh and Alessandro Vesely are listed as the author/editor of > draft-ordogh-spam-reporting-using-imap-kleansed-00. Are they stating > on behalf of Research In Motion Limited that IPR disclosure #1609 is > not applicable for draft-ordogh-spam-reporting-using-imap-kleansed-00? Not only I cannot speak for RIM, but I have never actually seen that patent application. I'm looking forward for a RIM's statement that either confirms or denies that that patent does not apply to a reduced version like the one I posted. I'm confident that my post can be deleted promptly in case RIM gives a negative response. The IPR is filed here: https://datatracker.ietf.org/ipr/1609/ The kleansed version is here: http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap-kleansed/ Sincerely, Alessandro Vesely From alexey.melnikov@isode.com Wed Jan 11 04:48:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0821F8667; Wed, 11 Jan 2012 04:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJJ-A+5WIEOg; Wed, 11 Jan 2012 04:48:16 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0387A21F864A; Wed, 11 Jan 2012 04:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326286093; d=isode.com; s=selector; i=@isode.com; bh=fd9d9+FfPlg99OnnWMDpq/dlEW6ny+gqS4EFYatjVDI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=E81nlLmJnCPxYIqU1U7DMD840Z0OPFzlhOXYMReSOZAp9h7RYrzlCCAdSE25KEFdwtQbkt PUUCX4wDwTyC8fcw6gI2HI9lbqqVxeLMLoFPh/ree3BWn0rcI8E0F0W9XVZKbAvuZ/JsgQ m8SmlrVXi1fMLiHqpvIN93dEMYTYoNI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 11 Jan 2012 12:48:13 +0000 Message-ID: <4F0D8520.1080206@isode.com> Date: Wed, 11 Jan 2012 12:48:32 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Glenn Parsons References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000203060407060504080107" Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 12:48:19 -0000 This is a multi-part message in MIME format. --------------000203060407060504080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Glenn, Thank you for your review. On 10/01/2012 21:10, Glenn Parsons wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > 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-melnikov-smtp-priority-04 > Title: Simple Mail Transfer Protocol extension for Message Priorities > Reviewer: Glenn Parsons > Review Date: January 10, 2012 > Summary: > This draft is not ready for publication as a Proposed Standard and > should be revised before publication > Major Issues: > 3. in item #7 I presume this should be LMTP, but my concern is that > it says this is being defined for LMTP. Since LMTP is informational, > I don't think that is appropriate. Instead, I would suggest that it > is defined for Message Submission and as a result may also be used for > LMTP. I would prefer this to be noted in an Appendix (along with the > LMTP advice in section 7) -- but if you would prefer it to remain in > the main body, it needs to be reworded. In either case, I would move > LMTP to the informative references. I know that LMTP (RFC 2033) being Informational is annoying, but really, it is a perfectly valid DownRef and can be called out during IETF LC. (At some point LMTP should be promoted to Proposed Standard, but that is largely independent of this work.) > 3. the too long example in 3.1 is apparently justified by item #6 > here ... but you can't have a line longer than 72 chars in an RFC... I think I've fixed that in my copy. > but more importantly, how do you guarantee that this does not > accidentally blow something up. This is a HUGE change that is > mentioned in passing without justification. This seems like a large > hurdle for an implementation to be able to add support for this. Why? Advertisement of supported levels is entirely optional. > The use for this appears to be to fit in message size parameters for > each priority (and I presume the message size is in bytes as it does > not say). Yes, in bytes. Clarified in my copy. > So why not use Kb instead of bytes? I was trying to be consistent with the SIZE SMTP extension which also uses bytes. But as you are the second person to complain about that, maybe I will give up and switch to Kb ;-). > Or render the numbers in hex? Or split it over two lines? The last doesn't work well with SMTP. At least no SMTP extension ever listed more than 1 capability in EHLO response. > I think any of these would be better than increasing the line length. > 5. The priority level definition is not clear. There are 200 possible > values. But there MUST be at least 6 supported. OK that seems like > overkill -- why can't it be from -9 to 9 then? Anyway, is that 6 > distinct numbers, 6 distinct numbers from the range shown, or any > number for the range shown? Further I would suggest that a default > value should be specified for these 6 levels and the default mapping > ranges -- all in a table. As other people made the same comment, I will reply to this with my reasoning in a separate email. > 6 & 8. You need to pick something and be consistent. I would suggest > it is not necessary for them to be the same. So the EHLO one could be > short "PRI" and the header long "Message Transfer Priority". In any > case, the terminology then needs alignment throughout the document. > A definition of the Priority message header field is missing. It > should be after section 3. I think a forward reference in section 4.2 (where the MT-Priority header field is specified) would be sufficient. Unless you meant something else. > Minor Issues: > Title: I would change "Message Priorities " to "Message Transfer > Priority" > 6. The units for "message size" need to be indicated at some point in > the document, at least in the syntax of section 6. This is already fixed in my copy (will be in -05). > 3. I would suggest to replace "The following service extension is > defined:" with "The Priorty SMTP service extension is defined as > follows:" > 5.1.x I am somewhat concerned about informative implementation details > -- I presume that is why this is informative? Or is it because this > is not exhaustive? Mostly the latter. > In any case, I think this should be in the appendix. Ok. > 6. It is confusing to have both specifications for the ESMTP and > Header field in the same place. I would suggest separate > appropriatley titled sub-sections of section 6 > 7. I would suggest adding an example fo the message header field in > this clause. > 9. What are the "anchor" placeholders for? This is just a hint to RFC Editor to insert the final RFC number, once known. > 9. Presumably the TBD items need to be filled in... The 2 values will be assigned by IANA before publication. > Nits: > 3.1 the example is too long > ** There is 1 instance of too long lines in the document, the longest > one being 12 characters in excess of 72. > ...but I could not find this one: > == There are 1 instance of lines with non-RFC2606-compliant FQDNs in > the document. Ok, I will check. --------------000203060407060504080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Glenn,
Thank you for your review.

On 10/01/2012 21:10, Glenn Parsons wrote:
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
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-melnikov-smtp-priority-04
Title: Simple Mail Transfer Protocol extension for Message Priorities
Reviewer: Glenn Parsons
Review Date:  January 10, 2012
Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication
Major Issues:
3.  in item #7 I presume this should be LMTP, but my concern is that it says this is being defined for LMTP.  Since LMTP is informational, I don't think that is appropriate.  Instead, I would suggest that it is defined for Message Submission and as a result may also be used for LMTP.   I would prefer this to be noted in an Appendix (along with the LMTP advice in section 7) -- but if you would prefer it to remain in the main body, it needs to be reworded.  In either case, I would move LMTP to the informative references.
I know that LMTP (RFC 2033) being Informational is annoying, but really, it is a perfectly valid DownRef and can be called out during IETF LC.
(At some point LMTP should be promoted to Proposed Standard, but that is largely independent of this work.)
3.  the too long example in 3.1 is apparently justified by item #6 here … but you can't have a line longer than 72 chars in an RFC…
I think I've fixed that in my copy.
but more importantly, how do you guarantee that this does not accidentally blow something up.  This is a HUGE change that is mentioned in passing without justification.  This seems like a large hurdle for an implementation to be able to add support for this.
Why? Advertisement of supported levels is entirely optional.
The use for this appears to be to fit in message size parameters for each priority (and I presume the message size is in bytes as it does not say).
Yes, in bytes. Clarified in my copy.
So why not use Kb instead of bytes?
I was trying to be consistent with the SIZE SMTP extension which also uses bytes. But as you are the second person to complain about that, maybe I will give up and switch to Kb ;-).
Or render the numbers in hex?  Or split it over two lines?
The last doesn't work well with SMTP. At least no SMTP extension ever listed more than 1 capability in EHLO response.
I think any of these would be better than increasing the line length.
5. The priority level definition is not clear.  There are 200 possible values.  But there MUST be at least 6 supported.  OK that seems like overkill -- why can't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number for the range shown?  Further I would  suggest that a default value should be specified for these 6 levels and the default mapping ranges -- all in a table.
As other people made the same comment, I will reply to this with my reasoning in a separate email.
6 & 8. You need to pick something and be consistent.  I would suggest it is not necessary for them to be the same.  So the EHLO one could be short "PRI" and the header long "Message Transfer Priority".  In any case, the terminology then needs alignment throughout the document.
A definition of the Priority message header field is missing.  It should be after section 3.
I think a forward reference in section 4.2 (where the MT-Priority header field is specified) would be sufficient. Unless you meant something else.
Minor Issues:
Title:  I would change "Message Priorities " to "Message Transfer Priority"
6. The units for "message size" need to be indicated at some point in the document, at least in the syntax of section 6.
This is already fixed in my copy (will be in -05).
3. I would suggest to replace "The following service extension is defined:" with "The Priorty SMTP service extension is defined as follows:"
5.1.x I am somewhat concerned about informative implementation details -- I presume that is why this is informative?  Or is it because this is not exhaustive?
Mostly the latter.
In any case, I think this should be in the appendix.
Ok.
6. It is confusing to have both specifications for the ESMTP and Header field in the same place.   I would suggest separate appropriatley titled sub-sections of section 6
7.  I would suggest adding an example fo the message header field in this clause.
9.  What are the "anchor" placeholders for?
This is just a hint to RFC Editor to insert the final RFC number, once known.
9. Presumably the TBD items need to be filled in...
The 2 values will be assigned by IANA before publication.
Nits: 
 
3.1 the example is too long
** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72.
…but I could not find this one:
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document.
Ok, I will check.

--------------000203060407060504080107-- From nick@inex.ie Wed Jan 11 04:21:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976B221F87D8; Wed, 11 Jan 2012 04:21:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHfKZoYw3ug3; Wed, 11 Jan 2012 04:21:53 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29721F8782; Wed, 11 Jan 2012 04:21:46 -0800 (PST) X-Envelope-To: iesg@ietf.org Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q0BCMoOK068065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 12:22:52 GMT (envelope-from nick@inex.ie) Message-ID: <4F0D7EC8.90603@inex.ie> Date: Wed, 11 Jan 2012 12:21:28 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120110143618.09180b88@elandnews.com> In-Reply-To: <6.2.5.6.2.20120110143618.09180b88@elandnews.com> X-Enigmail-Version: 1.3.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Jan 2012 08:31:47 -0800 Cc: draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-v6ops-ipv6-discard-prefix X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 12:21:53 -0000 On 10/01/2012 23:31, S Moonesamy wrote: > In the Introduction Section: > > "This document updates [RFC5156]." > > It is not clear what is being updated as RFC 5156 is a compilation of > special IPv6 addresses defined in other RFCs. this document requests another special ipv6 address prefix, which is what RFC5156 is all about. So it's appropriate that it mentions that it's updating RFC5156, no? Nick From sm@elandsys.com Wed Jan 11 11:22:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0874B21F874F for ; Wed, 11 Jan 2012 11:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90JOGCySN+Yh for ; Wed, 11 Jan 2012 11:22:42 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D38F421F8750 for ; Wed, 11 Jan 2012 11:22:41 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0BJMOrm001189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 11:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326309758; i=@elandsys.com; bh=fvbclxw8TQHKvC+RYv3dLIVXOB8lDaMPCoPY49b8b7s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ZdBO1At8R6/Qfe9OLh6XD+F86mhJVuBUMXcQfeTMXIrr61wljBA5P+pm4xAPV0Aqc UcP+T13WyPjRajQ4gaNn+BMOFMar0iVlUlhwH9ZnI8M30JRQgo4bWSmntQV+kP/EWG BrldQfqN3EbEZXHYTRFugGlX6A8k7+hT9g1sFfo0= Message-Id: <6.2.5.6.2.20120111074406.0b203d58@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 07:54:40 -0800 To: Nick Hilliard From: S Moonesamy In-Reply-To: <4F0D7EC8.90603@inex.ie> References: <6.2.5.6.2.20120110143618.09180b88@elandnews.com> <4F0D7EC8.90603@inex.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-v6ops-ipv6-discard-prefix X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:22:46 -0000 Hi Nick, At 04:21 11-01-2012, Nick Hilliard wrote: >this document requests another special ipv6 address prefix, which is what >RFC5156 is all about. So it's appropriate that it mentions that it's >updating RFC5156, no? Yes. The last sentence in the Abstract Section contains "updates RFC5156 by explaining". The Introduction Section does not contain a similar explanation. I consider my comments as addressed. Regards, S. Moonesamy From msk@cloudmark.com Wed Jan 11 12:27:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE041F0C4F for ; Wed, 11 Jan 2012 12:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYnveGQ51Y4V for ; Wed, 11 Jan 2012 12:27:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 675671F0C46 for ; Wed, 11 Jan 2012 12:27:44 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 12:27:36 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 11 Jan 2012 12:27:43 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 11 Jan 2012 12:27:43 -0800 Thread-Topic: [apps-discuss] Spam reporting over IMAP Thread-Index: AczQRD806X6VlO/xT8m+c17brcFj6gAWnMng Message-ID: References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> <4F0C8F7E.4070809@tana.it> <6.2.5.6.2.20120110124010.0968e868@resistor.net> <4F0D57A6.70508@tana.it> In-Reply-To: <4F0D57A6.70508@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Jon M. Jurgovan" , Sarah Guichard Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:27:46 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Alessandro Vesely > Sent: Wednesday, January 11, 2012 1:35 AM > To: apps-discuss@ietf.org; Jon M. Jurgovan > Cc: Sarah Guichard > Subject: Re: [apps-discuss] Spam reporting over IMAP >=20 > > Zoltan Ordogh and Alessandro Vesely are listed as the author/editor of > > draft-ordogh-spam-reporting-using-imap-kleansed-00. Are they stating > > on behalf of Research In Motion Limited that IPR disclosure #1609 is > > not applicable for draft-ordogh-spam-reporting-using-imap-kleansed-00? >=20 > Not only I cannot speak for RIM, but I have never actually seen that > patent application. I'm looking forward for a RIM's statement that > either confirms or denies that that patent does not apply to a reduced > version like the one I posted. I'm confident that my post can be > deleted promptly in case RIM gives a negative response. >=20 > The IPR is filed here: > https://datatracker.ietf.org/ipr/1609/ This looks and feels a lot like the IPR claim Yahoo! made against DomainKey= s (RFC4870). The difference here, I think, is that Yahoo! also offered int= o the public domain an open source implementation of DK. Does RIM plan to = do something like that too? Otherwise, I'm concerned that we will be contributing, presumably for "free= ", support in development of this toward the standards track where the bene= ficiary is RIM. Not a very "open" approach to an open standards body. I p= ersonally wouldn't be inclined to be very supportive. Hopefully RIM can give us some good assurances that this is all on the leve= l. Or give us all free Blackberries. -MSK From msk@cloudmark.com Wed Jan 11 13:06:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA28E11E80B2 for ; Wed, 11 Jan 2012 13:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4neDv1lCVWvj for ; Wed, 11 Jan 2012 13:06:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2076E11E8079 for ; Wed, 11 Jan 2012 13:06:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 13:06:36 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 13:06:42 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 11 Jan 2012 13:06:40 -0800 Thread-Topic: Adoption of draft-kucherawy-received-state? Thread-Index: AczQpOnJku4xPT04TR+hvDkzgrnQHg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15818EXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 21:06:44 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15818EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can I get a show of support (or objection) to processing this through APPSA= WG? Mykyta already gave a +1 to this before it was asked, but others have not s= aid so explicitly. I'm game, of course. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15818EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can I get a show= of support (or objection) to processing this through APPSAWG?

 

Mykyta alr= eady gave a +1 to this before it was asked, but others have not said so exp= licitly.

 

I’m game, of course.

=  

-MSK

<= /html>= --_000_F5833273385BB34F99288B3648C4F06F19C6C15818EXCHC2corpclo_-- From glenn.parsons@ericsson.com Thu Jan 12 09:42:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7558721F8588; Thu, 12 Jan 2012 09:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.321 X-Spam-Level: X-Spam-Status: No, score=-5.321 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PRIOR=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPi2C257QdAC; Thu, 12 Jan 2012 09:42:54 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCA521F84CF; Thu, 12 Jan 2012 09:42:54 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0CHgmdN012810; Thu, 12 Jan 2012 11:42:50 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.96]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 12 Jan 2012 12:42:44 -0500 From: Glenn Parsons To: Alexey Melnikov Date: Thu, 12 Jan 2012 12:42:44 -0500 Thread-Topic: [apps-discuss] Review of draft-melnikov-smtp-priority-04 Thread-Index: AczQX0od9GnYw07LQEqiOKcQUwOJigA8Pxfw Message-ID: References: <4F0D8520.1080206@isode.com> In-Reply-To: <4F0D8520.1080206@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78EUSAACMS0714e_" MIME-Version: 1.0 Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:42:57 -0000 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alexey, You're welcome :-) Despite your assertion that LMTP would be a valid DownRef ... I do not thin= k this extension should be defined for it. That is I would suggest adding = text along the lines of ...it is defined for Message Submission and as a re= sult may also be used for LMTP. On lines longer than 72 -- it just feels bad. And further, you have no jus= tification for this here. Is it for the message length? If it is won't mo= ving to Kb remove the need for a longer line? On the naming you need to be consistent. For example, is it "PRI" or "PRIO= RITY" On docuemnt organization, there are two things defined here: Priority SMTP= extension & Priority message header. These need to be in distinct section= s with appropriate titles. It is the second that is currently hidden. Cheers, Glenn. ________________________________ From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: January-11-12 7:49 AM To: Glenn Parsons Cc: apps-discuss@ietf.org; draft-melnikov-smtp-priority.all@tools.ietf.org;= iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 Hi Glenn, Thank you for your review. On 10/01/2012 21:10, Glenn Parsons wrote: I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-melnikov-smtp-priority-04 Title: Simple Mail Transfer Protocol extension for Message Priorities Reviewer: Glenn Parsons Review Date: January 10, 2012 Summary: This draft is not ready for publication as a Proposed Standard and should b= e revised before publication Major Issues: 3. in item #7 I presume this should be LMTP, but my concern is that it say= s this is being defined for LMTP. Since LMTP is informational, I don't thi= nk that is appropriate. Instead, I would suggest that it is defined for Me= ssage Submission and as a result may also be used for LMTP. I would prefe= r this to be noted in an Appendix (along with the LMTP advice in section 7)= -- but if you would prefer it to remain in the main body, it needs to be r= eworded. In either case, I would move LMTP to the informative references. I know that LMTP (RFC 2033) being Informational is annoying, but really, it= is a perfectly valid DownRef and can be called out during IETF LC. (At some point LMTP should be promoted to Proposed Standard, but that is la= rgely independent of this work.) 3. the too long example in 3.1 is apparently justified by item #6 here ...= but you can't have a line longer than 72 chars in an RFC... I think I've fixed that in my copy. but more importantly, how do you guarantee that this does not accidentally = blow something up. This is a HUGE change that is mentioned in passing with= out justification. This seems like a large hurdle for an implementation to= be able to add support for this. Why? Advertisement of supported levels is entirely optional. The use for this appears to be to fit in message size parameters for each p= riority (and I presume the message size is in bytes as it does not say). Yes, in bytes. Clarified in my copy. So why not use Kb instead of bytes? I was trying to be consistent with the SIZE SMTP extension which also uses = bytes. But as you are the second person to complain about that, maybe I wil= l give up and switch to Kb ;-). Or render the numbers in hex? Or split it over two lines? The last doesn't work well with SMTP. At least no SMTP extension ever liste= d more than 1 capability in EHLO response. I think any of these would be better than increasing the line length. 5. The priority level definition is not clear. There are 200 possible valu= es. But there MUST be at least 6 supported. OK that seems like overkill -= - why can't it be from -9 to 9 then? Anyway, is that 6 distinct numbers, 6= distinct numbers from the range shown, or any number for the range shown? = Further I would suggest that a default value should be specified for thes= e 6 levels and the default mapping ranges -- all in a table. As other people made the same comment, I will reply to this with my reasoni= ng in a separate email. 6 & 8. You need to pick something and be consistent. I would suggest it is= not necessary for them to be the same. So the EHLO one could be short "PR= I" and the header long "Message Transfer Priority". In any case, the termi= nology then needs alignment throughout the document. A definition of the Priority message header field is missing. It should be= after section 3. I think a forward reference in section 4.2 (where the MT-Priority header fi= eld is specified) would be sufficient. Unless you meant something else. Minor Issues: Title: I would change "Message Priorities " to "Message Transfer Priority" 6. The units for "message size" need to be indicated at some point in the d= ocument, at least in the syntax of section 6. This is already fixed in my copy (will be in -05). 3. I would suggest to replace "The following service extension is defined:"= with "The Priorty SMTP service extension is defined as follows:" 5.1.x I am somewhat concerned about informative implementation details -- I= presume that is why this is informative? Or is it because this is not exh= austive? Mostly the latter. In any case, I think this should be in the appendix. Ok. 6. It is confusing to have both specifications for the ESMTP and Header fie= ld in the same place. I would suggest separate appropriatley titled sub-s= ections of section 6 7. I would suggest adding an example fo the message header field in this c= lause. 9. What are the "anchor" placeholders for? This is just a hint to RFC Editor to insert the final RFC number, once know= n. 9. Presumably the TBD items need to be filled in... The 2 values will be assigned by IANA before publication. Nits: 3.1 the example is too long ** There is 1 instance of too long lines in the document, the longest one b= eing 12 characters in excess of 72. ...but I could not find this one: =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in th= e document. Ok, I will check. --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Alexey,
 
You're=20 welcome :-)
 
Despite your assertion that LMTP would be a valid DownRef ... I do= not=20 think this extension should be defined for it.  That is I would sugges= t=20 adding text along the lines of ...it is defined for Message Submission and as a result may also b= e used=20 for LMTP.
 
On lines longer than 72 -- it just fe= els=20 bad.  And further, you have no justification for this here.  Is i= t for=20 the message length?  If it is won't moving to Kb remove the need for a= =20 longer line?
 
On the naming you need to be=20 consistent.  For example, is it "PRI" or=20 "PRIORITY"
 
On docuemnt organization, there are t= wo things=20 defined here:  Priority SMTP extension & Priority message header.&= nbsp;=20 These need to be in distinct sections with appropriate titles.  It is = the=20 second that is currently hidden.
 
Cheers,
Glenn.
 
From: Alexey Melnikov=20 [mailto:alexey.melnikov@isode.com]
Sent: January-11-12 7:49=20 AM
To: Glenn Parsons
Cc: apps-discuss@ietf.org;=20 draft-melnikov-smtp-priority.all@tools.ietf.org;=20 iesg@ietf.org
Subject: Re: [apps-discuss] Review of=20 draft-melnikov-smtp-priority-04

Hi Glenn,
Thank you for your review.

On 10/01/2012 21:= 10,=20 Glenn Parsons wrote:=20
I have been selected a= s the=20 Applications Area Directorate reviewer for this draft (for background on= =20 appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate).=20
Please resolve these c= omments=20 along with any other Last Call comments you may receive. Please wait for= =20 direction from your document shepherd or AD before posting a new version = of=20 the draft.
Document:=20 draft-melnikov-smtp-priority-04
Title: Simple Mail Transfer Protocol=20 extension for Message Priorities
Reviewer: Glenn Parsons
Review=20 Date:  January 10, 2012
Summary:
This draft is not read= y for=20 publication as a Proposed Standard and should be revised before=20 publication
Major Issues:
3.  in item #7 I = presume=20 this should be LMTP, but my concern is that it says this is being defined= for=20 LMTP.  Since LMTP is informational, I don't think that is=20 appropriate.  Instead, I would suggest that it is defined for Messag= e=20 Submission and as a result may also be used for LMTP.   I would= =20 prefer this to be noted in an Appendix (along with the LMTP advice in sec= tion=20 7) -- but if you would prefer it to remain in the main body, it needs to = be=20 reworded.  In either case, I would move LMTP to the informative=20 references.
I know that LMTP (RFC 2033) being Informat= ional=20 is annoying, but really, it is a perfectly valid DownRef and can be called = out=20 during IETF LC.
(At some point LMTP should be promoted to Proposed Stand= ard,=20 but that is largely independent of this work.)
3.  the too long = example=20 in 3.1 is apparently justified by item #6 here … but you can't have= a line=20 longer than 72 chars in an RFC…
I think I've fixe= d that in my=20 copy.
but more importantly, = how do=20 you guarantee that this does not accidentally blow something up.  Th= is is=20 a HUGE change that is mentioned in passing without justification.  T= his=20 seems like a large hurdle for an implementation to be able to add support= for=20 this.
Why? Advertisement of supported levels is entirel= y=20 optional.
The use for this appea= rs to=20 be to fit in message size parameters for each priority (and I presume the= =20 message size is in bytes as it does not say).
Yes,= in=20 bytes. Clarified in my copy.
So why not use Kb inst= ead of=20 bytes?
I was trying to be consistent with the SIZE= SMTP=20 extension which also uses bytes. But as you are the second person to compla= in=20 about that, maybe I will give up and switch to Kb ;-).
Or render the numbers = in=20 hex?  Or split it over two lines?
The last doesn't= work=20 well with SMTP. At least no SMTP extension ever listed more than 1 capabili= ty in=20 EHLO response.
I think any of these w= ould be=20 better than increasing the line length.
5. The priority level= =20 definition is not clear.  There are 200 possible values.  But t= here=20 MUST be at least 6 supported.  OK that seems like overkill -- why ca= n't=20 it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 dist= inct=20 numbers from the range shown, or any number for the range shown?  Fu= rther=20 I would  suggest that a default value should be specified for these = 6=20 levels and the default mapping ranges -- all in a table.
As=20 other people made the same comment, I will reply to this with my reasoning = in a=20 separate email.
6 & 8. You need to= pick=20 something and be consistent.  I would suggest it is not necessary fo= r=20 them to be the same.  So the EHLO one could be short "PRI" and the h= eader=20 long "Message Transfer Priority".  In any case, the terminology then= =20 needs alignment throughout the document.
A definition of the Pr= iority=20 message header field is missing.  It should be after section=20 3.
I think a forward reference in section 4.2 (where the= =20 MT-Priority header field is specified) would be sufficient. Unless you mean= t=20 something else.
Minor Issues:
Title:  I would c= hange=20 "Message Priorities " to "Message Transfer Priority"
6. The units for "mess= age=20 size" need to be indicated at some point in the document, at least in the= =20 syntax of section 6.
This is already fixed in my copy (= will be=20 in -05).
3. I would suggest to = replace=20 "The following service extension is defined:" with "The Priorty SMTP serv= ice=20 extension is defined as follows:"
5.1.x I am somewhat co= ncerned=20 about informative implementation details -- I presume that is why this is= =20 informative?  Or is it because this is not=20 exhaustive?
Mostly the latter.
In any case, I think t= his=20 should be in the appendix.
Ok.
6. It is confusing to = have=20 both specifications for the ESMTP and Header field in the same=20 place.   I would suggest separate appropriatley titled sub-sect= ions=20 of section 6
7.  I would sugge= st=20 adding an example fo the message header field in this clause.
9.  What are the= =20 "anchor" placeholders for?
This is just a hint to RFC E= ditor=20 to insert the final RFC number, once known.
9. Presumably the TBD = items=20 need to be filled in...
The 2 values will be assigned b= y IANA=20 before publication.
Nits: 
 
3.1 the example is too long
** There is 1 instance= of too=20 long lines in the document, the longest one being 12 characters in excess= of=20 72.
…but I could not= find this=20 one:
=3D=3D There are 1 ins= tance of=20 lines with non-RFC2606-compliant FQDNs in the document.
Ok, I=20 will check.

--_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78EUSAACMS0714e_-- From msk@cloudmark.com Thu Jan 12 10:35:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD021F84D7; Thu, 12 Jan 2012 10:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlsmHeY0CtDB; Thu, 12 Jan 2012 10:35:03 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25521F84D6; Thu, 12 Jan 2012 10:35:03 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 10:34:55 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Jan 2012 10:35:02 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" Date: Thu, 12 Jan 2012 10:35:00 -0800 Thread-Topic: AppsDir Review of draft-ietf-dnsext-xnamercode Thread-Index: AczRWOSb3T5cxrYTTDKTQq7fMmXudQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: [apps-discuss] AppsDir Review of draft-ietf-dnsext-xnamercode X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:35:05 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/a= rea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-dnsext-xnamercode Title: xNAME RCODE and Status Bits Clarification Reviewer: Murray S. Kucherawy Review Date: January 12, 2012 IETF Last Call Date: N/A IESG Telechat Date: N/A The draft clarifies prior ambiguities with respect to how a resolver is sup= posed to report answer meta-data when resolving a name where the first answ= er returned in a potential series of query-responses is actually a pointer = to another record. It is precise and concise. Summary: This draft is almost ready for publication as a Standards Track RF= C but has a couple of issues that should be addressed before publication. Major Issues: Given that this is a potentially important clarification with interoperabil= ity considerations, I believe this document should say it updates at least = RFC1035 (since its ambiguity is specifically called out), and possibly RFC2= 672 and RFC2308. Make sure the Abstract also says this explicitly. Minor Issues: In Section 1, "There is a proposal for another redirection RR." Is it appr= opriate to make reference to that here? I don't know to which one you're r= eferring or what status it has, so the answer might be "no"; just checking. Section 2 identifies two status bits as part of this clarification document= . However, it also says explicitly that their definitions are unchanged fr= om the documents that introduced them. I'm curious then as to why they are= included in this document at all; that is, what clarification is being pro= vided? Unlike Section 3, any ambiguity about their use has not been identi= fied here. If in fact there isn't any, I think this section can be removed= . If you like, you can introduce references to and overviews of their defi= nitions in a new subsection of Section 1, since you do talk about them in S= ection 4. Nits: In Section 3, the exclamation mark legitimately relays bewilderment here, b= ut unfortunately I think it should just be a period. Even better would be = to end the sentence with "says that some servers are implemented differentl= y" or suchlike. In Section 4, the clause "if the following apply" should be amended by addi= ng "all of" or "one of" or something more specific. --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applic= ations Area Directorate reviewer for this draft (for background on appsdir,= please see  = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAre= aDirectorate).

Please resolve these comments along wi= th 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-dnsext-xnamercode
Title: xNAME R= CODE and Status Bits Clarification
Reviewer: Murray S. Kucherawy
Revi= ew Date: January 12, 2012
IETF Last Call Date: N/A
IESG Telechat Date= : N/A

The draft clarifies prior ambiguities with respect t= o how a resolver is supposed to report answer meta-data when resolving a na= me where the first answer returned in a potential series of query-responses= is actually a pointer to another record.  It is precise and concise.<= o:p>

Summary: This draft is almost ready for publication as a S= tandards Track RFC but has a couple of issues that should be addressed befo= re publication.

Major Issues:

Given tha= t this is a potentially important clarification with interoperability consi= derations, I believe this document should say it updates at least RFC1035 (= since its ambiguity is specifically called out), and possibly RFC2672 and R= FC2308.  Make sure the Abstract also says this explicitly.<= /p>

Minor Issues:

In Section 1, “There is a propos= al for another redirection RR.”  Is it appropriate to make refer= ence to that here?  I don’t know to which one you’re refer= ring or what status it has, so the answer might be “no”; just c= hecking.

Section 2 identifies two status bits as part of t= his clarification document.  However, it also says explicitly that the= ir definitions are unchanged from the documents that introduced them. = I’m curious then as to why they are included in this document at all= ; that is, what clarification is being provided?  Unlike Section 3, an= y ambiguity about their use has not been identified here.  If in fact = there isn’t any, I think this section can be removed.  If you li= ke, you can introduce references to and overviews of their definitions in a= new subsection of Section 1, since you do talk about them in Section 4.

Nits:

In Section 3, the exclamation mark le= gitimately relays bewilderment here, but unfortunately I think it should ju= st be a period.  Even better would be to end the sentence with “= says that some servers are implemented differently” or suchlike.=

In Section 4, the clause “if the following apply” = should be amended by adding “all of” or “one of” or= something more specific.

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_-- From msk@cloudmark.com Thu Jan 12 12:46:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543221F0C38 for ; Thu, 12 Jan 2012 12:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+0VCRUJ2JrL for ; Thu, 12 Jan 2012 12:46:11 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC4711E809D for ; Thu, 12 Jan 2012 12:46:11 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 12:46:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 Jan 2012 12:46:10 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 12 Jan 2012 12:46:09 -0800 Thread-Topic: Adoption of draft-kucherawy-received-state? Thread-Index: AczQpOnJku4xPT04TR+hvDkzgrnQHgAxjAqw 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: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15859EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:46:12 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15859EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For evidence that there's interest in this work, or at least a lot of input= to it, visit http://www.imc.org/ietf-smtp/mail-archive/. From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Wednesday, January 11, 2012 1:07 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Adoption of draft-kucherawy-received-state? Can I get a show of support (or objection) to processing this through APPSA= WG? Mykyta already gave a +1 to this before it was asked, but others have not s= aid so explicitly. I'm game, of course. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15859EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For evidence that there’s interest in this work, or at = least a lot of input to it, visit http://www.imc.org/ietf-smtp/mail-archive= /.

=  

From: a= pps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On B= ehalf Of Murray S. Kucherawy
Sent: Wednesday, January 11, 201= 2 1:07 PM
To: apps-discuss@ietf.org
Subject: [apps-disc= uss] Adoption of draft-kucherawy-received-state?

 

Can I= get a show of support (or objection) to processing this through APPSAWG?

 

Mykyta already gave a +1 to this before it was asked, but others have not = said so explicitly.

 

I’m game, of course.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15859EXCHC2corpclo_-- From dhc@dcrocker.net Fri Jan 13 08:23:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116FE21F8577 for ; Fri, 13 Jan 2012 08:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.638 X-Spam-Level: X-Spam-Status: No, score=-6.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPI7-pvQSO5Q for ; Fri, 13 Jan 2012 08:23:45 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4F21F8565 for ; Fri, 13 Jan 2012 08:23:45 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0DGNdYj017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jan 2012 08:23:45 -0800 Message-ID: <4F105A7F.2030706@dcrocker.net> Date: Fri, 13 Jan 2012 08:23:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Jan 2012 08:23:45 -0800 (PST) Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:23:46 -0000 On 1/11/2012 1:06 PM, Murray S. Kucherawy wrote: > Can I get a show of support (or objection) to processing this through APPSAWG? +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Fri Jan 13 09:25:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE9F21F8559 for ; Fri, 13 Jan 2012 09:25:58 -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.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhIGF+8uJMup for ; Fri, 13 Jan 2012 09:25:56 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA021F8554 for ; Fri, 13 Jan 2012 09:25:56 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0DHPhrf027021 for ; Fri, 13 Jan 2012 09:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326475549; i=@resistor.net; bh=XyCJyUTr8nXz3bMD+eqExkmp5BXbolQ4srz1/nAzECM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=saK/Z1+6Bq3q+OyLuim5FaGdmJAyLyJOiSj/c57rUl7vWwWxsbrTDT9oZmxxDn/CY CH9tUr/BSsFMv56LoQrwZ5dDc5EWnVP6se3la41eyatK6gVQCGqYRANRFIM2uULmZM ZWy+xnYkX1RFI3n7REqkQhuSyAEuW9tJaBIW8JAs= Message-Id: <6.2.5.6.2.20120113085624.09424d58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Jan 2012 09:01:46 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:25:58 -0000 At 13:06 11-01-2012, Murray S. Kucherawy wrote: >Can I get a show of support (or objection) to processing this through APPSAWG? This draft registers a new optional clause that can be used in trace fields. I support the processing. BTW, the normative reference to RFC 5322 ([MAIL] reference in ABNF) is missing. Regards, -sm From john-ietf@jck.com Fri Jan 13 10:53:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09D21F8530 for ; Fri, 13 Jan 2012 10:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcDQz92oRypu for ; Fri, 13 Jan 2012 10:53:41 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92F21F850D for ; Fri, 13 Jan 2012 10:53:41 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RlmFw-0007oK-Cc; Fri, 13 Jan 2012 13:53:40 -0500 Date: Fri, 13 Jan 2012 13:53:39 -0500 From: John C Klensin To: "Murray S. Kucherawy" , 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: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:53:44 -0000 Murray and others, You can consider this an objection to AppsAWG handling the document in this form or one of the first comments in the dicussion of it. SMTP rather carefully defines "trace information" or "trace headers" and then limits that category to two types of information, the Received header fields and the Return-path one. I think I know why Jon Postel did it that way, but it is pure reconstruction: if I actually knew at the time, I've long since forgotten. In any event, we have discovered repeatedly (and sometimes painfully) that the the Received header field is not well designed for extensibility. It depends on an ordered, context-dependent, reserved keyword model (something I don't think anyone would do today) and then switches to an Atom-String pair model for additional clauses. While I have no problem at all with the type of facility the draft proposes, I think that, if we are going to entertain this sort of thing, we should have a serious discussion about how far we want to go in extending "Received:" and when it is time to add one or more additional Trace header fields, possibly with a typology of functions that each serves (beyond "inserted by a transit MTA or something else") and with a syntax that is clearly name-value based, rather than even partially dependent on parser recognition of specific keywords. Let's not turn "Received:" further into a kludge just because it is there. john --On Thursday, January 12, 2012 12:46 -0800 "Murray S. Kucherawy" wrote: > For evidence that there's interest in this work, or at least a > lot of input to it, visit > http://www.imc.org/ietf-smtp/mail-archive/. > > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. > Kucherawy Sent: Wednesday, January 11, 2012 1:07 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] Adoption of > draft-kucherawy-received-state? > > Can I get a show of support (or objection) to processing this > through APPSAWG? > > Mykyta already gave a +1 to this before it was asked, but > others have not said so explicitly. > > I'm game, of course. From zordogh@rim.com Fri Jan 13 11:11:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386FB21F856A for ; Fri, 13 Jan 2012 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.357 X-Spam-Level: X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXchedqGHHsa for ; Fri, 13 Jan 2012 11:11:21 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6573B21F8568 for ; Fri, 13 Jan 2012 11:11:20 -0800 (PST) X-AuditID: 0a412830-b7fe76d000001ee9-a0-4f1081d776f8 Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CA.F1.07913.7D1801F4; Fri, 13 Jan 2012 19:11:19 +0000 (GMT) Received: from XCT108CNC.rim.net (10.65.161.208) by XHT104CNC.rim.net (10.65.22.52) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 13 Jan 2012 14:11:19 -0500 Received: from XMB107ACNC.rim.net ([fe80::f1d2:c1d5:f469:3f83]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.01.0339.001; Fri, 13 Jan 2012 14:11:17 -0500 From: Zoltan Ordogh To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Thread-Topic: Spam reporting over IMAP Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+ADJcaFQ Date: Fri, 13 Jan 2012 19:11:17 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: multipart/alternative; boundary="_000_1DE983233DBBEB4A81F18FABD8208D76226BE438XMB107ACNCrimne_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXC5Shmonu9UcDf4GWbicXqlyvYLFZ/3MHm wOTRMXEXk8eSJT+ZApiiGhhtEvPy8ksSS1IVUlKLk22VfFLTE3MUAooyyxKTKxVcMouTcxIz c1OLlBQyU2yVTJQUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/ roWFqaWuoZKdLhJI+MedcWydRcHSvYwV6xp/sDUwvljE2MXIwSEhYCLR8Ieji5ETyBSTuHBv PVsXIxeHkEAPk8SHfWtYIZxljBK97c9YIJxtQM6FLywg3WwCqhJzrsaCdIsIJEhMeb+TEcQW BgpvXPObBSKuJnH4x0Eo20hiw/Np7CA2C1DNhf+bwWxeAU+JS6ePs4LYQgLBEh2v+8FsToEQ iZn3F4P1MgrISuw+e50JxGYWEJe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStKPGnczAJRny9x oecJC8QuQYmTMyFsIQEZiedTLrFPYBSbhWTsLCQts5C0QMR1JBbs/sQGYWtLLFv4mhnGPnPg MROy+AJG9lWMgrkZxQZmhsl5yXpFmbl6eaklmxjBCUfDYAfjhL1ahxgFOBiVeHh9awT8hVgT y4orcw8xSnAwK4nwSpkChXhTEiurUovy44tKc1KLDzG6AkNuIrMUd3I+MBnmlcQbGxjg5iiJ 82qr3/MTEkgHJr3s1NSC1CKYOUwcnFINjDrflRlv/P2gfog3r227+cP6k6+m8nc8fnLxP9ON 4F8VJ/WjE1Zv+axxMdX3dP3u0y3BJkl7tq44d+39+8Jf86bx7v1e5DbvawPnEa96ns6NRyuP RnbUsLfwJhTdbbzKJ7taaq3f7ymPfffvCpZrfRW6OiJ4TmzVqnyjQA4bf4lI7u4nnddsZyqx FGckGmoxFxUnAgBBPX2lXgMAAA== Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 19:11:26 -0000 --_000_1DE983233DBBEB4A81F18FABD8208D76226BE438XMB107ACNCrimne_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, Instead of responding to individual emails one by one, I try to clarify some= of the concerns at least in a single response. I would like to start with a story. I few companies got together in OMA EVVM to enhance the OMTP Visual Voice Ma= il 1.3 specs. During the requirements phase it has been identified that spam voicemails ar= e an issue, and a reporting mechanism must be in place. OMA typically uses in-house solutions when it's available. This is where OMA= -SpamRep comes to the picture; the OMA-SpamRep provide exactly that: spam re= porting. OMA-SpamRep unfortunately two weaknesses: - it is an RFC3462-based reporting mechanism: to file report, one must inclu= de the original email. - it is HTTP-based. - it cannot manage the mailbox (to make a decision and do what needs to be d= one [leavealone, flag, move, delete]) so one would need to go through IMAP a= nyway. Some OMA members believe that keeping the bandwidth consumption at a minimum= level is crucial, which make those two weaknesses stand out. Consider that voicemails can be large (100k>) and establishing a separate co= nnection when you already have one is far from being efficient. So, members in OMA have studied this topic and concluded that: - we should keep it all in IMAP (reuse the existing IMAP connection= ), - report spam by using a reference (instead of sending entire messa= ges), - let the service provider decide how spam is handled (instead of e= xplicitly flagging, moving, deletion messages, leave these decision to the s= erver). - an IMAP server has an ample supply of bandwidth to chat with anot= her service to hand over 100k+ attachments in microseconds - including a bon= us: without counting the traffic (generated by a useless piece of spam) into= a user's traffic quota (which is especially expensive while one is roaming= ). - allow a server to utilize any spam aggregator service - such as= a service based on OMA SpamRep - (instead of explicitly depending on one sp= ecific service). Additional requirements include the ability to report messages that are no l= onger spam, being able to include additional information (severity, nature o= f the spam), etc. So, this is how it all began. Fast-forward a few months. I volunteered to write up a draft that would include a new IMAP command that= does all that OMA EVVM needs, so I did. The draft has been reviewed in OMA EVVM, adjusted a bit, and finally uploade= d to IETF. I sent out an email about the draft to the MARF mailing list, explaining whe= re it comes from. We have received a few technical comments, but the MARF gr= oup was concerned about the lack of IMAP experts in the group, so it was not= taken into the MARF charter. A bit later, a liaison statement was sent from OMA to IETF, seeking collabor= ation and a "home" for the draft; as required by RFC3975. OMA EVVM have not received any response from IETF, so a discussion began in= OMA EVVM regarding the possibility of releasing IMAP extensions within OMA= EVVM. Lacking any other choices, it will surely happen. But. I would prefer keeping an IMAP extension in the midst of IETF for sever= al reasons (some of which Alexey already elaborated in his email), so I star= ted talking with Murray and Alexey offline, asking for advice, regarding the= silence of IETF and our options to progress this draft. - Alexey was kind enough to have a look at the draft and send a goo= d deal of comments our way - which we have all intention to address. - Murray was kind enough to start a discussion to see whether there= 's interest in the draft. - I was also told that there won't be an IMAP-related working group= for a long time (which is fine; there's no point creating a WG for a single= draft). Which bring us to where we are today: - There is a draft that fulfills a set of requirements (does what O= MA EVVM needs it to do). - We have received some comments already (Alessandro, Alexey - than= k you). - The only goal of this thread (as Murray said already) is to test= the waters and see if there is interest in IETF APPSAWG to work a draft lik= e this. So far I've seen both positive and negative feedback, discussion of technica= l issues already, and even a new draft. To me, that shows that there is some= level of interest. PS. I am solely a technical contributor, so asking me IPR-related questions= will always be a dead end. Please direct those questions directly to the ap= propriate contact person, which, in, this case is Sarah Guichard. Thank you. From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] O= n Behalf Of Murray S. Kucherawy Sent: January 9, 2012 1:51 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Spam reporting over IMAP In September the OMA sent a notice to the IETF that it had submitted draft-o= rdogh-spam-reporting-using-imap for our consideration as they need it (or so= mething like it) to complete work of their Enhanced Visual Voice Mail workin= g group. It has since then failed to get any IETF attention. It was submitted to the Messaging Abuse Reporting Format (MARF) working grou= p but they are not chartered to handle this work, nor is there any apparent= interest or momentum to recharter to do so. Is there any interest among those of us following APPSAWG to do this kind of= work? I can't think of any current working groups where it might otherwise= fit. I can suggest they present in Paris if they want to gauge interest if people= would be interested in hearing something about it. Otherwise, I believe I= should reply to them that the IETF is not currently doing work in this area= so their options include an ISE submission or something AD-sponsored that g= oes for Experimental status or suchlike. I'd be happy if someone (or a few of us) here could review it and make some= suggestions about next steps. Thanks, M. Kucherawy --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_1DE983233DBBEB4A81F18FABD8208D76226BE438XMB107ACNCrimne_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,

Instead of responding t= o individual emails one by one, I try to clarify some of the concerns at lea= st in a single response.

 

I would like to start w= ith a story.

 

I few companies got tog= ether in OMA EVVM to enhance the OMTP Visual Voice Mail 1.3 specs.

During the requirements= phase it has been identified that spam voicemails are an issue, and a repor= ting mechanism must be in place.

OMA typically uses in-h= ouse solutions when it’s available. This is where OMA-SpamRep comes to= the picture; the OMA-SpamRep provide exactly that: spam reporting.

OMA-SpamRep unfortunate= ly two weaknesses:

- it is an RFC3462-base= d reporting mechanism: to file report, one must include the original email.<= o:p>

-  it is HTTP-base= d.

- it cannot manage the= mailbox (to make a decision and do what needs to be done [leavealone, flag,= move, delete]) so one would need to go through IMAP anyway.

Some OMA members believ= e that keeping the bandwidth consumption at a minimum level is crucial, whic= h make those two weaknesses stand out.

Consider that voicemail= s can be large (100k>) and establishing a separate connection when you al= ready have one is far from being efficient.

So, members in OMA have= studied this topic and concluded that:

-  &= nbsp;       we should keep= it all in IMAP (reuse the existing IMAP connection),

-  &= nbsp;       report spam by= using a reference (instead of sending entire messages),

-  &= nbsp;       let the service= provider decide how spam is handled (instead of explicitly flagging, moving= , deletion messages, leave these decision to the server).<= /p>

-  &= nbsp;       an IMAP server= has an ample supply of bandwidth to chat with another service to hand over= 100k+ attachments in microseconds – including a bonus: without co= unting the traffic (generated by a useless piece of spam) into a user’s traffic  quota (which is especially= expensive while one is roaming).

-  &= nbsp;       allow a server= to utilize any spam aggregator service  - such as a service based on O= MA SpamRep - (instead of explicitly depending on one specific service).=

Additional requirements= include the ability to report messages that are no longer spam, being able= to include additional information (severity, nature of the spam), etc.=

 

So, this is how it all= began.

Fast-forward a few mont= hs.

 

I volunteered to write= up a draft that would include a new IMAP command that does all that OMA EVV= M needs, so I did.

The draft has been revi= ewed in OMA EVVM, adjusted a bit, and finally uploaded to IETF.

I sent out an email abo= ut the draft to the MARF mailing list, explaining where it comes from. We ha= ve received a few technical comments, but the MARF group was concerned about= the lack of IMAP experts in the group, so it was not taken into the MARF charter.

A bit later, a liaison= statement was sent from OMA to IETF, seeking collaboration and a “hom= e” for the draft; as required by RFC3975.

OMA EVVM have not recei= ved any response from IETF, so a discussion began in OMA EVVM regarding the= possibility of releasing IMAP extensions within OMA EVVM. Lacking any other= choices, it will surely happen.

But. I would prefer kee= ping an IMAP extension in the midst of IETF for several reasons (some of whi= ch Alexey already elaborated in his email), so I started talking with Murray= and Alexey offline, asking for advice, regarding the silence of IETF and our options to progress this draft.<= /o:p>

-  &= nbsp;       Alexey was kind= enough to have a look at the draft and send a good deal of comments our way= – which we have all intention to address.

-  &= nbsp;       Murray was kind= enough to start a discussion to see whether there’s interest in the d= raft.

-  &= nbsp;       I was also told= that there won’t be an IMAP-related working group for a long time (wh= ich is fine; there’s no point creating a WG for a single draft).<= /o:p>

 

Which bring us to where= we are today:

-  &= nbsp;       There is a draf= t that fulfills a set of requirements (does what OMA EVVM needs it to do).

-  &= nbsp;       We have receive= d some comments already (Alessandro, Alexey – thank you).

-  &= nbsp;       The only goal o= f this thread (as Murray said already) is to test the waters and see if ther= e is interest in IETF APPSAWG to work a draft like this.

 

So far I’ve seen= both positive and negative feedback, discussion of technical issues already= , and even a new draft. To me, that shows that there is some level of intere= st.

 

PS. I am solely a techn= ical contributor, so asking me IPR-related questions will always be a dead e= nd. Please direct those questions directly to the appropriate contact person= , which, in, this case is Sarah Guichard. Thank you.

 

 

From: apps-discus= s-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: January 9, 2012 1:51 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Spam reporting over IMAP

 

In September the OMA sent a notice to the IETF that i= t had submitted draft-ordogh-spam-reporting-using-imap for our consideration= as they need it (or something like it) to complete work of their Enhanced V= isual Voice Mail working group.  It has since then failed to get any IETF attention.


It was submitted to the Messaging Abuse Reporting Format (MARF) working grou= p but they are not chartered to handle this work, nor is there any apparent= interest or momentum to recharter to do so.

 

Is there any interest among those of us following APP= SAWG to do this kind of work?  I can’t think of any current worki= ng groups where it might otherwise fit.

 

I can suggest they present in Paris if they want to g= auge interest if people would be interested in hearing something about it.&n= bsp; Otherwise, I believe I should reply to them that the IETF is not curren= tly doing work in this area so their options include an ISE submission or something AD-sponsored that goes for E= xperimental status or suchlike.

 

I’d be happy if someone (or a few of us) here c= ould review it and make some suggestions about next steps.

 

Thanks,

 

M. Kucherawy

<hat-type=3D’OMA-Liaison’/>

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_1DE983233DBBEB4A81F18FABD8208D76226BE438XMB107ACNCrimne_-- From julian.reschke@gmx.de Sat Jan 14 03:51:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0F21F85AF for ; Sat, 14 Jan 2012 03:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCdvGjPFvLjw for ; Sat, 14 Jan 2012 03:51:40 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9387721F85AE for ; Sat, 14 Jan 2012 03:51:39 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 11:51:37 -0000 Received: from p5DCC28C9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.40.201] by mail.gmx.net (mp057) with SMTP; 14 Jan 2012 12:51:37 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+AXfUtfFOAuR81GfGiWbObeyrtMcmPGRmYXb6d/6 0Wo3pJ7MP55mbM Message-ID: <4F116C45.2060605@gmx.de> Date: Sat, 14 Jan 2012 12:51:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> In-Reply-To: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 11:51:40 -0000 Hi, I just submitted a new revision of draft-reschke-http-status-308 - see below (HTML version at ). At this point, I'd like to solicit additional feedback before I submit this to the IESG (which I plan to do in two weeks from now). With respect to the venue: this isn't an HTTPbis WG deliverable due to our constrained charter. It *could* be an Applications Area WG deliverable; however, in a similar case (draft-nottingham-http-new-status, just out of IETF LC) we decided not to do this. Feedback on this appreciated as well... Best regards, Julian -------- Original Message -------- Subject: I-D Action: draft-reschke-http-status-308-02.txt Date: Sat, 14 Jan 2012 02:55:23 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect) Author(s) : Julian F. Reschke Filename : draft-reschke-http-status-308-02.txt Pages : 7 Date : 2012-01-14 This document specifies the additional HyperText Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From sm@resistor.net Sat Jan 14 04:03:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468A221F8503; Sat, 14 Jan 2012 04:03:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP+rCpyK9QeI; Sat, 14 Jan 2012 04:03:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0315521F84F6; Sat, 14 Jan 2012 04:03:15 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0EC38d3029048; Sat, 14 Jan 2012 04:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326542594; i=@resistor.net; bh=ZcBVy0ynj9LmI3kldrOBqrt0ON1qSrXUFxLPiJdeAXE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=PkqRCff2RgCjQmFaI98Cr5hVLU7ruHKd7DH39LxlZ7s8smt5RH1E4et1D69HwFkPL o6UOXs84gm23FwjZ9OPpoPUZe+jYDOepP8P8w2klkAblQBIwVKRSNYicq0EBc7V8Ie d2+IZOc/tTdRS7D+smLd8PoaSMVqtoW4SbBJyQ34= Message-Id: <6.2.5.6.2.20120114024516.09b814f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jan 2012 04:00:29 -0800 To: Zoltan Ordogh From: SM In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.ne t> References: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: trustees@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 12:03:18 -0000 Hi Zoltan, At 11:11 13-01-2012, Zoltan Ordogh wrote: >Instead of responding to individual emails one by one, I try to >clarify some of the concerns at least in a single response. The single response does not address the issue I raised ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04079.html ). >PS. I am solely a technical contributor, so asking me IPR-related >questions will always be a dead end. Please direct those questions >directly to the appropriate contact person, which, in, this case is >Sarah Guichard. Thank you. draft-ordogh-spam-reporting-using-imap-kleansed-00 lists Zoltan Ordogh, Research In Motion Limited, as the author of the Internet-Draft. The document states that: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79." Do you have any concerns about draft-ordogh-spam-reporting-using-imap-kleansed-00 in respect to BCP 78 and BCP 79? Regards, -sm From vesely@tana.it Sat Jan 14 05:32:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387121F859F; Sat, 14 Jan 2012 05:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHcR3j9R8J0L; Sat, 14 Jan 2012 05:32:29 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6430721F8567; Sat, 14 Jan 2012 05:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326547947; bh=szuSUpjJlPSOEFbZeT6bT7V6pHJE0X7dsE9RW9uhpwU=; l=2493; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=HKotkOIBMRykYeUr/yJHXNR8hXbtoD2fANcWDcQCKaZ1XfJW9hHSnlgtTB72VtEcZ T1JmAwuowgDeS5LJiA3uN3W6xsgMBp6+OnuZEzZ8vEjJKPU5WZnk4c0meKXIrLMJUe JniTTPc7uHgo6XxMn4gZNX8E1JQoUCLitu0mEZ+I= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 14 Jan 2012 14:32:27 +0100 id 00000000005DC035.000000004F1183EB.00001F3E Message-ID: <4F1183EA.4070505@tana.it> Date: Sat, 14 Jan 2012 14:32:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Zoltan Ordogh References: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: ietf , apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 13:32:30 -0000 Hi Zoltan, On 13/Jan/12 20:11, Zoltan Ordogh wrote: > > I would like to start with a story. A rather similar story is summarized here: http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs > A bit later, a liaison statement was sent from OMA to IETF, seeking > collaboration and a “home†for the draft; as required by RFC3975. I assume you're still talking about SREP. I read a reply by John Klensin, whom I consider a sort of IETF guru, and it didn't prospect a bright future for the draft. I posted a "kleansed" version trying to address some of those concerns, in an attempt to improve the chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed the IPR qualification of the document too. In fact, I had the impression that the IPR was that way because OMA SpamRep was being mentioned, albeit not being specified, and also because that was one of the points raised. I hope my editing was correct, but your approval as author is needed. > PS. I am solely a technical contributor, So am I (but I signed no contract.) > so asking me IPR-related questions will always be a dead end. As a survival requirement, you have to be able to answer SM's question, though. > Please direct those questions directly to the appropriate contact > person, which, in, this case is Sarah Guichard. I sent my previous comment on this to Jon M. Jurgovan, cc Sarah Guichard, but had no reply either. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. The above boilerplate formally makes of no effect whatever else you wrote in that message, according to Andrew's explanation: http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html I usually group these issues to the same bin I use for IPRs, as I guess many others on this list do. Unfortunately, at times they become relevant, which is why we have to deal with them. See "survival" above :-) Specifically, if you need a written authorization of your employer in order to contribute technical specifications to the IETF under IETF's terms, please ask them to provide it. I guess we need that paperwork. Ciao Ale From evnikita2@gmail.com Sat Jan 14 05:44:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71721F8605 for ; Sat, 14 Jan 2012 05:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5l9oeMs3yCZ for ; Sat, 14 Jan 2012 05:44:09 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 287FD21F85D8 for ; Sat, 14 Jan 2012 05:44:09 -0800 (PST) Received: by obcwo10 with SMTP id wo10so4037181obc.31 for ; Sat, 14 Jan 2012 05:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ekvSJVGo0gHATFO03nW4qR3HljYl9jy5d7bhaCtOhbs=; b=M2Qja66/+FictiMfgPDDmN5voUGtM10tx2YjhdA9smSXf3rVQriXjflA7LVa5hR2bP AiYkUDGAHpDSxArjbUZBfV994ODG0/pcItJsx1xk2LmSGsv6lWACs7EHBiNo21dv75Mj M8jSn4ExztFSS8gRm8R4oCdjie8GQgd7FgTBg= MIME-Version: 1.0 Received: by 10.182.109.38 with SMTP id hp6mr4371265obb.64.1326548648818; Sat, 14 Jan 2012 05:44:08 -0800 (PST) Received: by 10.182.213.71 with HTTP; Sat, 14 Jan 2012 05:44:08 -0800 (PST) In-Reply-To: <4F116C45.2060605@gmx.de> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> Date: Sat, 14 Jan 2012 15:44:08 +0200 Message-ID: From: Mykyta Yevstifeyev To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 13:44:11 -0000 Hello, Hasn't HTTPbis WG considered incorporating this into httpbis-p2 draft? Is this a question of "experimentality" of the proposed extension (as Intended status is Experimental)? Otherwise, having quickly reviewed the document, I am fine with its publica= tion. Mykyta Yevstifeyev 2012/1/14 Julian Reschke : > Hi, > > I just submitted a new revision of draft-reschke-http-status-308 - see be= low > (HTML version at > )= . > > At this point, I'd like to solicit additional feedback before I submit th= is > to the IESG (which I plan to do in two weeks from now). > > With respect to the venue: this isn't an HTTPbis WG deliverable due to ou= r > constrained charter. It *could* be an Applications Area WG deliverable; > however, in a similar case (draft-nottingham-http-new-status, just out of > IETF LC) we decided not to do this. Feedback on this appreciated as well.= .. > > Best regards, Julian > > > -------- Original Message -------- > Subject: I-D Action: draft-reschke-http-status-308-02.txt > Date: Sat, 14 Jan 2012 02:55:23 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The Hypertext Transfer Protoco= l (HTTP) Status Code > 308 (Permanent Redirect) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Julian F. Reschke > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-reschke-http-status-308-02= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-14 > > =A0 This document specifies the additional HyperText Transfer Protocol > =A0 (HTTP) Status Code 308 (Permanent Redirect). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-reschke-http-status-308-02.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Sat Jan 14 06:29:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0A21F85F6 for ; Sat, 14 Jan 2012 06:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.321 X-Spam-Level: X-Spam-Status: No, score=-103.321 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8asg+3tZjo79 for ; Sat, 14 Jan 2012 06:29:25 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4FE1421F85E6 for ; Sat, 14 Jan 2012 06:29:24 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 14:29:23 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp013) with SMTP; 14 Jan 2012 15:29:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/UYvcYPhDU4trcc/vK2PZi8MjU6ooxpVPA2QCYqV PnacJg82pywH+Z Message-ID: <4F11913A.1020602@gmx.de> Date: Sat, 14 Jan 2012 15:29:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@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: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 14:29:26 -0000 On 2012-01-14 14:44, Mykyta Yevstifeyev wrote: > Hello, > > Hasn't HTTPbis WG considered incorporating this into httpbis-p2 draft? The charter of the HTTPbis WG currently does not allow adding new features. > Is this a question of "experimentality" of the proposed extension (as > Intended status is Experimental)? That as well. > Otherwise, having quickly reviewed the document, I am fine with its publication. Thanks. Best regards, Julian From derhoermi@gmx.net Sat Jan 14 07:18:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91B21F8545 for ; Sat, 14 Jan 2012 07:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtO6FH+657KJ for ; Sat, 14 Jan 2012 07:18:40 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 321E421F8596 for ; Sat, 14 Jan 2012 07:18:39 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 15:18:38 -0000 Received: from dslb-094-223-151-066.pools.arcor-ip.net (EHLO HIVE) [94.223.151.66] by mail.gmx.net (mp015) with SMTP; 14 Jan 2012 16:18:38 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX181FqNZhU01Di7H8+vBtZcEiPP0S9e33qWgK9ajxX TIKk4EgXJASGsx From: Bjoern Hoehrmann To: Julian Reschke Date: Sat, 14 Jan 2012 16:18:40 +0100 Message-ID: <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> In-Reply-To: <4F116C45.2060605@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 Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 15:18:41 -0000 * Julian Reschke wrote: >I just submitted a new revision of draft-reschke-http-status-308 - see >below (HTML version at >). > >At this point, I'd like to solicit additional feedback before I submit >this to the IESG (which I plan to do in two weeks from now). Your HTML example has a bad and doesn't even validate, never minding the lack of character encoding information in the sample re- sponse. I would suggest something like HTTP/1.1 308 Permanent Redirect Content-Type: text/html;charset=utf-8 Location: http://example.com/new ... <meta http-equiv='refresh' content='0; url=http://example.com/new'> ... which would avoid the stylistic problems in addition to being much shorter. In the IANA Considerations I think it is better to say something like "This document adds such and such to registry so and so" or whatever, rather than the imperative, as the "shall" will be weird after IANA added it, and not having to change such text is better than having to. The RFC3986 reference seems non-normative to me. Back when someone at the IETF secretariat checked internet drafts prior to posting them, I had one rejected because the Abstract was too short. Your Abstract is much shorter, it might be a good idea to add a sentence what the status code is for. I think you need a better term for "permanent URI". How about simply re- moving the "permanent" and possibly adding "new" to the second instance? The fallback requirement Unless the request method was HEAD, the representation of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s), since most user agents do not understand the 308 status code yet. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. strikes me as a bad idea. It's a transient problem so it should be con- ditioned and how widely supported this is, and it's only useful if you have some HTML implementation on the other end or an interactive user; a web service not meant for interactive use where you can be sure that the code is supported, because, say, you control the client, is unaffected, and if you add that as another exception you basically end up saying you can do this so your site works better with legacy clients in some situ- ations and making your site work good is probably a good idea, so I'd prefer just saying that. I don't really want to ponder whether I should send this hypertext response in response to an OPTIONS request in 2015, just because your specification says I should. -- 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 julian.reschke@gmx.de Sat Jan 14 07:28:07 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A031421F85A4 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.997 X-Spam-Level: X-Spam-Status: No, score=-102.997 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7JbOO9hLO8J for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:28:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 34F8521F85A1 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 07:28:05 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 15:28:04 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp013) with SMTP; 14 Jan 2012 16:28:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX180GMEgs4U0JCjRYoRW4Q5OXYx0YZSQ2StCwGfE3n Pnzul9pRDIrL8v Message-ID: <4F119EFE.7040106@gmx.de> Date: Sat, 14 Jan 2012 16:27:58 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann <derhoermi@gmx.net> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> In-Reply-To: <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 15:28:07 -0000 On 2012-01-14 16:18, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> I just submitted a new revision of draft-reschke-http-status-308 - see >> below (HTML version at >> <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-02.html>). >> >> At this point, I'd like to solicit additional feedback before I submit >> this to the IESG (which I plan to do in two weeks from now). > > Your HTML example has a bad<title> and doesn't even validate, never > minding the lack of character encoding information in the sample re- > sponse. I would suggest something like - what's the problem with the title? - why do I need to specify encoding? It's all US-ASCII - validator.nu says it's happy once I had the HTML4 strict doctype; would that work for you? > HTTP/1.1 308 Permanent Redirect > Content-Type: text/html;charset=utf-8 > Location: http://example.com/new > > ... > <meta http-equiv='refresh' content='0; url=http://example.com/new'> > ... > > which would avoid the stylistic problems in addition to being much > shorter. > > In the IANA Considerations I think it is better to say something like > "This document adds such and such to registry so and so" or whatever, > rather than the imperative, as the "shall" will be weird after IANA > added it, and not having to change such text is better than having to. The RFC Editor rewrites this part upon publication. > The RFC3986 reference seems non-normative to me. May be. > Back when someone at the IETF secretariat checked internet drafts prior > to posting them, I had one rejected because the Abstract was too short. > Your Abstract is much shorter, it might be a good idea to add a sentence > what the status code is for. I'll monitor what happens with draft-nottingham-http-new-status, just out of LC which looks similar to me. (It also has "invalid" HTML, why didn't you complain? :-) > I think you need a better term for "permanent URI". How about simply re- > moving the "permanent" and possibly adding "new" to the second instance? I'd prefer to use language consistent with RFC 2616. > The fallback requirement > > Unless the request method was HEAD, the representation of the response > SHOULD contain a short hypertext note with a hyperlink to the new > URI(s), since most user agents do not understand the 308 status code > yet. Therefore, the note SHOULD contain the information necessary for > a user to repeat the original request on the new URI. > > strikes me as a bad idea. It's a transient problem so it should be con- > ditioned and how widely supported this is, and it's only useful if you > have some HTML implementation on the other end or an interactive user; a > web service not meant for interactive use where you can be sure that the > code is supported, because, say, you control the client, is unaffected, > and if you add that as another exception you basically end up saying you > can do this so your site works better with legacy clients in some situ- > ations and making your site work good is probably a good idea, so I'd > prefer just saying that. I don't really want to ponder whether I should > send this hypertext response in response to an OPTIONS request in 2015, > just because your specification says I should. Again, this is consistent with RFC 2616 and HTTPbis (for now). We may want to tune the text in HTTPbis (please follow up over there), in which case I'll apply the same changes to the spec for 308. Best regards, Julian From derhoermi@gmx.net Sat Jan 14 07:49:06 2012 Return-Path: <derhoermi@gmx.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0321F84F1 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afkz1mumbwgG for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:49:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C24F821F84EA for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 07:49:05 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 15:48:53 -0000 Received: from dslb-094-223-151-066.pools.arcor-ip.net (EHLO HIVE) [94.223.151.66] by mail.gmx.net (mp008) with SMTP; 14 Jan 2012 16:48:53 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+qaQ4pyDSqCRJGowN5JhFXMsVugIOq6MhWaGGpuP UL0176mVuzldsJ From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Julian Reschke <julian.reschke@gmx.de> Date: Sat, 14 Jan 2012 16:48:59 +0100 Message-ID: <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> In-Reply-To: <4F119EFE.7040106@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 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 15:49:07 -0000 * Julian Reschke wrote: >- what's the problem with the title? When the redirect target disappears but the redirect does not, then you might end up with "Permanent Redirect" as title in search results which looks very broken and is uninformative. A better title would be "Moved to <new location>". >- why do I need to specify encoding? It's all US-ASCII Because RFC 2854 says it's strongly recommended to use the parameter. >- validator.nu says it's happy once I had the HTML4 strict doctype; >would that work for you? I can live with that. >The RFC Editor rewrites this part upon publication. Or forgets to do so and you forget to check and we end up with bad text. >> I think you need a better term for "permanent URI". How about simply re- >> moving the "permanent" and possibly adding "new" to the second instance? > >I'd prefer to use language consistent with RFC 2616. Well, in RFC 2616 it makes a little bit more sense as there you have the contrast with temporary addresses, but "permanent" is the condition that the resource has a different address than the current one, but that does not mean the new address will be "permanent". But oh well, your argument is good enough. -- 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 julian.reschke@gmx.de Sat Jan 14 07:54:22 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E821F84FD for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV1AUAq5He1o for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 07:54:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5254E21F84FB for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 07:54:21 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 15:54:20 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp059) with SMTP; 14 Jan 2012 16:54:20 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19GNuVt+z9GKmQnvYx8klbAorVC8V4G2J2u+eiH55 KgCljwmSCEj1CJ Message-ID: <4F11A526.6020909@gmx.de> Date: Sat, 14 Jan 2012 16:54:14 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann <derhoermi@gmx.net> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> In-Reply-To: <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 15:54:22 -0000 On 2012-01-14 16:48, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> - what's the problem with the title? > > When the redirect target disappears but the redirect does not, then you > might end up with "Permanent Redirect" as title in search results which > looks very broken and is uninformative. A better title would be "Moved > to<new location>". 3xx responses never should show up in search results. Or am I missing something? >> - why do I need to specify encoding? It's all US-ASCII > > Because RFC 2854 says it's strongly recommended to use the parameter. Well, it's a silly recommendation in this case. And it's NOT UPPERCASE! >> - validator.nu says it's happy once I had the HTML4 strict doctype; >> would that work for you? > > I can live with that. > >> The RFC Editor rewrites this part upon publication. > > Or forgets to do so and you forget to check and we end up with bad text. Please trust my AUTH48 skills. >>> I think you need a better term for "permanent URI". How about simply re- >>> moving the "permanent" and possibly adding "new" to the second instance? >> >> I'd prefer to use language consistent with RFC 2616. > > Well, in RFC 2616 it makes a little bit more sense as there you have the > contrast with temporary addresses, but "permanent" is the condition that > the resource has a different address than the current one, but that does > not mean the new address will be "permanent". But oh well, your argument > is good enough. Again, I'm with you in that we may want to tune the 3xx descriptions. But we should be consistent in what we change. Best regards, Julian From derhoermi@gmx.net Sat Jan 14 08:51:16 2012 Return-Path: <derhoermi@gmx.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4121F8542 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 08:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FtzVu4FpbUB for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 08:51:16 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DC23221F8483 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 08:51:15 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 16:51:11 -0000 Received: from dslb-094-223-151-066.pools.arcor-ip.net (EHLO HIVE) [94.223.151.66] by mail.gmx.net (mp014) with SMTP; 14 Jan 2012 17:51:11 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+fcVdCqp+fNWxu90y7zGeGFBxFvbSz8E70IzI0bO WgR0OamYgQnv3+ From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Julian Reschke <julian.reschke@gmx.de> Date: Sat, 14 Jan 2012 17:51:17 +0100 Message-ID: <1j93h7du1f85o4egf685k1g8upm4j9fsn4@hive.bjoern.hoehrmann.de> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> <4F11A526.6020909@gmx.de> In-Reply-To: <4F11A526.6020909@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 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 16:51:16 -0000 * Julian Reschke wrote: >On 2012-01-14 16:48, Bjoern Hoehrmann wrote: >> * Julian Reschke wrote: >>> - what's the problem with the title? >> >> When the redirect target disappears but the redirect does not, then you >> might end up with "Permanent Redirect" as title in search results which >> looks very broken and is uninformative. A better title would be "Moved >> to<new location>". > >3xx responses never should show up in search results. Or am I missing >something? When all of http://schnitzelmitkartoffelsalat.example/ redirects to some address the search engine cannot connect to, and someone searches for, say, "schnitzelmitkartoffelsalat.example", the search engine might still list the site in the results, and might link the proper address instead of the redirect target which it cannot resolve (reasons include that the user might be able to connect to sites the search engine can't connect to). >>> - why do I need to specify encoding? It's all US-ASCII >> >> Because RFC 2854 says it's strongly recommended to use the parameter. > >Well, it's a silly recommendation in this case. And it's NOT UPPERCASE! If you really want to argue that the example is better when it does not declare the character encoding without very clearly indicating that the declaration has been elided because it's "all US-ASCII" ... Do you still keep Internet Explorer 6 around? It should be possible to make an ex- ample that does not redirect to where you think it would, but I would have to set up a virtual machine for testing and there kinda would be no point if you don't have the right browser to try it. -- 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 julian.reschke@gmx.de Sat Jan 14 09:15:41 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBA021F84D4 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 09:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALjIDbScPr7j for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 09:15:41 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D3EF221F84AA for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 09:15:40 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 17:15:39 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp071) with SMTP; 14 Jan 2012 18:15:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+lKvkUlr2lBpjkXemFDz6EcpTnJO1aBhg3ixTl7h +axDmIsDyj00wJ Message-ID: <4F11B832.1040205@gmx.de> Date: Sat, 14 Jan 2012 18:15:30 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann <derhoermi@gmx.net> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> <4F11A526.6020909@gmx.de> <1j93h7du1f85o4egf685k1g8upm4j9fsn4@hive.bjoern.hoehrmann.de> In-Reply-To: <1j93h7du1f85o4egf685k1g8upm4j9fsn4@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 17:15:41 -0000 On 2012-01-14 17:51, Bjoern Hoehrmann wrote: > ... >>>> - why do I need to specify encoding? It's all US-ASCII >>> >>> Because RFC 2854 says it's strongly recommended to use the parameter. >> >> Well, it's a silly recommendation in this case. And it's NOT UPPERCASE! > > If you really want to argue that the example is better when it does not > declare the character encoding without very clearly indicating that the > declaration has been elided because it's "all US-ASCII" ... Do you still I think it doesn't matter at all; but I'll change it. > keep Internet Explorer 6 around? It should be possible to make an ex- > ample that does not redirect to where you think it would, but I would > have to set up a virtual machine for testing and there kinda would be no > point if you don't have the right browser to try it. Could you elaborate about what this has to do with IE6? Best regards, Julian From john-ietf@jck.com Sat Jan 14 09:40:17 2012 Return-Path: <john-ietf@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D121F8578; Sat, 14 Jan 2012 09:40:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0NqVTusuzfP; Sat, 14 Jan 2012 09:40:16 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38B21F856C; Sat, 14 Jan 2012 09:40:16 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Rm7aJ-000PBX-Qr; Sat, 14 Jan 2012 12:40:08 -0500 Date: Sat, 14 Jan 2012 12:40:06 -0500 From: John C Klensin <john-ietf@jck.com> To: Alessandro Vesely <vesely@tana.it>, Zoltan Ordogh <zordogh@rim.com> Message-ID: <8F9BBA9DC2586FB6E35803F4@PST.JCK.COM> In-Reply-To: <4F1183EA.4070505@tana.it> References: <F5833273385BB34F99288B3648C4F06F19C6C157A4@EXCH-C2.corp.cloudmark.com> <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> <4F1183EA.4070505@tana.it> 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: ietf <ietf@ietf.org>, apps-discuss@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 17:40:17 -0000 --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely <vesely@tana.it> wrote: >... >> A bit later, a liaison statement was sent from OMA to IETF, >> seeking collaboration and a "home" for the draft; as >> required by RFC3975. > > I assume you're still talking about SREP. I read a reply by > John Klensin, whom I consider a sort of IETF guru, and it > didn't prospect a bright future for the draft. I posted a > "kleansed" version trying to address some of those concerns, > in an attempt to improve the chances that APPSAWG will adopt > it. Somewhat arbitrarily, I changed the IPR qualification of > the document too. In fact, I had the impression that the IPR > was that way because OMA SpamRep was being mentioned, albeit > not being specified, and also because that was one of the > points raised. > I hope my editing was correct, but your approval as author is > needed. >... Alessandro, Zoltan, Guru or not (some would certainly dispute that), this is strictly a personal comment and personal opinion. Just to clarify my view of this (other may have different opinions)... (1) I think SM's question, and anything else having to do with the IRP status of this document (or pair of documents) has to be completely clear. The IETF could certainly decide to process the document even if the technology were encumbered (has happened many times before), but uncertainty is pretty much a showstopper. Alessandro's concerns about distribution disclaimers on email messages that discuss the topic only reinforce my concern in this area. (2) Similarly, both of you, and RIM and OMA, need to understand that handing something like this off to IETF, especially for standards-track processing, is a handoff of change control. The IETF can modify (we hope improve) things as it likes, even after approval of the first version of the document as a Proposed Standard. Joint ownership/ change control arrangements are possible, but they are very hard and time-consuming to negotiate and perhaps, due to some bad experience, likely to get harder. (3) The leadership of AppAWG, and the ADs, will do as they think appropriate, but, if I were making the rules, no one would spend energy trying to sort out the differences between a pair of competing documents. I suggest that the two of you get together, offlist, and see if you can reach clear agreement on a single draft that supercedes both documents. That is a matter of courtesy to those of us you are asking to consider the work and is quite independent of the IPR concerns (although they do interact). All three of those issues are administrative, not technical. They should be easily solved. My personal preferences is that the AppsAWG, and the apps-discuss list, spend no more time on this until/unless they are resolved. YMMD, of course. (4) The core of my previous comments was a technical concern, not an administrative one. Even if one ignores the security concerns, the stability issues for normative references, and so on, many of us believe that the IMAP protocol has become far too complicated, with too many options and features. That complexity increases the requirements on IMAP servers that wish to support a wide range of clients and applications and on clients that wish to support a reasonable range of features but work with servers that may not support all of them. Whatever the advantages, too much code and too many code paths are not conducive to very high quality, bug-free, implementations. This proposal seems to me to take IMAP into a whole new area. I'm not questions whether or not that is possible because I'd be certain it would be, even without the assertiosn that there are implementations out there. I am questioning whether there is a strong enough case to be made that this belongs in IMAP to justify further clutter in the protocol and even lower odds of seeing high-quality clients. I observe that probably the best general-purpose --as distinct from, e.g., specialized for mobile devices-- IMAP client out there is now quite old, largely unmaintained, and has not picked up on any of the new features added in the last several years. Neither version of the document really addresses that issue. Some of the comments from the two of you about why it is hard and/or expensive to do it in other ways certainly have merit, but need, IMO, to be balanced off against other considerations including the above. That balance won't be easy to find especially since, as I am sure you both know, there is no community agreement about the degree to which it is appropriate to make normal, desired, email work worse in order to provide better facilities for spam-handling, especially spam-handling at or after the final delivery MTA. Bottom line: I think we should see a single draft that really addresses all of the technical issues, including the design tradeoffs and security topics, _and_ addresses the IPR/administrative one in a way with which we can all be comfortable before being asked to decide whether AppsAWG should take this up. If asked to make a decision without such a draft having been posted, I would vote "no". john From derhoermi@gmx.net Sat Jan 14 09:49:27 2012 Return-Path: <derhoermi@gmx.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AEC21F853B for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 09:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpYV2kVBPvuU for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 09:49:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 862FE21F852D for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 09:49:26 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 17:49:23 -0000 Received: from dslb-094-223-151-066.pools.arcor-ip.net (EHLO HIVE) [94.223.151.66] by mail.gmx.net (mp034) with SMTP; 14 Jan 2012 18:49:23 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/BeL8SnrTB6JI5UHcr+b0GKx23HbQMj+aBdo4kB5 lP5PPq72uCjOIn From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Julian Reschke <julian.reschke@gmx.de> Date: Sat, 14 Jan 2012 18:49:30 +0100 Message-ID: <r6e3h7tjp3q1fup4qbkugskociimsvoucs@hive.bjoern.hoehrmann.de> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> <4F11A526.6020909@gmx.de> <1j93h7du1f85o4egf685k1g8upm4j9fsn4@hive.bjoern.hoehrmann.de> <4F11B832.1040205@gmx.de> In-Reply-To: <4F11B832.1040205@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 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 17:49:27 -0000 * Julian Reschke wrote: >> keep Internet Explorer 6 around? It should be possible to make an ex- >> ample that does not redirect to where you think it would, but I would >> have to set up a virtual machine for testing and there kinda would be no >> point if you don't have the right browser to try it. > >Could you elaborate about what this has to do with IE6? Without explicit declarations browsers will auto-detect an encoding and in case of Internet Explorer 6 that means that some US-ASCII documents without encoding declarations are treated as UTF-7 encoded documents, so if you try to redirect to something like /Bj+APY-rn/ IE might end up on /Björn/ even though "Bj+APY-rn" is "all US-ASCII". That problem was not specific to Internet Explorer 6, but it's the cheapest target. Avoiding such misdetection is important for security reasons, so responses with- out encoding declarations are likely to be or to become security risks. It's like seeing `"SELECT * FROM table WHERE column = '$user_input';"` in a PHP tutorial. -- 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 julian.reschke@gmx.de Sat Jan 14 10:17:30 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5B21F8574 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 10:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj6t+pyeLUcr for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 10:17:29 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1F93821F855E for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 10:17:28 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 18:17:25 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp025) with SMTP; 14 Jan 2012 19:17:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/j5qAh2JHjIj3IpgxgU+07gtcrDCi7EWOc11VyuW REf3DJpKl13t9Q Message-ID: <4F11C6B0.8090506@gmx.de> Date: Sat, 14 Jan 2012 19:17:20 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann <derhoermi@gmx.net> References: <20120114105523.32324.64307.idtracker@ietfa.amsl.com> <4F116C45.2060605@gmx.de> <8i53h715g9kjghtgqhsjqvb4mdnelqaqa0@hive.bjoern.hoehrmann.de> <4F119EFE.7040106@gmx.de> <qt73h7p28jvcc91at1r4n8c8cpdsetjfod@hive.bjoern.hoehrmann.de> <4F11A526.6020909@gmx.de> <1j93h7du1f85o4egf685k1g8upm4j9fsn4@hive.bjoern.hoehrmann.de> <4F11B832.1040205@gmx.de> <r6e3h7tjp3q1fup4qbkugskociimsvoucs@hive.bjoern.hoehrmann.de> In-Reply-To: <r6e3h7tjp3q1fup4qbkugskociimsvoucs@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] informal Last Call on draft-reschke-http-status-308-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 18:17:30 -0000 On 2012-01-14 18:49, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >>> keep Internet Explorer 6 around? It should be possible to make an ex- >>> ample that does not redirect to where you think it would, but I would >>> have to set up a virtual machine for testing and there kinda would be no >>> point if you don't have the right browser to try it. >> >> Could you elaborate about what this has to do with IE6? > > Without explicit declarations browsers will auto-detect an encoding and > in case of Internet Explorer 6 that means that some US-ASCII documents > without encoding declarations are treated as UTF-7 encoded documents, so > if you try to redirect to something like /Bj+APY-rn/ IE might end up on > /Björn/ even though "Bj+APY-rn" is "all US-ASCII". That problem was not > specific to Internet Explorer 6, but it's the cheapest target. Avoiding > such misdetection is important for security reasons, so responses with- > out encoding declarations are likely to be or to become security risks. > It's like seeing `"SELECT * FROM table WHERE column = '$user_input';"` > in a PHP tutorial. Ack. Thanks. "charset=" added. From alexey.melnikov@isode.com Sat Jan 14 13:35:32 2012 Return-Path: <alexey.melnikov@isode.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70FF21F8547 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 13:35:32 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyJbNb7WmWNF for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 13:35:32 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8621F8546 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 13:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326576930; d=isode.com; s=selector; i=@isode.com; bh=ycVYX+W0fD2gBy6JV4Y7WGei9Kw4vqjheFaNy8hYi48=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RG20TzvUkF27GvMVZeqFislejxWVpUAuoWt1l25TPZ9XK2nurU9HD8ynC9gAKJkF5uh9OA N2nYZitdJCk0vvYhGj5P+qEdz5yu6yQ277KUHjqavPmFu6ttwQbVP8BruNh5gkA3nx2N32 4IuuNbNTJloVwMSXnDjXDhkQbV6D7tM=; Received: from [188.29.195.193] (188.29.195.193.threembb.co.uk [188.29.195.193]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TxH1HQAV54VC@rufus.isode.com>; Sat, 14 Jan 2012 21:35:27 +0000 Message-ID: <4F11F52D.2040600@isode.com> Date: Sat, 14 Jan 2012 21:35:42 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Murray S. Kucherawy" <msk@cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] AppsDir Review of draft-kucherawy-authres-spf-erratum-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 21:35:32 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-kucherawy-authres-spf-erratum-01 Title: Authentication-Results Registration Update for SPF Results Reviewer: Alexey Melnikov Review Date: January 14, 2012 IETF Last Call Date: 3 February, 2012 IESG Telechat Date: N/A This draft updates the registry of authentication method results in Authentication-Results: message header fields, correcting an error for one Sender Policy Framework (SPF) entry. It also update the corresponding IANA registry with field "status" (i.e. "active" or "deprecated"). Summary: This draft is ready for publication as a Standards Track RFC. Major Issues: None Minor Issues: None Nits: (were already caught by SecDir and other reviews.) From johnl@iecc.com Sat Jan 14 15:52:32 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8529921F84D3 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 15:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.215 X-Spam-Level: X-Spam-Status: No, score=-104.215 tagged_above=-999 required=5 tests=[AWL=-1.616, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSGhBD1Z1LTZ for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 15:52:32 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F085221F84D1 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 15:52:31 -0800 (PST) Received: (qmail 93414 invoked from network); 14 Jan 2012 23:52:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Jan 2012 23:52:29 -0000 Date: 14 Jan 2012 23:52:07 -0000 Message-ID: <20120114235207.20340.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <AD693E95D4252DC3E8F3832F@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 23:52:32 -0000 >Let's not turn "Received:" further into a kludge just because it >is there. I see your point, but I'm trying to weigh the relative uglitude of adding more clauses in Received: lines against adding yet more trace headers. IANA already has a registry for Additional-registered-clauses at http://www.iana.org/assignments/mail-parameters, but as far as I can tell, there's no registry of trace headers. On the third hand, there probably should be a registry of trace headers, since there's nothing I can find now beyond the extremely incomplete list in section 3.6.7 of RFC 5322. R's, John From dhc@dcrocker.net Sat Jan 14 16:48:45 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10521F84A2 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 16:48:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+1eMx7EiD7V for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 16:48:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0621F848B for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 16:48:44 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0F0mcgV027703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 16:48:43 -0800 Message-ID: <4F122257.10301@dcrocker.net> Date: Sat, 14 Jan 2012 16:48:23 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John C Klensin <john-ietf@jck.com> References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar k.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> In-Reply-To: <AD693E95D4252DC3E8F3832F@PST.JCK.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, 14 Jan 2012 16:48:44 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 00:48:45 -0000 On 1/13/2012 10:53 AM, John C Klensin wrote: > SMTP rather carefully defines "trace information" or "trace > headers" and then limits that category to two types of What is the import of this observation, relative to the current proposal? You appear to be intending it as a constraint, but I don't understand how, specifically. > In any event, we have discovered repeatedly (and sometimes > painfully) that the the Received header field is not well > designed for extensibility. I don't recall seeing these claims before or documentation that they are valid. Can you provide some citations? Note that the definition of the Received: header field provides a registry for addition of new clauses, so you appear to be saying that extensibility is not viable. > It depends on an ordered, > context-dependent, reserved keyword model (something I don't If you are saying that the specific placement of the clause is essential, then please document this requirement -- beyond what is in the RFC5321 spec and the proposed clause spec -- both in terms of what you believe is acceptable and different from the current specification and also the basis for this. > we should have a serious discussion about how far > we want to go in extending "Received:" and when it is time to > add one or more additional Trace header fields, possibly with a > typology of functions that each serves (beyond "inserted by a > transit MTA or something else") and Please review the latest version, specifically the 'Discussion' section, which provides exactly the consideration you are calling for. > with a syntax that is > clearly name-value based, rather than even partially dependent > on parser recognition of specific keywords. I don't understand the requirement you are proposing, since the "name" of a name/value pair is a specific keyword. Hence, your saying "rather than" appears to be contradictory. You seem to be meaning something else, but I can't guess what. > Let's not turn "Received:" further into a kludge just because it > is there. How is it already a kludge? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Sat Jan 14 17:57:55 2012 Return-Path: <john-ietf@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4ED21F84B3 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 17:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibg86WOJlfXY for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 17:57:54 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id AE5D821F845A for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 17:57:54 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RmFM1-0004Vv-82; Sat, 14 Jan 2012 20:57:53 -0500 Date: Sat, 14 Jan 2012 20:57:52 -0500 From: John C Klensin <john-ietf@jck.com> To: John Levine <johnl@taugh.com>, apps-discuss@ietf.org Message-ID: <61D306C70A44794D8930CCB6@PST.JCK.COM> In-Reply-To: <20120114235207.20340.qmail@joyce.lan> References: <20120114235207.20340.qmail@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 01:57:55 -0000 --On Saturday, January 14, 2012 23:52 +0000 John Levine <johnl@taugh.com> wrote: >> Let's not turn "Received:" further into a kludge just because >> it is there. > > I see your point, but I'm trying to weigh the relative > uglitude of adding more clauses in Received: lines against > adding yet more trace headers. IANA already has a registry for > Additional-registered-clauses at > http://www.iana.org/assignments/mail-parameters, but as far as > I can tell, there's no registry of trace headers. There is no registry of trace headers because there are, and have been since RFC 821, only two of them: "Received:" and "Return-path:". I'm suggesting that the time may have come to add one or more rather than continuing to overload "Received:". If we were to start adding additional ones, a registry would certainly be in order. Unless we do, a registry would just be work for its own sake, at least IMO. > On the third hand, there probably should be a registry of > trace headers, since there's nothing I can find now beyond the > extremely incomplete list in section 3.6.7 of RFC 5322. See above. And here we go down that rathole: I hope that 5321 and 5322 are consistent, but, if there were any respect in which they were not, we get back to the old question of which one is authoritative: 5321 because creating the things and putting them in is the responsibility of the MTA or 5322 because they are, after all, header field names. john From dhc@dcrocker.net Sat Jan 14 19:03:41 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8922B21F84AF for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 19:03:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORnFaGL77iPW for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 19:03:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C89F921F84B2 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 19:03:40 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0F33WDP001928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 19:03:37 -0800 Message-ID: <4F1241F5.2000906@dcrocker.net> Date: Sat, 14 Jan 2012 19:03:17 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John C Klensin <john-ietf@jck.com> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> In-Reply-To: <61D306C70A44794D8930CCB6@PST.JCK.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, 14 Jan 2012 19:03:37 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 03:03:41 -0000 On 1/14/2012 5:57 PM, John C Klensin wrote: > I'm suggesting that the time may have come to > add one or more rather than continuing to overload "Received:". "continuing to"? please explain the history of overloading that has taken place; I'm not aware of it. Please then explain how the current proposal exceeds a reasonable enhancement of the Received field. "received" refers to transitions. The enhancement merely documents more transitions. Please also note that creating a separate kind of header field, such as for transitions /within/ a host, will then require correlating the /within/ fields and the /between/ (Received:) fields. If you think there is anything about the current situation that is a kluge, you ain't seen nothing' yet. > And here we go down that rathole: I hope that 5321 and 5322 are > consistent, but, if there were any respect in which they were > not, we get back to the old question of which one is > authoritative: 5321 because creating the things and putting them > in is the responsibility of the MTA or 5322 because they are, > after all, header field names. What is it that will cause us to go down that rathole? There's nothing in the current proposal that creates the potential for loss of synchrony between 5321 and 5322. So how is your concern relevant here? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sat Jan 14 19:55:07 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD32121F8493 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 19:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FupRSPpciWn9 for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 19:55:06 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2F321F8492 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 19:55:06 -0800 (PST) Received: (qmail 76549 invoked from network); 15 Jan 2012 03:55:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=12b04.4f124e15.k1201; bh=QfVKvTz4oHJE4aOvU2CfCyZUSfFPdeLuvIodQwXRAMc=; b=ob/Dfusfk6R0jI2JjORuMhhvtEJYeuyx2qqbHIs3bCg6OW3X3m90zyL/uXZ4NiP/yopTsHr8UWOeVm/t/vcK1wRj+b8HWtfc21OimWMigttkQnx9efiugyaxvvpdWeRyE6H/n8bpF0NvWUCXTpxYI1By+wwFKbFq27AFwz77ATs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Jan 2012 03:54:39 -0000 Date: 14 Jan 2012 22:55:01 -0500 Message-ID: <alpine.BSF.2.00.1201142235000.1943@joyce.lan> From: "John R. Levine" <johnl@iecc.com> To: "John C Klensin" <john-ietf@jck.com> In-Reply-To: <61D306C70A44794D8930CCB6@PST.JCK.COM> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 03:55:08 -0000 >> http://www.iana.org/assignments/mail-parameters, but as far as >> I can tell, there's no registry of trace headers. > > There is no registry of trace headers because there are, and > have been since RFC 821, only two of them: "Received:" and > "Return-path:". If you believe what the RFCs say, there are many more trace headers than those two. RFC 5322 makes a special case of Resent-foo: fields, but they act an awful lot like trace headers. RFC 5451 says that Authentication-Results "should be treated as a Trace Field." RFC 5436 says "The 'Auto-Submitted' header field is considered a 'trace field'". RFC 4408 says that "The Received-SPF header field is a trace field." RFC 5518 says "VBR-Info is a 'trace header field'". That horse left the barn a long time ago. RFC 5537 also lists a bunch of trace fields for usenet, which isn't mail, but it might be a good idea to reserve them to avoid collisions. > I'm suggesting that the time may have come to > add one or more rather than continuing to overload "Received:". It's certainly time for a trace field registry. And I suppose that if we have one, adding new trace fields isn't that big a deal. R's, John From msk@cloudmark.com Sat Jan 14 20:30:43 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFBD21F844F for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 20:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0hN96TmzNBi for <apps-discuss@ietfa.amsl.com>; Sat, 14 Jan 2012 20:30:42 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8006A21F8449 for <apps-discuss@ietf.org>; Sat, 14 Jan 2012 20:30:42 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 14 Jan 2012 20:30:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 14 Jan 2012 20:30:41 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Sat, 14 Jan 2012 20:30:43 -0800 Thread-Topic: [apps-discuss] Adoption of draft-kucherawy-received-state? Thread-Index: AczTF5zorF/YjQkhQqWMLPi5R5O2wQAJqrSA Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158A3@EXCH-C2.corp.cloudmark.com> References: <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <20120114235207.20340.qmail@joyce.lan> In-Reply-To: <20120114235207.20340.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 04:30:43 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John Levine > Sent: Saturday, January 14, 2012 3:52 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? >=20 > I see your point, but I'm trying to weigh the relative uglitude of > adding more clauses in Received: lines against adding yet more trace > headers. IANA already has a registry for Additional-registered-clauses > at http://www.iana.org/assignments/mail-parameters, but as far as I can > tell, there's no registry of trace headers. In fact, this was added by RFC5321, and it is this mechanism that this draf= t is attempting to employ. So if augmenting Received is a bad idea, I'm le= ft wondering why RFC5321 deliberately enabled it. -MSK From msk@cloudmark.com Sat Jan 14 20:39:07 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CB321F848B; Sat, 14 Jan 2012 20:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es-lq0UJYN1n; Sat, 14 Jan 2012 20:39:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8A21F8486; Sat, 14 Jan 2012 20:39:02 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 14 Jan 2012 20:38:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 14 Jan 2012 20:39:01 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" <draft-ietf-dnsext-xnamercode.all@tools.ietf.org>, "dnsext@ietf.org" <dnsext@ietf.org> Date: Sat, 14 Jan 2012 20:39:03 -0800 Thread-Topic: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode Thread-Index: AczTF7h+C89jFOt7SQi7vDe/yejG+gAJy4UA Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158A4@EXCH-C2.corp.cloudmark.com> References: <AczRWOSb3T5cxrYTTDKTQq7fMmXudQ==> <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com> <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.gmail.com> In-Reply-To: <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 04:39:07 -0000 Hi Donald, > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Saturday, January 14, 2012 3:53 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; draft-ietf-dnsext-xnamercode.all@tools.ietf.or= g; dnsext@ietf.org > Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode >=20 > > Section 2 identifies two status bits as part of this clarification > > document.=A0 However, it also says explicitly that their definitions ar= e > > unchanged from the documents that introduced them.=A0 I'm curious then > > as to why they are included in this document at all; that is, what > > clarification is being provided?=A0 Unlike Section 3, any ambiguity > > about their use has not been identified here.=A0 If in fact there isn't > > any, I think this section can be removed.=A0 If you like, you can > > introduce references to and overviews of their definitions in a new > > subsection of Section 1, since you do talk about them in Section 4. >=20 > Well, the name of the document is "xNAME RCODE and Status Bits > Clarification". I'm not sure why it would make that much difference to > move Section 2 on status bits to a new subpart of Section 1. As you > say, they are further discussed in Section 4. It seems to me that > something can "clarify" with making any change. Given no objections in > the DNSEXT WG to this material, I am inclined to leave it in. My point is not so much the position of the text as its purpose. You're ri= ght of course about the title, but it's not clear to me what is being clari= fied with respect to the status bits, since you explicitly say they are unc= hanged from their definitions. That is, it seems to me deleting Section 2 = entirely wouldn't remove anything from the document. If the purpose is merely to restate their definitions or refer to them so t= he Section 4 text is more meaningful, then informative references to the pl= aces where those are when you talk about them in Section 4 seems simpler th= an what's there now. -MSK From sm@resistor.net Sun Jan 15 00:59:44 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB6221F84A0 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 00:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uczoU09G1Mqt for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 00:59:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB521F849C for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 00:59:41 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0F8xLfh017418; Sun, 15 Jan 2012 00:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326617969; i=@resistor.net; bh=it41xNceEZPLkcdgr+Z8vs2A1UStKCInJEbrhwOmDdA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=BBAUyIcx4RR2Kq6i0CuoVU+XruQS/RrNKl4MIvUeP8CjBXgXdgjWp4soRhJknkt+d uZTw8sBZf1QTNVnltn0QDFTgPMJR62vUqC4/wse2+uWoFL8KmPk5eLfWWmPJvTB7Z+ UPmXbUiNNYd820NIOttD67FvgDQaF+xxwIGExFqE= Message-Id: <6.2.5.6.2.20120114233239.0ac5fd88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Jan 2012 00:54:07 -0800 To: "John R. Levine" <johnl@iecc.com> From: SM <sm@resistor.net> In-Reply-To: <alpine.BSF.2.00.1201142235000.1943@joyce.lan> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 08:59:44 -0000 Hi John, At 19:55 14-01-2012, John R. Levine wrote: >If you believe what the RFCs say, there are many more trace headers >than those two. RFC > 5322 makes a special case of Resent-foo: fields, but they act an > awful lot like trace headers. RFC 5451 says that > Authentication-Results "should be treated as a Trace Field." RFC > 5436 says "The 'Auto-Submitted' header field is considered a 'trace > field'". RFC 4408 says that "The Received-SPF header field is a > trace field." RFC 5518 says "VBR-Info is a 'trace header field'". > That horse left the barn a long time ago. RFC 5537 also lists a > bunch of trace fields for usenet, which isn't mail, but it might be > a good idea to reserve them to avoid collisions. The Auto-Submitted header field is defined in RFC 3834. It references RFC 2822 normatively. RFC 5451 defines Authentications-Results and references RFC 5322 normatively. RFC 5518 (VBR-Info) references RFC 5322 normatively. RFC 4408 references RFC 2822 normatively. RFC 5518 likely used the same path as RFC 5451. RFC 3834 does not mention Trace Field but RFC 5436 does. I would say that some of the header fields were defined as "trace fields" to restrict the ordering of existing "trace fields header lines". RFC 5322 contains a requirement not to reorder "trace header fields". Most of the header fields can be traced backed to RFC 5322 as that document defines a syntax for text messages. Beliefs in RFCs could be traced back to the feature sought. Regards, -sm From sm@resistor.net Sun Jan 15 02:56:49 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8848121F8470 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 02:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eu+T15A6wTI for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 02:56:44 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB68721F846B for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 02:56:44 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0FAuQRs018862; Sun, 15 Jan 2012 02:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326624998; i=@resistor.net; bh=31c0mpaNQmLUZLjpNxS927T0mzPxnoP+4t3c0TdS07U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=eVN7zTd8S2vfH5XSI6D73aX/+RR4eTLAlh5TidVUgb00voyyr9C+5ZNhOxTqxvwO9 vxuodP4hEm4+F7glrPvaWtEh5rs6CXYPspf+WD5l/feoxwTD5O7F/AHx4tNi4Cu4QC P9uGgnaYGrfIqPuKXb1QsMyKzcLozSGrnNoYfm0A= Message-Id: <6.2.5.6.2.20120115013005.098f3460@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Jan 2012 02:53:20 -0800 To: "Murray S. Kucherawy" <msk@cloudmark.com> From: SM <sm@resistor.net> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158A3@EXCH-C2.corp.cl oudmark.com> References: <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <20120114235207.20340.qmail@joyce.lan> <F5833273385BB34F99288B3648C4F06F19C6C158A3@EXCH-C2.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 10:56:49 -0000 Hi Murray, At 20:30 14-01-2012, Murray S. Kucherawy wrote: >In fact, this was added by RFC5321, and it is this mechanism that >this draft is attempting to employ. So if augmenting Received is a >bad idea, I'm left wondering why RFC5321 deliberately enabled it. I'll comment on the Additional-registered-clauses part only. The Additional-registered-clauses registry was added, in my opinion, to keep matters simple. What made it into RFC 5321 IANA Considerations Section is: "The registry will contain clause names, a description, a summary of the syntax of the associated String, and a reference. As new clauses are defined, they may, in principle, specify creation of their own registries if the Strings consist of reserved terms or keywords rather than less restricted strings. As with link and protocol identifiers, additional clauses may be registered only by standardization or by way of an RFC-documented, IESG-approved, Experimental protocol extension. The additional clause name space is for identification and is not limited in size: the IESG is encouraged to approve on the basis of clear documentation, actual use or strong signs that the clause will be used, and a distinct requirement rather than preferences about the properties of the clause itself." The Additional-registered-clauses sub-registry is currently empty as the clause is not used in any RFC. I don't have an opinion at the moment about what should or should not go into the registry. Regards, -sm From john-ietf@jck.com Sun Jan 15 07:51:49 2012 Return-Path: <john-ietf@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD29A21F84A2 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 07:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT9wMnF+uwIg for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 07:51:49 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B77AA21F845C for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 07:51:48 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RmSMy-000E0p-Dj; Sun, 15 Jan 2012 10:51:44 -0500 Date: Sun, 15 Jan 2012 10:51:43 -0500 From: John C Klensin <john-ietf@jck.com> To: "John R. Levine" <johnl@iecc.com> Message-ID: <54978B203C73F673C5287DE3@PST.JCK.COM> In-Reply-To: <alpine.BSF.2.00.1201142235000.1943@joyce.lan> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 15:51:49 -0000 --On Saturday, January 14, 2012 22:55 -0500 "John R. Levine" <johnl@iecc.com> wrote: >>> http://www.iana.org/assignments/mail-parameters, but as far >>> as I can tell, there's no registry of trace headers. >> >> There is no registry of trace headers because there are, and >> have been since RFC 821, only two of them: "Received:" and >> "Return-path:". > > If you believe what the RFCs say, there are many more trace > headers than those two. RFC 5322 makes a special case of > Resent-foo: fields, but they act an awful lot like trace > headers. RFC 5451 says that Authentication-Results "should be > treated as a Trace Field." RFC 5436 says "The > 'Auto-Submitted' header field is considered a 'trace field'". > RFC 4408 says that "The Received-SPF header field is a trace > field." RFC 5518 says "VBR-Info is a 'trace header field'". > That horse left the barn a long time ago. RFC 5537 also lists > a bunch of trace fields for usenet, which isn't mail, but it > might be a good idea to reserve them to avoid collisions. This is the sort of disconnect between the specifications about SMTP MTAs and the specifications of header fields and their names that I mentioned in an earlier note and to which Dave Crocker took significant exception. While I don't want to go on a quest for specific language, I believe that, from the MTA point of view, part of the definition of "trace field" is that they are inserted by MTAs, in transit. From that point of view, while fields like the Resent-* set are used to trace the handling of a message (but so are Sender and maybe Message-ID), they are MUA functions and hence not trace fields in the MTA sense. Some of the things you list above are probably consistent with the MTA definition; others are probably not. I think that distinction is worth preserving and, despite some excessively casual language, don't think we have breached it yet. Then again, I think the multi-level distinction between envelope and content information in X.400 is one of the few important desirable distinctions between their model and ours (in which transport tracing information is put into message headers because we don't have a better place). YMMD, of course. >> I'm suggesting that the time may have come to >> add one or more rather than continuing to overload >> "Received:". > > It's certainly time for a trace field registry. And I suppose > that if we > have one, adding new trace fields isn't that big a deal. I don't have any problem with such a registry. It seems to me that you've done most of the work of identifying what should be in it. Personally, I'd rather see either separate subregistries for MTA and MUA trace info or a field that distinguishes the former from the latter. Do you want to generate the I-D? I'm happy to review and/or help as needed. best, john From d3e3e3@gmail.com Sat Jan 14 15:53:24 2012 Return-Path: <d3e3e3@gmail.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005221F84D9; Sat, 14 Jan 2012 15:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG8zTbZ4Nuwl; Sat, 14 Jan 2012 15:53:24 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459EC21F84D8; Sat, 14 Jan 2012 15:53:23 -0800 (PST) Received: by lagv3 with SMTP id v3so1113849lag.31 for <multiple recipients>; Sat, 14 Jan 2012 15:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9NXP+55R/rk3aHjHLdCS9KBXJ4Jkm17rnKnfNsMWHgM=; b=YvqNdOWCsE+FTDKG/Kr/UO552T9NtunYb29Eqd7XGgrznfiHQzwzY/D30pO4aoTOtg PncHku+yZIP0dtgo6zC7ayHuCRfvWC9YESlo91JteNtHwIkrrjtytwPaWlSuS0KQQSo+ RWc3XADtiePpilfTi02k1maPedc1j/PkgLXH0= Received: by 10.152.113.131 with SMTP id iy3mr3148865lab.39.1326585202280; Sat, 14 Jan 2012 15:53:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.12.9 with HTTP; Sat, 14 Jan 2012 15:53:01 -0800 (PST) In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com> References: <AczRWOSb3T5cxrYTTDKTQq7fMmXudQ==> <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com> From: Donald Eastlake <d3e3e3@gmail.com> Date: Sat, 14 Jan 2012 18:53:01 -0500 Message-ID: <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.gmail.com> To: "Murray S. Kucherawy" <msk@cloudmark.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Jan 2012 08:07:17 -0800 Cc: "dnsext@ietf.org" <dnsext@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" <draft-ietf-dnsext-xnamercode.all@tools.ietf.org> Subject: Re: [apps-discuss] [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 14 Jan 2012 23:53:24 -0000 Hi Murray, Thanks for the review, see responses below... On Thu, Jan 12, 2012 at 1:35 PM, Murray S. Kucherawy <msk@cloudmark.com> wr= ote: > I have been selected as the Applications Area Directorate reviewer for th= is > draft (for background on appsdir, please see > =A0http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirector= ate). > > 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-dnsext-xnamercode > Title: xNAME RCODE and Status Bits Clarification > Reviewer: Murray S. Kucherawy > Review Date: January 12, 2012 > IETF Last Call Date: N/A > IESG Telechat Date: N/A > > The draft clarifies prior ambiguities with respect to how a resolver is > supposed to report answer meta-data when resolving a name where the first > answer returned in a potential series of query-responses is actually a > pointer to another record.=A0 It is precise and concise. > > Summary: This draft is almost ready for publication as a Standards Track = RFC > but has a couple of issues that should be addressed before publication. > > Major Issues: > > Given that this is a potentially important clarification with > interoperability considerations, I believe this document should say it > updates at least RFC1035 (since its ambiguity is specifically called out)= , > and possibly RFC2672 and RFC2308.=A0 Make sure the Abstract also says thi= s > explicitly. No problem with me to make that addition for these three RFCs. > Minor Issues: > > In Section 1, =93There is a proposal for another redirection RR.=94=A0 Is= it > appropriate to make reference to that here?=A0 I don=92t know to which on= e > you=92re referring or what status it has, so the answer might be =93no=94= ; just > checking. This is right at the beginning of Section 1 as motivation for clarifying the situation and to make it clear that this document is intended to apply to future redirection RRs (unless, of course, the document specifying them says otherwise). I could make this a bit more definite by saying "There has been a proposal for another redirection RR that would combine the effects of both CNAME and DNAME." In fact, there is a renewed effort to start work on such an RR just in the past few days. > Section 2 identifies two status bits as part of this clarification > document.=A0 However, it also says explicitly that their definitions are > unchanged from the documents that introduced them.=A0 I=92m curious then = as to > why they are included in this document at all; that is, what clarificatio= n > is being provided?=A0 Unlike Section 3, any ambiguity about their use has= not > been identified here.=A0 If in fact there isn=92t any, I think this secti= on can > be removed.=A0 If you like, you can introduce references to and overviews= of > their definitions in a new subsection of Section 1, since you do talk abo= ut > them in Section 4. Well, the name of the document is "xNAME RCODE and Status Bits Clarification". I'm not sure why it would make that much difference to move Section 2 on status bits to a new subpart of Section 1. As you say, they are further discussed in Section 4. It seems to me that something can "clarify" with making any change. Given no objections in the DNSEXT WG to this material, I am inclined to leave it in. > Nits: > > In Section 3, the exclamation mark legitimately relays bewilderment here, > but unfortunately I think it should just be a period.=A0 Even better woul= d be > to end the sentence with =93says that some servers are implemented > differently=94 or suchlike. I kind of like it the way it is!!! But I'm OK with changing it to a period. > In Section 4, the clause =93if the following apply=94 should be amended b= y > adding =93all of=94 or =93one of=94 or something more specific. Sure, should be "all of". Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From ned.freed@mrochek.com Sun Jan 15 08:16:16 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2605821F8474 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 08:16:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q7rO2i8+wUt for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 08:16:15 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 489FA21F845E for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 08:15:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAT5KHWWNK000FER@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Jan 2012 08:15:54 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OARPS2OYZK000HW1@mauve.mrochek.com>; Sun, 15 Jan 2012 08:15:51 -0800 (PST) Message-id: <01OAT5KFXSHA000HW1@mauve.mrochek.com> Date: Sun, 15 Jan 2012 07:53:41 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Sat, 14 Jan 2012 16:48:23 -0800" <4F122257.10301@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <k.com@missing-host.mrochek.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <4F122257.10301@dcrocker.net> To: Dave CROCKER <dhc@dcrocker.net> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 16:16:16 -0000 > On 1/13/2012 10:53 AM, John C Klensin wrote: > > SMTP rather carefully defines "trace information" or "trace > > headers" and then limits that category to two types of > What is the import of this observation, relative to the current proposal? > You appear to be intending it as a constraint, but I don't understand how, > specifically. > > In any event, we have discovered repeatedly (and sometimes > > painfully) that the the Received header field is not well > > designed for extensibility. > I don't recall seeing these claims before or documentation that they are valid. > Can you provide some citations? While I am unaware of any standards usage of this particular extensibility feature, ever since it was defined there has been some ad-hoc use of it. I have not observed any issues with this usage. To the extent there have been problems, it's been with obsolete forms that have never worked well and jsut a general failure to implement basic stuff like date-time parsing propoerly. > Note that the definition of the Received: header field provides a registry for > addition of new clauses, so you appear to be saying that extensibility is not > viable. If that's indeed the case, then this is a serious problem that trascends the present discussion. Consider: The claim is that a fairly important feature of a particalur standard cannot be used because if it is sure to cause interoperability problems. If so, then this pretty clearly fails to meet the criteria for standards advancment: Stuff like this is supposed to be removed, redone, or at least severerly restricted before advancing past proposed. At an absolute minimum the registry would need to be closed to new entries. > > It depends on an ordered, > > context-dependent, reserved keyword model (something I don't > If you are saying that the specific placement of the clause is essential, then > please document this requirement -- beyond what is in the RFC5321 spec and the > proposed clause spec -- both in terms of what you believe is acceptable and > different from the current specification and also the basis for this. +1 > > we should have a serious discussion about how far > > we want to go in extending "Received:" and when it is time to > > add one or more additional Trace header fields, possibly with a > > typology of functions that each serves (beyond "inserted by a > > transit MTA or something else") and I have found additional header fields to be be more problematic than extending Received:. For one thing, agents tend to assume that Received: is the only field deserving such treatement and many do not even have a list of additional fields to copy when moving trace information around. (And this operation does happen in various cases.) And even if such a list is maintained, there's always the update problem when a new trace field is defined. For another, while it's fairly safe to rely on headers of the same type staying in the same order, the same cannot always be said for fields of different types. > Please review the latest version, specifically the 'Discussion' section, which > provides exactly the consideration you are calling for. > > with a syntax that is > > clearly name-value based, rather than even partially dependent > > on parser recognition of specific keywords. > I don't understand the requirement you are proposing, since the "name" of a > name/value pair is a specific keyword. Hence, your saying "rather than" appears > to be contradictory. > You seem to be meaning something else, but I can't guess what. > > Let's not turn "Received:" further into a kludge just because it > > is there. > How is it already a kludge? Whether or not it is a kludge is of precisely zero interest to me. It's the mechanim we have. We have a problem to solve here, and unfortunately all of the possible solutions have issues. In my judgement out of all the available options the best is to extend Received:, messy syntax and all. All of the other options, including but not limited to additional trace fields, replacing Received: with something else, replacing Received; while retaining generation of Received; for backwards compatibility, are even worse. And the worst option is effectively saying that addttional trace information can never be added again. That would really suck. Ned From vesely@tana.it Sun Jan 15 10:58:16 2012 Return-Path: <vesely@tana.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E621F8472 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 10:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDbUsXF-p3L3 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 10:58:15 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0C21F8442 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 10:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326653893; bh=zq9zVkQsYDClmohiXyKTuXw02esOS+X7AL+gy3UC500=; l=2002; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Mh2cbUnwVnLjRn1/jtKiTu4KTOMU0AAa3WXsyFKGkYD2oAEM0ZDc8DiG4zN09R0Bi RK8f6PIcVYKli3DXsuU0aBbv3KtuL1LSVmjeeqPhQoZQPSzXxNBiICiXdzb/ERee92 MGYYdK8DTCV8St3E1YLMyqd2cekSl6tX50DjQ8LI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 15 Jan 2012 19:58:13 +0100 id 00000000005DC039.000000004F1321C5.00001E58 Message-ID: <4F1321C5.7000807@tana.it> Date: Sun, 15 Jan 2012 19:58:13 +0100 From: Alessandro Vesely <vesely@tana.it> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <k.com@missing-host.mrochek.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <4F122257.10301@dcrocker.net> <01OAT5KFXSHA000HW1@mauve.mrochek.com> In-Reply-To: <01OAT5KFXSHA000HW1@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 18:58:16 -0000 On 15/Jan/12 16:53, Ned Freed wrote: > > We have a problem to solve here, and unfortunately all of the > possible solutions have issues. In my judgement out of all the > available options the best is to extend Received:, messy syntax and > all. All of the other options, including but not limited to > additional trace fields, replacing Received: with something else, > replacing Received; while retaining generation of Received; for > backwards compatibility, are even worse. This judgment is difficult to understand, for me at least, without considering an actual alternative. For an example trace field to be paired with "Received:", I'd pick "Sent:". Consider: Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 489FA21F845E; Sun, 15 Jan 2012 08:15:57 -0800 (PST) Sent: to ietfa.amsl.com to-addr 12.22.58.30 to-port 25 by mauve.mrochek.com by-addr 66.59.230.40 by-port 1438 date "Sun, 15 Jan 2012 08:15:57 -0800 (PST)" Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAT5KHWWNK000FER@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Jan 2012 08:15:54 -0800 (PST) ... That "Sent:" field is to be written on the fly, and if the message is rejected (5xx) or delayed (4xx), then the field gets discarded. There is a lot of redundant data. It wastes bandwidth, but can be used to check proper ordering, synchronization, and consistency. The format can be similar and new at the same time. Both fields can be extended, but no coordination between their formats is to be mandated. An advantage of the new field, for the problem at hand, is that it allows to make a final statement rather than forecasting a state. It would be possible to tell this is the 4th attempt in 15 minutes, as after greylisting. > And the worst option is effectively saying that additional trace > information can never be added again. That would really suck. +1. From dhc@dcrocker.net Sun Jan 15 11:46:19 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487521F8483 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:46:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99EsPh+41a1A for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:46:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23FF821F847C for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 11:46:19 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0FJkDXO030481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 11:46:18 -0800 Message-ID: <4F132D04.1020003@dcrocker.net> Date: Sun, 15 Jan 2012 11:46:12 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> In-Reply-To: <alpine.BSF.2.00.1201142235000.1943@joyce.lan> 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, 15 Jan 2012 11:46:19 -0800 (PST) Subject: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 19:46:19 -0000 Folks, On 1/14/2012 7:55 PM, John R. Levine wrote: > It's certainly time for a trace field registry. And I suppose that if we > have one, adding new trace fields isn't that big a deal. It would help for folks to explain what the specific need for a "trace fields" registry is. I'm not seeing it. A registry is for the purpose of coordination. It allows participants to know what exists, either for: a) discovering to use the information, or b) discovery to avoid conflicts in assigning new values Registries incur a cost, so the associated benefit needs to be quite clear. 1. What coordination purpose will be served by the new registry? We already have a registry to fields[1], so the 'trace' registry would be redundant with a subset of the that existing registry. Redundancy is usually bad. 2. Why is redundancy acceptable, here? d/ [1] http://tools.ietf.org/html/rfc3864 -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sun Jan 15 11:54:24 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69BE21F847C for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:54:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJvKVZlGxa4H for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:54:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57CAB21F8475 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 11:54:24 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0FJsINg030586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jan 2012 11:54:23 -0800 Message-ID: <4F132EE9.9070507@dcrocker.net> Date: Sun, 15 Jan 2012 11:54:17 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John C Klensin <john-ietf@jck.com> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> <54978B203C73F673C5287DE3@PST.JCK.COM> In-Reply-To: <54978B203C73F673C5287DE3@PST.JCK.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, 15 Jan 2012 11:54:24 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 19:54:25 -0000 On 1/15/2012 7:51 AM, John C Klensin wrote: > This is the sort of disconnect between the specifications about > SMTP MTAs and the specifications of header fields and their > names that I mentioned in an earlier note and to which Dave > Crocker took significant exception. While I don't want to go on > a quest for specific language, I believe that, from the MTA Since I'm cited by name, I'll clarify that what I took exception to were assertions of fact that I believe to be wrong and that I asked to see documented. Unfortunately, anyone can make any claim they feel like making. Consequently, responsible technical discussion means that the making of a claim does indeed require someone's doing the work of providing specifics. Typically, the person making an affirmative assertion of fact carries the responsibility for substantiating it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Sun Jan 15 11:58:47 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4E21F847A for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:58:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+TbtqXRk+CX for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:58:47 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32421F8476 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 11:58:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OATDCQE6Z4004MDT@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Jan 2012 11:58:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OARPS2OYZK000HW1@mauve.mrochek.com>; Sun, 15 Jan 2012 11:58:38 -0800 (PST) Message-id: <01OATDCNTH0M000HW1@mauve.mrochek.com> Date: Sun, 15 Jan 2012 11:51:09 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Sun, 15 Jan 2012 19:58:13 +0100" <4F1321C5.7000807@tana.it> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <k.com@missing-host.mrochek.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <4F122257.10301@dcrocker.net> <01OAT5KFXSHA000HW1@mauve.mrochek.com> <4F1321C5.7000807@tana.it> To: Alessandro Vesely <vesely@tana.it> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 19:58:48 -0000 > On 15/Jan/12 16:53, Ned Freed wrote: > > > > We have a problem to solve here, and unfortunately all of the > > possible solutions have issues. In my judgement out of all the > > available options the best is to extend Received:, messy syntax and > > all. All of the other options, including but not limited to > > additional trace fields, replacing Received: with something else, > > replacing Received; while retaining generation of Received; for > > backwards compatibility, are even worse. > This judgment is difficult to understand, for me at least, without > considering an actual alternative. For an example trace field to be > paired with "Received:", I'd pick "Sent:". Consider: > Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) > by ietfa.amsl.com (Postfix) with ESMTP id 489FA21F845E; > Sun, 15 Jan 2012 08:15:57 -0800 (PST) > Sent: to ietfa.amsl.com to-addr 12.22.58.30 to-port 25 > by mauve.mrochek.com by-addr 66.59.230.40 by-port 1438 > date "Sun, 15 Jan 2012 08:15:57 -0800 (PST)" > Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com > (PMDF V6.1-1 #35243) id <01OAT5KHWWNK000FER@mauve.mrochek.com> for > apps-discuss@ietf.org; Sun, 15 Jan 2012 08:15:54 -0800 (PST) > ... > That "Sent:" field is to be written on the fly, and if the message is > rejected (5xx) or delayed (4xx), then the field gets discarded. > There is a lot of redundant data. It wastes bandwidth, but can be > used to check proper ordering, synchronization, and consistency. The > format can be similar and new at the same time. Both fields can be > extended, but no coordination between their formats is to be mandated. We went over all of these tradeoffs in tedious detail back in the MIME work. The original proposal for MIME headers (written by Bob Smart and myself) was to add additional paired fields as you are doing here. Once you work through all the details, all sorts of problems emerge - it's just not possible to keep the fields ordered due to vagarities of agent processing. This then led to proposals for linkage ids, but the complexity is such that implementations are pretty much guaranteed to botch it. (And now you're back to either extending Received: or abusing the semantics of some existing clause - exactly what the new field is trying to avoid.) Encoded words were then proposed by Keith Moore, and rather obviously had better operational characteristics. Sure, there were bobbles with implementations that didn't really support proper syntax processing, but in hindsight it was clearly the right choice. Ned From johnl@iecc.com Sun Jan 15 12:08:59 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7697021F8498 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.153 X-Spam-Level: X-Spam-Status: No, score=-104.153 tagged_above=-999 required=5 tests=[AWL=-1.554, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDXTok792yYf for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:08:58 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8181521F849A for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 12:08:58 -0800 (PST) Received: (qmail 719 invoked from network); 15 Jan 2012 20:08:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jan 2012 20:08:55 -0000 Date: 15 Jan 2012 20:08:33 -0000 Message-ID: <20120115200833.33736.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <01OAT5KFXSHA000HW1@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 20:08:59 -0000 >While I am unaware of any standards usage of this particular extensibility >feature, ever since it was defined there has been some ad-hoc use of it. I have >not observed any issues with this usage. To the extent there have been >problems, it's been with obsolete forms that have never worked well and jsut a >general failure to implement basic stuff like date-time parsing propoerly. I've written my share of received header parsers (it's unavoidable if you want to send a non-trivial number of abuse reports) and I will agree that extra clauses are not an issue. The problem, as usual, is people who don't read the spec at all before they start coding, and there's not much we can do about that. R's, John From johnl@iecc.com Sun Jan 15 12:16:36 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E799321F8471 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.095 X-Spam-Level: X-Spam-Status: No, score=-104.095 tagged_above=-999 required=5 tests=[AWL=-1.496, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t15akhBdrjUl for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:16:36 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3989821F8468 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 12:16:36 -0800 (PST) Received: (qmail 5688 invoked from network); 15 Jan 2012 20:16:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jan 2012 20:16:35 -0000 Date: 15 Jan 2012 20:16:13 -0000 Message-ID: <20120115201613.34004.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <54978B203C73F673C5287DE3@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 20:16:37 -0000 >> It's certainly time for a trace field registry. And I suppose >> that if we have one, adding new trace fields isn't that big a deal. > >I don't have any problem with such a registry. It seems to me >that you've done most of the work of identifying what should be >in it. Personally, I'd rather see either separate subregistries >for MTA and MUA trace info or a field that distinguishes the >former from the latter. Do you want to generate the I-D? I'm >happy to review and/or help as needed. Sure. My list above was generated using my favorite semantic analysis tool, grep, on my directory full of RFCs. I sort of see your distinction between MTA and MUA headers, although I don't see anything in the list other than Resent-* that strikes me as something an MUA would do. The closest is Auto-Submitted: for SIEVE mailto: notifications, something that's in the MDA or maybe MSA. R's, John From johnl@iecc.com Sun Jan 15 12:18:40 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3685B21F8471 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.042 X-Spam-Level: X-Spam-Status: No, score=-104.042 tagged_above=-999 required=5 tests=[AWL=-1.443, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry2pJNhoTUIM for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 12:18:39 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B467021F8468 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 12:18:39 -0800 (PST) Received: (qmail 6704 invoked from network); 15 Jan 2012 20:18:39 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jan 2012 20:18:39 -0000 Date: 15 Jan 2012 20:18:17 -0000 Message-ID: <20120115201817.34086.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <4F132D04.1020003@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 15 Jan 2012 20:18:40 -0000 > 1. What coordination purpose will be served by the new registry? Unlike other headers, trace headers can occur multiple times in a message, and their order means something. This should be of use to code that parses headers. >We already have a registry to fields[1], so the 'trace' registry would be >redundant with a subset of the that existing registry. Redundancy is usually bad. > > 2. Why is redundancy acceptable, here? I suppose that adding a trace flag to the existing registry would do the trick. R's, John From alexey.melnikov@isode.com Mon Jan 16 05:14:45 2012 Return-Path: <alexey.melnikov@isode.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4999F21F85C2; Mon, 16 Jan 2012 05:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.833 X-Spam-Level: X-Spam-Status: No, score=-100.833 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HTML_MESSAGE=0.001, MANGLED_PRIOR=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 556E9AWWnfaI; Mon, 16 Jan 2012 05:14:42 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B121F858E; Mon, 16 Jan 2012 05:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326719678; d=isode.com; s=selector; i=@isode.com; bh=hp/q+w7q2abO5/XkmzLaovqVa3sgyRJu8Wia04+r57g=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xLZ31GDTvqWaAgFFvMRPYiyMr80aWlmWxvC8buTo7t8NouGI3etauM6CDM/amax4Qg5VhF 1uVtyA/CwfkyMdx0+2/hcaiVdoiKlD7YSJrGjwgo2lmt+BrQpdMD8zlocsGZq4O5N4xY+3 ouncMGWj2+RjzkDPU0ev4bSYCNGwgCY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TxQiugAV539O@rufus.isode.com>; Mon, 16 Jan 2012 13:14:35 +0000 Message-ID: <4F131C67.6000007@isode.com> Date: Sun, 15 Jan 2012 18:35:20 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Glenn Parsons <glenn.parsons@ericsson.com> References: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se> <4F0D8520.1080206@isode.com> <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050400090800090901050102" Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" <draft-melnikov-smtp-priority.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 13:14:45 -0000 This is a multi-part message in MIME format. --------------050400090800090901050102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2012 17:42, Glenn Parsons wrote: > Alexey, > You're welcome :-) > Despite your assertion that LMTP would be a valid DownRef ... I do not > think this extension should be defined for it. If your suggestion is based on procedural ground, then I don't think it is valid (please point out to a document which says that Informative reference can't be used normatively). If you suggest this for some other reason, can you please elaborate? > That is I would suggest adding text along the lines of ...it is > defined for Message Submission and as a result may also be used for LMTP. I don't think that would be correct. There are 3 essentially different protocols: Mail Submission, SMTP used to talk to MTAs, and LMTP. For each one the decision about whether an SMTP extension can be used with it needs to be made separately and independently. > On lines longer than 72 -- it just feels bad. SMTP line length limits are generally much higher, but I see your point. > And further, you have no justification for this here. Is it for the > message length? Yes. > If it is won't moving to Kb remove the need for a longer line? Ok, will do :-). > On the naming you need to be consistent. For example, is it "PRI" or > "PRIORITY" > On docuemnt organization, there are two things defined here: Priority > SMTP extension & Priority message header. These need to be in > distinct sections with appropriate titles. It is the second that is > currently hidden. Ok. > Cheers, > Glenn. > ------------------------------------------------------------------------ > *From:* Alexey Melnikov [mailto:alexey.melnikov@isode.com] > *Sent:* January-11-12 7:49 AM > *To:* Glenn Parsons > *Cc:* apps-discuss@ietf.org; > draft-melnikov-smtp-priority.all@tools.ietf.org; iesg@ietf.org > *Subject:* Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 > > Hi Glenn, > Thank you for your review. > > On 10/01/2012 21:10, Glenn Parsons wrote: >> I have been selected as the Applications Area Directorate reviewer >> for this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> 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-melnikov-smtp-priority-04 >> Title: Simple Mail Transfer Protocol extension for Message Priorities >> Reviewer: Glenn Parsons >> Review Date: January 10, 2012 >> Summary: >> This draft is not ready for publication as a Proposed Standard and >> should be revised before publication >> Major Issues: >> 3. in item #7 I presume this should be LMTP, but my concern is that >> it says this is being defined for LMTP. Since LMTP is informational, >> I don't think that is appropriate. Instead, I would suggest that it >> is defined for Message Submission and as a result may also be used >> for LMTP. I would prefer this to be noted in an Appendix (along >> with the LMTP advice in section 7) -- but if you would prefer it to >> remain in the main body, it needs to be reworded. In either case, I >> would move LMTP to the informative references. > I know that LMTP (RFC 2033) being Informational is annoying, but > really, it is a perfectly valid DownRef and can be called out during > IETF LC. > (At some point LMTP should be promoted to Proposed Standard, but that > is largely independent of this work.) >> 3. the too long example in 3.1 is apparently justified by item #6 >> here ... but you can't have a line longer than 72 chars in an RFC... > I think I've fixed that in my copy. >> but more importantly, how do you guarantee that this does not >> accidentally blow something up. This is a HUGE change that is >> mentioned in passing without justification. This seems like a large >> hurdle for an implementation to be able to add support for this. > Why? Advertisement of supported levels is entirely optional. >> The use for this appears to be to fit in message size parameters for >> each priority (and I presume the message size is in bytes as it does >> not say). > Yes, in bytes. Clarified in my copy. >> So why not use Kb instead of bytes? > I was trying to be consistent with the SIZE SMTP extension which also > uses bytes. But as you are the second person to complain about that, > maybe I will give up and switch to Kb ;-). >> Or render the numbers in hex? Or split it over two lines? > The last doesn't work well with SMTP. At least no SMTP extension ever > listed more than 1 capability in EHLO response. >> I think any of these would be better than increasing the line length. >> 5. The priority level definition is not clear. There are 200 >> possible values. But there MUST be at least 6 supported. OK that >> seems like overkill -- why can't it be from -9 to 9 then? Anyway, is >> that 6 distinct numbers, 6 distinct numbers from the range shown, or >> any number for the range shown? Further I would suggest that a >> default value should be specified for these 6 levels and the default >> mapping ranges -- all in a table. > As other people made the same comment, I will reply to this with my > reasoning in a separate email. >> 6 & 8. You need to pick something and be consistent. I would suggest >> it is not necessary for them to be the same. So the EHLO one could >> be short "PRI" and the header long "Message Transfer Priority". In >> any case, the terminology then needs alignment throughout the document. >> A definition of the Priority message header field is missing. It >> should be after section 3. > I think a forward reference in section 4.2 (where the MT-Priority > header field is specified) would be sufficient. Unless you meant > something else. >> Minor Issues: >> Title: I would change "Message Priorities " to "Message Transfer >> Priority" >> 6. The units for "message size" need to be indicated at some point in >> the document, at least in the syntax of section 6. > This is already fixed in my copy (will be in -05). >> 3. I would suggest to replace "The following service extension is >> defined:" with "The Priorty SMTP service extension is defined as >> follows:" >> 5.1.x I am somewhat concerned about informative implementation >> details -- I presume that is why this is informative? Or is it >> because this is not exhaustive? > Mostly the latter. >> In any case, I think this should be in the appendix. > Ok. >> 6. It is confusing to have both specifications for the ESMTP and >> Header field in the same place. I would suggest separate >> appropriatley titled sub-sections of section 6 >> 7. I would suggest adding an example fo the message header field in >> this clause. >> 9. What are the "anchor" placeholders for? > This is just a hint to RFC Editor to insert the final RFC number, once > known. >> 9. Presumably the TBD items need to be filled in... > The 2 values will be assigned by IANA before publication. >> Nits: >> 3.1 the example is too long >> ** There is 1 instance of too long lines in the document, the longest >> one being 12 characters in excess of 72. >> ...but I could not find this one: >> == There are 1 instance of lines with non-RFC2606-compliant FQDNs in >> the document. > Ok, I will check. > --------------050400090800090901050102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 12/01/2012 17:42, Glenn Parsons wrote: <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta content="MSHTML 6.00.6002.18538" name="GENERATOR"> <div><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">Alexey,</font></span></div> <div><span class="707193317-12012012"></span> </div> <div><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">You're welcome :-)</font></span></div> <div><span class="707193317-12012012"></span><span class="707193317-12012012"></span> </div> <div><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">Despite your assertion that LMTP would be a valid DownRef ... I do not think this extension should be defined for it.</font></span></div> </blockquote> If your suggestion is based on procedural ground, then I don't think it is valid (please point out to a document which says that Informative reference can't be used normatively). If you suggest this for some other reason, can you please elaborate? <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">That is I would suggest adding text along the lines of <font face="Times New Roman"><font color="#000000" size="3">...it is defined for Message Submission and as a result may also be used for LMTP.</font></font></font></span></div> </blockquote> I don't think that would be correct. There are 3 essentially different protocols: Mail Submission, SMTP used to talk to MTAs, and LMTP. For each one the decision about whether an SMTP extension can be used with it needs to be made separately and independently.  <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">On lines longer than 72 -- it just feels bad.</font></span></span></div> </blockquote> SMTP line length limits are generally much higher, but I see your point.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">And further, you have no justification for this here.  Is it for the message length?</font></span></span></div> </blockquote> Yes.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2"> If it is won't moving to Kb remove the need for a longer line?</font></span></span></div> </blockquote> Ok, will do :-).<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">On the naming you need to be consistent.  For example, is it "PRI" or "PRIORITY"</font></span></span></div> <div><span class="707193317-12012012"><span class="707193317-12012012"></span></span> </div> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">On docuemnt organization, there are two things defined here:  Priority SMTP extension & Priority message header.  These need to be in distinct sections with appropriate titles.  It is the second that is currently hidden.</font></span></span></div> </blockquote> Ok.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">Cheers,</font></span></span></div> <div><span class="707193317-12012012"><span class="707193317-12012012"><font color="#0000ff" face="Arial" size="2">Glenn.</font></span></span></div> <div><span class="707193317-12012012"><span class="707193317-12012012"></span></span> </div> <div> <hr tabindex="-1"> </div> <div><font face="Tahoma" size="2"><b>From:</b> Alexey Melnikov [<a class="moz-txt-link-freetext" href="mailto:alexey.melnikov@isode.com">mailto:alexey.melnikov@isode.com</a>] <br> <b>Sent:</b> January-11-12 7:49 AM<br> <b>To:</b> Glenn Parsons<br> <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:draft-melnikov-smtp-priority.all@tools.ietf.org">draft-melnikov-smtp-priority.all@tools.ietf.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:iesg@ietf.org">iesg@ietf.org</a><br> <b>Subject:</b> Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04<br> </font><br> </div> Hi Glenn,<br> Thank you for your review.<br> <br> On 10/01/2012 21:10, Glenn Parsons wrote: <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <meta content="Microsoft Exchange Server" name="Generator"> <!-- converted from rtf --> <style>.EmailQuote { PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid } </style> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate</a>). </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">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.</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Document: draft-melnikov-smtp-priority-04<br> Title: Simple Mail Transfer Protocol extension for Message Priorities <br> Reviewer: Glenn Parsons<br> Review Date:  January 10, 2012<br> </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Summary: </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">This draft is not ready for publication as a Proposed Standard and should be revised before publication</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Major Issues:</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3.  in item #7 I presume this should be LMTP, but my concern is that it says this is being defined for LMTP.  Since LMTP is informational, I don't think that is appropriate.  Instead, I would suggest that it is defined for Message Submission and as a result may also be used for LMTP.   I would prefer this to be noted in an Appendix (along with the LMTP advice in section 7) -- but if you would prefer it to remain in the main body, it needs to be reworded.  In either case, I would move LMTP to the informative references. </div> </blockquote> I know that LMTP (RFC 2033) being Informational is annoying, but really, it is a perfectly valid DownRef and can be called out during IETF LC.<br> (At some point LMTP should be promoted to Proposed Standard, but that is largely independent of this work.) <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3.  the too long example in 3.1 is apparently justified by item #6 here … but you can't have a line longer than 72 chars in an RFC…</div> </blockquote> I think I've fixed that in my copy.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">but more importantly, how do you guarantee that this does not accidentally blow something up.  This is a HUGE change that is mentioned in passing without justification.  This seems like a large hurdle for an implementation to be able to add support for this.</div> </blockquote> Why? Advertisement of supported levels is entirely optional. <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">The use for this appears to be to fit in message size parameters for each priority (and I presume the message size is in bytes as it does not say). <br> </div> </blockquote> Yes, in bytes. Clarified in my copy.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">So why not use Kb instead of bytes? <br> </div> </blockquote> I was trying to be consistent with the SIZE SMTP extension which also uses bytes. But as you are the second person to complain about that, maybe I will give up and switch to Kb ;-).<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Or render the numbers in hex?  Or split it over two lines?</div> </blockquote> The last doesn't work well with SMTP. At least no SMTP extension ever listed more than 1 capability in EHLO response.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">I think any of these would be better than increasing the line length.</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">5. The priority level definition is not clear.  There are 200 possible values.  But there MUST be at least 6 supported.  OK that seems like overkill -- why can't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number for the range shown?  Further I would  suggest that a default value should be specified for these 6 levels and the default mapping ranges -- all in a table.</div> </blockquote> As other people made the same comment, I will reply to this with my reasoning in a separate email.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6 & 8. You need to pick something and be consistent.  I would suggest it is not necessary for them to be the same.  So the EHLO one could be short "PRI" and the header long "Message Transfer Priority".  In any case, the terminology then needs alignment throughout the document.</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">A definition of the Priority message header field is missing.  It should be after section 3.</div> </blockquote> I think a forward reference in section 4.2 (where the MT-Priority header field is specified) would be sufficient. Unless you meant something else. <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Minor Issues:</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Title:  I would change "Message Priorities " to "Message Transfer Priority"</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6. The units for "message size" need to be indicated at some point in the document, at least in the syntax of section 6.</div> </blockquote> This is already fixed in my copy (will be in -05).<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3. I would suggest to replace "The following service extension is defined:" with "The Priorty SMTP service extension is defined as follows:" </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">5.1.x I am somewhat concerned about informative implementation details -- I presume that is why this is informative?  Or is it because this is not exhaustive?</div> </blockquote> Mostly the latter.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">In any case, I think this should be in the appendix.</div> </blockquote> Ok.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6. It is confusing to have both specifications for the ESMTP and Header field in the same place.   I would suggest separate appropriatley titled sub-sections of section 6</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">7.  I would suggest adding an example fo the message header field in this clause.</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">9.  What are the "anchor" placeholders for?</div> </blockquote> This is just a hint to RFC Editor to insert the final RFC number, once known.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">9. Presumably the TBD items need to be filled in...</div> </blockquote> The 2 values will be assigned by IANA before publication.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Nits:  </div> <div> </div> <div>3.1 the example is too long </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. </div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">…but I could not find this one:</div> <div style="MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. </div> </blockquote> Ok, I will check.<br> <br> </blockquote> <br> <br> </body> </html> --------------050400090800090901050102-- From ned.freed@mrochek.com Mon Jan 16 07:59:59 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7921F8677 for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 07:59:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXA4CwKT80Eg for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 07:59:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CEAFB21F8615 for <apps-discuss@ietf.org>; Mon, 16 Jan 2012 07:59:58 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAUJB09PNK015AGA@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 16 Jan 2012 07:59:54 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OARPS2OYZK000HW1@mauve.mrochek.com>; Mon, 16 Jan 2012 07:59:49 -0800 (PST) Message-id: <01OAUJAX2HRI000HW1@mauve.mrochek.com> Date: Mon, 16 Jan 2012 07:57:40 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Sun, 15 Jan 2012 20:08:33 +0000" <20120115200833.33736.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> To: John Levine <johnl@taugh.com> Cc: ned.freed@mrochek.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 15:59:59 -0000 > >While I am unaware of any standards usage of this particular extensibility > >feature, ever since it was defined there has been some ad-hoc use of it. I have > >not observed any issues with this usage. To the extent there have been > >problems, it's been with obsolete forms that have never worked well and jsut a > >general failure to implement basic stuff like date-time parsing propoerly. > I've written my share of received header parsers (it's unavoidable if > you want to send a non-trivial number of abuse reports) and I will > agree that extra clauses are not an issue. The problem, as usual, is > people who don't read the spec at all before they start coding, and > there's not much we can do about that. Exactly. And given eixsting use of nonstandard clauses any parser that fails to handle them is not materially different from one that fails to handle other syntax details. I completely fail to see why we should be catering to this level of brokennness at this late date. Ned From ned.freed@mrochek.com Mon Jan 16 08:12:46 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE18421F869C for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 08:12:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGzZKU2knTuK for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 08:12:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4273921F869A for <apps-discuss@ietf.org>; Mon, 16 Jan 2012 08:12:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAUJQ7J47K000VUG@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 16 Jan 2012 08:12:39 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OARPS2OYZK000HW1@mauve.mrochek.com>; Mon, 16 Jan 2012 08:12:06 -0800 (PST) Message-id: <01OAUJQ57QIA000HW1@mauve.mrochek.com> Date: Mon, 16 Jan 2012 08:09:26 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Sun, 15 Jan 2012 11:46:12 -0800" <4F132D04.1020003@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> <4F132D04.1020003@dcrocker.net> To: Dave CROCKER <dhc@dcrocker.net> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 16:12:46 -0000 > Folks, > On 1/14/2012 7:55 PM, John R. Levine wrote: > > It's certainly time for a trace field registry. And I suppose that if we > > have one, adding new trace fields isn't that big a deal. > It would help for folks to explain what the specific need for a "trace fields" > registry is. I'm not seeing it. > A registry is for the purpose of coordination. It allows participants to know > what exists, either for: > a) discovering to use the information, or > b) discovery to avoid conflicts in assigning new values > Registries incur a cost, so the associated benefit needs to be quite clear. > 1. What coordination purpose will be served by the new registry? > We already have a registry to fields[1], so the 'trace' registry would be > redundant with a subset of the that existing registry. Redundancy is usually bad. > 2. Why is redundancy acceptable, here? I have to agree with John Levine here - why can't this just be an added flag in the existiing header registry. The cost of that should be *far* lower than a new registry. In fact after experience with having additional purpose-specific media type registries (something we should never have allowed), I am *strongly* opposed to overlapping registries of any sort. (Right now I owe IANA a response about how in the blazes to address the current multiple registries for media types.) Ned From dhc@dcrocker.net Mon Jan 16 09:24:24 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C192521F86A9 for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 09:24:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgfBnQYAmkWg for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 09:24:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E735521F86A7 for <apps-discuss@ietf.org>; Mon, 16 Jan 2012 09:24:23 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0GHOGrI026578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2012 09:24:23 -0800 Message-ID: <4F145D3E.8040502@dcrocker.net> Date: Mon, 16 Jan 2012 09:24:14 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ned Freed <ned.freed@mrochek.com> References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> <4F132D04.1020003@dcrocker.net> <01OAUJQ57QIA000HW1@mauve.mrochek.com> In-Reply-To: <01OAUJQ57QIA000HW1@mauve.mrochek.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, 16 Jan 2012 09:24:23 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 17:24:24 -0000 On 1/16/2012 8:09 AM, Ned Freed wrote: > I have to agree with John Levine here - why can't this just be an added flag in > the existiing header registry. The cost of that should be *far* lower than a > new registry. In fact after experience with having additional purpose-specific > media type registries (something we should never have allowed), I am *strongly* > opposed to overlapping registries of any sort. (Right now I owe IANA a response > about how in the blazes to address the current multiple registries for media > types.) I am still left with the basic concern, independent of whether this is a field in an existing registry or is a new registry: What is the utility of marking some fields as 'trace' fields? What coordination does it facilitate? I really do not understand the point. In the spec, it's useful to have the label 'trace' for education, to conceptually aggregate some fields. But what is the /functional/ benefit of the label? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From glenn.parsons@ericsson.com Mon Jan 16 15:07:00 2012 Return-Path: <glenn.parsons@ericsson.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D0921F85D5; Mon, 16 Jan 2012 15:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.809 X-Spam-Level: X-Spam-Status: No, score=-4.809 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PRIOR=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRS5ku3NJNLG; Mon, 16 Jan 2012 15:06:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 164CD21F85B5; Mon, 16 Jan 2012 15:06:56 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q0GN6l7E023217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jan 2012 17:06:48 -0600 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.61]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 16 Jan 2012 18:06:47 -0500 From: Glenn Parsons <glenn.parsons@ericsson.com> To: Alexey Melnikov <alexey.melnikov@isode.com> Date: Mon, 16 Jan 2012 18:06:45 -0500 Thread-Topic: [apps-discuss] Review of draft-melnikov-smtp-priority-04 Thread-Index: AczUUNLU3XUN39iTQVuE5r8LTHt6XAAUPQhQ Message-ID: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6@EUSAACMS0714.eamcs.ericsson.se> References: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se> <4F0D8520.1080206@isode.com> <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.ericsson.se> <4F131C67.6000007@isode.com> In-Reply-To: <4F131C67.6000007@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6EUSAACMS0714e_" MIME-Version: 1.0 Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" <draft-melnikov-smtp-priority.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 23:07:00 -0000 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alexey, My objection on LMTP is not procedural, I just think it is cleaner to defin= e the SMTP Extension normatively as-is. This extension does not need LMTP = as a normative reference to be valid for LMTP -- but my real concern is tha= t it should not be "defined" for LMTP. So I suggest changing section 3 to not have LMTP in the defined enumerated = list: The Priorty SMTP service extension is defined as follows: 1. ... 2. 3. 4. 5. 6. ... The use of the Priority SMTP service extension is valid for SMTP, the submi= ssion service [RFC6409<http://tools.ietf.org/html/rfc6409>] and LMTP [RFC2= 033<http://tools.ietf.org/html/rfc2033>]. The support of this SMTP extensi= on is made separately and independently for each. Cheers, Glenn. ________________________________ From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: January-15-12 1:35 PM To: Glenn Parsons Cc: apps-discuss@ietf.org; draft-melnikov-smtp-priority.all@tools.ietf.org;= iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 On 12/01/2012 17:42, Glenn Parsons wrote: Alexey, You're welcome :-) Despite your assertion that LMTP would be a valid DownRef ... I do not thin= k this extension should be defined for it. If your suggestion is based on procedural ground, then I don't think it is = valid (please point out to a document which says that Informative reference= can't be used normatively). If you suggest this for some other reason, can= you please elaborate? That is I would suggest adding text along the lines of ...it is defined for= Message Submission and as a result may also be used for LMTP. I don't think that would be correct. There are 3 essentially different prot= ocols: Mail Submission, SMTP used to talk to MTAs, and LMTP. For each one t= he decision about whether an SMTP extension can be used with it needs to be= made separately and independently. On lines longer than 72 -- it just feels bad. SMTP line length limits are generally much higher, but I see your point. And further, you have no justification for this here. Is it for the messag= e length? Yes. If it is won't moving to Kb remove the need for a longer line? Ok, will do :-). On the naming you need to be consistent. For example, is it "PRI" or "PRIO= RITY" On docuemnt organization, there are two things defined here: Priority SMTP= extension & Priority message header. These need to be in distinct section= s with appropriate titles. It is the second that is currently hidden. Ok. Cheers, Glenn. ________________________________ From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: January-11-12 7:49 AM To: Glenn Parsons Cc: apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>; draft-melnikov-smt= p-priority.all@tools.ietf.org<mailto:draft-melnikov-smtp-priority.all@tools= .ietf.org>; iesg@ietf.org<mailto:iesg@ietf.org> Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 Hi Glenn, Thank you for your review. On 10/01/2012 21:10, Glenn Parsons wrote: I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-melnikov-smtp-priority-04 Title: Simple Mail Transfer Protocol extension for Message Priorities Reviewer: Glenn Parsons Review Date: January 10, 2012 Summary: This draft is not ready for publication as a Proposed Standard and should b= e revised before publication Major Issues: 3. in item #7 I presume this should be LMTP, but my concern is that it say= s this is being defined for LMTP. Since LMTP is informational, I don't thi= nk that is appropriate. Instead, I would suggest that it is defined for Me= ssage Submission and as a result may also be used for LMTP. I would prefe= r this to be noted in an Appendix (along with the LMTP advice in section 7)= -- but if you would prefer it to remain in the main body, it needs to be r= eworded. In either case, I would move LMTP to the informative references. I know that LMTP (RFC 2033) being Informational is annoying, but really, it= is a perfectly valid DownRef and can be called out during IETF LC. (At some point LMTP should be promoted to Proposed Standard, but that is la= rgely independent of this work.) 3. the too long example in 3.1 is apparently justified by item #6 here ...= but you can't have a line longer than 72 chars in an RFC... I think I've fixed that in my copy. but more importantly, how do you guarantee that this does not accidentally = blow something up. This is a HUGE change that is mentioned in passing with= out justification. This seems like a large hurdle for an implementation to= be able to add support for this. Why? Advertisement of supported levels is entirely optional. The use for this appears to be to fit in message size parameters for each p= riority (and I presume the message size is in bytes as it does not say). Yes, in bytes. Clarified in my copy. So why not use Kb instead of bytes? I was trying to be consistent with the SIZE SMTP extension which also uses = bytes. But as you are the second person to complain about that, maybe I wil= l give up and switch to Kb ;-). Or render the numbers in hex? Or split it over two lines? The last doesn't work well with SMTP. At least no SMTP extension ever liste= d more than 1 capability in EHLO response. I think any of these would be better than increasing the line length. 5. The priority level definition is not clear. There are 200 possible valu= es. But there MUST be at least 6 supported. OK that seems like overkill -= - why can't it be from -9 to 9 then? Anyway, is that 6 distinct numbers, 6= distinct numbers from the range shown, or any number for the range shown? = Further I would suggest that a default value should be specified for thes= e 6 levels and the default mapping ranges -- all in a table. As other people made the same comment, I will reply to this with my reasoni= ng in a separate email. 6 & 8. You need to pick something and be consistent. I would suggest it is= not necessary for them to be the same. So the EHLO one could be short "PR= I" and the header long "Message Transfer Priority". In any case, the termi= nology then needs alignment throughout the document. A definition of the Priority message header field is missing. It should be= after section 3. I think a forward reference in section 4.2 (where the MT-Priority header fi= eld is specified) would be sufficient. Unless you meant something else. Minor Issues: Title: I would change "Message Priorities " to "Message Transfer Priority" 6. The units for "message size" need to be indicated at some point in the d= ocument, at least in the syntax of section 6. This is already fixed in my copy (will be in -05). 3. I would suggest to replace "The following service extension is defined:"= with "The Priorty SMTP service extension is defined as follows:" 5.1.x I am somewhat concerned about informative implementation details -- I= presume that is why this is informative? Or is it because this is not exh= austive? Mostly the latter. In any case, I think this should be in the appendix. Ok. 6. It is confusing to have both specifications for the ESMTP and Header fie= ld in the same place. I would suggest separate appropriatley titled sub-s= ections of section 6 7. I would suggest adding an example fo the message header field in this c= lause. 9. What are the "anchor" placeholders for? This is just a hint to RFC Editor to insert the final RFC number, once know= n. 9. Presumably the TBD items need to be filled in... The 2 values will be assigned by IANA before publication. Nits: 3.1 the example is too long ** There is 1 instance of too long lines in the document, the longest one b= eing 12 characters in excess of 72. ...but I could not find this one: =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in th= e document. Ok, I will check. --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18538" name=3DGENERATOR></HEAD> <BODY text=3D#000000 bgColor=3D#ffffff> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Alexey,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>My objection on LMTP is not procedural, I just thi= nk it is=20 cleaner to define the SMTP Extension normatively as-is.  This extensio= n=20 does not need LMTP as a normative reference to be valid for LMTP -- but my = real=20 concern is that it should not be "defined" for LMTP.</FONT></SPAN></DI= V> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>So I suggest changing section 3 to not have LMTP i= n the=20 defined enumerated list:</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>The Priorty SM= TP service=20 extension is defined as follows:</SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>1. ...</SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>2.</SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>3.</SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>4.</SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>5.</SPAN></DIV= > <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012>6. ...</SPAN><= /DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2><FONT color=3D#000000>The use of the Priority SMTP= =20 service extension is valid for SMTP, the submission service =20 [</FONT><A title=3D'"Message Submission for Mail"'=20 href=3D"http://tools.ietf.org/html/rfc6409">RFC6409</A><FONT color=3D#00000= 0>] and=20 LMTP [</FONT><A title=3D'"Local Mail Transfer Protocol"'=20 href=3D"http://tools.ietf.org/html/rfc2033">RFC2033</A><FONT=20 color=3D#000000>].  <FONT face=3D"Times New Roman" size=3D3>The suppor= t of=20 this SMTP extension is made separately and independently for=20 each. </FONT><BR></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 size=3D2><FONT color=3D#0000ff>Cheers,</FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Glenn.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D002185422-16012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2><B>From:</B> Alexe= y Melnikov=20 [mailto:alexey.melnikov@isode.com] <BR><B>Sent:</B> January-15-12 1:35=20 PM<BR><B>To:</B> Glenn Parsons<BR><B>Cc:</B> apps-discuss@ietf.org;=20 draft-melnikov-smtp-priority.all@tools.ietf.org;=20 iesg@ietf.org<BR><B>Subject:</B> Re: [apps-discuss] Review of=20 draft-melnikov-smtp-priority-04<BR></FONT><BR></DIV> <DIV></DIV>On 12/01/2012 17:42, Glenn Parsons wrote:=20 <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <META content=3D"MSHTML 6.00.6002.18538" name=3DGENERATOR> <DIV><SPAN class=3D707193317-12012012><FONT face=3DArial color=3D#0000ff= =20 size=3D2>Alexey,</FONT></SPAN></DIV> <DIV><SPAN class=3D707193317-12012012></SPAN> </DIV> <DIV><SPAN class=3D707193317-12012012><FONT face=3DArial color=3D#0000ff= =20 size=3D2>You're welcome :-)</FONT></SPAN></DIV> <DIV><SPAN class=3D707193317-12012012></SPAN><SPAN=20 class=3D707193317-12012012></SPAN> </DIV> <DIV><SPAN class=3D707193317-12012012><FONT face=3DArial color=3D#0000ff= =20 size=3D2>Despite your assertion that LMTP would be a valid DownRef ... I = do not=20 think this extension should be defined for=20 it.</FONT></SPAN></DIV></BLOCKQUOTE>If your suggestion is based on procedur= al=20 ground, then I don't think it is valid (please point out to a document whic= h=20 says that Informative reference can't be used normatively). If you suggest = this=20 for some other reason, can you please elaborate? <BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><FONT face=3DArial color=3D#0000ff = size=3D2>That=20 is I would suggest adding text along the lines of <FONT=20 face=3D"Times New Roman"><FONT color=3D#000000 size=3D3>...it is defined = for Message=20 Submission and as a result may also be used for=20 LMTP.</FONT></FONT></FONT></SPAN></DIV></BLOCKQUOTE>I don't think that wo= uld be=20 correct. There are 3 essentially different protocols: Mail Submission, SMTP= used=20 to talk to MTAs, and LMTP. For each one the decision about whether an SMTP= =20 extension can be used with it needs to be made separately and=20 independently.  <BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>On lines longer than 72 -- it just = feels=20 bad.</FONT></SPAN></SPAN></DIV></BLOCKQUOTE>SMTP line length limits are=20 generally much higher, but I see your point.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>And further, you have no justificat= ion for=20 this here.  Is it for the message=20 length?</FONT></SPAN></SPAN></DIV></BLOCKQUOTE>Yes.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>If it is won't moving to Kb remove = the need=20 for a longer line?</FONT></SPAN></SPAN></DIV></BLOCKQUOTE>Ok, will do :-)= .<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>On the naming you need to be=20 consistent.  For example, is it "PRI" or=20 "PRIORITY"</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D707193317-12012012><SPAN=20 class=3D707193317-12012012></SPAN></SPAN> </DIV> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>On docuemnt organization, there are= two things=20 defined here:  Priority SMTP extension & Priority message=20 header.  These need to be in distinct sections with appropriate=20 titles.  It is the second that is currently=20 hidden.</FONT></SPAN></SPAN></DIV></BLOCKQUOTE>Ok.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EF04E78@EUSAACMS0714.eamcs.er= icsson.se=20 type=3D"cite"> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D707193317-12012012><SPAN class=3D707193317-12012012><F= ONT=20 face=3DArial color=3D#0000ff size=3D2>Glenn.</FONT></SPAN></SPAN></DIV> <DIV><SPAN class=3D707193317-12012012><SPAN=20 class=3D707193317-12012012></SPAN></SPAN> </DIV> <DIV> <HR tabIndex=3D-1> </DIV> <DIV><FONT face=3DTahoma size=3D2><B>From:</B> Alexey Melnikov [<A=20 class=3Dmoz-txt-link-freetext=20 href=3D"mailto:alexey.melnikov@isode.com">mailto:alexey.melnikov@isode.co= m</A>]=20 <BR><B>Sent:</B> January-11-12 7:49 AM<BR><B>To:</B> Glenn=20 Parsons<BR><B>Cc:</B> <A class=3Dmoz-txt-link-abbreviated=20 href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</A>; <A=20 class=3Dmoz-txt-link-abbreviated=20 href=3D"mailto:draft-melnikov-smtp-priority.all@tools.ietf.org">draft-mel= nikov-smtp-priority.all@tools.ietf.org</A>;=20 <A class=3Dmoz-txt-link-abbreviated=20 href=3D"mailto:iesg@ietf.org">iesg@ietf.org</A><BR><B>Subject:</B> Re:=20 [apps-discuss] Review of=20 draft-melnikov-smtp-priority-04<BR></FONT><BR></DIV>Hi Glenn,<BR>Thank yo= u for=20 your review.<BR><BR>On 10/01/2012 21:10, Glenn Parsons wrote:=20 <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <META content=3D"Microsoft Exchange Server" name=3DGenerator><!-- conve= rted from rtf --> <STYLE>.EmailQuote { PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid } </STYLE> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">I have been selected= as the=20 Applications Area Directorate reviewer for this draft (for background o= n=20 appsdir, please see <A class=3Dmoz-txt-link-freetext=20 href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaD= irectorate"=20 moz-do-not-send=3D"true">http://trac.tools.ietf.org/area/app/trac/wiki/= ApplicationsAreaDirectorate</A>).=20 </DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Please resolve these= =20 comments along with any other Last Call comments you may receive. Pleas= e=20 wait for direction from your document shepherd or AD before posting a n= ew=20 version of the draft.</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Document:=20 draft-melnikov-smtp-priority-04<BR>Title: Simple Mail Transfer Protocol= =20 extension for Message Priorities <BR>Reviewer: Glenn Parsons<BR>Review= =20 Date:  January 10, 2012<BR></DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Summary: </DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">This draft is not re= ady for=20 publication as a Proposed Standard and should be revised before=20 publication</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Major Issues:</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3.  in item #7 = I=20 presume this should be LMTP, but my concern is that it says this is bei= ng=20 defined for LMTP.  Since LMTP is informational, I don't think that= is=20 appropriate.  Instead, I would suggest that it is defined for Mess= age=20 Submission and as a result may also be used for LMTP.   I wou= ld=20 prefer this to be noted in an Appendix (along with the LMTP advice in=20 section 7) -- but if you would prefer it to remain in the main body, it= =20 needs to be reworded.  In either case, I would move LMTP to the=20 informative references. </DIV></BLOCKQUOTE>I know that LMTP (RFC 2033) = being=20 Informational is annoying, but really, it is a perfectly valid DownRef an= d can=20 be called out during IETF LC.<BR>(At some point LMTP should be promoted t= o=20 Proposed Standard, but that is largely independent of this work.) <BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3.  the too lon= g=20 example in 3.1 is apparently justified by item #6 here … but you = can't have=20 a line longer than 72 chars in an RFC…</DIV></BLOCKQUOTE>I think = I've fixed=20 that in my copy.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">but more importantly= , how=20 do you guarantee that this does not accidentally blow something up.&nbs= p;=20 This is a HUGE change that is mentioned in passing without=20 justification.  This seems like a large hurdle for an implementati= on to=20 be able to add support for this.</DIV></BLOCKQUOTE>Why? Advertisement o= f=20 supported levels is entirely optional. <BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">The use for this app= ears to=20 be to fit in message size parameters for each priority (and I presume t= he=20 message size is in bytes as it does not say). <BR></DIV></BLOCKQUOTE>Ye= s, in=20 bytes. Clarified in my copy.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">So why not use Kb in= stead=20 of bytes? <BR></DIV></BLOCKQUOTE>I was trying to be consistent with the= SIZE=20 SMTP extension which also uses bytes. But as you are the second person to= =20 complain about that, maybe I will give up and switch to Kb ;-).<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Or render the number= s in=20 hex?  Or split it over two lines?</DIV></BLOCKQUOTE>The last doesn= 't work=20 well with SMTP. At least no SMTP extension ever listed more than 1 capabi= lity=20 in EHLO response.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">I think any of these= would=20 be better than increasing the line length.</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">5. The priority leve= l=20 definition is not clear.  There are 200 possible values.  But= =20 there MUST be at least 6 supported.  OK that seems like overkill -= - why=20 can't it be from -9 to 9 then?  Anyway, is that 6 distinct numbers= , 6=20 distinct numbers from the range shown, or any number for the range=20 shown?  Further I would  suggest that a default value should = be=20 specified for these 6 levels and the default mapping ranges -- all in a= =20 table.</DIV></BLOCKQUOTE>As other people made the same comment, I will = reply=20 to this with my reasoning in a separate email.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6 & 8. You need = to pick=20 something and be consistent.  I would suggest it is not necessary = for=20 them to be the same.  So the EHLO one could be short "PRI" and the= =20 header long "Message Transfer Priority".  In any case, the termino= logy=20 then needs alignment throughout the document.</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">A definition of the= =20 Priority message header field is missing.  It should be after sect= ion=20 3.</DIV></BLOCKQUOTE>I think a forward reference in section 4.2 (where = the=20 MT-Priority header field is specified) would be sufficient. Unless you me= ant=20 something else. <BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Minor Issues:</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Title:  I would= change=20 "Message Priorities " to "Message Transfer Priority"</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6. The units for "me= ssage=20 size" need to be indicated at some point in the document, at least in t= he=20 syntax of section 6.</DIV></BLOCKQUOTE>This is already fixed in my copy= (will=20 be in -05).<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">3. I would suggest t= o=20 replace "The following service extension is defined:" with "The Priorty= SMTP=20 service extension is defined as follows:" </DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">5.1.x I am somewhat= =20 concerned about informative implementation details -- I presume that is= why=20 this is informative?  Or is it because this is not=20 exhaustive?</DIV></BLOCKQUOTE>Mostly the latter.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">In any case, I think= this=20 should be in the appendix.</DIV></BLOCKQUOTE>Ok.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">6. It is confusing t= o have=20 both specifications for the ESMTP and Header field in the same=20 place.   I would suggest separate appropriatley titled=20 sub-sections of section 6</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">7.  I would sug= gest=20 adding an example fo the message header field in this clause.</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">9.  What are th= e=20 "anchor" placeholders for?</DIV></BLOCKQUOTE>This is just a hint to RFC= Editor=20 to insert the final RFC number, once known.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">9. Presumably the TB= D items=20 need to be filled in...</DIV></BLOCKQUOTE>The 2 values will be assigned= by=20 IANA before publication.<BR> <BLOCKQUOTE=20 cite=3Dmid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.= ericsson.se=20 type=3D"cite"> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">Nits:  </DIV> <DIV> </DIV> <DIV>3.1 the example is too long </DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">** There is 1 instan= ce of=20 too long lines in the document, the longest one being 12 characters in= =20 excess of 72. </DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">…but I could n= ot find this=20 one:</DIV> <DIV style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt">=3D=3D There are 1 i= nstance of=20 lines with non-RFC2606-compliant FQDNs in the document. </DIV></BLOCKQU= OTE>Ok,=20 I will check.<BR><BR></BLOCKQUOTE><BR><BR></BODY></HTML> --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3FF5F8B6EUSAACMS0714e_-- From fanf2@hermes.cam.ac.uk Mon Jan 16 15:31:58 2012 Return-Path: <fanf2@hermes.cam.ac.uk> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E239921F86A5 for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 15:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.36 X-Spam-Level: X-Spam-Status: No, score=-5.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDQKXCIVEEJY for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 15:31:58 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 130A221F85B4 for <apps-discuss@ietf.org>; Mon, 16 Jan 2012 15:31:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35805) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Rmw1q-0004zc-EQ (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 16 Jan 2012 23:31:54 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rmw1q-0005w8-E1 (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 16 Jan 2012 23:31:54 +0000 Date: Mon, 16 Jan 2012 23:31:54 +0000 From: Tony Finch <dot@dotat.at> X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John C Klensin <john-ietf@jck.com> In-Reply-To: <AD693E95D4252DC3E8F3832F@PST.JCK.COM> Message-ID: <alpine.LSU.2.00.1201162328340.29180@hermes-2.csi.cam.ac.uk> References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar k.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch <fanf2@hermes.cam.ac.uk> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 16 Jan 2012 23:31:59 -0000 John C Klensin <john-ietf@jck.com> wrote: > > While I have no problem at all with the type of facility the > draft proposes, I think that, if we are going to entertain this > sort of thing, we should have a serious discussion about how far > we want to go in extending "Received:" Wouldn't this just be re-hashing a discussion that we already had quite recently? Murray's draft uses an extensibility hook (the Additional-Registered-Clauses ABNF production) that was added in RFC 5321. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Viking, North Utsire: Southerly 4 or 5. Slight or moderate. Showers then fair. Good. From johnl@iecc.com Mon Jan 16 21:19:42 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1948121F8598 for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 21:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.878 X-Spam-Level: X-Spam-Status: No, score=-103.878 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPl3+e4Wpspa for <apps-discuss@ietfa.amsl.com>; Mon, 16 Jan 2012 21:19:41 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3C21F8589 for <apps-discuss@ietf.org>; Mon, 16 Jan 2012 21:19:41 -0800 (PST) Received: (qmail 43567 invoked from network); 17 Jan 2012 05:19:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Jan 2012 05:19:40 -0000 Date: 17 Jan 2012 05:19:18 -0000 Message-ID: <20120117051918.1570.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <4F145D3E.8040502@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 05:19:42 -0000 > What is the utility of marking some fields as 'trace' fields? > > What coordination does it facilitate? I really do not understand the point. Please see the message I sent yesterday, which answers those questions. R's, John From ned.freed@mrochek.com Tue Jan 17 07:40:22 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBA21F8699 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 07:40:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdnlOskmEwBZ for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 07:40:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2959521F8600 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 07:40:22 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAVWWWHNU80013YM@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 17 Jan 2012 07:40:12 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAV4R81PYO0137RD@mauve.mrochek.com>; Tue, 17 Jan 2012 07:40:02 -0800 (PST) Message-id: <01OAVWWPTGN60137RD@mauve.mrochek.com> Date: Tue, 17 Jan 2012 07:37:03 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Mon, 16 Jan 2012 09:24:14 -0800" <4F145D3E.8040502@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan> <4F132D04.1020003@dcrocker.net> <01OAUJQ57QIA000HW1@mauve.mrochek.com> <4F145D3E.8040502@dcrocker.net> To: Dave CROCKER <dhc@dcrocker.net> Cc: Ned Freed <ned.freed@mrochek.com>, apps-discuss@ietf.org Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 15:40:22 -0000 > On 1/16/2012 8:09 AM, Ned Freed wrote: > > I have to agree with John Levine here - why can't this just be an added flag in > > the existiing header registry. The cost of that should be *far* lower than a > > new registry. In fact after experience with having additional purpose-specific > > media type registries (something we should never have allowed), I am *strongly* > > opposed to overlapping registries of any sort. (Right now I owe IANA a response > > about how in the blazes to address the current multiple registries for media > > types.) > I am still left with the basic concern, independent of whether this is a field > in an existing registry or is a new registry: > What is the utility of marking some fields as 'trace' fields? An obvious one is certain types of forwarding and digesting, where you want to strip trace information. Logging of trace also comes to mind. Our software has several lists of fields in it that it uses for such purposes; it would be helpful not to have to look through dozens of RFCs to figure out the content of such lists. > What coordination does it facilitate? I really do not understand the > point. Not sure what you mean by "coordination". > In the spec, it's useful to have the label 'trace' for education, to > conceptually aggregate some fields. But what is the /functional/ benefit of the > label? See above. Ned From d3e3e3@gmail.com Tue Jan 17 05:44:02 2012 Return-Path: <d3e3e3@gmail.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4B21F86B2; Tue, 17 Jan 2012 05:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.357 X-Spam-Level: X-Spam-Status: No, score=-104.357 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ohZqBpOGl7B; Tue, 17 Jan 2012 05:44:02 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59E21F86AF; Tue, 17 Jan 2012 05:44:01 -0800 (PST) Received: by lagv3 with SMTP id v3so2616910lag.31 for <multiple recipients>; Tue, 17 Jan 2012 05:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UeGN0S82pyweof8Nwo4Sq863ukPKZ9wbqOCPv+o4dNc=; b=m6FlbMZ3mIYnItINSCldGqFUvvB8NKlVm5aaDFSIxWK0jKkEsIbizIZsHpQj7qrsLL sHXvpBVfrOfU+6VWP6i0CzntlIUhB8A4QLdgOZcbJoXhXNNANOoeTbI7iBfJHACRO6ge HStf6hZqr0WDkuXRiMz+tb4GAwFYBU1nI7WvU= Received: by 10.112.48.193 with SMTP id o1mr4240087lbn.1.1326807840372; Tue, 17 Jan 2012 05:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.131 with HTTP; Tue, 17 Jan 2012 05:43:39 -0800 (PST) In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158A4@EXCH-C2.corp.cloudmark.com> References: <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com> <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.gmail.com> <F5833273385BB34F99288B3648C4F06F19C6C158A4@EXCH-C2.corp.cloudmark.com> From: Donald Eastlake <d3e3e3@gmail.com> Date: Tue, 17 Jan 2012 08:43:39 -0500 Message-ID: <CAF4+nEFyJrX8NhD72tgZBaqKK+8s6h8+G--iYjHxQwphiVJ7Lg@mail.gmail.com> To: "Murray S. Kucherawy" <msk@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Jan 2012 08:07:30 -0800 Cc: "dnsext@ietf.org" <dnsext@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" <draft-ietf-dnsext-xnamercode.all@tools.ietf.org> Subject: Re: [apps-discuss] [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 13:44:02 -0000 Hi, On Sat, Jan 14, 2012 at 11:39 PM, Murray S. Kucherawy <msk@cloudmark.com> w= rote: > Hi Donald, > >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: Saturday, January 14, 2012 3:53 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; draft-ietf-dnsext-xnamercode.all@tools.ietf.o= rg; dnsext@ietf.org >> Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode >> >> > Section 2 identifies two status bits as part of this clarification >> > document.=A0 However, it also says explicitly that their definitions a= re >> > unchanged from the documents that introduced them.=A0 I'm curious then >> > as to why they are included in this document at all; that is, what >> > clarification is being provided?=A0 Unlike Section 3, any ambiguity >> > about their use has not been identified here.=A0 If in fact there isn'= t >> > any, I think this section can be removed.=A0 If you like, you can >> > introduce references to and overviews of their definitions in a new >> > subsection of Section 1, since you do talk about them in Section 4. >> >> Well, the name of the document is "xNAME RCODE and Status Bits >> Clarification". I'm not sure why it would make that much difference to >> move Section 2 on status bits to a new subpart of Section 1. As you >> say, they are further discussed in Section 4. It seems to me that >> something can "clarify" with making any change. Given no objections in >> the DNSEXT WG to this material, I am inclined to leave it in. > > My point is not so much the position of the text as its purpose. =A0You'r= e right of course about the title, but it's not clear to me what is being c= larified with respect to the status bits, since you explicitly say they are= unchanged from their definitions. =A0That is, it seems to me deleting Sect= ion 2 entirely wouldn't remove anything from the document. > > If the purpose is merely to restate their definitions or refer to them so= the Section 4 text is more meaningful, then informative references to the = places where those are when you talk about them in Section 4 seems simpler = than what's there now. The purpose is to clarify as the title says. I do not accept your position that text which does not change something therefore cannot be a clarification. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > -MSK From dhc@dcrocker.net Tue Jan 17 08:48:48 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7B11E8079 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 08:48:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx+UcrCWWvqr for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 08:48:47 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B43E811E8076 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 08:48:47 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0HGmf5r022693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 08:48:46 -0800 Message-ID: <4F15A667.4030708@dcrocker.net> Date: Tue, 17 Jan 2012 08:48:39 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120115201817.34086.qmail@joyce.lan> In-Reply-To: <20120115201817.34086.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 17 Jan 2012 08:48:47 -0800 (PST) Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 16:48:48 -0000 On 1/15/2012 12:18 PM, John Levine wrote: >> 1. What coordination purpose will be served by the new registry? > > Unlike other headers, trace headers can occur multiple times in a > message, and their order means something. This should be of use to > code that parses headers. Summary: Your note and Ned's suggest to me a reasonable basis for adding a column to the existing message header fields registry. (Picky detail: Return-path isn't supposed to appear more than one. So the "multiple times" is currently limited to Received:. Also... This has been an interesting exercise. I had not previously noticed that RFC5321 and RFC5322 have conflicting definitions of 'trace'. RFC5321 equates it only to Received. RFC5322 uses it to describe a class of fields. If we are going to start doing more formal things about "trace" stuff, we are going to need to resolve this disparity. In addition, I suspect some folk are looking to increase the number of fields counted as <trace> and we're going to need to consider each field carefully, since the class gets special treatment. RFC5322: 3.6: More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information. ... | Field | Min | Max number | Notes | +----------------+--------+------------+----------------------------+ | trace | 0 | unlimited | Block prepended - see | | | | | 3.6.7 | 3.6.7: trace = [return] 1*received return = "Return-Path:" path CRLF received = "Received:" *received-token ";" date-time CRLF RFC5321: 4.1.1.4: When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. 4.4. Trace Information When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in Section 4.1.1.4. -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Jan 17 09:33:47 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD371F0C4E for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 09:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-QeZesvXfiB for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 09:33:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 614401F0C4D for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 09:33:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 17 Jan 2012 09:33:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 17 Jan 2012 09:33:45 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Tue, 17 Jan 2012 09:33:44 -0800 Thread-Topic: [apps-discuss] possibleTrace fields registry Thread-Index: AczVN+Qd4n8QpaMITr61H/ZDHhJ0jQABg97Q Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158B7@EXCH-C2.corp.cloudmark.com> References: <20120115201817.34086.qmail@joyce.lan> <4F15A667.4030708@dcrocker.net> In-Reply-To: <4F15A667.4030708@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 17:33:47 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Dave CROCKER > Sent: Tuesday, January 17, 2012 8:49 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] possibleTrace fields registry >=20 > This has been an interesting exercise. I had not previously noticed > that RFC5321 and RFC5322 have conflicting definitions of 'trace'. > RFC5321 equates it only to Received. RFC5322 uses it to describe a > class of fields. I don't see this as being a conflict. RFC5322 defines a trace field in gen= eral terms, and RFC5321 discusses one specific instance of a trace field, n= amely Received, as being the only one SMTP itself cares about. It doesn't = mean there aren't others, but an MTA doesn't do anything special with them = (i.e., doesn't add any new ones). -MSK From dhc@dcrocker.net Tue Jan 17 10:06:40 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6CF21F8475 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.885 X-Spam-Level: X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0t6jriHnYX2 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:06:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8767721F8474 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 10:06:39 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0HI6Xlr024990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 10:06:39 -0800 Message-ID: <4F15B8A7.9080907@dcrocker.net> Date: Tue, 17 Jan 2012 10:06:31 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120115201817.34086.qmail@joyce.lan> <4F15A667.4030708@dcrocker.net> <F5833273385BB34F99288B3648C4F06F19C6C158B7@EXCH-C2.corp.cloudmark.com> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158B7@EXCH-C2.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 17 Jan 2012 10:06:39 -0800 (PST) Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 18:06:40 -0000 On 1/17/2012 9:33 AM, Murray S. Kucherawy wrote: >> This has been an interesting exercise. I had not previously noticed >> that RFC5321 and RFC5322 have conflicting definitions of 'trace'. >> RFC5321 equates it only to Received. RFC5322 uses it to describe a >> class of fields. > > I don't see this as being a conflict. RFC5322 defines a trace field in general terms, and RFC5321 discusses one specific instance of a trace field, namely Received, as being the only one SMTP itself cares about. It doesn't mean there aren't others, but an MTA doesn't do anything special with them (i.e., doesn't add any new ones). Except that that's not what RFC5321 says. Your interpretation actually requires some linguistic creativity. RFC5321 does not note a larger concept, with Received being an instance. It simply uses the one term to refer to the one header field. (IMO, RFCs 821 and 822 created the problem of redundant and sometimes divergent definitions, though I hadn't noticed this one before.) So I think that what you've really done is suggest a simple and reasonable fix, requiring only a small amount of wording change to RFC 5321. When <trace> was a loosely-used term, the disparity didn't matter much. But since there is talk of formalizing the construct further, we should be careful about the details and not relay on assumptions about interpretation of specification text. Note, for example, the view that /any/ trace field can be repeated... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Tue Jan 17 10:36:26 2012 Return-Path: <vesely@tana.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B321F8473 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jgnTLs1I5pQ for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:36:25 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6921F846F for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 10:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326825384; bh=jieM098mAji0XH6wc9PjEV/sI1DmVYS/SvKTecMxJwA=; l=285; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LwR9a5inYLsbbuRtArPpOue1vo4mUnmtl5hYuljbSXXk6E5DZRTjYgHFEZ9UVd1Vs MON6YEMb9LyPcUwoqZbP3ZcF4D0sCtE3PDDDa9EYSPC1QFKW/n9FR8b+9Ho3nlCpED d3SskX+RA5ridvbZkL/Lz/fXFBHy/9RD3qPgCjhc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Jan 2012 19:36:24 +0100 id 00000000005DC039.000000004F15BFA8.00004C5A Message-ID: <4F15BFA8.6010608@tana.it> Date: Tue, 17 Jan 2012 19:36:24 +0100 From: Alessandro Vesely <vesely@tana.it> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120115201817.34086.qmail@joyce.lan> <4F15A667.4030708@dcrocker.net> In-Reply-To: <4F15A667.4030708@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 18:36:26 -0000 On 17/Jan/12 17:48, Dave CROCKER wrote: > RFC5321 equates it only to Received. RFC5322 uses it to describe a > class of fields. RFC 5321 also defines Return-Path, of course. As both definitions are given in Section 4.4, one could derive that they are both "Trace Information". From wwwrun@rfc-editor.org Tue Jan 17 11:17:55 2012 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497C11E80BB; Tue, 17 Jan 2012 11:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.774 X-Spam-Level: X-Spam-Status: No, score=-103.774 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1czRO7jKKzg; Tue, 17 Jan 2012 11:17:54 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id C20F511E807F; Tue, 17 Jan 2012 11:17:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D617F72E041; Tue, 17 Jan 2012 11:14:53 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120117191453.D617F72E041@rfc-editor.org> Date: Tue, 17 Jan 2012 11:14:53 -0800 (PST) Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] STD 73, RFC 6522 on The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 19:17:55 -0000 A new Request for Comments is now available in online RFC libraries. STD 73 RFC 6522 Title: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages Author: M. Kucherawy, Ed. Status: Standards Track Stream: IETF Date: January 2012 Mailbox: msk@cloudmark.com Pages: 9 Characters: 15715 Obsoletes: RFC3462 See Also: STD0073 I-D Tag: draft-ietf-appsawg-rfc3462bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc6522.txt The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports. This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK] This document is a product of the Applications Area Working Group Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nico@cryptonector.com Tue Jan 17 12:44:56 2012 Return-Path: <nico@cryptonector.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF021F873A for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 12:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV9H8IvxNZZS for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 12:44:56 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54821F8734 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 12:44:56 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id A4CC267C07A for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 12:44:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=A91cIWxaMZJ5SUFNTuFbLx7r3T1EI6eo7i1maT0o5ju5 dpZee+isFYjFK6H1h6qi3Zy9EIN5BHVJ70krFKuyVUs5/1son4wpZi0frXmkhgpD k2ytJzhicRKjaJBiHcOX3p3BzDZmGJxp21+HqjG958EkrqXv5MH9r3obXYbRGZQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=BXv2n4qEaZSm9vQAeSS0GS7+pYo=; b=RmWd9BZ3J0K /+Q7Idajwa21BEtn3Jpw0xxqNKj9czlM2HXIGBBb3qUVDR99WJVBrUx63eKFV/Sh nVYyEGuCT9VMc9FFDggFkgQdWHwsqcFa20CLAlTx124ccVp6+0TlVcu3HA7PpAIu 7i30D5ndf1M1wZ67T4LGHKu1SuN3TA4I= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 430C067C079 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 12:44:50 -0800 (PST) Received: by pbbb2 with SMTP id b2so4394953pbb.31 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 12:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.196 with SMTP id n4mr37320215pbv.33.1326833089841; Tue, 17 Jan 2012 12:44:49 -0800 (PST) Received: by 10.68.220.105 with HTTP; Tue, 17 Jan 2012 12:44:49 -0800 (PST) In-Reply-To: <4F15A667.4030708@dcrocker.net> References: <20120115201817.34086.qmail@joyce.lan> <4F15A667.4030708@dcrocker.net> Date: Tue, 17 Jan 2012 14:44:49 -0600 Message-ID: <CAK3OfOjgLXR4X22yjOH24RvkXZzUDwoPHhuwsjxwt6mTJTwsSA@mail.gmail.com> From: Nico Williams <nico@cryptonector.com> To: dcrocker@bbiw.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] possibleTrace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 17 Jan 2012 20:44:56 -0000 On Tue, Jan 17, 2012 at 10:48 AM, Dave CROCKER <dhc@dcrocker.net> wrote: > RFC5321: > > =C2=A0 4.1.1.4: > > =C2=A0 When the SMTP server accepts a message either for relaying or for > =C2=A0 final delivery, it inserts a trace record (also referred to > =C2=A0 interchangeably as a "time stamp line" or "Received" line) at the = top > =C2=A0 of the mail data. > > > =C2=A0 4.4. =C2=A0Trace Information > > =C2=A0 When an SMTP server receives a message for delivery or further > =C2=A0 processing, it MUST insert trace ("time stamp" or "Received") > =C2=A0 information at the beginning of the message content, as discussed = in > =C2=A0 Section 4.1.1.4. I read 4.4 as implying that "Received" (a.k.a. "time stamp") is an example of known trace headers. I read 4.1.1.4 as implying that "Received" is the only then-known trace hea= der. I don't read either as excluding other trace headers -- it'd be quite a stretch to do so. At most we have an erratum against RFC5321, but a need to update it? just for this? IMO: no need to update RFC5321. Nico -- From johnl@iecc.com Tue Jan 17 18:11:16 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2877521F847B for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 18:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.838 X-Spam-Level: X-Spam-Status: No, score=-103.838 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpDx5SommY01 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 18:11:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8A21F847A for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 18:11:14 -0800 (PST) Received: (qmail 57754 invoked from network); 18 Jan 2012 02:11:12 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Jan 2012 02:11:12 -0000 Date: 18 Jan 2012 02:10:50 -0000 Message-ID: <20120118021050.33898.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <4F15A667.4030708@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [apps-discuss] Draft for trace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 02:11:16 -0000 I wrote a draft to add a trace column to the existing header field registry. This is mostly about the registry; SM's draft (which I didn't know he was writing) is more about what trace fields are. R's, John ------------------- snippo ----------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Registry for Mail Trace Fields Author(s) : Taughannock Networks Filename : draft-levine-trace-header-registry-00.txt Pages : 4 Date : 2012-01-17 SMTP mail software adds trace header fields to messages as they pass through the mail system. This document updates the definition of trace header fields, and adds trace field information to the registries for Permanent Message Header Fields and Provisional Message Header Fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-levine-trace-header-registry-00.txt From ned.freed@mrochek.com Tue Jan 17 18:21:33 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1164021F854D for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 18:21:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E6MAt02Y5Pr for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 18:21:23 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5AED721F8493 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 18:21:19 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAWJARJME800UWXO@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 17 Jan 2012 18:21:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAVYW3FP280137RD@mauve.mrochek.com>; Tue, 17 Jan 2012 18:21:15 -0800 (PST) Message-id: <01OAWJAQ2AOA0137RD@mauve.mrochek.com> Date: Tue, 17 Jan 2012 18:20:43 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Wed, 18 Jan 2012 02:10:50 +0000" <20120118021050.33898.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F15A667.4030708@dcrocker.net> <20120118021050.33898.qmail@joyce.lan> To: John Levine <johnl@taugh.com> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft for trace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 02:21:33 -0000 > I wrote a draft to add a trace column to the existing header field > registry. This is mostly about the registry; SM's draft (which I > didn't know he was writing) is more about what trace fields are. Would it make sense to you and SM to combine them? Ned From sm@elandsys.com Tue Jan 17 21:13:23 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C5C11E808F for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 21:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2nyfRCCxDJu for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 21:13:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C85E911E8083 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 21:13:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.235.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0I5D5ZO011795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 21:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326863599; i=@elandsys.com; bh=zMaT3yCnDVHYP6fwNqPLXUU4P2YiqPH1hYcknf1QgQE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=LYUkSRCF5H5AobvZzU/T11KzBOM8z7qYbgRw0WC/8gQF0i7WlL6n8yN1Hq+b/5MtY 7MqS7rXyEwVaGjdlsfny1KlmfdXXUeDKO05sDoLF0qJyVmfMpSrxFgqmIKL+QDWjuJ z1DB87Q8xAcfMyF6nXg/B7Yg69pKtYnQRJ4QCyRI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326863599; i=@elandsys.com; bh=zMaT3yCnDVHYP6fwNqPLXUU4P2YiqPH1hYcknf1QgQE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=QXjE4dX3TmhCQT2S/WvQCiYWrQF88d24A0wXzahb8e8W2nVPyCB//NKuUwLiSj8TG cIKHHIBDLEuAdwgHIGQKkWSMBUZJLT/gX9cnX46x3ouGxeiK+6DxksZ6Ni3+7Zl52u QIbm7e7Dqy5gtNjDaKptr8MHE9OozvgcAT3S3wUI= Message-Id: <6.2.5.6.2.20120117195933.0b36b1f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jan 2012 21:09:41 -0800 To: "John Levine" <johnl@taugh.com> From: S Moonesamy <sm+ietf@elandsys.com> In-Reply-To: <20120118021050.33898.qmail@joyce.lan> References: <4F15A667.4030708@dcrocker.net> <20120118021050.33898.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Draft for trace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 05:13:23 -0000 Hi John, At 18:10 17-01-2012, John Levine wrote: >I wrote a draft to add a trace column to the existing header field >registry. This is mostly about the registry; SM's draft (which I >didn't know he was writing) is more about what trace fields are. Yes. I wrote about Trace fields in response to the latest discussions on this list. draft-moonesamy-mail-trace-fields-00 provides some background information about Trace fields, hence the reference to RFC 4871 (obsolete). BTW, I already know about the invalid RFC822 reference. The draft does not mention the registry part as you mentioned that you might work on that. I only covered mail-related specifications mentioning Trace fields up to "VBR-Info" as they are related to the DKIM work. RFC 5598 is not mentioned as it uses RFC 2505 (antispam) to reference "trace information". I don't feel strongly about the question of Trace fields. I'll comment on draft-levine-trace-header-registry-00 as we looked at the topic from different viewpoints. Section 3.6 of RFC 5322 discusses about "trace header field" and has a requirement for not reordering them and a recommendation for keeping them in blocks (see issues in Section 6 of draft-moonesamy-mail-trace-fields-00). Section 3.1 of draft-levine-trace-header-registry-00 keeps the requirement and drops the recommendation. Such a change would generate some on-list discussion. My preference is to use "trace information" to discuss about documenting the progress of a message through the e-mail system (second paragraph of Section 3.1 of your draft). Section 3.6 of RFC 5322 mentions that: "the trace header fields and resent header fields MUST NOT be reordered" I'll defer to the editor of RFC 5322 as to what exactly is a Trace field as it is not clear given the text quoted above and what's in Section 3.6.7. As a reply to Ned's question, I am ok with combining the two drafts if John thinks that the material is appropriate for the topic he is tackling. Regards, S. Moonesamy From msk@cloudmark.com Tue Jan 17 22:23:28 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DECB21F86C6 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 22:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk4jZ-Nx5uEz for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 22:23:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5721F86C5 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 22:23:27 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 17 Jan 2012 22:23:18 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 17 Jan 2012 22:23:27 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Tue, 17 Jan 2012 22:23:30 -0800 Thread-Topic: [apps-discuss] Draft for trace fields registry Thread-Index: AczVh+b2jA71ywagQS6cWlYn9KBhiQAIaPOg Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158D8@EXCH-C2.corp.cloudmark.com> References: <4F15A667.4030708@dcrocker.net> <20120118021050.33898.qmail@joyce.lan> <01OAWJAQ2AOA0137RD@mauve.mrochek.com> In-Reply-To: <01OAWJAQ2AOA0137RD@mauve.mrochek.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 Subject: Re: [apps-discuss] Draft for trace fields registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 06:23:28 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Ned Freed > Sent: Tuesday, January 17, 2012 6:21 PM > To: John Levine > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Draft for trace fields registry >=20 > > I wrote a draft to add a trace column to the existing header field > > registry. This is mostly about the registry; SM's draft (which I > > didn't know he was writing) is more about what trace fields are. >=20 > Would it make sense to you and SM to combine them? I like the idea of doing all of the "trace header field" cleanup work we're= talking about in a single document. However, all of this seems orthogonal to the processing of the "received-st= ate" draft, because I still think tagging Received fields in that way is th= e right thing to do. From sm@elandsys.com Wed Jan 18 09:21:25 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7F21F84BD for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 09:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIOJ9MnCo-DQ for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 09:21:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2821F84C2 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 09:21:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0IHKdlq019229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 09:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326907275; i=@elandsys.com; bh=+JnJ+enxwPr4Fu4PMiS6c9wc0MYB24UnxMzVFfHFw6Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=AMEyGRsSISP9biWcG4mYrw4OwrNX1MZJdYFoAixmAQcD/RD2WMIUN6929WDKOOMvF TNfoPesAEw02WpuVi9LsqC1jNxxy1019J8PJDBMxW6rqTYa0psCj0xleO2PIgqTepz 0aVA8MghG+FTsPg4Ly850WkmMQOkEtBt9Vmz5o80= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326907275; i=@elandsys.com; bh=+JnJ+enxwPr4Fu4PMiS6c9wc0MYB24UnxMzVFfHFw6Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=175vSzsKF+bCiDUEsB4kkaU+h719L2b5xkGvftpGbQp91S/9sO79HpJ1hiCFaBSJF HoYFyOSZYQln1nusLQdip/IWg/qgz5puSro56FHolJaoa68ZvoOcZtTMB6i3ETU7yg xAocAV4Lf33GK7glXtExSFjc6m0UkT/yW97N2lMs= Message-Id: <6.2.5.6.2.20120118080640.097bb400@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Jan 2012 09:16:15 -0800 To: apps-discuss@ietf.org From: S Moonesamy <sm+ietf@elandsys.com> In-Reply-To: <6.2.5.6.2.20120108011725.0bfaf2b8@resistor.net> References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> <F5833273385BB34F99288B3648C4F06F19C6C1578F@EXCH-C2.corp.cloudmark.com> <6.2.5.6.2.20120108011725.0bfaf2b8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 17:21:25 -0000 Hello, I plan to submit draft-moonesamy-rfc2369bis-02 today. The list of changes from -01 are: o Added ABNF and reference to RFC 5234 o Removed text about postmaster in List-Owner Section o Removed User Interface guidelines from Appendix B o Removed SHOULD include a "mailto" based command in Section 3 o Modified the text to first paragraph of Section 3.1 Thanks to Mykyta Yevstifeye, Murray S. Kucherawy and John Levine for feedback. I'll summarize the comments. As usual, if I misunderstood anything you said, please email me. I added "List-Sequence" in the Abstract Section as Mykyta suggested [1] and added the IANA registration. I included the ABNF he suggested and some editorial changes (mailto). Murray suggested [2] including ABNF. As he commented on the language at the top of 3.1 sounding vaguely like a minimum compliance statement, I modified the text. The suggestion to use "postmaster" in Section 3.5 of draft-moonesamy-rfc2369bis-01 has been removed. The Client Implementation appendix has been removed as John Levine also commented on not providing UI guidance. I have not added a reference to draft-gregorio-uritemplate (values expanded by MUA). John Levine suggested [3] not providing MUA user interface design advice. Appendix B has been removed. I removed the text that sounded like the "the constant harping to use mailto:". I kept Section 4 about Nested lists. Murray also mentioned having some text in the Security Considerations Section to recommend that MUAs should not generate the header fields. I didn't make that change as there is already a recommendation in the second paragraph of Section 3. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04032.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04039.html 3. http://www.ietf.org/mail-archive/web/appsdir/current/msg00687.html From msk@cloudmark.com Wed Jan 18 10:47:39 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0D021F869D for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 10:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yju9B0v-Q5Ht for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 10:47:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAF921F8585 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 10:47:32 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 18 Jan 2012 10:47:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 18 Jan 2012 10:47:31 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Wed, 18 Jan 2012 10:47:30 -0800 Thread-Topic: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 Thread-Index: AczWBZ5pdPQZzZPkTVaS+22tCY/4OgAChhcA Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158EA@EXCH-C2.corp.cloudmark.com> References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> <F5833273385BB34F99288B3648C4F06F19C6C1578F@EXCH-C2.corp.cloudmark.com> <6.2.5.6.2.20120108011725.0bfaf2b8@resistor.net> <6.2.5.6.2.20120118080640.097bb400@resistor.net> In-Reply-To: <6.2.5.6.2.20120118080640.097bb400@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 18:47:39 -0000 Sounds like a good step forward. One thing I might suggest including, either in the Abstract, Introduction o= r an Appendix, is an explanation of why this is being reissued. In particu= lar, you've said your main impetus for doing this is the URL-URI evolution,= so I imagine it would be helpful to highlight that in some way. -MSK From sm@elandsys.com Wed Jan 18 11:57:38 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23511E809D for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 11:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEzIVRMWXlVE for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 11:57:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA93911E807F for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 11:57:33 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.237.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0IJvKTs007207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 11:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326916651; i=@elandsys.com; bh=8cGAWtx80wnTLdzxBHLLMjs9A9RcHWQn6qSyXEXAXGw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=DyCzOtkXiXk0zyIz2inVKcw1Z0C91laQq3BqipWfKK8BZNrLzkEpjV2bAB351nWG6 EuX5MYgmvr0mM99CGrknDP5PUQI2S2sNQJ5b9GMdreyW5B8Or/GtvbYr+ClyqQ8woY RrBTxoHC6tcWLp/Qf7hvJ1ZVyAe8r7x2XfSyR+0s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1326916651; i=@elandsys.com; bh=8cGAWtx80wnTLdzxBHLLMjs9A9RcHWQn6qSyXEXAXGw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=CwHRZCftjBEcFRjF1hn06JfrlDwTUJ9gJ++ZXOFjbA9gsou7lRPP+imIqSn/x+Zb3 5TO21UG/meTZO/Uf/NxVwqBmwGPBxGLKY4Jq0dMfE3UjBb1eIYLquBXoJCynA3b1Ya yPOWuB3e7/f3/zYLTM0/Uyn9H5Ye5o7Y9EEmdTMs= Message-Id: <6.2.5.6.2.20120118111712.0961dda8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Jan 2012 11:57:12 -0800 To: apps-discuss@ietf.org From: S Moonesamy <sm+ietf@elandsys.com> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158EA@EXCH-C2.corp.cl oudmark.com> References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan> <F5833273385BB34F99288B3648C4F06F19C6C1578F@EXCH-C2.corp.cloudmark.com> <6.2.5.6.2.20120108011725.0bfaf2b8@resistor.net> <6.2.5.6.2.20120118080640.097bb400@resistor.net> <F5833273385BB34F99288B3648C4F06F19C6C158EA@EXCH-C2.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] [appsdir] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 19:57:38 -0000 Hi Murray, At 10:47 18-01-2012, Murray S. Kucherawy wrote: >Sounds like a good step forward. Thanks. >One thing I might suggest including, either in the Abstract, >Introduction or an Appendix, is an explanation of why this is being >reissued. In particular, you've said your main impetus for doing >this is the URL-URI evolution, so I imagine it would be helpful to >highlight that in some way. I changed the first paragraph of the Introduction Section as follows: RFC 2369 [RFC2369] defined additional header fields to be added to email messages sent by mailing list managers (MLMs). The significant change in this document is the use of Uniform Resource Identifier (URI) [RFC3986], instead of Uniform Resource Locator (URL), allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. The content of each new header field is typically a URI - usually "mailto" [RFC6068] - which identifies the relevant information or performs the command directly. Regards, S. Moonesamy From john-ietf@jck.com Wed Jan 18 14:35:19 2012 Return-Path: <john-ietf@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5817811E80B0 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 14:35:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DavSeNghV9uD for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 14:35:18 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B1ADB11E80A2 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 14:35:18 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Rne2g-0007te-TN for apps-discuss@ietf.org; Wed, 18 Jan 2012 17:31:42 -0500 X-Vipre-Scanned: 0815DE89002C310815DFD6-TDI Date: Wed, 18 Jan 2012 17:35:17 -0500 From: John C Klensin <john-ietf@jck.com> To: apps-discuss@ietf.org Message-ID: <3EBF175E9FCAA85080916A79@[192.168.1.128]> In-Reply-To: <01OAUJAX2HRI000HW1@mauve.mrochek.com> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@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 Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 22:35:19 -0000 Hi. I had a major system failure on Sunday, may have lost some hours of email, and, while I got an alternate server up early Monday, I have been only only slowly digging out. The discussion seems to have progressed significantly after I dropped out, including a couple of new I-Ds. While I hope those could be consolidated to the degree possible, I think the idea of getting these things registered is just great. It may still be worth clarifying the point/suggestion I was trying to make. First, my concern was that loading too much disparate information into "Received:", and especially intermixing post-delivery MUA information with in transit MTA information might not be a sufficiently good idea that we should do it automatically and without thinking. I didn't say "don't do it", especially wrt this specific proposal. I did suggest that it was worth examining the question. Second, please remember that, while RFC 5321 requires RFC 5322-conforming date-time fields, the <daytime> production of RFC 821 is a little different. The 821 syntax is not quite a proper subset of the 5321/5322 syntax (e.g., seconds are required in 821 and not in 5321/5322, 821 permitted two-digit years, etc.). Both 821 and 5321 require that both FROM and BY appear, but I've seen that rule broken innumerable times. 5321 permits "TCP-info" to be supplied as a comment to BY (in <Extended-domain>); 821 does not. I've also seen liberties taken with the specific format of the <date-time> (or <datetime>) fields, especially by systems on the other side of gateways that, e.g., use ISO dates (both 821 and 5321 warn against (5321 says "MUST NOT") later systems messing with those fields to try to "correct" them). The multiple-path FOR form is still seen in the wild, despite the security issues and language in 5321 deprecating it. If multiple paths or mailboxes are used with FOR, the beginning of the [Additional-Registered-Clauses] becomes ambiguous, at least in theory. I have no doubt that Ned, or anyone else even half as competent, can sort this out and has implementations that do so. I believe that any MUA that is really as robust as 5322 MUAs are supposed to be (indeed required to be to deal with other common erroneous practices) can get it right. But we see intermediate MTAs and post-delivery filters trying to check these fields for bogus information as part of spam assessments, and some of those are not too bright. So what I was suggesting, and continue to suggest, is that it may be time to think about whether it is better to keep adding fields to "Received:" or whether one or more additional header fields are in order. Clearly the disadvantage of additional ones is that something that treats anything appearing between the first and last "Received:" header fields other than more of them as bogus would get into trouble. The advantage is that something that wants to find one of these things for processing purposes would know exactly where to look, rather than having to parse "Received:" fields, looking for the relevant information, and trusting that someone hasn't used the same <Additional-Registered-Clauses> for something else (despite the SHOULD NOT) in 5321 Section 4.4). If we concluded that additional header fields, with different names, were appropriate, it might still be the case that the current "received-state" proposal would belong within "Received:". I'm just suggesting that we ask the question. john From msk@cloudmark.com Wed Jan 18 15:20:48 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4428911E80D6 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 15:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CWuJgykSCC2 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 15:20:47 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACBB11E80B5 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 15:20:47 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 18 Jan 2012 15:20:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 18 Jan 2012 15:20:46 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Wed, 18 Jan 2012 15:20:45 -0800 Thread-Topic: [apps-discuss] Adoption of draft-kucherawy-received-state? Thread-Index: AczWMXaqVjHq9fXYSD++30DcpXrmTQABI9Gw Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cloudmark.com> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> In-Reply-To: <3EBF175E9FCAA85080916A79@[192.168.1.128]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 23:20:48 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John C Klensin > Sent: Wednesday, January 18, 2012 2:35 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? >=20 > First, my concern was that loading too much disparate information into > "Received:", and especially intermixing post-delivery MUA information > with in transit MTA information might not be a sufficiently good idea tha= t we should do it > automatically and without thinking. I didn't say "don't do > it", especially wrt this specific proposal. I did suggest that it was > worth examining the question. I had thought there was objection to doing the received-state work by using= Additional-Registered-Clauses, when my own MTA implementation experience s= uggests to me that it's actually ideal and that a new header field wouldn't= be right for this. Rather, what I'm seeing now is just an observation tha= t the whole "trace field" thing is a little under-defined and we need to fi= x that. I can buy that if we agree the two topics are in fact separate. And an interesting observation: When I wrote RFC5451, my goal was to call A= uthentication-Results a trace field specifically because preserving the ord= er of addition of Received fields with this mixed in is an important hint t= o figuring out where, and perhaps why, message authentication work ran into= problems. So I only wanted to piggyback on the "don't reorder or change t= his" rule that had already been laid out rather than re-stating it. Howeve= r, it also has an end-user purpose, which you correctly called post-deliver= y MUA information. That part isn't exactly trace information per se, or ma= ybe it is but it's actually MUA-actionable. So that header field is actual= ly a mix of both types of header field, I suppose: Agents should all follow= trace header field handling rules, but it actually contains actionable stu= ff. I'm hoping it doesn't thus deserve its own hybrid category... One reason I prefer a Received extension for the received state work is bec= ause moving it into its own header field requires repetition of a bunch of = information (hostname and date, for starters) that's already present in a c= orresponding Received field. Thus, it seems it would add more clutter than= it's worth to go that route. > So what I was suggesting, and continue to suggest, is that it may be > time to think about whether it is better to keep adding fields to > "Received:" or whether one or more additional header fields are in > order. I think perhaps the amalgamated draft we seem to see forming between John's= and SM's proposals might do well to talk about situations where each appro= ach (Additional-Registered-Clause vs. new header field) is more appropriate= . > The advantage is that something that wants to find one of these things > for processing purposes would know exactly where to look, rather than > having to parse "Received:" fields, looking for the relevant > information, and trusting that someone hasn't used the same > <Additional-Registered-Clauses> for something else (despite the SHOULD > NOT) in 5321 Section 4.4). So far since the parsing of Received is mostly 1*(key value) up until the d= ate part, parsing hasn't been a problem for systems I've worked on. Most s= ystems appropriately ignore things they don't understand. However, natural= ly, I don't claim to speak for anything more than a fraction of the Receive= d parsers out there. -MSK From john@jck.com Wed Jan 18 16:16:04 2012 Return-Path: <john@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B9411E80CC for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:16:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVN-ctiN116T for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:16:03 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 90ADB21F84BD for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:16:03 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john@jck.com>) id 1RnfcB-00085u-Gn; Wed, 18 Jan 2012 19:12:27 -0500 X-Vipre-Scanned: 08721AD7002C3108721C24-TDI Date: Wed, 18 Jan 2012 19:16:02 -0500 From: John C Klensin <john@jck.com> To: "Murray S. Kucherawy" <msk@cloudmark.com>, apps-discuss@ietf.org Message-ID: <7DECF7F6F0E78270C1FD4FDE@[192.168.1.128]> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cloudmark.com> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cloudmark.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 00:16:04 -0000 --On Wednesday, January 18, 2012 15:20 -0800 "Murray S. Kucherawy" <msk@cloudmark.com> wrote: >> First, my concern was that loading too much disparate >> information into "Received:", and especially intermixing >> post-delivery MUA information with in transit MTA information >> might not be a sufficiently good idea that we should do it >> automatically and without thinking. I didn't say "don't do >> it", especially wrt this specific proposal. I did suggest >> that it was worth examining the question. > I had thought there was objection to doing the received-state > work by using Additional-Registered-Clauses, when my own MTA > implementation experience suggests to me that it's actually > ideal and that a new header field wouldn't be right for this. > Rather, what I'm seeing now is just an observation that the > whole "trace field" thing is a little under-defined and we > need to fix that. I can buy that if we agree the two topics > are in fact separate. First, this is exactly the discussion I wanted to encourage. There is a huge difference, IMO, between "MTA implementation experience suggests to me that it's actually ideal and that a new header field wouldn't be right for this" and "let's push this into "Received:" because "Received:" is there. And, yes, the topics are mostly -- but not entirely-- separate. > And an interesting observation: When I wrote RFC5451, my goal > was to call Authentication-Results a trace field specifically > because preserving the order of addition of Received fields > with this mixed in is an important hint to figuring out where, > and perhaps why, message authentication work ran into > problems. So I only wanted to piggyback on the "don't reorder > or change this" rule that had already been laid out rather > than re-stating it. However, it also has an end-user purpose, > which you correctly called post-delivery MUA information. > That part isn't exactly trace information per se, or maybe it > is but it's actually MUA-actionable. So that header field is > actually a mix of both types of header field, I suppose: > Agents should all follow trace header field handling rules, > but it actually contains actionable stuff. I'm hoping it > doesn't thus deserve its own hybrid category... While I share your hope that it does not, the other line that is being crossed here is between "used primarily for debugging" (a phrase that, if I recall, appears both in 5321 and 821) in contexts that imply "mostly parsed and interpreted by humans" and "actionable by MUAs" (which implies a lot of parsing and interpretation by machines). The tradeoffs may still favor putting everything in "Received:" header fields, or my favor splitting it up in some way. I actually don't have a position on the subject; I am only asking that we discuss it rather than dropping into an accidental default. > One reason I prefer a Received extension for the received > state work is because moving it into its own header field > requires repetition of a bunch of information (hostname and > date, for starters) that's already present in a corresponding > Received field. Thus, it seems it would add more clutter than > it's worth to go that route. Makes sense. >> So what I was suggesting, and continue to suggest, is that it >> may be time to think about whether it is better to keep >> adding fields to "Received:" or whether one or more >> additional header fields are in order. > > I think perhaps the amalgamated draft we seem to see forming > between John's and SM's proposals might do well to talk about > situations where each approach (Additional-Registered-Clause > vs. new header field) is more appropriate. If that happened, my concern and, for this issue, interest would shift entirely to the discussion of that draft and away from your specific draft. >> The advantage is that something that wants to find one of >> these things for processing purposes would know exactly where >> to look, rather than having to parse "Received:" fields, >> looking for the relevant information, and trusting that >> someone hasn't used the same <Additional-Registered-Clauses> >> for something else (despite the SHOULD NOT) in 5321 Section >> 4.4). > > So far since the parsing of Received is mostly 1*(key value) > up until the date part, parsing hasn't been a problem for > systems I've worked on. Most systems appropriately ignore > things they don't understand. However, naturally, I don't > claim to speak for anything more than a fraction of the > Received parsers out there. Ack. john From sm@resistor.net Wed Jan 18 16:27:33 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7311E80D7 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkmVfKPHDE-T for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:32 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BAF21F8582 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:27:32 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0J0RNkA021416 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326932851; i=@resistor.net; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sDylpu1GVroIvQWfYKtzrryeL4a/7WJM7tutvxW5A8001Ivrjje0P0kf1/+UeK6lI sGK+gOe5GaBxu8uVUTABiOJRAMxSdCzzie8BWDoHC/tb9bo/Zkf2EUMdygKhAeFu6M V9vqrQx3g6azxooLaN+Buulwq/F69nyhs3IV4T5I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326932851; i=@resistor.net; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wcSgdYZwOhT2Q8wX4oOjNfsHC1Um07Pq+zddlVqLblhbh3HUyn86fn2VjYVp7jXka QYCeybsUTHh9y2WRxToogoCRJJaHSeyUL3qoNCqhbM56VdKlVZYuu4Taf3S0Qf1osE Dd40R0tc9/Vd43JjFkPWYf1KOEuK+e+hXP3QZI5E= Message-Id: <6.2.5.6.2.20120118155854.0a1c4730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Jan 2012 16:19:58 -0800 To: apps-discuss@ietf.org From: SM <sm@resistor.net> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cl oudmark.com> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 00:27:33 -0000 Hi Murray, At 15:20 18-01-2012, Murray S. Kucherawy wrote: >And an interesting observation: When I wrote RFC5451, my goal was to >call Authentication-Results a trace field specifically because >preserving the order of addition of Received fields with this mixed >in is an important hint to figuring out where, and perhaps why, >message authentication work ran into problems. So I only wanted to >piggyback on the "don't reorder or change this" rule that had >already been laid out rather than re-stating Several other specifications have followed the piggyback path. In my opinion, the question is worth discussing as it is not clear whether it is an acceptable practice. > it. However, it also has an end-user purpose, which you correctly > called post-delivery MUA information. That part isn't exactly > trace information per se, or maybe it is but it's actually > MUA-actionable. So that header field is actually a mix of both > types of header field, I suppose: Agents should all follow trace > header field handling rules, but it actually contains actionable > stuff. I'm hoping it doesn't thus deserve its own hybrid category... It's easier to pretend not to see this part instead of trying to come up with a hybrid category. :-) >I think perhaps the amalgamated draft we seem to see forming between >John's and SM's proposals might do well to talk about situations >where each approach (Additional-Registered-Clause vs. new header >field) is more appropriate. I haven't discussed the approach to take with John Levine. I don't have a preference at the moment. Regards, -sm From sm@resistor.net Wed Jan 18 16:27:33 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78A11E808C for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 686gltu6w4Py for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:30 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37321F857A for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:27:30 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0J0RNk8021416; Wed, 18 Jan 2012 16:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326932848; i=@resistor.net; bh=9PLPlVhbJLuEaPYBMkumYsG2ujPurCrHbNvAHJ1WJ8g=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Eah6GfmGKBymACfq2vYBxZ83I1VlvezgiYj0sYArmFFyClrVyWmjYdqwni1LD5IcF IrKyeRMcq7htZH0ASd3W1UkYhcIX8+vsfg3jZCEzvbZFVE9nCRfM1Rep2ZtZ8SXXlD 1a16uEpv6b0E642usmMPPDh+Ckdn3acJe//XCwyM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326932848; i=@resistor.net; bh=9PLPlVhbJLuEaPYBMkumYsG2ujPurCrHbNvAHJ1WJ8g=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=NOPC+wm9ndzJZKQ8tjkF15Hu2GhlFX9NUUIMmboSQxG5SYrOCnCceDSlSJQxAkLJe 8h3i1r/lkQy0bejoJ0DE38UvCdGh5KZ2UYT5QDEc7KurtBQl9KN1nfzzc9yKwkcUzh uHEF6OosQeMxtv4PteWIPbuny0SJiO5fGxHDsQ+4= Message-Id: <6.2.5.6.2.20120118153446.0a1c44a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Jan 2012 15:58:46 -0800 To: John C Klensin <john-ietf@jck.com> From: SM <sm@resistor.net> In-Reply-To: <3EBF175E9FCAA85080916A79@[192.168.1.128]> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 00:27:33 -0000 Hi John, At 14:35 18-01-2012, John C Klensin wrote: >I had a major system failure on Sunday, may have lost some hours >of email, and, while I got an alternate server up early Monday, I hope that everything is fine now. >I have been only only slowly digging out. The discussion seems >to have progressed significantly after I dropped out, including >a couple of new I-Ds. While I hope those could be consolidated >to the degree possible, I think the idea of getting these things >registered is just great. I sent John Levine the XML. There may be a few controversies down the road as the topic touches both RFC 5321 and 5322. >fields to try to "correct" them). The multiple-path FOR form is >still seen in the wild, despite the security issues and language >in 5321 deprecating it. If multiple paths or mailboxes are used >with FOR, the beginning of the [Additional-Registered-Clauses] >becomes ambiguous, at least in theory. That was issue #37. >I have no doubt that Ned, or anyone else even half as competent, >can sort this out and has implementations that do so. I believe >that any MUA that is really as robust as 5322 MUAs are supposed >to be (indeed required to be to deal with other common erroneous >practices) can get it right. But we see intermediate MTAs and >post-delivery filters trying to check these fields for bogus >information as part of spam assessments, and some of those are >not too bright. Yes. I tested the example in draft-kucherawy-received-state with some CPAN code and it did not cause any problems. I don't know the effects on legacy code. I vaguely recall coming across a parser bug a few years back when parsing a "Received:" header field inserted by a MTA implementation. Regards, -sm From Claudio.Allocchio@garr.it Thu Jan 19 02:21:41 2012 Return-Path: <Claudio.Allocchio@garr.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9972421F846A for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 02:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DEALS=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWBO7v1d+fwH for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 02:21:41 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 514C021F8469 for <apps-discuss@ietf.org>; Thu, 19 Jan 2012 02:21:35 -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.5/8.14.5) with ESMTP id q0JALVN0014638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 11:21:32 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q0JALVN0014638 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=F0KwaOzwcUMxTMMb5s2AIu9T0c3SojcBDMVq5WZOPdJcmhWCXRH8QQLkekL9HeisA GOT5ue0Ks0OnElyUSAECTcjE1EMmVH4Ie2KNE5xywpnYx+GI6CIxPsnex2nfw/d55Tm xvnKIvLtdTpMLLRf9Sm+HNWrvly2hnqbAlJ9bLI= Date: Thu, 19 Jan 2012 11:21:29 +0100 (CET) From: Claudio Allocchio <Claudio.Allocchio@garr.it> X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: apps-discuss@ietf.org, draft-ietf-sipclf-format.all@tools.ietf.org Message-ID: <alpine.OSX.2.02.1201161423200.36734@mac-allocchio3.garrtest.units.it> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [apps-discuss] AppsDir review of draft-ietf-sipclf-format-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 10:21:41 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-sipclf-format-05 Title: Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) Reviewer: Claudio Allocchio Review Date: 2012-01-18 IETF Last Call Date: unknown IESG Telechat Date: unknown NOTE: is there is an IESG telechat which I'm missing, just copy this messae to iesg ML! Summary: This draft is ready for publication as a Proposed Standard RFC; it just needs one consideration about a minor issue about an external reference, and fixing some Nits. Major Issues: NONE Minor Issues: just one ! * Section "3. Document Conventions" The authors have decided "For the sake of clarity and completeness" to quote a full section of RFC4475 into this document. However there were quite long discussions in the Apps Dir in other reviews if this quoting practice is appropriate or not, because it can lead to discrepacies, when the quoted document is updated or obsoleted, resuing in confusion for the readers who just trust the quoted text without checking the state of the referenced document. I would suggest, as in the other cases, NOT to quote the external text, but to use an explicit external reference only, urging the reader to check that "for the sake of clarity". Nits: * Section "Copyright Notice" change the year to 2012. * Section "3. Document Conventions" remember to change "formatting rules for Internet-Drafts" into "formatting rules for RFCs" when published. * Section "4. Format" I do understand that it probably does not fit into the I-D formatting line lenghts, but... maybe an attempt to add aside the SIP CLF record depicted in Figure 1 the grouping described as <IndexPointers> <MandatoryFields> <OptionalFields> in the figure 1 itself (on the left?) may help in reading the distinction, and maybe may even not require to repeat portions of the figure itself later in the I-D, like in figure 3, figure 4 and figure 5. It is really a nit and just a suggestion. Not really important. What I am suggesting: +----------------------------------+ /| | / | | P | | o | | I i | | n n | | d t | | e e | | x r | | s | | \ | | \| | +----------------------------------+ /| | / | | M | | a F | | n i | | d e | | a l | | t d | | o s | | r | | y \ | | \| | +----------------------------------+ /| | / | | O | | p F | | t i | | i e | | o l | | n d | | a s | | l | | \ | | \| | +----------------------------------+ * Section "5. Example SIP CLF Record" Remember to change "Due to internet-draft conventions" into "Due to RFC conventions" when published (and also "to format it for an RFC" later on...). * From the DataTracker ID Nits check tool (References Nits): == Unused Reference: 'RFC5612' is defined on line 984, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-sipclf-problem-statement (ref. 'I-D.ietf-sipclf-problem-statement') Comment: the document shepard is aware and has a solution for these nits. Just apply it. ------------------------------------------------------------------------------ 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 ned.freed@mrochek.com Thu Jan 19 04:04:04 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E007E21F8631 for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 04:04:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80M5SgS+Exj7 for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 04:04:03 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D930521F862A for <apps-discuss@ietf.org>; Thu, 19 Jan 2012 04:04:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAYHXJ6KVK000K5U@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 19 Jan 2012 04:03:58 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OAVYW3FP280137RD@mauve.mrochek.com>; Thu, 19 Jan 2012 04:03:54 -0800 (PST) Message-id: <01OAYHXGQ9VO0137RD@mauve.mrochek.com> Date: Thu, 19 Jan 2012 03:44:01 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Wed, 18 Jan 2012 17:35:17 -0500" <3EBF175E9FCAA85080916A79@[192.168.1.128]> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> To: John C Klensin <john-ietf@jck.com> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 12:04:05 -0000 > First, my concern was that loading too much disparate > information into "Received:", and especially intermixing > post-delivery MUA information with in transit MTA information > might not be a sufficiently good idea that we should do it > automatically and without thinking. I didn't say "don't do > it", especially wrt this specific proposal. I did suggest that > it was worth examining the question. John, while I agree that adding post-delivery information to Received: fields would be bad, I'm completely failing to see how the current proposal does anything of the sort. It's entirely about what sort of queue the message ends up in and all of the cases clearly correspond to states prior to final delivery. If you think a rule about not adding MUA stuff to Received: fields needs to be stated explicity, the place for that is either in RFC 5321bis or in some sort of clarifying document. It makes no sense for it to be part of the present proposal. > Second, please remember that, while RFC 5321 requires RFC > 5322-conforming date-time fields, the <daytime> production of > RFC 821 is a little different. The 821 syntax is not quite a > proper subset of the 5321/5322 syntax (e.g., seconds are > required in 821 and not in 5321/5322, 821 permitted two-digit > years, etc.). Both 821 and 5321 require that both FROM and BY > appear, but I've seen that rule broken innumerable times. 5321 > permits "TCP-info" to be supplied as a comment to BY (in > <Extended-domain>); 821 does not. I've also seen liberties > taken with the specific format of the <date-time> (or > <datetime>) fields, especially by systems on the other side of > gateways that, e.g., use ISO dates (both 821 and 5321 warn > against (5321 says "MUST NOT") later systems messing with those > fields to try to "correct" them). The multiple-path FOR form is > still seen in the wild, despite the security issues and language > in 5321 deprecating it. If multiple paths or mailboxes are used > with FOR, the beginning of the [Additional-Registered-Clauses] > becomes ambiguous, at least in theory. And once again I'm failing to see any relevance. Yes, parsing Recieved: fields in the wild has some complications - in fact one of the complictions is the use of nonstandard clauses, which like it or not are present in the wild. There's nothing we can do at this point to change any of this. But the present proposal is to add a clause with a single keyword arugment. I fail to see a parsing problem in that. > I have no doubt that Ned, or anyone else even half as competent, > can sort this out and has implementations that do so. I believe > that any MUA that is really as robust as 5322 MUAs are supposed > to be (indeed required to be to deal with other common erroneous > practices) can get it right. But we see intermediate MTAs and > post-delivery filters trying to check these fields for bogus > information as part of spam assessments, and some of those are > not too bright. And those implementations are already failing on real world messages. I'm not seeing how this is going to have significant added impact. > So what I was suggesting, and continue to suggest, is that it > may be time to think about whether it is better to keep adding > fields to "Received:" or whether one or more additional header > fields are in order. Clearly the disadvantage of additional > ones is that something that treats anything appearing between > the first and last "Received:" header fields other than more of > them as bogus would get into trouble. The advantage is that > something that wants to find one of these things for processing > purposes would know exactly where to look, rather than having to > parse "Received:" fields, looking for the relevant information, > and trusting that someone hasn't used the same > <Additional-Registered-Clauses> for something else (despite the > SHOULD NOT) in 5321 Section 4.4). Again, the problems with Received: field parsing pale in comparison with the problems associated with having multiple order-dependent interrelated trace fields. Agents that reorder multiple occurances of the same field are rare, agents that lose or are incapable of "seeing" the relative order of multiple fields, not so much. Sieve is actually an example of this. Sieve can perform tests on all occurances of a given field or it can be restricted to look at the first, second, Nth, N-1th, etc. occurance. So as long as you have some idea of how many Received: fields are added prior to delivery in a given environment (and you usually do), you can write tests that check the correct field or fields and don't get confused by stuff provided by stuff outside the administrative domain (which is inherently unreliable). But there's no way to test something like "the Foo: field that appears after the Nth Bar: field". And an extension that does that is going to be very, very ugly, no matter how you slice it. And that ugliness is going to make using such an extension quite problematic, even for fairly experienced script constructors. Again, we went through all of this stuff in tedious detail back when MIME header internationalization was being standardized. The encoded-word propsoal certainly has had issues (mostly poor quality implementation - for some reason people just don't seem to get that certain activities have to be performed in a specific order), but it was small beer compared to the problems we would have had with multiple interconnected fields. > If we concluded that additional header fields, with different > names, were appropriate, it might still be the case that the > current "received-state" proposal would belong within > "Received:". I'm just suggesting that we ask the question. And my answer, I'm afraid, is still a very emphatic NO. Ned From john-ietf@jck.com Thu Jan 19 08:51:03 2012 Return-Path: <john-ietf@jck.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D521F8642 for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 08:51:03 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe8WEC8m07j5 for <apps-discuss@ietfa.amsl.com>; Thu, 19 Jan 2012 08:51:02 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B385C21F8680 for <apps-discuss@ietf.org>; Thu, 19 Jan 2012 08:51:02 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Rnv93-000Arf-Ld; Thu, 19 Jan 2012 11:47:25 -0500 X-Vipre-Scanned: 0C010CFD002C310C010E4A-TDI Date: Thu, 19 Jan 2012 11:51:01 -0500 From: John C Klensin <john-ietf@jck.com> To: Ned Freed <ned.freed@mrochek.com> Message-ID: <4BDC24D0DFF60AFE8CA82F6B@[192.168.1.128]> In-Reply-To: <01OAYHXGQ9VO0137RD@mauve.mrochek.com> References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> <01OAYHXGQ9VO0137RD@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: apps-discuss@ietf.org Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 16:51:03 -0000 --On Thursday, January 19, 2012 03:44 -0800 Ned Freed <ned.freed@mrochek.com> wrote: >> First, my concern was that loading too much disparate >> information into "Received:", and especially intermixing >> post-delivery MUA information with in transit MTA information >> might not be a sufficiently good idea that we should do it >> automatically and without thinking. I didn't say "don't do >> it", especially wrt this specific proposal. I did suggest >> that it was worth examining the question. > > John, while I agree that adding post-delivery information to > Received: fields would be bad, I'm completely failing to see > how the current proposal does anything of the sort. It's > entirely about what sort of queue the message ends up in and > all of the cases clearly correspond to states prior to final > delivery. I thought I was clear in my initial note. If I wasn't, I apologize. Let me try to say it differently: It is reasonable to hypothesize that there is some information that people might want to capture between when the message leaves the Submission server and when it arrives on the user's screen-equivalent that should not be loaded onto Received fields. One can make the argument that some things should be in different header fields from "Received:" on the basis of parsing idiosyncrasies associated with the changing definition of "Received:" over the years (which I overstressed), concerns about arbitrarily-long header fields (as with parsing, more a concern for lower-quality implementations than high-quality ones), precedent, or aesthetics, but the hypothesis remains. My guess is that at least part of the dividing line will work out to be associated with states before or after final delivery, but that was an example, not a position. Perhaps, for example, some authentication information should be separated out as well. Perhaps not. I believe that we should take that issue up and start developing a theory and guidelines before adding more stuff to "Received:". I believe that any WG that is going to take up specifications that propose adding "Received:" clauses should be obligated to address this more philosophical boundary question about what belongs there and, as has been pointed out, the issue of an appropriate registry for such clauses. I've expressed absolutely no opinion about whether the data elements proposed in this particular specification belong in "Received:" or not. My guess is that they probably do. If that opinion is generally shared, I don't see any problem moving ahead with this specification _as long as a serious effort is underway in parallel to address the broader issue. > If you think a rule about not adding MUA stuff to Received: > fields needs to be stated explicity, the place for that is > either in RFC 5321bis or in some sort of clarifying document. > It makes no sense for it to be part of the present proposal. Never suggested it should be. All I've suggested is that, if AppsAWG is going to take up this sort of proposal, it should be prepared to take on that classification question --more broadly stated than "MUA stuff in 'Received:'" as well. I haven't even said "solve the general problem before addressing the specific proposal". >... > And once again I'm failing to see any relevance. Yes, parsing > Received: fields in the wild has some complications - in fact > one of the complictions is the use of nonstandard clauses, > which like it or not are present in the wild. There's nothing > we can do at this point to change any of this. But the present > proposal is to add a clause with a single keyword arugment. I > fail to see a parsing problem in that. See above. >> I have no doubt that Ned, or anyone else even half as >> competent, can sort this out and has implementations that do >> so. I believe that any MUA that is really as robust as 5322 >> MUAs are supposed to be (indeed required to be to deal with >> other common erroneous practices) can get it right. But we >> see intermediate MTAs and post-delivery filters trying to >> check these fields for bogus information as part of spam >> assessments, and some of those are not too bright. > > And those implementations are already failing on real world > messages. I'm not seeing how this is going to have significant > added impact. Again, with the understanding that what I'm saying is "please can we examine the tradeoffs" and not "don't do this", let me suggest where significant added impact might occur. Suppose I have a moderately fragile real world implementation that is not now failing because it was written on the assumption that "Received:" fields are used for debugging information and it doesn't actually have to parse them at all. If it does minimally parse them -- e.g., for loop detection purposes (which mostly requires only that it recognize "Received:" header fields that it might have added -- its belief in the "debugging" model is such that it can and does simply ignore any "Received:" header field that confuses it. Now we come along and put information in the "Received:" field to which it actually needs to pay attention. Its sloppy parsing and willingness to discard confusing ones keeps it from getting to that information. That actually does have significant added impact relative to having the information in a separate header field that can be analyzed without having to first parse "Received:" into its components. Of course, whether that "significant added impact" is worse (because the weak implementation can't find the information) or actually an improvement (because that implementation might be encouraged to clean up its act) is one of those tradeoffs I've been talking about. As you know from experience, I'm inclined to favor the "get them to clean up their act" plan for such situations. But I also recognize that it sometimes works poorly enough to believe there is a tradeoff that ought to be considered. But, again, "considered" and "tradeoffs" arsn't "I think there is anything wrong with this proposal". I just want to see us ask the question in a serious way. > Again, the problems with Received: field parsing pale in > comparison with the problems associated with having multiple > order-dependent interrelated trace fields. Agents that reorder > multiple occurances of the same field are rare, agents that > lose or are incapable of "seeing" the relative order of > multiple fields, not so much. >... Again, this (including the Sieve issue) is exactly the discussion of tradeoffs I was hoping to encourage. I'm not as convinced as you are that the issues were settled with MIME i18n and encoded words, but that is another matter. And it seems to me that the Sieve example argues against even using different header fields/names for post-final-delivery information, at least without a degree of hair-splitting about the definition of final delivery that we have so far managed to avoid. If the answer turns out to be "No, let's keep putting everything into 'Received:'", I have no problem with that. john From zordogh@rim.com Thu Jan 19 14:10:33 2012 Return-Path: <zordogh@rim.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1927321F86B1; Thu, 19 Jan 2012 14:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.887 X-Spam-Level: X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EliqQplfk4zW; Thu, 19 Jan 2012 14:10:31 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7227921F86DC; Thu, 19 Jan 2012 14:10:30 -0800 (PST) X-AuditID: 0a41282f-b7f9d6d000002fe5-57-4f1894cd07d8 Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 56.41.12261.DC4981F4; Thu, 19 Jan 2012 22:10:21 +0000 (GMT) Received: from XCT107CNC.rim.net (10.65.161.207) by XHT105CNC.rim.net (10.65.12.216) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 19 Jan 2012 17:10:21 -0500 Received: from XMB107ACNC.rim.net ([fe80::f1d2:c1d5:f469:3f83]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.01.0339.001; Thu, 19 Jan 2012 17:10:20 -0500 From: Zoltan Ordogh <zordogh@rim.com> To: John C Klensin <john-ietf@jck.com>, Alessandro Vesely <vesely@tana.it> Thread-Topic: [apps-discuss] Spam reporting over IMAP Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+ADJcaFQADFelgAACKZQAAC4je8QAD4ANWA= Date: Thu, 19 Jan 2012 22:10:19 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsXC5chzQ/fsFAl/gy03ZCxWv1zBZvFs43wW i9ZLf9gsJt79yeLA4rFkyU8mj8srXzN7nNjFG8Ac1cBok5iXl1+SWJKqkJJanGyr5JOanpij EFCUWZaYXKngklmcnJOYmZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy 8xRS85LzUzLz0m2VPIP9dS0sTC11DZXsdJFAwj/ujIP/epgLPidUTFvxhbGB8aBvFyMnh4SA icTJi4+YIWwxiQv31rN1MXJxCAn0MknsOXKaFcJZzihx7uRxRghnG6NE17Y77F2MHBxsAqoS c67GgnSLCHhJTLt7lQ3EZhbwlFh3/yITiC0MtGH+nSfsEDWmEktnXoCy/STWzDsOZrMAjdm0 /jkriM0L1Lv+5j0WEJtRQFZi99nrTBAzxSVuPZnPBHGpgMSSPeehrhaVePn4HyuErSjxpHEz C0S9nsSNqVOg7tGWWLbwNTPEfEGJkzOfgNUICchIPJ9yiX0Co9gsJCtmIWmfhaR9FpL2BYws qxgFczOKDcwMkvOS9Yoyc/XyUks2MYKTiIb+Dsa+vVqHGAU4GJV4eEP7JfyFWBPLiitzDzFK cDArifA29AGFeFMSK6tSi/Lji0pzUosPMVoAQ2IisxR3cj4wweWVxBsbGKBwlMR5NdXv+QkJ pANTUnZqakFqEUwrEwenVAPjhQfsn9P+zWa7NS0s6/SziA+a9YVueyfJC2UXcL+1Fl0RoXpq nS1Xs8OTSd/zZhXOY3Y4VL16cuXX0t0vPrE/FJ1sdmBm7/vDQiZf3t/nrJip5fX6qvO87vkd jzIyjSc8W1owfWNucAoTt7Uzk3fDjy8H9R+VfBBYzeektlqkZjvTXr0plaY8SizFGYmGWsxF xYkAW7VcJTsDAAA= Cc: ietf <ietf@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: [apps-discuss] FW: Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 22:10:33 -0000 Hi all, I would like to address the issues that involve SM, Alessandro and John firs= t. I understand the confusion has risen because my name is listed as an author= on draft-ordogh-spam-reporting-using-imap-kleansed-00. I would like to make it clear that while draft-ordogh-spam-reporting-using-i= map-kleansed-00 bears my name and I am listed as the author of this, I was n= ot involved - nor consulted - on its development. I am of course happy to wo= rk with anyone who wishes to progress either draft as long as the work gets= done in IETF. As I said before, if there is no interest to keep the work in= IETF, while not desirable, it is perfectly fine; the work will happen in OM= A EVVM. I noticed that a declaration has been made on draft-ordogh-spam-reporting-us= ing-imap-kleansed-00. This simple fact should answer SM's question. Alessandro said he emailed Sarah and got no response. I asked Sarah and she= told me she have not received any emails from Alessandro. The only thing I= can add here is that RIM has very strict spam filters in place. The sender= or the recipient will not know what happened to an email. If you do not get= a response within a reasonable timeframe, please email the person again (wi= th a different subject and body, to ensure that there's absolutely nothing i= n the mail that might trigger a spam filter). BTW, since I am bound by RIM's= policies as Sarah, this holds true for my emails as well. Speaking of IT policies. Regarding John's concern about the disclaimer in the email message. It is an= IT policy in RIM, there is nothing I can do about it as it is beyond my con= trol. Since the emails are sent to a public mailing list, all information in= the email can be considered public - in which case I believe that disclaime= r does not apply. If I accidently put some information into that email that= was not meant to be public, I will have to follow up on it and you will kno= w. Next, I try to do my best to address John's other comments below (2 through= 4). > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: January 14, 2012 12:40 PM > To: Alessandro Vesely; Zoltan Ordogh > Cc: ietf; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Spam reporting over IMAP > > > > --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely <vesely@tana= .it> wrote: > > >... > >> A bit later, a liaison statement was sent from OMA to IETF, seeking > >> collaboration and a "home" for the draft; as required by RFC3975. > > > > I assume you're still talking about SREP. I read a reply by John > > Klensin, whom I consider a sort of IETF guru, and it didn't prospect > > a bright future for the draft. I posted a "kleansed" version trying > > to address some of those concerns, in an attempt to improve the > > chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed > > the IPR qualification of the document too. In fact, I had the > > impression that the IPR was that way because OMA SpamRep was being > > mentioned, albeit not being specified, and also because that was one > > of the points raised. > > > I hope my editing was correct, but your approval as author is needed. > >... > > Alessandro, Zoltan, > > Guru or not (some would certainly dispute that), this is strictly a > personal comment and personal opinion. Just to clarify my view of this (o= ther may have different opinions)... > > (1) I think SM's question, and anything else having to do with the IRP > status of this document (or pair of documents) has to be > completely clear. The IETF could certainly decide to process > the document even if the technology were encumbered (has happened many > times before), but uncertainty is pretty much a showstopper. > Alessandro's concerns about distribution disclaimers on email messages tha= t discuss the topic only reinforce my concern in this area. > [Z=D6r] I addressed this above. > (2) Similarly, both of you, and RIM and OMA, need to understand that > handing something like this off to IETF, especially for > standards-track processing, is a handoff of change control. The IETF > can modify (we hope improve) things as it likes, even after approval > of the first version of the document as a Proposed Standard. Joint owners= hip/ change control arrangements are possible, but they are very hard and ti= me-consuming to negotiate and perhaps, due to some bad experience, likely to= get harder. > [Z=D6r] I think I understand your concern. The draft contains one possible s= olution - one that fulfills the requirements set and was 'good enough' for O= MA. It is not a draft from OMA. It is an individual contribution; OMA merely= endorses it because it fulfills the requirement they need. I am fairly conf= ident that if IETF can find a more efficient solution than the one in my dra= ft, one that fulfills the requirement OMA needs, then OMA will be more than= happy to discard my draft - even as a whole if need be - and go with the mo= re efficient solution instead. The only concern I would expect OMA to raise= in this case is the schedule (the availability of a fairly stable draft). I= said already that I am happy to work with either document. I can also say t= hat while I would not be particularly happy about discarding my draft consid= ering the amount of time I invested in writing it and doing the legwork in O= MA, I would not make a big deal out of discarding it in favor of a more effi= cient solution that achieves the objectives set. These statements, as a whole, should re-assure that it is not a simple hando= ff of change control. Rather, an initial draft (including its imperfections)= to kick off the work in IETF - a work entirely owned by IETF, as laid out i= n RFC3975. It is unfortunate that there was no response to the liaison state= ment sent from OMA to IETF; these things could have been clarified long ago. > (3) The leadership of AppAWG, and the ADs, will do as they think > appropriate, but, if I were making the rules, no one would spend > energy trying to sort out the differences between a pair of competing > documents. I suggest that the two of you get together, offlist, and > see if you can reach clear agreement on a single draft that supercedes > both documents. That is a matter of courtesy to those of us you are askin= g to consider the work and is quite independent of the IPR concerns (althoug= h they do interact). [Z=D6r] I am not asking anyone to discuss the merits of either draft; in fac= t, I left out all technical discussions - on purpose. What I would like to f= igure whether IETF is interested on working on this topic - which is the sam= e thing that was asked in the liaison statement. I mean, I can work offline= with Alessandro and come up with a nice, consolidated draft - but that woul= d not solve anything because in the end, we would have to ask the same quest= ions afterwards; a draft supported by only two participants won't make it in= to a standards-track RFC. Ergo, more support to work on this topic (not a sp= ecific draft) would be needed. And, this is exactly what I am trying to figu= re out. > > All three of those issues are administrative, not technical. > They should be easily solved. My personal preferences is that the > AppsAWG, and the apps-discuss list, spend no more time on this until/unles= s they are resolved. YMMD, of course. [Z=D6r] From my perspective, these administrative issues have been addressed= . > > (4) The core of my previous comments was a technical concern, not an > administrative one. [Z=D6r] Again, I would like to leave technical discussions out, for now at l= east, especially because the draft in question may change substantially (may= be even thrown out) once the work starts. > Even if one ignores the security concerns, the > stability issues for normative references, and so on, many of us believe t= hat the IMAP protocol has become far too complicated, with too many options= and features. > That complexity increases the requirements on IMAP servers that wish > to support a wide range of clients and applications and on clients that wi= sh to support a reasonable range of features but > work with servers that may not support all of them. Whatever > the advantages, too much code and too many code paths are not > conducive to very high quality, bug- free, implementations. > [Z=D6r] That is my understanding as well. After Lemonade concluded its work,= there were rumors about IMAP5 - which, I understand, would have removed the= unused things from the specifications, consolidated must-haves into the bas= e spec, and tidied up the loose ends a bit. Unfortunately it did not happen,= so we have to work with what we have - and however undesirable the situatio= n is. Sooner or later, IETF will have to face this problem and deal with thi= s issue, irrespective of any newly proposed extensions. If you ask me, the s= ooner it happens, the better. The problem has been identified already, which= is always a good sign because it indicates that people know exactly what ne= eds to be done. The only thing I am unsure of is: "What's keeping IETF from= taking an action?". Standards evolve and soon, it will have been 10 years s= ince IMAP4 was released. But, I believe that this discussion is more or less= irrelevant to the original topic in question; this is not why I am knocking= on the IETF door. OMA has decided to use IMAP4 already. > This proposal seems to me to take IMAP into a whole new area. > I'm not questions whether or not that is possible because I'd be > certain it would be, even without the assertiosn that there are > implementations out there. I am questioning whether there is a strong > enough case to be made that this belongs in IMAP to justify further > clutter in the protocol and even lower odds of seeing high-quality > clients. I observe that probably the best general-purpose --as > distinct from, e.g., specialized for mobile > devices-- IMAP client out there is now quite old, largely > unmaintained, and has not picked up on any of the new features > added in the last several years. Neither version of the > document really addresses that issue. Some of the comments from the > two of you about why it is hard and/or expensive to do it in other > ways certainly have merit, but need, IMO, to be balanced off against other= considerations including the above. > That balance won't be easy to find especially since, as I am sure you > both know, there is no community agreement about the degree to which > it is appropriate to make normal, desired, email work worse in order > to provide better facilities for spam-handling, especially spam-handling a= t or after the final delivery MTA. [Z=D6r] I cannot possibly comment on what gets picked up, what does not get= picked up (or why) in individual client or server implementations, or, in v= arious services. All I can say is that there is a hole, OMA is trying to fil= l it in and one possible solution has been created - and now I am trying to= find out whether there's interest in working on this topic. > > Bottom line: I think we should see a single draft that really > addresses all of the technical issues, including the design tradeoffs > and security topics, _and_ addresses the IPR/administrative one in a way w= ith which we can all be comfortable before being asked to decide whether App= sAWG should > take this up. If asked to make a decision without such a draft > having been posted, I would vote "no". > > john [Z=D6r] There is nothing I can add here that I have not said already. I have= received a good deal of comments offline. I plan on addressing those, uploa= ding a revision, checking in with Alessandro and addressing the rest of the= comments later either as a new draft of an update. Comments, new draft, comments, new drafts. Isn't it already a "work being do= ne" in IETF driven by interest of individuals? Feels like normal IETF proced= ure to me. Just a thought. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From sm@resistor.net Thu Jan 19 15:11:41 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D221F84CE; Thu, 19 Jan 2012 15:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJD5Jc+ozvPD; Thu, 19 Jan 2012 15:11:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBA21F84C3; Thu, 19 Jan 2012 15:11:40 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0JNBWIM021712; Thu, 19 Jan 2012 15:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327014698; i=@resistor.net; bh=8DjRiTad4JD6AIlDKjy0AKp8mU7iPAjzBPXmUx+SV9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vhj7BdHi4ykbGkR65fyVMGCywUaUCK0a4uk4R3rJbI7U5MF7YtiP4V8yhQZzc120j 84sDmRpWyGACTy5eCuFrJ/By0wRl2pzcbbLHrrQ5ODqCwAEArg3SoBkciBMkS8Tidg Y2eGYlkedWqRR/zDgMROSTEhlBE1/xDUSqPo+MFQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327014698; i=@resistor.net; bh=8DjRiTad4JD6AIlDKjy0AKp8mU7iPAjzBPXmUx+SV9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gaBM5MGKdLOfy/lUTLD0veskfark3jKbh/dzoQcU+YFnPcOsYSdy3XlFz4MsybRbi XqH5X1s3rpcUGlVChO3XysUVxJEIZ9mY6TF8Ycw9pip2QEnR+KVfEHtVynNqMbvS8N 36LarFJTmEc0LwBu+Bt++SJOExNTmgM3CvyUBUFI= Message-Id: <6.2.5.6.2.20120119144439.0634f518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jan 2012 15:11:02 -0800 To: Zoltan Ordogh <zordogh@rim.com> From: SM <sm@resistor.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.ne t> References: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf <ietf@ietf.org>, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 23:11:41 -0000 Hi Zoltan, At 14:10 19-01-2012, Zoltan Ordogh wrote: >I understand the confusion has risen because my name is listed as an >author on draft-ordogh-spam-reporting-using-imap-kleansed-00. >I would like to make it clear that while >draft-ordogh-spam-reporting-using-imap-kleansed-00 bears my name and >I am listed as the author of this, I was not involved - nor >consulted - on its development. I am of course happy to work with >anyone who wishes to progress either draft as long as the work gets >done in IETF. As I said before, if there Thanks for the explanation. >I noticed that a declaration has been made on >draft-ordogh-spam-reporting-using-imap-kleansed-00. This simple fact >should answer SM's question. I would like to thank you and Research In Motion Limited for resolving the issue. Regards, -sm From internet-drafts@ietf.org Fri Jan 20 01:21:37 2012 Return-Path: <internet-drafts@ietf.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A8821F84D4; Fri, 20 Jan 2012 01:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6yynJEfKhOU; Fri, 20 Jan 2012 01:21:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4121F84CE; Fri, 20 Jan 2012 01:21:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120120092132.6095.6602.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 01:21:32 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 09:21:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Best Current Practices for Email Greylisting Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-greylisting-01.txt Pages : 10 Date : 2012-01-20 This memo describes best current practices for the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-01.txt From vesely@tana.it Fri Jan 20 07:03:46 2012 Return-Path: <vesely@tana.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A189121F8575; Fri, 20 Jan 2012 07:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQPRJ9OLN4nF; Fri, 20 Jan 2012 07:03:46 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C382321F856C; Fri, 20 Jan 2012 07:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327071823; bh=dEQxPmhhpUe5MrZuNuDj6ei7zuuGpSn+ot/NnSh5ZXg=; l=844; h=Message-ID:Date:From:MIME-Version:To:CC: Content-Transfer-Encoding; b=KjmdKb6JjmJl1eQTgqYmMnyB1r62hRpf6l6hIi6cq93SX0SRKBS15w+09t5EnXUJZ 7lGWTOktgFsRk0PbQhpBAJv0ppNBe8zzx9hfqTUIk2Ut40Zbm9sS/bv6xbu/+j4Op0 eshtvftNFuOhqacqBa5E5EX8Xj+DJXT+78TrKkXY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Jan 2012 16:03:43 +0100 id 00000000005DC039.000000004F19824F.0000033C Message-ID: <4F19824E.9020101@tana.it> Date: Fri, 20 Jan 2012 16:03:42 +0100 From: Alessandro Vesely <vesely@tana.it> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf-action@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: apps discuss <apps-discuss@ietf.org>, ietf <ietf@ietf.org> Subject: [apps-discuss] Please remove draft-ordogh-spam-reporting-using-imap-kleansed from I-D repository X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 15:03:46 -0000 Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears "wrong" copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely From vesely@tana.it Fri Jan 20 09:39:15 2012 Return-Path: <vesely@tana.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703121F852D for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 09:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzY1eMyRYIZ7 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 09:39:14 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 018A621F8523 for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 09:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327081152; bh=X3bYKVBVlcSRXPgjeFvPMVZYL0S5+C+QHBCjNojb8NY=; l=2842; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WHc0gQhsMP65LuBz5ShykNtJBBs2OTS/JzASgUhi8NOdw8wfz3arPcrsoOOUghgGH yu3IokEnLZediBwyPwQsIsCwkX35sQ/c6OY7o5PZLeo8RqUMC2LMqlOfJXdDUo7jyZ ghxXjjpoxbAN/DW4YCk7h9V3faUVRqDWUjM+Q7Y8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Jan 2012 18:39:12 +0100 id 00000000005DC048.000000004F19A6C0.00002B73 Message-ID: <4F19A6C0.4040602@tana.it> Date: Fri, 20 Jan 2012 18:39:12 +0100 From: Alessandro Vesely <vesely@tana.it> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> <01OAYHXGQ9VO0137RD@mauve.mrochek.com> In-Reply-To: <01OAYHXGQ9VO0137RD@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Stanzas of trace fields, was Adoption of draft-kucherawy-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 17:39:15 -0000 (Subject changed according to topics separation) On 19/Jan/12 12:44, Ned Freed wrote: > Sieve is actually an example of this. Sieve can perform tests on > all occurances of a given field or it can be restricted to look at > the first, second, Nth, N-1th, etc. occurance. So as long as you > have some idea of how many Received: fields are added prior to > delivery in a given environment (and you usually do), you can write > tests that check the correct field or fields and don't get confused > by stuff provided by stuff outside the administrative domain (which > is inherently unreliable). > > But there's no way to test something like "the Foo: field that > appears after the Nth Bar: field". And an extension that does that > is going to be very, very ugly, no matter how you slice it. And > that ugliness is going to make using such an extension quite > problematic, even for fairly experienced script constructors. Good point. However, we already have that situation: see e.g. http://www.rfc-editor.org/errata_search.php?rfc=5451&eid=2818 (Hey, I did get Murray's approval before posting that :-) Perhaps, "the Foo: field of the Nth trace stanza" is easier. We should just convene that "Received:" fields delimit trace stanzas. Of course, all the RFCs that mention "trace header fields" say that these go at the top of the header. Some of them explicitly mention "Received:" (quotes below), but also RFC 5322 and RFC 5518 obviously imply such positioning if we assume that "Received:" is always present. Thus, it seems feasible to introduce this concept, in one of the trace- I-Ds, perhaps? Quotes (emphasis added): RFC 4408: The Received-SPF header field is a trace field (see [RFC2822] Section 3.6.7) and SHOULD be prepended to the existing header, above the *Received*: field that is generated by the SMTP receiver. RFC 5436: If the implementation retains the "Received" fields from the triggering message (see above), the "Auto- Submitted" field MUST be placed above those "*Received*" fields, serving as a boundary between the ones from the triggering message and those that will be part of the notification message. RFC 5451: On the presumption that internal MTAs are fully compliant with Section 3.6 of [MAIL], and the compliant internal MTAs are using their own host names or the ADMD's DNS domain name as the "authserv-id" token, the header field proposed here should always appear above a *Received*: header added by a trusted MTA. RFC 6376: INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this is to insert the DKIM-Signature header field at the beginning of the header block. In particular, it may be placed before any existing *Received* header fields. This is consistent with treating DKIM-Signature as a trace header field. From Jeff.Hodges@KingsMountain.com Fri Jan 20 10:41:57 2012 Return-Path: <Jeff.Hodges@KingsMountain.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3B21F8514 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 10:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IemGOo8ILENk for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 10:41:56 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 6E1A321F84EE for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 10:41:56 -0800 (PST) Received: (qmail 23553 invoked by uid 0); 20 Jan 2012 18:35:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Jan 2012 18:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=mUy2U1BpfNYMDd5EKhchuMU7oiyAGNCTZ2DMQcshBKg=; b=KTPCG/+XPr3LmN6yrlI5X/qLJkbTFTEZec8zcYn0YZh/PunejMofSBUHZfSVD8NCtD5t5ndJbD7NALn4pwOS7y2tLeTydDxEoafdXy4BPXt+BkBC7NQnHTEei4Vie2JL; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.101]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RoJIu-0000BZ-TG; Fri, 20 Jan 2012 11:35:12 -0700 Message-ID: <4F19B3DF.5050402@KingsMountain.com> Date: Fri, 20 Jan 2012 10:35:11 -0800 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Apps Discuss <apps-discuss@ietf.org>, IETF WebSec WG <websec@ietf.org>, RAI Discuss <rai-discuss@ietf.org>, Internet Area Discuss <int-area@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [apps-discuss] TheRightKey@ietf.org -- next gen broad user-facing internet trust infrastructure discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 18:41:57 -0000 this list, TheRightKey@ietf.org -- where next gen broad user-facing internet trust infrastructure is being discussed, was originally advertised to SAAG, PKIX, TLS, and DANE. Sending to these lists in case any potentially interested parties missed it. HTH, =JeffH ------- Forwarded Message Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat <ietf-secretariat@ietf.org> To: IETF Announcement list <ietf-announce@ietf.org> CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. ------- End of Forwarded Message From paulej@packetizer.com Fri Jan 20 10:55:28 2012 Return-Path: <paulej@packetizer.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2D21F8650 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 10:55:28 -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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCugV2y4npd3 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 10:55:28 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DABBA21F8646 for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 10:55:27 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q0KItPBr004448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jan 2012 13:55:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1327085725; bh=m/IgvSnZGrwJSo/8mOYfr5ZHH5Ke/hYli0c92Dhu5so=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sYi3fki+VYbnyqeoXqnyPidpmxVdU3arTgUVigdXor2mnEjkrLJ/He3GE3If1QnlI nKHLEoslJelVbE07bXzO4Oe3iAJuGSnJRSeCXra3NB+DRP6JkmffVJxHYR0QibrRkV NlIEX/Mp7OoUVX+JICVJg3gVAcrXvwIYgyED1XBo= From: "Paul E. Jones" <paulej@packetizer.com> To: <msk@cloudmark.com> References: <20120120092132.6095.6602.idtracker@ietfa.amsl.com> In-Reply-To: <20120120092132.6095.6602.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 13:55:04 -0500 Message-ID: <02e501ccd7a5$05a0c620$10e25260$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGBk2W8BNUlxQseu0YFp/ty1I18TpasEHSA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 18:55:29 -0000 Mark, I did seen this previously, but it is interesting to see it appear nonetheless. I am one of those who implement greylisting. I have experienced the negative aspects you describe in the document. Perhaps the most frustrating is that I have found two service providers that do not properly deal with greylisting, or perhaps I don't deal with them properly. These service providers apparently have a fairly large array of mail servers and they appear to select an IP address randomly when they re-try. On my server, that just imposes more delay. In some cases, messages do not get through until I whitelist their server address ranges. Quickly grabbing some statistic on my server for this week, the different approaches have blocked the following percentages of mail: Greylisting 16% SPF 38% Spamhaus 40% RDNS 4% Own RBL 2% These numbers are not exact. I would estimate a margin of error of not more than 1% on greylisting, SPF, and Spamhaus. Our own RBL blocks very little right now, as I changed the algorithm to be a bit more forgiving. It now only blocks those who tend to be serious "repeat offenders". I suspect if I turn off greylisting, Spamhaus and SPF will likely catch the bulk of the spam blocked by greylisting. What these two services do is catch senders who are "out of policy" and who are known spammers. I hate being forced to blacklist domains, IP addresses, etc., but it is extremely effective and has proven to be necessary. I think it's useful to document greylisting for information purposes, but do we want to make it a BCP? The reason I ask is that longer-term, I would think we'd want to recommend policy-oriented solutions (e.g., SPF or DKIM). If policies were strictly enforced and properly implemented, machines controlled by bots would not get past the policy enforcement. I also question whether greylisting would be effective long-term. I actually have seen some machines re-send email. You are right that many just "fire and forget", but that would change if required. So, elevating greylisting to BCP might just force a change in spammer tactics, thus rendering greylisting completely ineffective. The reason I am supportive of documenting as informational is that servers should consider such implementations and that it has utility today. But, calling it a "best" practice seems to be a bit much. It's a practice driven out of necessity, mainly because we do not have all of the kinks worked out of policy-based solutions. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, January 20, 2012 4:22 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting- > 01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. > > Title : Best Current Practices for Email Greylisting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-greylisting-01.txt > Pages : 10 > Date : 2012-01-20 > > This memo describes best current practices for the art of email > greylisting, the practice of providing temporarily degraded service > to unknown email clients as an anti-abuse mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting- > 01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-01.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Fri Jan 20 11:16:08 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A643321F869E for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 11:16:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTudqqxIud51 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 11:16:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63E21F869C for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 11:16:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 11:16:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 20 Jan 2012 11:16:07 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "Paul E. Jones" <paulej@packetizer.com> Date: Fri, 20 Jan 2012 11:16:06 -0800 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt Thread-Index: AQGBk2W8BNUlxQseu0YFp/ty1I18TpasEHSAgAAVtrA= Message-ID: <F5833273385BB34F99288B3648C4F06F19C89DFAA9@EXCH-C2.corp.cloudmark.com> References: <20120120092132.6095.6602.idtracker@ietfa.amsl.com> <02e501ccd7a5$05a0c620$10e25260$@packetizer.com> In-Reply-To: <02e501ccd7a5$05a0c620$10e25260$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 20 Jan 2012 19:16:08 -0000 Hi Paul, > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Friday, January 20, 2012 10:55 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: RE: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01= .txt >=20 > Mark, Who? ;-) > I think it's useful to document greylisting for information purposes, > but do we want to make it a BCP? The reason I ask is that longer-term, > I would think we'd want to recommend policy-oriented solutions (e.g., SPF= or DKIM). > If policies were strictly enforced and properly implemented, machines > controlled by bots would not get past the policy enforcement. >=20 > I also question whether greylisting would be effective long-term. I > actually have seen some machines re-send email. You are right that > many just "fire and forget", but that would change if required. So, > elevating greylisting to BCP might just force a change in spammer > tactics, thus rendering greylisting completely ineffective. >=20 > The reason I am supportive of documenting as informational is that > servers should consider such implementations and that it has utility > today. But, calling it a "best" practice seems to be a bit much. It's > a practice driven out of necessity, mainly because we do not have all > of the kinks worked out of policy-based solutions. The original (and current) plan is to include some consensus recommended pr= actices in terms of greylisting. If the Working Group decides it wants to = stop short of making any recommendations, then changing to Informational is= entirely appropriate. I don't have a particular preference. The -01 version of this draft fills out the definitions of each kind of gre= ylisting we know of and presents some background (thanks to John Levine for= the text there), but I didn't fill out the recommendations section because= we haven't talked about what we would like to say in there yet. There is a small team of people within MAAWG that want to make some recomme= ndations about greylisting, so the output of that work might be useful here= . They meet in about a month, so I'll report back after that, and we can f= igure out what to do next. -MSK From sm@elandsys.com Fri Jan 20 16:00:55 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2AA21F86DA for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 16:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWf2oXcaGV7v for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 16:00:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E592821F869D for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 16:00:52 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.235.213]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0L00aoT004034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 16:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327104048; i=@elandsys.com; bh=XvdvCm/r8Yfd9vSb9iIWmcZ76xK/+CoiSPv15gVSebg=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=Zzlk+BzmKKBXOWFjf6M7v5llYheblilPIMx9Tc9H+2Y7PHuQNVa0pw2JaJTiZwMx/ E/7Y73PzTsUdrQVCFABLB9JtOGlDzfd5O9u2W7qzwspGcvkQqk45ovxTs0WqDPaeZo ObVaBpXP2ddX35uNuUTIuJz4TexzOzGX6xtqS05c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327104048; i=@elandsys.com; bh=XvdvCm/r8Yfd9vSb9iIWmcZ76xK/+CoiSPv15gVSebg=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=vh6w11YE0JymCTuSBgHb/XmjAwLYsUgUmCx9vkp+Je5d5J1lhEUCtSuaVUaf3pHWW owEcweW1ITcWLB16zUErvNocN+W84W/fGPPyfHEaxAE5NixXM1xTvqYf71pqZh919H ekGZ4U36/8lQ7SacSUMlodzVO6SICaGmk/qDOcAQ= Message-Id: <6.2.5.6.2.20120120145614.09414138@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Jan 2012 15:40:34 -0800 To: apps-discuss@ietf.org From: S Moonesamy <sm+ietf@elandsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Feedback on draft-moonesamy-rfc2919bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 00:00:55 -0000 Hello, I moved the List-Sequence header field from 2369bis to draft-moonesamy-rfc2919bis-02 after discussing about the drafts with Grant Neufeld. I'll submit the revision in a few days. Murray S. Kucherawy [1] [2] commented on the purpose of Appendix A.1. I will be making the following change: A popular feature of some MLMs is the "tagging" of the Subject header field by prefixing the header field's contents with the name of the mailing list, e.g. "[example]" for a list called "example". The difference between a List Identifier and a subject tag is that while a List Identifier is unique, a subject tag is usually the short form of a mailing list's name. Such a namespace is inherently flat, unmanaged and thus non-unique. I removed the text in Section 6 about case-insensitive string comparison. Murray also commented on the switch from "localhost" to "invalid" and I responded to the comment [3]. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04039.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04049.html 3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04040.html From johnl@iecc.com Fri Jan 20 20:45:02 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FB821F8700 for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 20:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.338 X-Spam-Level: X-Spam-Status: No, score=-108.338 tagged_above=-999 required=5 tests=[AWL=2.861, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERSM8OWTFama for <apps-discuss@ietfa.amsl.com>; Fri, 20 Jan 2012 20:45:02 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9920221F8552 for <apps-discuss@ietf.org>; Fri, 20 Jan 2012 20:45:01 -0800 (PST) Received: (qmail 62482 invoked from network); 21 Jan 2012 04:44:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jan 2012 04:44:59 -0000 Date: 21 Jan 2012 04:44:37 -0000 Message-ID: <20120121044437.94978.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C89DFAA9@EXCH-C2.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 04:45:02 -0000 Based on my experience, here's some advice for how to make greylisting work. My goal is to use it to recognize broken mail clients that don't retry. Once a client has shown that it knows how to retry, there is no further benefit from greylisting it. (It may be sending spam, but you'll have to recognize it other ways.) * Greylist on the triple [IP, MAIL FROM, RCPT TO]. After a successful retry, whitelist all further mail from the IP. I don't feel strongly whether you should put just one RCPT TO in the triple or wait for DATA and put all of them. * The greylister should have a time window within which retries will be accepted. On mine, the minimum is one minute, the maximum is 24 hours. I think those are reasonable. You want a minimum because some spamware retries immediately, you want a maximum both to keep the retry table from filling up with junk and so two spams sent a week apart aren't interpreted as a retry. Some people set their minimum much longer, several hours, but I don't see any benefit to that unless you believe in the blacklist theory. * Whitelist entries should time out eventually. I delete them when there's been no mail from the IP for a week. * If you have multiple incoming servers at the same MX distance, they should share a single greylist database. This handles the case where the retry goes to a different server, and lets all the servers share the IP whitelist. I do this by making the greylister a standalone daemon, and use a very simple UDP protocol to query it. If you're Google or Yahoo and have multiple server pools all over the world, I suppose a database per pool would do. * Since some senders have multiple outgoing servers, allow approximate matches on the retry IP. I take anything in the same /24 which seems to work OK. I only whitelist the IP that retries, but I should probably whitelist both. * The greylister MUST have a manual whitelist. Some legit senders just don't work with greylisting for a variety of reasons, most of which are not in conflict with RFC 5321. R's, John From salvatore.loreto@ericsson.com Sat Jan 21 10:11:57 2012 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288FF21F8467; Sat, 21 Jan 2012 10:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.498 X-Spam-Level: X-Spam-Status: No, score=-108.498 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXEaRfbWjO7R; Sat, 21 Jan 2012 10:11:56 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE08821F8468; Sat, 21 Jan 2012 10:11:53 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-ab-4f1affe727e3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.09.23425.7EFFA1F4; Sat, 21 Jan 2012 19:11:52 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Sat, 21 Jan 2012 19:11:51 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 49C832321; Sat, 21 Jan 2012 20:11:51 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 012E651D9A; Sat, 21 Jan 2012 20:11:51 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4E22B50C2B; Sat, 21 Jan 2012 20:11:50 +0200 (EET) Message-ID: <4F1AFFE5.7000901@ericsson.com> Date: Sat, 21 Jan 2012 19:11:49 +0100 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-avtcore-srtp-vbr-audio-04.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------070006020505050405090406" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: The IESG <iesg@ietf.org> Subject: [apps-discuss] Apps Dir review for: draft-ietf-avtcore-srtp-vbr-audio-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 18:11:57 -0000 --------------070006020505050405090406 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-avtcore-srtp-vbr-audio-04 Title: Guidelines for the use of Variable Bit Rate Audio with Secure RTP Reviewer: Salvatore Loreto Review Date: 2012-01-21 IESG Telechat Date: Summary: I have read and reviewed this draft. The draft is really clear on describing the issues and the proposed solution. So in my opinion is ready, from an application point of view, to be published as Proposed Standard as proposed in the avtcore mailing list discussion. best regards Salvatore Loreto -- Salvatore Loreto www.sloreto.com --------------070006020505050405090406 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> <br> I have been selected as the Applications Area Directorate reviewer for this draft<br> (for background on appsdir, please see <a class="ext-link" href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate"><span class="icon"> </span>http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate</a>). <br> </p> <p> Please resolve these comments along with any other Last Call comments you may receive. <br> Please wait for direction from your document shepherd or AD before posting a new version of the draft.<br> </p> <p> <br> Document: draft-ietf-avtcore-srtp-vbr-audio-04<br> </p> <p> Title: Guidelines for the use of Variable Bit Rate Audio with Secure RTP<br> Reviewer: Salvatore Loreto<br> Review Date: 2012-01-21<br> IESG Telechat Date: <br> </p> <p><br> Summary: <br> I have read and reviewed this draft.<br> The draft is really clear on describing the issues and the proposed solution.<br> So in my opinion is ready, from an application point of view, to be published as Proposed Standard<br> as proposed in the avtcore mailing list discussion.<br> </p> <p><br> </p> best regards<br> Salvatore Loreto<br> <pre class="moz-signature" cols="72">-- Salvatore Loreto <a class="moz-txt-link-abbreviated" href="http://www.sloreto.com">www.sloreto.com</a></pre> </body> </html> --------------070006020505050405090406-- From salvatore.loreto@ericsson.com Sat Jan 21 10:15:19 2012 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C51E21F846E; Sat, 21 Jan 2012 10:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.648 X-Spam-Level: X-Spam-Status: No, score=-108.648 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGqG7dXezbzu; Sat, 21 Jan 2012 10:15:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BE1DE21F846C; Sat, 21 Jan 2012 10:15:17 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-33-4f1b00b45c8c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FF.59.23425.4B00B1F4; Sat, 21 Jan 2012 19:15:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Sat, 21 Jan 2012 19:15:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6BCC22321; Sat, 21 Jan 2012 20:15:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 188DD51D9A; Sat, 21 Jan 2012 20:15:16 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6BA7450C2B; Sat, 21 Jan 2012 20:15:15 +0200 (EET) Message-ID: <4F1B00B3.9040908@ericsson.com> Date: Sat, 21 Jan 2012 19:15:15 +0100 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> References: <4F1AFFE5.7000901@ericsson.com> In-Reply-To: <4F1AFFE5.7000901@ericsson.com> Content-Type: multipart/alternative; boundary="------------080800010309090701020106" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-avtcore-srtp-vbr-audio@tools.ietf.org, The IESG <iesg@ietf.org> Subject: [apps-discuss] Apps Dir review for: draft-ietf-avtcore-srtp-vbr-audio-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 18:15:19 -0000 --------------080800010309090701020106 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-avtcore-srtp-vbr-audio-04 Title: Guidelines for the use of Variable Bit Rate Audio with Secure RTP Reviewer: Salvatore Loreto Review Date: 2012-01-21 IESG Telechat Date: Summary: I have read and reviewed this draft. The draft is really clear on describing the issues and the proposed solution. So in my opinion is ready, from an application point of view, to be published as Proposed Standard as proposed in the avtcore mailing list discussion. best regards Salvatore Loreto -- Salvatore Loreto www.sloreto.com --------------080800010309090701020106 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> <br> I have been selected as the Applications Area Directorate reviewer for this draft<br> (for background on appsdir, please see <a moz-do-not-send="true" class="ext-link" href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate"><span class="icon"> </span>http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate</a>). <br> </p> <p> Please resolve these comments along with any other Last Call comments you may receive. <br> Please wait for direction from your document shepherd or AD before posting a new version of the draft.<br> </p> <p> <br> Document: draft-ietf-avtcore-srtp-vbr-audio-04<br> </p> <p> Title: Guidelines for the use of Variable Bit Rate Audio with Secure RTP<br> Reviewer: Salvatore Loreto<br> Review Date: 2012-01-21<br> IESG Telechat Date: <br> </p> <p><br> Summary: <br> I have read and reviewed this draft.<br> The draft is really clear on describing the issues and the proposed solution.<br> So in my opinion is ready, from an application point of view, to be published as Proposed Standard<br> as proposed in the avtcore mailing list discussion.<br> </p> <p><br> </p> best regards<br> Salvatore Loreto<br> <pre class="moz-signature" cols="72">-- Salvatore Loreto <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.sloreto.com">www.sloreto.com</a></pre> </body> </html> --------------080800010309090701020106-- From johnl@iecc.com Sun Jan 22 14:02:53 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CE621F8592 for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.534 X-Spam-Level: X-Spam-Status: No, score=-108.534 tagged_above=-999 required=5 tests=[AWL=2.665, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7LsV0SdMIqm for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 14:02:53 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADC821F8585 for <apps-discuss@ietf.org>; Sun, 22 Jan 2012 14:02:52 -0800 (PST) Received: (qmail 56205 invoked from network); 22 Jan 2012 22:02:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jan 2012 22:02:51 -0000 Date: 22 Jan 2012 22:02:29 -0000 Message-ID: <20120122220229.87477.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 22 Jan 2012 22:02:54 -0000 As promised, I smooshed S.M.'s draft and mine together, so here's one that has both his narrative text and my registry additions. R's, John PS: This is unrelated to Murray's draft, which I think is an entirely reasonable application of a new Received: clause. -------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mail Header Trace Fields Author(s) : Taughannock Networks S. Moonesamy Filename : draft-levine-trace-header-registry-01.txt Pages : 6 Date : 2012-01-22 SMTP mail software adds trace fields to messages as they pass through the mail system. This memo provides background information about trace fields in mail standards. It discusses the use of trace fields in mail-related specifications. It updates the definition of trace header fields, and adds trace field information to the relevant registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt From barryleiba@gmail.com Sun Jan 22 17:05:44 2012 Return-Path: <barryleiba@gmail.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED8B21F85E9 for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 17:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3if9i7CgXTy for <apps-discuss@ietfa.amsl.com>; Sun, 22 Jan 2012 17:05:41 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A79C921F85E4 for <apps-discuss@ietf.org>; Sun, 22 Jan 2012 17:05:41 -0800 (PST) Received: by obbwc12 with SMTP id wc12so2964183obb.31 for <apps-discuss@ietf.org>; Sun, 22 Jan 2012 17:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=zHE/ZBxBzYPDmxx+mmU2yAgKmg4HfT0b5+cZ4dxdlV0=; b=NpW/llCrmbYPihw87nRJBpDDSNRI333hPpLLgrzYW4uV5jsblqbgqBj/wefWhupxis awSXr7YnJKBNAx4lSBpVSCdExhe47ZDRRn0gsEPkOOBlbON2pBqYqUAbYHYU7cXLlOa9 PGHAIxEayUGoOQ4Vq5YHSus+NdhAtLswNPBrw= MIME-Version: 1.0 Received: by 10.182.47.10 with SMTP id z10mr6145848obm.19.1327280739980; Sun, 22 Jan 2012 17:05:39 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.55.137 with HTTP; Sun, 22 Jan 2012 17:05:39 -0800 (PST) Date: Sun, 22 Jan 2012 20:05:39 -0500 X-Google-Sender-Auth: cmidUsytsJiHPJhdUY-mfleSCO0 Message-ID: <CALaySJL46XM0nzxpOsxQKFvMHKC-nfR5jz3P4eZv-YKG3+0Z2A@mail.gmail.com> From: Barry Leiba <barryleiba@computer.org> To: apps-discuss@ietf.org, draft-ietf-dane-protocol.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 01:05:45 -0000 An Applications Area Directorate review has been requested for draft-ietf-dane-protocol-14, and I have been selected as the reviewer (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Summary: The protocol appears solid and useful, and the document does not seem to have any major issues. I have some comments below, a few substantive but most editorial. I've marked the substantive ones (and the editorial ones that I think significantly affect the understanding of the document) with "SUBSTANTIVE". -------------- Section 1.2 OLD DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital Trivial, but I think it will read better this way: NEW DNSSEC [RFC4033] [RFC4034] [RFC4035] uses cryptographic keys and digital OLD Information retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. The non-parallel construction of the first two clauses made me read this too many times before I could parse it. NEW Information that is retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. -------------- Section 2.1.1 OLD This will be an IANA registry in order to make it easier to add additional certificate usages in the future. NEW This value is defined in a new IANA registry [see sec 7.2] in order to make it easier to add additional certificate usages in the future. I also suggest adding section references in sections 2.1.2 and 2.1.3, to the other two IANA registries. OLD formats for certificates, those certificates will need their own certificate types. NEW formats for certificates, those certificates will need their own certificate usage values. -------------- Section 2.1.3 SUBSTANTIVE OLD Using the same hash algorithm as is used in the signature in the certificate will make it more likely that the TLS client will understand this TLSA data. I think I know what this is meant to say, but I had to work too hard for it to become clear. Maybe this?: NEW Because a client support for multiple hash algorithms might be limited, it is advisable to use the same hash algorithm for the matching type as is used for the signature in the certificate. Doing so will increase the likelihood of interoperability. -------------- Section 2.1.4 SUBSTANTIVE OLD The "association data" to be matched. The field contains the bytes to be matched or the hash of the bytes to be matched. The source of the data to be matched is controlled by the Matching Type field. It's definitely NOT the "hash of the bytes to be matched", right? The hash *is* the set of bytes to be matched. I know what you're trying to say, but this seems an imprecise way to say it. Maybe this?: NEW The "association data" to be matched. The field contains the bytes to be matched -- the raw data, for matching type 0, or the hash of the raw data, for matching types 1 and 2. -------------- Section 2.3 SUBSTANTIVE The first example has an opening parenthesis after "IN TLSA"; the second and third don't. -------------- Section 3 SUBSTANTIVE 2. The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", "udp" and "sctp". Should there be a registry for these, as well? -------------- Section 4.1 OLD Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that the must be found in any of the PKIX validation chains Spurious "the". NEW Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that must be found in any of the PKIX validation chains -------------- Section 4.4 OLD Some specifications such at [RFC6125] detail how to match the identify given in a PKIX certificate with those expected by the user. Two typos here: "such at" and "identify". NEW Some specifications such as [RFC6125] detail how to match the identity given in a PKIX certificate with those expected by the user. OLD o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. Non-parallelism. NEW o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted. ...or, alternatively, remove "to cause" entirely. I prefer changing "to" to "MUST"; the repetition is more clear, I think. OLD Clients that validate the DNSSEC signatures themselves MUST either use standard DNSSEC validation procedures or a secure transport (such Misplaced "either". NEW Clients that validate the DNSSEC signatures themselves MUST use either standard DNSSEC validation procedures or a secure transport (such Moreover, I find that the parenthesized list separates the "MUST use secure transport" from "between A and B" with too much, making it easy to lose the message. Maybe this?: SUBSTANTIVE NEW NEW Clients that validate the DNSSEC signatures themselves MUST use either standard DNSSEC validation procedures or a secure transport between themselves and the entity performing the DNSSEC signature validation. Examples of such secure transport are TSIG [RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071]. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. -------------- Section 5 The different types of certificates for association defined in TLSA are matched with various sections of [DANEUSECASES]. The three use cases from section 3 of [DANEUSECASES] are covered in this protocol as follows: There are four use cases in DANEUSECASES; you don't mention 3.4 Delegated Services. Is that an oversight, or should you say, "Three of the use cases ..." ? (note that some of these might be excessively glib) That seems like an odd thing to say in a completed document, so I presume you'll either decide to say more or take that parenthesized statement out. For my part, I think what's there now is fine. -------------- Section 6 OLD A system creating TLSA records that conforms to this specification MUST be able to create TLSA records containing certificate usages 0, 1 and 2. A system creating TLSA records that conforms to this specification MUST be able to create TLSA records with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo). A system creating TLSA records that conforms to this specification MUST be able to create TLSA records using matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to create TLSA records using matching type 2 (SHA-512). Here, the repetition seems clumsy, heavy. May I suggest this?: NEW A system creating TLSA records that conforms to this specification MUST be able to create TLSA records o containing certificate usages 0, 1 and 2, o with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo), and o using matching type 0 (no hash used) and matching type 1 (SHA-256). In addition, the system SHOULD be able to create TLSA records using matching type 2 (SHA-512). Similarly, I suggest this for the next paragraph: NEW NEXT A TLS client conforming to this specification MUST be able to o correctly interpret TLSA records with certificate usages 0, 1 and 2, o compare a certificate for association with a certificate from TLS using selectors type 0 and 1, o compare a certificate for association with a certificate from TLS using matching type 0 (no hash used) and matching type 1 (SHA-256). In addition, the client SHOULD be able to make such comparisons using matching type 2 (SHA-512). -------------- Section 7.2 SUBSTANTIVE This document creates a new registry, "Certificate Usages for TLSA Resource Records". The registry policy is "RFC Required". Have a look at http://tools.ietf.org/html/draft-leiba-iana-policy-update and you'll see where this comment is coming from. RFC Required might be the right choice for this registry, and the fact that you're using Specification Required for the other registries makes me confident that you've thought about it and chosen for a good reason. I'd like to see the reason(s) documented here. Something like, 'The registry policy is "RFC Required" because community review of this parameter is necessary to ensure [blah-blah].' Reasonable? -------------- Section 7.3 The other two registry definitions say: Applications to the registry can request specific values that have yet to be assigned. ...and this one doesn't. I presume it should for consistency. Or is there something else here? -------------- Section 8 SUBSTANTIVE The client, seeing the proxy's new certificate for the supposed destination will not set up a TLS session. Thus, such proxies might choose to aggressively block TLSA requests and/or responses. Having not been in on the discussions about this, I'm not sure whether this is (1) advice to SSL proxies, (2) a warning to intended hosts, or (3) a warning to clients. If (1), I'm also not sure how it would do the blocking, and whether something should be said about that here. If (2) or (3), I'm also not sure what, if anything, they should be advised to do about the situation. -------------- Appendix A I started to correct errors here, but then found that there are *so* many typos, missing "the", number disagreements, and other grammatical errors in the appendix that I just have to suggest to Paul that you go through it and fix them -- I'm sure they're a result of non-native English writing. The RFC Editor will eventually fix what's left, but we should do our best first. -------------- Barry From cabo@tzi.org Sun Jan 22 17:44:11 2012 Return-Path: <cabo@tzi.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8D21F85D5; Sun, 22 Jan 2012 17:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHOVob08hbvZ; Sun, 22 Jan 2012 17:44:10 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BE28121F85D1; Sun, 22 Jan 2012 17:44:09 -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 q0N1hnVf017394; Mon, 23 Jan 2012 02:43:49 +0100 (CET) Received: from [192.168.217.117] (p54899A62.dip.t-dialin.net [84.137.154.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 88DDBA6A; Mon, 23 Jan 2012 02:43:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Carsten Bormann <cabo@tzi.org> Date: Mon, 23 Jan 2012 02:43:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <A7D68D42-9FCC-4C84-ADC4-62F03696558B@tzi.org> To: IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-decade-arch-04.all@tools.ietf.org X-Mailer: Apple Mail (2.1251.1) Cc: decade@ietf.org, SM <sm+ietf@elandsys.com> Subject: [apps-discuss] APPSDIR review of draft-ietf-decade-arch-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 01:44:11 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . 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. Gruesse, Carsten --------------------------------- Document: draft-ietf-decade-arch-04 Title: DECADE Architecture Reviewer: Carsten Bormann Review Date: 2012-01-22 ** Summary: This draft is not ready for publication as an Informational RFC and should be revised before publication. Note: I decided to review this by reading the architecture document only, to see whether it is able to stand alone. Note that this implies that the review is likely incomplete. Given the cluster of entangled documents this is a part of, I recommend a concerted review of the next version(s). ** Major Issues: A1) General: Although this is not explicitly said in the introduction, the objective of this document appears to be both: -- to provide an architecture that will constrain and guide the further work of DECADE; -- to present the architecture in an introductory, reasonably accessible way, which will facilitate understanding the specific protocol specifications envisaged. These two (prescriptive vs. descriptive) objectives of this document do conflict, and the conflict is not always managed. In particular, the document goes to considerable detail in describing the protocols, but it is not clear whether this is just illustrating the architecture (as I would expect in an architecture document) or actually constraining the protocol design. E.g., -- for the write-through PUT (section 7.1), it is specified that just one target server can be given to the intermediary. Is this an accident or deliberate? -- For GET, returning the data is optional (section 7.1)? -- "DRP is specified as being carried through extension fields within an SDT (e.g., HTTP headers)." (section 6). Is it always extension fields or is it sometimes the body? (Well, the HTTP body could be called an extension field of HTTP, too.) I think the point is that the DRP data are mostly piggy-backed on SDT. Why not say that. A1a) There are a number of places where the architecture is not yet explicit about the role of entities and data objects that it requires to function. Again, the document needs to decide for itself whether these entities and objects are illustrative only or part of the prescriptive elements of the architecture. E.g., -- is the "abstract specification of ... operation" in 6.2.1 and 6.2.2 only provided for illustration, or is the architecture limiting itself to exactly these two operations? -- There appear to be some implicit parameters such as application context? -- Or, for a PUT, how are metadata such as the expiration time established? -- Is the introductory sentence of 7 intended to limit the server-to-server interaction to a pull model ("download")? -- What is the semantics of a third-party (client-to-server-to-server) GET with respect to the middle server? Is the initiating server supposed to execute a local PUT with the result? Or what is its role? A2) Terminology: The architecture defines a number of terms quite deliberately (section 2), but misses out on a few important ones. Some important roles in the architecture (such as the ticket generating server) are only introduced cursorily, without considering the implications of their existence to the architecture. A2a) "user" (4.5.2) appears to be a central concept of the architecture, but is fleshed out only very thinly. A related concept might or might not be "account", which is only touched on, or "principal" (used in the appendices only). A2b) 4.5.2 introduces an "Application Provider" that is used nowhere else. What is that? Is that an important functional entity? A2c) The capability architecture (the "token" as a data structure, and its interaction with various functional elements) is a central element of the DECADE architecture. -- See RFC 4949 with respect to the usage of the term "token". -- The "token generating server" appears to be important, but is not called out in the list of functional elements in 2. How does a client select/find one? -- The document repeatedly (5.4, 6.1.2) states that a DECADE client must trust the token generating server, but never indicates why. -- Obviously, the DECADE servers need to trust the tokens. This is not discussed. -- The token is said to contain data object names, but then it is also meant to be useful for a "batch of operations", some of which may concern data the names of which we don't know yet. -- How is it useful to "allow a DECADE Server to detect when a token is used multiple times" (what is the server supposed to do when it = has detected that?)? -- Do tokens need a revocation mechanism? A2d) Sections 4.3 and 6.1.3 use a concept called "application context". Apparently application contexts are quite important for DECADE operations (e.g., 6.1.3 makes clear that "objects" are always associated with an application context); what are these application contexts? Who creates, deletes them? Resource control, access control for them? (Some operations seem to have an application context as an implicit parameter. Assumptions like these need to be spelled out.) A2e) 3.1: "Let S(A) denote A's DECADE storage server." This concept of ownership is never explained. Is it important? A3) The appendices provide relatively raw existence proofs that are likely to be overtaken by events in a year from now. Much of these are (overly) brief mini-tutorials for the relevant protocols. Appendix A.3 is about a protocol that itself does not seem to be fully cooked at this point. This is certainly useful material to collect for the WG, but it is not clear that these should be part of this document. There are lots of additional issues in these appendices, e.g.: A.1.1.1) HTTPS (where is the reference?) is a security protocol, but does not provide access control. A.1.1.3) This would need to (at least briefly) examine the interactions between HTTP caching and DECADE protocol operation. A.1.3) This specifies (?) "In the reply, the hash is sent in an ETAG header." What kind of response are we talking about? 304? Is this really part of the architecture? A.1.5) Why should the transfer protocol provide the complete access control mechanism? Access control is a local function. Transfer protocols just have to make sure the necessary parameters are in place (and/or may be used for transferring the parameters in the first place). When talking about OAUTH 2, add the relevant reference(s). I have not undertaken to review the appendices in any detail. A4) Is the architectural thinking converged enough on issues of naming? E.g., -- 4.3 seems to imply "resource identifiers" are being used that are the same between different servers. -- 5.3.1 seems to support this by building names in a predictable way out of hashes. In particular, "a DECADE client knows the name of a data object before it is completely stored at the DECADE server." -- However, if DECADE is to be used for real-time interactions, some thought needs to be given on the point in time when hash-based data identifiers/names can be generated. A DECADE client that PUTs video to a DECADE server may not have the complete byte-string of a slice in hand when it starts sending, so it can't send a hash-based name at the start. This is likely to have some impact on the protocol mappings possible. (It also makes it less clear that there is a good reason not to support name generation by the server right from the start.) -- A.2.3 says "DECADE may find the concept of collections to be useful if there is a need to support directory like structures in DECADE. It also discusses WebDAV's MOVE and COPY operations. What is the point when the name uniquely follows from the content? -- 6.1.2 says tokens include "Permitted objects (e.g., names of data objects that may be read or written)" and "It is possible for DRP to allow tokens to apply to a batch of operations to reduce communication overhead required between DECADE Clients." Does this require prescience on what the hash values of future slices will be? A5) Authorization based in IP addresses (6.1.2 "permitted clients") is rarely appropriate. A6) Much of the information discussed in 6.1.3 will be PII. The architecture must discuss how the protocols will provide the flexibility to cope with different data protection and surveillance regulations. For instance, the level of logging performed by a server may be an important parameter that must be indicated to the client before it starts operation, or some of it may conversely be clandestine. A7) Please rewrite section 9 from scratch. There is no need to explain fundamentals of cryptographic data structures (assuming that the next version will use terms that can be referenced properly). Instead, actual security considerations of the DECADE architecture must be discussed, e.g., the cache discovery attack mentioned above. More importantly, there needs to be a discussion of the threat model, the trust relationships envisaged, etc. Please see RFC 3552. ** Minor Issues: M1) Terminology Beyond the problems listed above, the draft needs an overhaul in its terminology. E.g.: -- it uses "TTL" as a term for an object expiration time, without ever explaining the term. (What is actually meant is an expiration time, *NOT* a lifetime/duration or hop count that would be analogous to IPv4's use of the abreviation.) -- using "data object" as the term for the things saved in a DECADE server is highly confusing. It is not always clear whether the raw byte string or the combination of this and certain metadata is meant. Do NOT use "contents" in its plural form as a synonym for "data objects" (4.2). Indeed, the document would improve by using "content" very sparingly, only in the overview sections, and being precise about data objects otherwise. (It would be preferable to have a name for the "data objects" that is distinctive from the plain English meaning of that term. E.g., slice.) E.g., while we learn about data objects that they are immutable and not all of the same size, we need consistent terms for the various kinds of metadata used, such as the DECADE metadata that are used in managing the localized storage vs. those metadata that would be visible in the SDT. "If an application wishes to store such metadata persistently within DECADE, it can be stored within data objects themselves." (What does that mean? New, separate objects? Within the existing ones? In the slice byte-string itself?) -- "data transport protocol" contains the term "transport protocol" which means something different in the IETF. We tend to use "transfer protocol" for the purpose intended. -- 4.4 introduces a "location". What is that? A DECADE server? -- "Traffic De-duplication" is a seriously misleading term for validated cache access. The whole point of the validation protocol in 8.2.1.2 appears to be to protect the cache at S against a colluding pair of A and R, under the assumption that A is not authorized to access S' copy of the object but compensates by being authorized to access R's copy. Since R can (1) indicate authorization and (2) prove to S it does have the data, both using the challenge-response protocol, S can fulfill the request for R. If that is the point, please say that. Please note that, from this exchange, A and R can still extract the fact that S had a copy. Discuss security implications of this discovery. 4.1) "However, the architecture may allow for more-than-one data transport protocols to be used." This *is* the architecture. It either allows it or not. (BTW, shouldn't the architecture also say something about negotiation/capability discovery?) 4.5.1) "The Storage Provider delegates the management of the resources at a DECADE server to one or more applications." What does that really mean? (And are the latter "Content Distribution Applications"?) 5.4) Is this really a digital signature? (Please reserve the term "digitally signed" for actual signatures, as opposed to including a kind of peer entity authentication that is directed towards a specific recipient. See RFC 4949.) 6.1) "...DRP allows one instance of such an application, e.g., an application endpoint, to apply access control and resource sharing policies on each of them." (them =3D DECADE servers.) That last sentence is rather ominous. Is this completely trivial, or does it actually mean anything? Is DRP maybe a reliable multicast protocol for control data? 6.1.4) The term "MIME type" has been superseded by "media type" (please also reference the relevant RFCs here). It is also not clear to me what that media type means in case of a slice of a larger resource representation. Why is a media type not copied with the object? 7.1) "It is also assumed that the operation performed at the remote server is the same as the operation in the original request." Explain "the same" -- are all parameters identical? Or is it just GET vs. PUT? ** Nits: [list editorial issues such as typographical errors, preferably = by section number] 1) "Content Distribution Applications" in the first sentence is not defined. Point to 2.6. 4.2) "are referred as" -> "are referred to as" 4.3) "Objects that are stored in a DECADE storage server can be accessed by DECADE content consumers by a resource identifier" second by -> via 4.3) " Because a DECADE content consumer can access more than one = storage server within a single application context, a data object = that is replicated across different storage servers managed by a = DECADE storage provider, can be accessed by a single identifier." Non sequitur. Change to: >> A DECADE content consumer may be able to access more than one storage server within a single application context. A data object that is replicated across different storage servers managed by a DECADE storage provider can still be accessed by a single identifier. << [Now, it is still not quite clear from that sentance whether that is a MUST (i.e., the whether the architecture mandates that all replicated copies MUST have the same identifier).] 4.5.2) "applications granted resources"? applications being granted resources? resources granted by applications? 5) s/principals/principles/ (Just once in the first paragraph; otherwise, principle vs. principal has been used correctly.) 6.2.2) defered -> deferred 7.1) "Note that when a DECADE client invokes a request a DECADE server with these additional parameters" -- syntax. 8.2.1.1) "When a DECADE client (A) indicates its DECADE account on a DECADE server (S) to fetch an object from a remote entity (R) (a DECADE server or DECADE client)..." What? The "account" is asked to fetch from a "client"? Ceterum censeo) RFCs, as any kind of formal technical publication, should use units in accordance with ISO/IEC 80000, in particular IEC 80000-13. Replace Mbps by Mbit/s, KB by KiB. ** Random observations: O1) The proto writeup says: > The document was reviewed by DECADE WG members, the WG Chairs, and > key non-WG contributors, particularly by David E Mcdysan, Borje > Ohlman, Akbar Rahman, Ning Zong and Dirk Kutscher. Akbar Rahman and Dirk Kutscher are co-authors of this document, so I sure hope they have reviewed this document. O2) The architecture does not give an argument why multiple SDTs are needed when all of them are just HTTP anyway. (Binding the SDT to multiple underlying protocols creates a lot of headaches that may be completely unnecessary. At least they aren't motivated.) But maybe it is not the job of the architecture document to actually motivate this highly complexity-inducing generality. E.g., A.2 alludes to a mapping to WebDAV, but then seems to go on suggesting modifications to WebDAV to enable that layering. This doesn't seem consistent. Indeed, it seems unlikely that DECADE can layer cleanly on top of either WebDAV or CDMI. A more productive view of these protocols may be as a toolkit to take certain parts from, that HTTP does not have, and that DECADE does not want to re-invent. Special care must be taken not to create a chimera, though. --- From john@jlc.net Mon Jan 23 05:19:54 2012 Return-Path: <john@jlc.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FE821F8745 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 05:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgelINNhYR37 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 05:19:53 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7D121F8742 for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 05:19:53 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4DD0333C24; Mon, 23 Jan 2012 08:19:53 -0500 (EST) Date: Mon, 23 Jan 2012 08:19:53 -0500 From: John Leslie <john@jlc.net> To: John Levine <johnl@taugh.com> Message-ID: <20120123131953.GA36092@verdi> References: <20120122220229.87477.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120122220229.87477.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 13:19:54 -0000 John Levine <johnl@taugh.com> wrote: > > As promised, I smooshed S.M.'s draft and mine together, so here's one that has > both his narrative text and my registry additions. > > http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt Nice work! But I stumbled over the difference (if any) between RFC2119 SHOULD and lower-case "should". I expect at least one IESG member would also stumble. I advise clarifying if possible. DKIM-Signature's "should" is quoting RFC6376, where it is a "SHOULD", unless I misunderstand. For Authentication-Results, RFC5451 does indeed use lower-case "should" for "be treated as a Trace field," but it uses upper-case "SHOULD" for "be added at the top of the message" -- I think folks tend to think of both of these as RFC2119 "SHOULD". For VBR-Info, RFC5518 uses "SHOULD". For Auto-Submitted, RFC5436 AFAICT uses "MUST", not "SHOULD" or "should". My take on this is that we'd do best to replace those five "should" with "SHOULD". The remaining "should" in Section 4, I'd simply remove. -- John Leslie <john@jlc.net> From sm@elandsys.com Mon Jan 23 07:30:24 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0CA21F86AD for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 07:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEw8+Mp10tim for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 07:30:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FA221F8596 for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 07:30:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0NFU34c014212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 07:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327332618; i=@elandsys.com; bh=uO11Saql+gLjPxxeHs+hXkSzxvChee+vQvRMatPbUCo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=GaITPmZfwvgB8l9gTBSyqeqxP0ZCkOFQChhIWbmtQABpov+Ov1LH2wiJboIVEKCQ3 6hsWn0OlKPvGpR6Tborkca3f0M0V7yUCXczY3iT74MkiKSYwf2YWdVCeitz/6V2qLh LoA47eS0BG1rUZ5Y+d3y+Jf1rwCnwW4loWPTNa3g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327332618; i=@elandsys.com; bh=uO11Saql+gLjPxxeHs+hXkSzxvChee+vQvRMatPbUCo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=lGgTwObFdlzCdk8e+y/1rOMcv1j5tfLzl0HPpbBqW8mTOxKViYKRp1qxAwQss2gT9 JpeS/JuRbMQnYCGXh0/AcRq9h7o6W6ZN1o4XGJ5uupaIdnSTlWMdXFmjbvovsnFI4e kb5MP9FH87nCvSEmps1gw7d6qNwrPFCsClBiYjns= Message-Id: <6.2.5.6.2.20120123061715.09faec70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2012 07:28:58 -0800 To: John Leslie <john@jlc.net> From: S Moonesamy <sm+ietf@elandsys.com> In-Reply-To: <20120123131953.GA36092@verdi> References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 15:30:24 -0000 Hi John, Thanks for the feedback. At 05:19 23-01-2012, John Leslie wrote: > But I stumbled over the difference (if any) between RFC2119 SHOULD and >lower-case "should". > > I expect at least one IESG member would also stumble. I advise clarifying >if possible. Would the argument that Section 3.1 mentions that "Further restrictions may be defined for Trace fields by the specifications that provide for their use" convince you? > DKIM-Signature's "should" is quoting RFC6376, where it is a "SHOULD", >unless I misunderstand. > > For Authentication-Results, RFC5451 does indeed use lower-case "should" >for "be treated as a Trace field," but it uses upper-case "SHOULD" for >"be added at the top of the message" -- I think folks tend to think of >both of these as RFC2119 "SHOULD". > > For VBR-Info, RFC5518 uses "SHOULD". > > For Auto-Submitted, RFC5436 AFAICT uses "MUST", not "SHOULD" or "should". > > My take on this is that we'd do best to replace those five "should" with >"SHOULD". That can be read as updating the requirements in those specifications. Section 3.2 could be moved to an appendix. The following paragraph, adapted from RFC 6125, could be used: This informative section is to delineate the history of thinking about Trace fields in mail-related specifications. It gathers together the text from various RFCs (the key words [RFC 2119] have been modified as this document does not indicate requirement levels for those RFCs). > The remaining "should" in Section 4, I'd simply remove. Ok. Regards, S. Moonesamy From msk@cloudmark.com Mon Jan 23 08:48:29 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAB321F86E8 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 08:48:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oto3PToGA-2 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 08:48:29 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0D21F85A1 for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 08:48:29 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 08:48:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 08:48:28 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Mon, 23 Jan 2012 08:48:27 -0800 Thread-Topic: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt Thread-Index: AczZ0bdFo3lwNlMlSTilAmgN3SZwVwAHNC2w Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D930@EXCH-C2.corp.cloudmark.com> References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> In-Reply-To: <20120123131953.GA36092@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 16:48:29 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John Leslie > Sent: Monday, January 23, 2012 5:20 AM > To: John Levine > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registr= y-01.txt >=20 > For Authentication-Results, RFC5451 does indeed use lower-case "should= " > for "be treated as a Trace field," but it uses upper-case "SHOULD" for > "be added at the top of the message" -- I think folks tend to think of > both of these as RFC2119 "SHOULD". I wish someone had caught that when I was getting that one published, but y= es, both are supposed to be SHOULDs in the RFC2119 sense. In order to avoid having this document mired in the "should" vs. "SHOULD" d= iscussion, the authors here might want to consider just listing the drafts = that ask for trace field status rather than making direct citations. From johnl@iecc.com Mon Jan 23 09:14:40 2012 Return-Path: <johnl@iecc.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6683921F8664 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 09:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.664 X-Spam-Level: X-Spam-Status: No, score=-108.664 tagged_above=-999 required=5 tests=[AWL=2.535, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VSbNuwb5PWa for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 09:14:40 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CD5BD21F865F for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 09:14:39 -0800 (PST) Received: (qmail 22326 invoked from network); 23 Jan 2012 17:14:39 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Jan 2012 17:14:39 -0000 Date: 23 Jan 2012 17:14:17 -0000 Message-ID: <20120123171417.44531.qmail@joyce.lan> From: "John Levine" <johnl@taugh.com> To: apps-discuss@ietf.org In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C9A7D930@EXCH-C2.corp.cloudmark.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 17:14:40 -0000 >In order to avoid having this document mired in the "should" vs. "SHOULD" discussion, the >authors here might want to consider just listing the drafts that ask for trace field status >rather than making direct citations. SM suggested adding a note saying that the section is quoting text from existing RFCs, and any 2119 words in this section mean whatever they meant in the original RFCs. Seems reasonable to me. R's, John From john@jlc.net Mon Jan 23 12:26:35 2012 Return-Path: <john@jlc.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4221F873E for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 12:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niyxC+7S9qbW for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 12:26:34 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A507721F873C for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 12:26:34 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9E5ED33C22; Mon, 23 Jan 2012 15:26:34 -0500 (EST) Date: Mon, 23 Jan 2012 15:26:34 -0500 From: John Leslie <john@jlc.net> To: S Moonesamy <sm+ietf@elandsys.com> Message-ID: <20120123202634.GC36092@verdi> References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> <6.2.5.6.2.20120123061715.09faec70@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120123061715.09faec70@resistor.net> User-Agent: Mutt/1.4.1i Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 20:26:35 -0000 S Moonesamy <sm+ietf@elandsys.com> wrote: > > That can be read as updating the requirements in those specifications. Making the "should" lower-case doesn't fix that problem. > Section 3.2 could be moved to an appendix. I don't think that's necessary, though it wouldn't bother me, I think it helps to have the body introduce these "new" trace headers. We could remove these "shoulds" just like I proposed for Section 4... > The following paragraph, adapted from RFC 6125, could be used: > > This informative section is to delineate the history of thinking about > Trace fields in mail-related specifications. It gathers together > the text from various RFCs (the key words [RFC 2119] have been modified > as this document does not indicate requirement levels for those RFCs). I don't like that text, especially the part claiming to quote, but modifying. Many folks believe that a lower-case "should" is still a RFC2119 keyword -- it's better not to open that argument. -- John Leslie <john@jlc.net> From sm@elandsys.com Mon Jan 23 13:15:24 2012 Return-Path: <sm@elandsys.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3B21F86C7 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 13:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY+aH14hsOVQ for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 13:15:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53321F86BE for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 13:15:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0NLEo5a014747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 13:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327353319; i=@elandsys.com; bh=lMAR3+dVe3sMwG99F5F4Joa5ER4jKLp6ibd98RAgroI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=o6yx4tz7LGDeNqH0ODFnl6P+KePtpVEmqLcOwoOoBVFdk0EkuQuCBXVQemnMBHvM1 taIN1EhlKdy5xVjMBSRYjyE8jNYau17/5+D0OJY6+G9zEzgTkM88DbLrI35FmJtV3l IpRD/SCcYoLLmNDnif07dxWJx6VENUToKdJdkkcM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327353319; i=@elandsys.com; bh=lMAR3+dVe3sMwG99F5F4Joa5ER4jKLp6ibd98RAgroI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=RUjKqg/8f+v48hCQn/z2Urz/HmQL5eaMenzw1qmv95hOQlr7IU49TWAR40/Vk5CaP VybGUocx7bTceX6XcsQbzg30lUPIBAdufHojbnG9JjcY4vIuvtzZRB1rDCV5N2nR05 SWMWYbQzTAoCxbOdWVv6ymcHY5uS1+hdVDuLdAZU= Message-Id: <6.2.5.6.2.20120123123554.0a88aca8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2012 13:06:57 -0800 To: John Leslie <john@jlc.net> From: S Moonesamy <sm+ietf@elandsys.com> In-Reply-To: <20120123202634.GC36092@verdi> References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> <6.2.5.6.2.20120123061715.09faec70@resistor.net> <20120123202634.GC36092@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 21:15:24 -0000 Hi John, At 12:26 23-01-2012, John Leslie wrote: > Making the "should" lower-case doesn't fix that problem. See below. > I don't think that's necessary, though it wouldn't bother me, I think >it helps to have the body introduce these "new" trace headers. > > We could remove these "shoulds" just like I proposed for Section 4... [snip] > I don't like that text, especially the part claiming to quote, but >modifying. > > Many folks believe that a lower-case "should" is still a RFC2119 >keyword -- it's better not to open that argument. Suggested text for Section 3.2: This informative section is to delineate the history of thinking about Trace fields in mail-related specifications. [RFC4408] defines the "Received-SPF:" header field as a Trace field and specifies that it is added above all other "Received-SPF:" header fields. [RFC6376] specifies that the "DKIM-Signature:" header field is treated as a Trace field and that it is not be reordered. It mentions that the header field is prepended to the message. DomainKeys Identified Mail (DKIM) relies on maintaining the ordering of header fields as a change of any "DKIM signed" header field can invalidate the DKIM signature. [RFC5451] defines an "Authentication-Results:" header field. It mentions that the field is to be treated as a Trace field to get an idea of how far away authentication checks, such as DKIM and Sender Policy Framework [RFC4408] were done. [RFC5518] defines a "VBR-Info:" header field and mentions that a message can contain multiple occurrences of these header fields. The document relies on the terminology in [RFC5322] to say that the "VBR- Info:" header field is a "trace header field". It also specifies that the header fields is be added at the top of the header fields. [RFC5436] defines an "Auto-Submitted:" header to be added to notification messages generated by Sieve filtering rules. Section 2.7.1 says "The "Auto-Submitted:" header field is considered a Trace field, similar to "Received:" header fields (see [RFC5321])." For Section 4: The recommendation that trace header fields is to be kept in blocks is not always followed. Some implementations add any new header field at the top of the message block without determining whether it is a Trace field. BTW, see the discussion paragraph in Section 1. If anyone has an opinion about that, please send comments. Regards, S. Moonesamy From tbray@textuality.com Mon Jan 23 13:23:20 2012 Return-Path: <tbray@textuality.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B668221F8693; Mon, 23 Jan 2012 13:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yly4vzQLlDv; Mon, 23 Jan 2012 13:23:19 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9615D21F8565; Mon, 23 Jan 2012 13:23:19 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4241649obb.31 for <multiple recipients>; Mon, 23 Jan 2012 13:23:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.113.97 with SMTP id ix1mr9350443obb.41.1327353799186; Mon, 23 Jan 2012 13:23:19 -0800 (PST) Received: by 10.182.36.1 with HTTP; Mon, 23 Jan 2012 13:23:19 -0800 (PST) X-Originating-IP: [76.10.184.184] Date: Mon, 23 Jan 2012 13:23:19 -0800 Message-ID: <CAHBU6isg9okckQV0bUL5aYij60-PD2KUY7=Y3=NzoSKj6nEkkA@mail.gmail.com> From: Tim Bray <tbray@textuality.com> To: apps-discuss@ietf.org, draft-ietf-oauth-v2-threatmodel-01.all@tools.ietf.org X-Gm-Message-State: ALoCoQn3nFpaEgXE2p9cc5fxD4mIgp96OU7pJhYTBaCfJZqjLoC+e/aUGQAqb/q4q0fz7Kob3c3H Content-Type: text/plain; charset=ISO-8859-1 Cc: iesg@ietf.org Subject: [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 21:23:20 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-oauth-v2-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the "minor issues" are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a "threat model" to include normative text. The basic idea would be to say "Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them." I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say "The following data elements MAY be stored or accessible...", Is this saying that "The OAuth2 RFC says that the following data elements MAY be..." or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: "SHALL"?! in 4.6.3 Adding to the concern, there is use of lower-case "must"; note 2nd & 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. Minor Issues: 4.1.2 first attack: It says "An attack may obtain the refresh tokens issued to a web server client." This needs to be clearer... a "Web server client" can be a browser or a native app. Do you mean, "the refresh tokens issued by the web server to multiple clients?" 4.1.2 last attack. In the case where a device is cloned, wouldn't "Utilize device lock to prevent unauthorized device access" still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like "minimize the risk that authenticated content is not protected" 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant information, which is unlikely to be consistent between sections 4 and 5, and adds difficulty to maintenance of this document without adding much value. I'd just wipe all these bullet lists out. If it's generated automatically it's less damaging, but still reduces readability. In the current draft, this is there for some countermeasures but absent for others. Another good reason to just take it out. 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is not adequate, but there are ways to do it without SMS. For more, see http://android-developers.blogspot.com/2011/03/identifying-app-installations.html 5.3.4 Surely a little more could be said about device lock. On a typical modern phone, "device lock" options include PINs, passwords, "face recognition" and so on. These are *not* equal in their level of security they provide. Nits: Formatting is lousy. There are notations, including ** and _whatever_ that I'm not familiar with in the RFC context. Section 1.0: s/in-built into/built into/ 2.1, last bullet point: "An example could by a..." s/by/be/ 2.2, 1st bullet point s/eaves drop/eavesdrop/ 2.3, 1st para, s/treat/threat/ 2.3.1, last bullet, "per authorization process". Adjectival phrases should be hyphenated: "per-authorization process" 2.3.3, last bullet, ditto 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" 3.1, 2nd para, should be ; not , after "within the authorization server" s/protected/protect/ s/different system/different systems/ 3.4 1st para, s/intermediary/intermediate/ list item 1. s/short-living/short-lived/ 3.5 s/malicious client/malicious clients/ 3.7 top of page 12, what is the underscore notation _client_id_ mean? I'm not familiar with this in the RFC context. 1st bullet point: s/token/token's/ 2nd bullet point, multiple issues, 1st sentence should be " the initial authorization and issuance of a token by an end-user to a particular client, and subsequent requests by this client to obtain tokens without user consent (automatic processing of repeated authorization) halfway down page 13, s/insures/ensures/ s/validates the clients/validates the client's/ 4. first sentence, s/this sections/this section/ 4.1.2 first para, the last sentence is confusing. How about: "Before enumerating the threats, here are some generally applicable countermeasures:" 4.2.4 2nd bullet s/could not be/can not be/ 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I assume that's supposed to be a hyperlink to one of the 5.* sections? 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the referrer header may contain an Authorization code in a ?a=b style argument 4.4.1.2 first bullet, "can be employed" is inconsistent with style of rest of doc 4.4.1.3 first 2 bullets have un-labeled links. 4.4.1.4 1st bullet s/authentication/authenticate/ 4.4.1.4 2nd bullet s/mean/means/ 4.4.1.7 2nd bullet s/tokens/token's/ 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ 4.4.1.10, 3rd bullet, s/aibility/ability/ 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ 4.4.1.12 I think the href to semicomplete.com needs to be turned into an IETF-style reference 4.4.2 " since HTTP user agents do not send fragments server requests." What you mean to say is "Since HTTP user agents do not send the fragment part of URIs to HTTP servers." 4.4.2.2 s/browser/browser's/ 5.1.4.1.3 s/consider to not store/refrain from storing/ 5.* s/may consider to $(verb)/may consider $(verb)ing/ 5.1.6 Needs some sort of sentence structure 5.3.2 Needs some sort of sentence structure; or is this intended just to be a title, with 5.3.3 etc nested under it? From tbray@textuality.com Mon Jan 23 13:27:11 2012 Return-Path: <tbray@textuality.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4A721F84C9; Mon, 23 Jan 2012 13:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJKL5seNbt0E; Mon, 23 Jan 2012 13:27:10 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1A21F84A6; Mon, 23 Jan 2012 13:27:10 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4247000obb.31 for <multiple recipients>; Mon, 23 Jan 2012 13:27:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.37.99 with SMTP id x3mr6098277obj.31.1327354029941; Mon, 23 Jan 2012 13:27:09 -0800 (PST) Received: by 10.182.36.1 with HTTP; Mon, 23 Jan 2012 13:27:09 -0800 (PST) X-Originating-IP: [76.10.184.184] Date: Mon, 23 Jan 2012 13:27:09 -0800 Message-ID: <CAHBU6ivA2YYkc_K8=7Xc_zBJR-zkW3zfQVn+Yfq+FjyRuifD=Q@mail.gmail.com> From: Tim Bray <tbray@textuality.com> To: apps-discuss@ietf.org, draft-ietf-oauth-v2-threatmodel-01.all@tools.ietf.org X-Gm-Message-State: ALoCoQm/FPX7RF4X48eE3Ere0cDWKXQYPFElm9bTZSHNwwWES3VOyzaWnP65qnkBP2chGBznGoeL Content-Type: text/plain; charset=ISO-8859-1 Cc: iesg@ietf.org Subject: [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 21:27:11 -0000 [pardon resend, must have cut/pasted suggested distribution wrong] I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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-oauth-v2-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the "minor issues" are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a "threat model" to include normative text. The basic idea would be to say "Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them." I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say "The following data elements MAY be stored or accessible...", Is this saying that "The OAuth2 RFC says that the following data elements MAY be..." or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: "SHALL"?! in 4.6.3 Adding to the concern, there is use of lower-case "must"; note 2nd & 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. Minor Issues: 4.1.2 first attack: It says "An attack may obtain the refresh tokens issued to a web server client." This needs to be clearer... a "Web server client" can be a browser or a native app. Do you mean, "the refresh tokens issued by the web server to multiple clients?" 4.1.2 last attack. In the case where a device is cloned, wouldn't "Utilize device lock to prevent unauthorized device access" still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like "minimize the risk that authenticated content is not protected" 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant information, which is unlikely to be consistent between sections 4 and 5, and adds difficulty to maintenance of this document without adding much value. I'd just wipe all these bullet lists out. If it's generated automatically it's less damaging, but still reduces readability. In the current draft, this is there for some countermeasures but absent for others. Another good reason to just take it out. 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is not adequate, but there are ways to do it without SMS. For more, see http://android-developers.blogspot.com/2011/03/identifying-app-installations.html 5.3.4 Surely a little more could be said about device lock. On a typical modern phone, "device lock" options include PINs, passwords, "face recognition" and so on. These are *not* equal in their level of security they provide. Nits: Formatting is lousy. There are notations, including ** and _whatever_ that I'm not familiar with in the RFC context. Section 1.0: s/in-built into/built into/ 2.1, last bullet point: "An example could by a..." s/by/be/ 2.2, 1st bullet point s/eaves drop/eavesdrop/ 2.3, 1st para, s/treat/threat/ 2.3.1, last bullet, "per authorization process". Adjectival phrases should be hyphenated: "per-authorization process" 2.3.3, last bullet, ditto 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" 3.1, 2nd para, should be ; not , after "within the authorization server" s/protected/protect/ s/different system/different systems/ 3.4 1st para, s/intermediary/intermediate/ list item 1. s/short-living/short-lived/ 3.5 s/malicious client/malicious clients/ 3.7 top of page 12, what is the underscore notation _client_id_ mean? I'm not familiar with this in the RFC context. 1st bullet point: s/token/token's/ 2nd bullet point, multiple issues, 1st sentence should be " the initial authorization and issuance of a token by an end-user to a particular client, and subsequent requests by this client to obtain tokens without user consent (automatic processing of repeated authorization) halfway down page 13, s/insures/ensures/ s/validates the clients/validates the client's/ 4. first sentence, s/this sections/this section/ 4.1.2 first para, the last sentence is confusing. How about: "Before enumerating the threats, here are some generally applicable countermeasures:" 4.2.4 2nd bullet s/could not be/can not be/ 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I assume that's supposed to be a hyperlink to one of the 5.* sections? 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the referrer header may contain an Authorization code in a ?a=b style argument 4.4.1.2 first bullet, "can be employed" is inconsistent with style of rest of doc 4.4.1.3 first 2 bullets have un-labeled links. 4.4.1.4 1st bullet s/authentication/authenticate/ 4.4.1.4 2nd bullet s/mean/means/ 4.4.1.7 2nd bullet s/tokens/token's/ 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ 4.4.1.10, 3rd bullet, s/aibility/ability/ 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ 4.4.1.12 I think the href to semicomplete.com needs to be turned into an IETF-style reference 4.4.2 " since HTTP user agents do not send fragments server requests." What you mean to say is "Since HTTP user agents do not send the fragment part of URIs to HTTP servers." 4.4.2.2 s/browser/browser's/ 5.1.4.1.3 s/consider to not store/refrain from storing/ 5.* s/may consider to $(verb)/may consider $(verb)ing/ 5.1.6 Needs some sort of sentence structure 5.3.2 Needs some sort of sentence structure; or is this intended just to be a title, with 5.3.3 etc nested under it? From msk@cloudmark.com Mon Jan 23 22:05:31 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792C821F85B8 for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 22:05:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN2r7dEgDOEP for <apps-discuss@ietfa.amsl.com>; Mon, 23 Jan 2012 22:05:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1F21F85AA for <apps-discuss@ietf.org>; Mon, 23 Jan 2012 22:05:30 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 22:05:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 23 Jan 2012 22:05:29 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Mon, 23 Jan 2012 22:05:28 -0800 Thread-Topic: [apps-discuss] FW: Spam reporting over IMAP Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+ADJcaFQADFelgAACKZQAAC4je8QAD4ANWAA3Trh8A== Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D969@EXCH-C2.corp.cloudmark.com> References: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] FW: Spam reporting over IMAP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 24 Jan 2012 06:05:31 -0000 Hi all, Going back through the thread discussing this work proposed to APPSAWG, I'v= e seen a couple of people willing to do work on it so long as there's some = evidence it will go somewhere on the Internet side of things. Accordingly, I've sent messages to contacts inside several of the big mailb= ox providers to ask if they would be interested in a spam reporting extensi= on to IMAP. I'll report back anything I get from them. Perhaps then we ca= n formulate a formal reply to OMA one way or the other. -MSK (OMA Liaison Manager) From barryleiba.mailing.lists@gmail.com Tue Jan 24 07:40:30 2012 Return-Path: <barryleiba.mailing.lists@gmail.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF04621F84D3 for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 07:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFIULH-g0jzl for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 07:40:30 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5B21F84D0 for <apps-discuss@ietf.org>; Tue, 24 Jan 2012 07:40:30 -0800 (PST) Received: by yenm3 with SMTP id m3so2012476yen.31 for <apps-discuss@ietf.org>; Tue, 24 Jan 2012 07:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=7+fQiZLnD2yl2+HzqbdTOeTYtIzScPCjZCvPaH7fE5I=; b=pHq74Sq+05jjKFR8DZ9jXugsB2UNPs4S26jXNMtQlWahcBl/6kpanSS1iTkhz3ThQa aGHR0vp9AxpJ6ArRG0zRD1RfsC7h+gAm68uIZwA8koeRbJoVdiM2xK1F7oC8rAJNqYnK FbczAGJbTLi4beL9LG159i7qDkMtEFhb21iaI= MIME-Version: 1.0 Received: by 10.236.157.10 with SMTP id n10mr19280512yhk.41.1327419629768; Tue, 24 Jan 2012 07:40:29 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Tue, 24 Jan 2012 07:40:29 -0800 (PST) In-Reply-To: <CALaySJL46XM0nzxpOsxQKFvMHKC-nfR5jz3P4eZv-YKG3+0Z2A@mail.gmail.com> References: <CALaySJL46XM0nzxpOsxQKFvMHKC-nfR5jz3P4eZv-YKG3+0Z2A@mail.gmail.com> Date: Tue, 24 Jan 2012 10:40:29 -0500 X-Google-Sender-Auth: laVHDxj0tWo0P7R5auKIClQTmr4 Message-ID: <CAC4RtVBmtChiDn-aecwXGTNAW+GerOZeUZn2AgNpdjS57uwuAQ@mail.gmail.com> From: Barry Leiba <barryleiba@computer.org> To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 24 Jan 2012 15:40:30 -0000 > An Applications Area Directorate review has been requested for > draft-ietf-dane-protocol-14, and I have been selected as the reviewer Just for the record: * This was requested as an early review; the document is not even in working-group last call yet. * The document editors and WG chairs responded to me privately, and the editors will be making most of the changes I've suggested (and I'm happy with the responses). * I'll re-review during WGLC, and give it a check during IETF Last Call as well. Barry From alexey.melnikov@isode.com Tue Jan 24 13:53:06 2012 Return-Path: <alexey.melnikov@isode.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF78411E8085 for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 13:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OApttTS6BvjR for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 13:53:05 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8C11E8079 for <apps-discuss@ietf.org>; Tue, 24 Jan 2012 13:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327441864; d=isode.com; s=selector; i=@isode.com; bh=MwP2myjNNgWM7ydZEitk+wQMYiYyZuOJyWChAr/zir0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=grv0msgGI1XiWlfqdV5TPBspTEyyRWJRDjfF4dO0kpZA2kt/gCMNi1RhKIfiHhpbBhlhAk 5BRgtroXMKJp6kXUaoz0inE+hjXzuez2eb8tfn7iIV+xbQP2nkTzeDp4VMGoXm0SsjTYTo CNEWDkyoL0+KCrKKD8f2O5FpymfArLY=; Received: from [188.28.223.89] (188.28.223.89.threembb.co.uk [188.28.223.89]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <Tx8nxQAV55lV@rufus.isode.com>; Tue, 24 Jan 2012 21:51:02 +0000 Message-ID: <4F1F1A72.1090302@isode.com> Date: Tue, 24 Jan 2012 20:54:11 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> References: <4EE2430E.4080501@isode.com> In-Reply-To: <4EE2430E.4080501@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 24 Jan 2012 21:53:06 -0000 On 09/12/2011 17:19, Alexey Melnikov wrote: > Dear WG participant, > I would like to initiate WGLC on draft-ietf-appsawg-xdash-02.txt. Due > to holiday season the WGLC is going to be a long one and will end on > January 6th. Please send any comments directly to the apps-discuss > mailing list, or directly to editors of the draft and myself. > Please send an email even if you reviewed the document and found no > issues with it. > > Thank you, > Alexey, as an APPSAWG co-chair. Truly yours was quite disorganized and the WGLC is definitely over by now. However there weren't many comments on the document, so it is either perfect or people don't care. I would like to give people a couple of extra days (till the end of Sunday) to contemplate errors of their ways (and redeem themselves by late reviews), at which point I am likely to do the shepherding write-up and ask our AD Pete to sponsor publication of the document. Best Regards, Alexey, as an APPSAWG co-chair. From paul.hoffman@vpnc.org Tue Jan 24 15:03:18 2012 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093E321F861A for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 15:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGys5-cYfisA for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 15:03:17 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9721F8602 for <apps-discuss@ietf.org>; Tue, 24 Jan 2012 15:03:17 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0ON3EsS017599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 16:03:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman <paul.hoffman@vpnc.org> In-Reply-To: <4F1F1A72.1090302@isode.com> Date: Tue, 24 Jan 2012 15:03:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> To: Alexey Melnikov <alexey.melnikov@isode.com> X-Mailer: Apple Mail (2.1251.1) Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 24 Jan 2012 23:03:18 -0000 On Jan 24, 2012, at 12:54 PM, Alexey Melnikov wrote: > On 09/12/2011 17:19, Alexey Melnikov wrote: > However there weren't many comments on the document, so it is either = perfect or people don't care. That's somewhat disingenuous. Some of us care very much but didn't think = that commenting on the document would have any effect on the outcome. My comments: the document makes grandiose, over-arching suggestions that = indicate a one-size-fits-all view of the standards process. I would = probably do the same if I were co-author of this document, with half of = my suggestions being the same as what is the draft and half being the = opposite. A different way to do the document would be a single paragraph: "People = have thought about this topic for over a decade, probably much harder = than you are thinking about this now. They often disagreed with each = other, indicating that you are not thinking hard enough about your = current choices. Whatever you choose to do with respect to = not-yet-defined parameters, you will likely regret the choice if your = protocol is at all popular." Such a concise document is much easier to = read and much less likely to be noticed than the current one. --Paul Hoffman From sm@resistor.net Tue Jan 24 19:36:20 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE511E80A2 for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 19:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBYFAiezBoB1 for <apps-discuss@ietfa.amsl.com>; Tue, 24 Jan 2012 19:36:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B911E8086 for <apps-discuss@ietf.org>; Tue, 24 Jan 2012 19:36:19 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0P3aCY6020097; Tue, 24 Jan 2012 19:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327462578; i=@resistor.net; bh=g608vU2Lpf2NZ5AehKCGsB52A+trDuCI0yMTtUMYJBc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=DPnaXfiNzmg07Y4bBjYZJY1u47y0GIbF4NwCX+diJoxsfAJaIxidVk5OiKE8wkTL2 D1GbA4hKucbICe9H2neJp7OTXhu0AcG1D7GS9764+/6PDpwLoG6SiVw5NCDVk+quFP AKnSjLfSENjiMUKg+kDaQ6Z+N4eidm2T9J/GeOAE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327462578; i=@resistor.net; bh=g608vU2Lpf2NZ5AehKCGsB52A+trDuCI0yMTtUMYJBc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=j+4HozURGCDXrswLhKivGhgObQc1sypGWQq2nX9/qMGkivZdcHpZDitGSyFpnfrsD 46yP0UhdZ2iBFeQm4Nz8BiqxdXQjyzwtsHpKGEzf0Qgq9D0xkxeKQVnb2awwe3yuCa 7Mx/+Qz7I2/2yezc0tAhIdWtO8Ktf4vXrKG+GZaw= Message-Id: <6.2.5.6.2.20120124185702.09ce6400@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Jan 2012 19:17:39 -0800 To: Paul Hoffman <paul.hoffman@vpnc.org> From: SM <sm@resistor.net> In-Reply-To: <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 03:36:20 -0000 Hi Paul, At 15:03 24-01-2012, Paul Hoffman wrote: >A different way to do the document would be a single paragraph: >"People have thought about this topic for over a decade, probably >much harder than you are thinking about this now. They often >disagreed with each other, indicating that you are not thinking hard >enough about your current choices. Whatever you choose to do with >respect to not-yet-defined parameters, you will likely regret the >choice if your protocol is at all popular." Such a concise document >is much easier to read and much less likely to be noticed than the current one. The above express the idea in simple words. There aren't any RFC 2119 key words though. That's highly inappropriate for a BCP. :-) I suggest moving draft-ietf-appsawg-xdash-02 to Last Call it is written in a language which protocol designers ought to understand. Regards, -sm From ietfc@btconnect.com Wed Jan 25 02:23:44 2012 Return-Path: <ietfc@btconnect.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6921F84D7 for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 02:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JbPfyh0bpvk for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 02:23:43 -0800 (PST) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 607B421F85DF for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 02:23:42 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr09.btconnect.com with SMTP id FZU55574; Wed, 25 Jan 2012 10:23:36 +0000 (GMT) Message-ID: <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> From: "t.petch" <ietfc@btconnect.com> To: "Paul Hoffman" <paul.hoffman@vpnc.org>, "Alexey Melnikov" <alexey.melnikov@isode.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> Date: Wed, 25 Jan 2012 10:24:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F1FD827.00D6, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.25.95414:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4F1FD828.0221,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 10:23:44 -0000 ----- Original Message ----- From: "Paul Hoffman" <paul.hoffman@vpnc.org> To: "Alexey Melnikov" <alexey.melnikov@isode.com> Cc: <apps-discuss@ietf.org> Sent: Wednesday, January 25, 2012 12:03 AM > On Jan 24, 2012, at 12:54 PM, Alexey Melnikov wrote: > > On 09/12/2011 17:19, Alexey Melnikov wrote: > > However there weren't many comments on the document, so it is either perfect or people don't care. > > That's somewhat disingenuous. Some of us care very much but didn't think that commenting on the document would have any effect on the outcome. > Yes, my thoughts exactly. The document reads like an edict from a socialist state, 'in future, you will ...[insert nonsense appropriate to your culture]' and taking on socialist states is a losing game for the individual. But you ask. The body of the document is dogmatic, the support for the bald statement lies in Appendix B (normative?) and is almost as weak. The e-mail that came to me contained 15 distinct X- headers; what are the creators of those meant to do now? And what in future when they wish to develop or experiment with a new idea, perhaps one that will be very successful but only within a walled garden? The real failure lies with SMTP, MIME etc, or those who specified it, who failed to see the need for migration (all too common a point of view in the IETF). Having a private namespace in which to develop and experiment without harming the Internet is an excellent idea and crops up in many forms, of which this I-D only addresses the 'X-' format. When such work is successful, and the desire is there to move it to the Internet, then a migration strategy is needed and it is this that the MIMiEs etc failed to plan for. This failure does not invalidate the case for a private portion of the namespace. And, to be expected really, this I-D fails to consider migration; what is going to happen now to those 15 X- headers and all the others that are in other e-mails? Where is your migration plan? And what about all the other private portions of namespaces that are designated with something other than X-? Will you produce an edict prohibiting them as well? Tom Petch > My comments: the document makes grandiose, over-arching suggestions that indicate a one-size-fits-all view of the standards process. I would probably do the same if I were co-author of this document, with half of my suggestions being the same as what is the draft and half being the opposite. > > A different way to do the document would be a single paragraph: "People have thought about this topic for over a decade, probably much harder than you are thinking about this now. They often disagreed with each other, indicating that you are not thinking hard enough about your current choices. Whatever you choose to do with respect to not-yet-defined parameters, you will likely regret the choice if your protocol is at all popular." Such a concise document is much easier to read and much less likely to be noticed than the current one. > > --Paul Hoffman > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From msk@cloudmark.com Wed Jan 25 11:43:04 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FF321F8504 for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 11:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0x8u9dzDqqx for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 11:43:04 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F137321F84FC for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 11:43:03 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 11:43:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 11:43:03 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Wed, 25 Jan 2012 11:43:02 -0800 Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: AczbS2+r1OOKnCoMRIG43byiud5/xAATTlxA Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> In-Reply-To: <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 19:43:04 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of t.petch > Sent: Wednesday, January 25, 2012 1:24 AM > To: Paul Hoffman; Alexey Melnikov > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt >=20 > And, to be expected really, this I-D fails to consider migration; what > is going to happen now to those 15 X- headers and all the others that > are in other e-mails? Where is your migration plan? I think it's there in plain sight: Drop the "X-" and register them. I think it's also clear that this can't affect deployed software that actua= lly looks for "X-" fields, but rather encourages new implementations of thi= ngs to avoid this practice. Seems perfectly reasonable to me. If the document doesn't already say something like that, I agree that it wo= uld be a useful thing to say. > And what about all the other private portions of namespaces that are > designated with something other than X-? Will you produce an edict > prohibiting them as well? The abstract says that this "causes more problems than it solves." Do you = envision some other solution to those problems? -MSK From sm@resistor.net Wed Jan 25 12:07:40 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86BD11E8089 for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMz8+lOeAEe1 for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:07:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C755F21F84EE for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 12:07:37 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0PK7VmM004650 for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 12:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327522056; i=@resistor.net; bh=TZ2JAoJk/blel991OPP7qChQbwsmVC+pv2q5CymdIXc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ri2i60SN7R2Bb6/i8C/3LyesiEmbRAlSnKZuKKl0KeNAGJ9g8kKgFdeTt9AHfPnO0 5l08+2RpbUCX0vFV64RRjO8m0+s89kMG2JiHfiRddMc+wn38fsk0XGwOIqM3O96zob v9BDdZW5LGYwz8ZMuk1ln+SDPXd6LKthAAWKOwTQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327522056; i=@resistor.net; bh=TZ2JAoJk/blel991OPP7qChQbwsmVC+pv2q5CymdIXc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=RyYxZ1tuMoheFZa+ivl/4bKQoUtkSAjuVa9e04xYnaKQZbWFjlS3gzYw9VQsD2IDy hiO8tZGABuq9uP/+0TEEsPT4HAJX9NWs0k8RGOzwBrZ2zbtaeBXzJWEmaPsq7Fr1a3 U0PLt7HmJue0njZZloSwwpCJFwQ0EgiWCjVf8TcA= Message-Id: <6.2.5.6.2.20120125120351.0b011f60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 25 Jan 2012 12:06:46 -0800 To: apps-discuss@ietf.org From: SM <sm@resistor.net> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cl oudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] X-Original (was: WGLC on draft-ietf-appsawg-xdash-02.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 20:07:40 -0000 Hi Murray, At 11:43 25-01-2012, Murray S. Kucherawy wrote: >I think it's there in plain sight: Drop the "X-" and register them. https://sites.google.com/site/oauthgoog/mlistsdkim Regards, -sm From msk@cloudmark.com Wed Jan 25 12:12:03 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E7721F84F5 for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUk0-oiCmUTQ for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:12:02 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E41BF21F84EF for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 12:12:02 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 12:12:02 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 12:12:02 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Wed, 25 Jan 2012 12:12:00 -0800 Thread-Topic: [apps-discuss] X-Original (was: WGLC on draft-ietf-appsawg-xdash-02.txt) Thread-Index: AczbnP+Ug3sUSoPoTJe8WCVgDsOXyQAAI3rw Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D9A0@EXCH-C2.corp.cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> <6.2.5.6.2.20120125120351.0b011f60@resistor.net> In-Reply-To: <6.2.5.6.2.20120125120351.0b011f60@resistor.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] X-Original (was: WGLC on draft-ietf-appsawg-xdash-02.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 20:12:03 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Wednesday, January 25, 2012 12:07 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] X-Original (was: WGLC on draft-ietf-appsawg-xdash= -02.txt) >=20 > Hi Murray, > At 11:43 25-01-2012, Murray S. Kucherawy wrote: > >I think it's there in plain sight: Drop the "X-" and register them. >=20 > https://sites.google.com/site/oauthgoog/mlistsdkim I'm working with them on that, actually. From stpeter@stpeter.im Wed Jan 25 12:28:28 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E8011E808E for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpbHl5vUtj9x for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:28:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D1BEC11E8087 for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 12:28:27 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A01AE40058; Wed, 25 Jan 2012 13:38:12 -0700 (MST) Message-ID: <4F2065E9.3000209@stpeter.im> Date: Wed, 25 Jan 2012 13:28:25 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" <msk@cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 20:28:28 -0000 On 1/25/12 12:43 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> [mailto:apps-discuss-bounces@ietf.org] On Behalf Of t.petch Sent: >> Wednesday, January 25, 2012 1:24 AM To: Paul Hoffman; Alexey >> Melnikov Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC >> on draft-ietf-appsawg-xdash-02.txt >> >> And, to be expected really, this I-D fails to consider migration; >> what is going to happen now to those 15 X- headers and all the >> others that are in other e-mails? Where is your migration plan? > > I think it's there in plain sight: Drop the "X-" and register them. Why drop the "X-" on existing parameters? Yes, that wasn't such a great idea, but the parameters exist, so there's no need to change them. Please note what Section 6 ("IANA Considerations") states: This document does not modify registration procedures currently in force for various application protocols. However, such procedures might be updated in the future to incorporate the best practices defined in this document. > I think it's also clear that this can't affect deployed software that > actually looks for "X-" fields, but rather encourages new > implementations of things to avoid this practice. Seems perfectly > reasonable to me. Yes, and the recommendations for creators of new parameters (Section 3) and for protocol designers (Section 4) are intentionally worded in terms of new parameters and protocols, not existing ones. > If the document doesn't already say something like that, I agree that > it would be a useful thing to say. It already does. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Wed Jan 25 12:33:25 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0553E21F84FC for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQYSqeBWPPkr for <apps-discuss@ietfa.amsl.com>; Wed, 25 Jan 2012 12:33:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F03DA21F84F9 for <apps-discuss@ietf.org>; Wed, 25 Jan 2012 12:33:23 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 12:33:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 12:33:23 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Wed, 25 Jan 2012 12:33:22 -0800 Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: Aczbn+Yfs3FtnQzVSEGpMvQBV/TSAAAAGBkw Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D9A7@EXCH-C2.corp.cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org> <010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> <4F2065E9.3000209@stpeter.im> In-Reply-To: <4F2065E9.3000209@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 20:33:25 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBb bWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1 LCAyMDEyIDEyOjI4IFBNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFdHTEMgb24gZHJh ZnQtaWV0Zi1hcHBzYXdnLXhkYXNoLTAyLnR4dA0KPiANCj4gV2h5IGRyb3AgdGhlICJYLSIgb24g ZXhpc3RpbmcgcGFyYW1ldGVycz8gWWVzLCB0aGF0IHdhc24ndCBzdWNoIGEgZ3JlYXQNCj4gaWRl YSwgYnV0IHRoZSBwYXJhbWV0ZXJzIGV4aXN0LCBzbyB0aGVyZSdzIG5vIG5lZWQgdG8gY2hhbmdl IHRoZW0uDQoNCkkgZ3Vlc3MgSSdtIHRoaW5raW5nIG9mIHRob3NlIGFwcGxpY2F0aW9ucyB0aGF0 IHByb2R1Y2UgWC0gZmllbGRzIHdoZXJlIG5vdGhpbmcgKGFwcGFyZW50bHkpIGNvbnN1bWVzIHRo ZW0gaW4gYW4gYXV0b21hdGVkIHdheS4gIEluIHRob3NlIGNhc2VzLCByZW5hbWluZyBhbmQgcmVn aXN0ZXJpbmcgaXMgaGFybWxlc3MuDQoNClRob3NlIHRoYXQgZG8gbmVlZCBhIHRyYW5zaXRpb24g cGxhbiwgd2hpY2ggaXMgdHlwaWNhbGx5ICJhY2NlcHQvZXhwZWN0IGVpdGhlciBmb3JtIiBpbiBt eSBleHBlcmllbmNlLg0KDQoNCg== From zordogh@rim.com Thu Jan 26 06:58:28 2012 Return-Path: <zordogh@rim.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6819B21F84CD for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 06:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vah88Ff4yaYS for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 06:58:27 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0E21F84BF for <apps-discuss@ietf.org>; Thu, 26 Jan 2012 06:58:26 -0800 (PST) X-AuditID: 0a412830-b7fc06d00000574a-05-4f216a1156f3 Received: from XHT103CNC.rim.net (xht103cnc.rim.net [10.65.22.51]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 3A.EC.22346.11A612F4; Thu, 26 Jan 2012 14:58:26 +0000 (GMT) Received: from XCT104CNC.rim.net (10.65.161.204) by XHT103CNC.rim.net (10.65.22.51) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 26 Jan 2012 09:58:25 -0500 Received: from XMB107ACNC.rim.net ([fe80::f1d2:c1d5:f469:3f83]) by XCT104CNC.rim.net ([fe80::bd22:1ec5:27cc:e392%17]) with mapi id 14.01.0339.001; Thu, 26 Jan 2012 09:58:24 -0500 From: Zoltan Ordogh <zordogh@rim.com> To: Alexey Melnikov <alexey.melnikov@isode.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: AQHM2uKSFaojOrhNTUO5G+1S1Yuvn5Yev+GA Date: Thu, 26 Jan 2012 14:58:23 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D76226DCA24@XMB107ACNC.rim.net> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> In-Reply-To: <4F1F1A72.1090302@isode.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXC5ShmrCuUpehvsO4bh8WM1UUWq1+uYHNg 8liy5CeTx6lmwwCmqAZGm8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzEzNzU IiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bnsr2th YWqpa6hkp4sEEv5xZ+zYvJux4CRPxbNXN5gaGGdydTFyckgImEgcfNDFAmGLSVy4t54NxBYS 6GGSaLuS08XIBWQvY5TYtWEzO0RiG6PEnrk1XYwcHGwCqhJzrsaChEUEkiR2tNxlArGFBZwl tp79xwIRd5F4enQiO4RtJHF27W2w+SxArVs6JjKD2LwCnhJTl89jghjvKnG+aSozyHhOAU2J SRNdQMKMArISu89eBythFhCXuPVkPhPEyQISS/acZ4awRSVePv7HCmErSjxp3MwCUa8jsWD3 JzYIW1ti2cLXUGsFJU7OfMICsVZG4vmUS+wTGMVnIVkxC0n7LCTts5C0L2BkWcUomJtRbGBm mJyXrFeUmauXl1qyiRGcNjQMdjBO2Kt1iFGAg1GJh3d9pKK/EGtiWXFl7iFGCQ5mJRHeO15A Id6UxMqq1KL8+KLSnNTiQ4wWwACayCzFnZwPTGl5JfHGBgYoHCVxXm31e35CAunAJJWdmlqQ WgTTysTBKdXAeDby+mS9yQ9UcrOa/eS5Jv89bWqw4IS/8ebdNZ+uRWkld6w6m9K8rktirWxv ecz/cJe2d8rcV+82Vez9tsr9yAVDxvPPbifs05NqM1zcPuG87G+9hJIUi06ftYUThTLnCQSK FBxe8HaK5p2zta+a13nqLYtcPYH1p3KtmMmBpzMFma+KJ0/7qMRSnJFoqMVcVJwIAFln2Ls0 AwAA Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Jan 2012 14:58:28 -0000 Looks "perfect" to me; I have only one question on section 3, bullet 2: How would you know that a name is unused? > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Alexey > Melnikov > Sent: January 24, 2012 3:54 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt > > On 09/12/2011 17:19, Alexey Melnikov wrote: > > Dear WG participant, > > I would like to initiate WGLC on draft-ietf-appsawg-xdash-02.txt. Due > > to holiday season the WGLC is going to be a long one and will end on > > January 6th. Please send any comments directly to the apps-discuss > > mailing list, or directly to editors of the draft and myself. > > Please send an email even if you reviewed the document and found no > > issues with it. > > > > Thank you, > > Alexey, as an APPSAWG co-chair. > Truly yours was quite disorganized and the WGLC is definitely over by now.= However there weren't many > comments on the document, so it is either perfect or people don't care. I= would like to give people a > couple of extra days (till the end of Sunday) to contemplate errors of the= ir ways (and redeem > themselves by late reviews), at which point I am likely to do the shepherd= ing write-up and ask our AD > Pete to sponsor publication of the document. > > Best Regards, > Alexey, as an APPSAWG co-chair. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From torsten@lodderstedt.net Wed Jan 25 12:42:06 2012 Return-Path: <torsten@lodderstedt.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCDD21F8548; Wed, 25 Jan 2012 12:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbcR3LeZJ9xb; Wed, 25 Jan 2012 12:42:05 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8DC21F853D; Wed, 25 Jan 2012 12:42:04 -0800 (PST) Received: from [79.253.19.45] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Rq9fM-0001Ls-6D; Wed, 25 Jan 2012 21:42:00 +0100 Message-ID: <4F206917.2080406@lodderstedt.net> Date: Wed, 25 Jan 2012 21:41:59 +0100 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: S Moonesamy <sm+ietf@elandsys.com>, Tim Bray <tbray@textuality.com> References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F1F08A2.4020707@lodderstedt.net> In-Reply-To: <4F1F08A2.4020707@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= X-Mailman-Approved-At: Thu, 26 Jan 2012 08:02:13 -0800 Cc: Mark Mcgloin <mark.mcgloin@ie.ibm.com>, draft-ietf-oauth-v2-threatmodel.all@tools.ietf.org, apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jan 2012 20:42:06 -0000 Hi Tim, thanks again for reviewing the threat model document. We will incorporate your comments into a new revision of our document. This work will take some time. So if anyone else wants to review the document, please wait until we announce availability of the next revision. regards, Torsten. Am 24.01.2012 20:38, schrieb Torsten Lodderstedt: > Hi, > > thanks for the thoroughly review. > > The threat document is intended to become an Informational RFC. So we > will follow your advice and remove all normative language. > > regards, > Torsten. > > Am 23.01.2012 22:47, schrieb S Moonesamy: >> The following is the AppsDir review performed by Tim Bray. It would >> be appreciated if a reply is sent to Tim Bray with a copy to the >> apps-discuss mailing list. >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> >> 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-oauth-v2-threatmodel-01 >> Title: OAuth 2.0 Threat Model and Security Considerations >> Reviewer: Tim Bray >> Review Date: Jan 23, 2012 >> >> Summary: This needs some more editorial work, but is basically sound. >> It's not clear, though, whether it wants to be an Informational RFC or >> not; the use of RFC2119 language needs special attention. I think a >> few of the "minor issues" are worthy of a little bit more work in >> another draft. >> >> Major Issues: >> >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I >> normally wouldn't expect a "threat model" to include normative text. >> The basic idea would be to say "Here is an enumeration of the threats, >> and here are the tools available to OAUTH2 implementors to meet them." >> I was impressed by the enumeration, which seemed very complete and >> well thought through. But the usage of 2119, which makes statements >> normative, seems inconsistent. I can think of 2 ways to address this: >> >> 1. Remove all the 2119 words, so this document isn't normative, and >> publish it as an Informational RFC >> 2. Go through and clean up the 2119 language so it's used >> consistently; then this becomes a normative document. >> >> This is going to affect the references to this document from other >> I-Ds in the OAuth suite, which are currently in last call. >> >> Here are all the section-numbered notes enumerating my issues around >> 2119, as I encountered them: >> >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >> threat analysis. When you say "The following data elements MAY be >> stored or accessible...", Is this saying that "The OAuth2 RFC says >> that the following data elements MAY be..." or is it saying something >> else. I don't think there's anything seriously wrong here, but a bit >> more explanation might be in order. I note a comparative absence of >> 2119-ese in section 5 describing countermeasures, where one would >> expect to find it. >> Also in 4.3.1, first bullet point, there's "Authorization servers >> MUST..." >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >> Related: "SHALL"?! in 4.6.3 >> Adding to the concern, there is use of lower-case "must"; note 2nd & >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >> >> Minor Issues: >> >> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >> issued to a web server client." This needs to be clearer... a "Web >> server client" can be a browser or a native app. Do you mean, "the >> refresh tokens issued by the web server to multiple clients?" >> >> 4.1.2 last attack. In the case where a device is cloned, wouldn't >> "Utilize device lock to prevent unauthorized device access" still be a >> countermeasure? In many devices, such cloning would carry along the >> user's device-lock settings. >> >> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. Perhaps this would be obvious to someone who is an >> OAuth2 implementor. >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. If that's not what it >> means, I don't understand what it's saying. If this is true, then the >> second bullet point is probably wrong. >> >> 4.6.6 1st bullet. I'm not convinced that the Cache-Control header >> will *ensure* that a client protects information properly. Should say >> something like "minimize the risk that authenticated content is not >> protected" >> >> 5.* The enumeration, for some but not all of the countermeasures in >> this section, of the threats against which this is a countermeasure, >> reduces readability and, unless it's generated automatically from the >> underlying source, is redundant information, which is unlikely to be >> consistent between sections 4 and 5, and adds difficulty to >> maintenance of this document without adding much value. I'd just wipe >> all these bullet lists out. If it's generated automatically it's less >> damaging, but still reduces readability. In the current draft, this >> is there for some countermeasures but absent for others. Another good >> reason to just take it out. >> >> 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is >> not adequate, but there are ways to do it without SMS. For more, see >> http://android-developers.blogspot.com/2011/03/identifying-app-installations.html >> >> >> 5.3.4 Surely a little more could be said about device lock. On a >> typical modern phone, "device lock" options include PINs, passwords, >> "face recognition" and so on. These are *not* equal in their level of >> security they provide. >> >> Nits: >> >> Formatting is lousy. There are notations, including ** and _whatever_ >> that I'm not familiar with in the RFC context. >> >> Section 1.0: s/in-built into/built into/ >> 2.1, last bullet point: "An example could by a..." s/by/be/ >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >> 2.3, 1st para, s/treat/threat/ >> 2.3.1, last bullet, "per authorization process". Adjectival phrases >> should be hyphenated: "per-authorization process" >> 2.3.3, last bullet, ditto >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >> 3.1, 2nd para, should be ; not , after "within the authorization server" >> s/protected/protect/ >> s/different system/different systems/ >> 3.4 1st para, s/intermediary/intermediate/ >> list item 1. s/short-living/short-lived/ >> 3.5 s/malicious client/malicious clients/ >> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >> I'm not familiar with this in the RFC context. >> 1st bullet point: s/token/token's/ >> 2nd bullet point, multiple issues, 1st sentence should be " the >> initial authorization and issuance of a token by an end-user >> to a particular client, and subsequent requests by this client to >> obtain tokens without user consent (automatic processing of >> repeated >> authorization) >> halfway down page 13, s/insures/ensures/ >> s/validates the clients/validates the client's/ >> 4. first sentence, s/this sections/this section/ >> 4.1.2 first para, the last sentence is confusing. How about: "Before >> enumerating the threats, here are some generally applicable >> countermeasures:" >> 4.2.4 2nd bullet s/could not be/can not be/ >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >> assume that's supposed to be a hyperlink to one of the 5.* sections? >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >> referrer header may contain an Authorization code in a ?a=b style >> argument >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >> rest of doc >> 4.4.1.3 first 2 bullets have un-labeled links. >> 4.4.1.4 1st bullet s/authentication/authenticate/ >> 4.4.1.4 2nd bullet s/mean/means/ >> 4.4.1.7 2nd bullet s/tokens/token's/ >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >> 4.4.1.10, 3rd bullet, s/aibility/ability/ >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >> an IETF-style reference >> 4.4.2 " since HTTP user agents do not send fragments server requests." >> What you mean to say is "Since HTTP user agents do not send the >> fragment part of URIs to HTTP servers." >> 4.4.2.2 s/browser/browser's/ >> 5.1.4.1.3 s/consider to not store/refrain from storing/ >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >> 5.1.6 Needs some sort of sentence structure >> 5.3.2 Needs some sort of sentence structure; or is this intended just >> to be a title, with 5.3.3 etc nested under it? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Jan 26 08:32:53 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E852A21F85A7 for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 08:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFOG3dQVwn-S for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 08:32:53 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 62FD321F858D for <apps-discuss@ietf.org>; Thu, 26 Jan 2012 08:32:53 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5415D40058; Thu, 26 Jan 2012 09:42:41 -0700 (MST) Message-ID: <4F217B2F.8090708@stpeter.im> Date: Thu, 26 Jan 2012 09:11:27 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Zoltan Ordogh <zordogh@rim.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <1DE983233DBBEB4A81F18FABD8208D76226DCA24@XMB107ACNC.rim.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226DCA24@XMB107ACNC.rim.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Jan 2012 16:32:54 -0000 On 1/26/12 7:58 AM, Zoltan Ordogh wrote: > Looks "perfect" to me; I have only one question on section 3, bullet 2: > How would you know that a name is unused? How about this? "SHOULD employ meaningful names that they have reason to believe are currently unused" You can't prove a negative, so that text is more actionable (e.g., you could do a quick Internet search to avoid obvious overlaps). Peter -- Peter Saint-Andre https://stpeter.im/ From zordogh@rim.com Thu Jan 26 09:16:49 2012 Return-Path: <zordogh@rim.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADE21F868C for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 09:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lBHgfybUjOt for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 09:16:49 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id C6DCE21F86A8 for <apps-discuss@ietf.org>; Thu, 26 Jan 2012 09:16:48 -0800 (PST) X-AuditID: 0a412830-b7fc06d00000574a-ac-4f218a765b8b Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 8F.C7.22346.67A812F4; Thu, 26 Jan 2012 17:16:38 +0000 (GMT) Received: from XHT140CNC.rim.net (10.65.12.32) by XHT105CNC.rim.net (10.65.12.216) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 26 Jan 2012 12:16:38 -0500 Received: from XCT107CNC.rim.net (10.65.161.207) by XHT140CNC.rim.net (10.65.12.32) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 26 Jan 2012 12:16:37 -0500 Received: from XMB107ACNC.rim.net ([fe80::f1d2:c1d5:f469:3f83]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.01.0339.001; Thu, 26 Jan 2012 12:16:37 -0500 From: Zoltan Ordogh <zordogh@rim.com> To: Peter Saint-Andre <stpeter@stpeter.im> Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: AQHM2uKSFaojOrhNTUO5G+1S1Yuvn5Yev+GAgABoe4D//7rMkA== Date: Thu, 26 Jan 2012 17:16:36 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D76226DCC52@XMB107ACNC.rim.net> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <1DE983233DBBEB4A81F18FABD8208D76226DCA24@XMB107ACNC.rim.net> <4F217B2F.8090708@stpeter.im> In-Reply-To: <4F217B2F.8090708@stpeter.im> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsXC5chzQ7esS9HfYOctWYsZq4ssVr9cwWZx bE8/swOzx5IlP5k8TjUbeszd84I5gDmqgdEmMS8vvySxJFUhJbU42VbJJzU9MUchoCizLDG5 UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeen ZOal2yp5BvvrWliYWuoaKtnpIoGEf9wZ557eZSy4wV1x4elRxgbGDdxdjBwcEgImEk3LuLoY OYFMMYkL99azdTFycQgJ9DJJvG6dyQySEBJYyijR+T8DIrGcUaL52W6oqm2MEisPP2EFmcQm oCox52osSIOIgJbEpWt97CA2s0CSxOwHj1lBbGEBZ4mtZ/+xQNS4SDw9OpEdwnaSOH3/J5jN AjTm9vf1YDW8Ap4SszdsYoXYBXTEpvsnwAZxAi14duYBmM0oICux++x1Johl4hK3nsxngnhH QGLJnvPMELaoxMvH/1ghbEWJJ42bWUBuZhbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hgXheRuL5 lEvsExglZyHZMAuhexaS7llIuhcwsqxiFMzNKDYwM0zOS9YryszVy0st2cQITj4aBjsYJ+zV OsQowMGoxMMr1K7oL8SaWFZcmXuIUYKDWUmE944XUIg3JbGyKrUoP76oNCe1+BCjBTCAJjJL cSfnAxNjXkm8sYEBCkdJnFdb/Z6fkEA6MK1lp6YWpBbBtDJxcEo1MO6bcClEwjs+TMrIVvxr 6pPwiZ8uB35XbtrbfLJCruz/5s7Kk+F+e89pTmufauU9bbW0pHtUAJ9E+0r33zeETmc/2v2Z xYZJZ4JHuJ7RifP+FuIZq67yC5ls+pQmt9uqkTdCZmnt9KXcN9Jvb3piWSrOLWfosU5GneNt 89LeCtUnofqiiiFvlFiKMxINtZiLihMBZBERHFcDAAA= Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Jan 2012 17:16:49 -0000 SGkgUGV0ZXIsDQpJIHRoaW5rIHRoYXQgaXQgaXMgYmV0dGVyLiBGcmFua2x5LCBJIGFtIG5v dCBzdXJlIHdoYXQgd291bGQgYmUgYSBmb29sLXByb29mIHNvbHV0aW9uIHRvIHRoaXMuDQpJ IGRvIHJlYWxpemUgaG93ZXZlciwgaXQgaGFzIGxpdHRsZSB0byBkbyB3aXRoIHRoZSBYLSBi ZWluZyB0aGVyZSBvciBtaXNzaW5nLi4uDQoNClBTLiBJbnRlcm5ldCBzZWFyY2hlcyBhcmUg bm90IG9ubHkgdW5yZWxpYWJsZSwgYnV0IGFsc28gdGllZCB0byBhIGNlcnRhaW4gInNuYXBz aG90IiBvZiB0aGUgaW50ZXJuZXQgdGFrZW4gYXQgYSBzcGVjaWZpYyBwb2ludCBpbiB0aW1l Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBldGVyIFNhaW50 LUFuZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXQ0KPiBTZW50OiBKYW51YXJ5IDI2 LCAyMDEyIDExOjExIEFNDQo+IFRvOiBab2x0YW4gT3Jkb2doDQo+IENjOiBBbGV4ZXkgTWVs bmlrb3Y7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlz Y3Vzc10gV0dMQyBvbiBkcmFmdC1pZXRmLWFwcHNhd2cteGRhc2gtMDIudHh0DQo+IA0KPiBP biAxLzI2LzEyIDc6NTggQU0sIFpvbHRhbiBPcmRvZ2ggd3JvdGU6DQo+ID4gTG9va3MgInBl cmZlY3QiIHRvIG1lOyBJIGhhdmUgb25seSBvbmUgcXVlc3Rpb24gb24gc2VjdGlvbiAzLCBi dWxsZXQgMjoNCj4gPiBIb3cgd291bGQgeW91IGtub3cgdGhhdCBhIG5hbWUgaXMgdW51c2Vk Pw0KPiANCj4gSG93IGFib3V0IHRoaXM/DQo+IA0KPiAiU0hPVUxEIGVtcGxveSBtZWFuaW5n ZnVsIG5hbWVzIHRoYXQgdGhleSBoYXZlIHJlYXNvbiB0byBiZWxpZXZlIGFyZSBjdXJyZW50 bHkgdW51c2VkIg0KPiANCj4gWW91IGNhbid0IHByb3ZlIGEgbmVnYXRpdmUsIHNvIHRoYXQg dGV4dCBpcyBtb3JlIGFjdGlvbmFibGUgKGUuZy4sIHlvdSBjb3VsZCBkbyBhIHF1aWNrIElu dGVybmV0DQo+IHNlYXJjaCB0byBhdm9pZCBvYnZpb3VzIG92ZXJsYXBzKS4NCj4gDQo+IFBl dGVyDQo+IA0KPiAtLQ0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0ZXIu aW0vDQo+IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1 ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3Rl ZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVn ZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2Yg dGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRy YW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== From stpeter@stpeter.im Thu Jan 26 09:19:45 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C082721F8638 for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 09:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brApI1mJlStq for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 09:19:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA821F862F for <apps-discuss@ietf.org>; Thu, 26 Jan 2012 09:19:41 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0087340058; Thu, 26 Jan 2012 10:29:29 -0700 (MST) Message-ID: <4F218B2E.5010606@stpeter.im> Date: Thu, 26 Jan 2012 10:19:42 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Zoltan Ordogh <zordogh@rim.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <1DE983233DBBEB4A81F18FABD8208D76226DCA24@XMB107ACNC.rim.net> <4F217B2F.8090708@stpeter.im> <1DE983233DBBEB4A81F18FABD8208D76226DCC52@XMB107ACNC.rim.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226DCC52@XMB107ACNC.rim.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 26 Jan 2012 17:19:45 -0000 On 1/26/12 10:16 AM, Zoltan Ordogh wrote: > Hi Peter, I think that it is better. Frankly, I am not sure what > would be a fool-proof solution to this. I'm not fool enough to seek fool-proof solutions. > I do realize however, it has > little to do with the X- being there or missing... > > PS. Internet searches are not only unreliable, but also tied to a > certain "snapshot" of the internet taken at a specific point in > time. Thus the word "currently". :) Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Thu Jan 26 16:59:47 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6721F8707 for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 16:59:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqqU1z+xH55l for <apps-discuss@ietfa.amsl.com>; Thu, 26 Jan 2012 16:59:47 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6E21F8699 for <apps-discuss@ietf.org>; Thu, 26 Jan 2012 16:59:47 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 16:59:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 26 Jan 2012 16:59:46 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Thu, 26 Jan 2012 16:59:44 -0800 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt Thread-Index: AczX9293BkYwwJAkT3+XKhVLEOgcEwEl17XA Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DA04@EXCH-C2.corp.cloudmark.com> References: <F5833273385BB34F99288B3648C4F06F19C89DFAA9@EXCH-C2.corp.cloudmark.com> <20120121044437.94978.qmail@joyce.lan> In-Reply-To: <20120121044437.94978.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 00:59:47 -0000 VGhhbmtzIGZvciB0aGlzLCBKb2huLiAgSSdtIHdvcmtpbmcgdGhlbSBpbnRvIHRoZSBuZXh0IHZl cnNpb24uDQoNCkFtb25nIHRoZSBub3RlcyBJIG1hZGUgZm9yIHBvc3NpYmxlIHRvcGljcywgSSBo YXZlIG9uZSBvdXRzdGFuZGluZyBxdWVzdGlvbjogU2hvdWxkIGEgZ3JleWxpc3RlciByZXR1cm4g YSA0MjEgcmVwbHkgYW5kIGRyb3AgdGhlIGNvbm5lY3Rpb24gd2hlbiBlbmZvcmNpbmcgdGhlIHJ1 bGUsIG9yIHNvbWUgb3RoZXIgNHl6IGNvZGU/ICBPciBkb2VzIGl0IG1hdHRlcj8NCg0KLU1TSw0K From simon@josefsson.org Fri Jan 27 05:45:16 2012 Return-Path: <simon@josefsson.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4061721F852B; Fri, 27 Jan 2012 05:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnMqK5Gv-Ftq; Fri, 27 Jan 2012 05:45:15 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3658921F8528; Fri, 27 Jan 2012 05:45:14 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0RDj7g7004287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Jan 2012 14:45:08 +0100 X-Hashcash: 1:22:120127:apps-discuss@ietf.org::03twXgSwdKYllJqr:0++R X-Hashcash: 1:22:120127:pkix@ietf.org::FGnwcqrqSzNh/F4b:tSN1 From: Simon Josefsson <simon@josefsson.org> To: apps-discuss@ietf.org, pkix@ietf.org References: <20120127133401.25242.24253.idtracker@ietfa.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Mail-Followup-To: apps-discuss@ietf.org X-Hashcash: 1:22:120127:i-d-announce@ietf.org::Dy0Hw68nYXEkYC4i:4+ST X-Hashcash: 1:22:120127:internet-drafts@ietf.org::XvgflzkHMI0cmCUS:DXqv Date: Fri, 27 Jan 2012 14:45:06 +0100 In-Reply-To: <20120127133401.25242.24253.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 27 Jan 2012 05:34:01 -0800") Message-ID: <877h0dcl99.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [apps-discuss] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 13:45:16 -0000 Folks, See announcement below for a document that attempts to describe the de-facto deployed usage of so called "PEM encoding" of X.509 related data blobs, including the '-----BEGIN CERTIFICATE-----' format. Many applications and security libraries rely on these formats, but to my knowledge they have never been standardized and there is unfortunately some confusion and ambiguity as a result. https://tools.ietf.org/html/draft-josefsson-pkix-textual As usual, comments and suggestions are appreciated. I'm not certain what fora is best for discussing the document, but I suspect the apps area group may be an appropriate venue, thus I'm adding an appropriate Mail-Followup-To header. If anyone believes discussion is inappropriate there, I'm happy to move the discussion elsewhere. If someone remembers the history around how the format was created, anecdotal or otherwise, that would also be helpful. Thanks, Simon internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Text Encodings of Some Security Related Structures > Author(s) : Simon Josefsson > Filename : draft-josefsson-pkix-textual-00.txt > Pages : 10 > Date : 2012-01-27 > > This document describe and discuss the text encodings of Public-Key > Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate > Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7 > structures, and Attribute Certificates. The text encodings are well- > known, implemented by several applications and libraries, and is > widely deployed. This document is intended to articulate the de- > facto rules that existing implementations operate by, and to give > recommendations that will promote interoperability going forward. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt From john@jlc.net Fri Jan 27 07:10:49 2012 Return-Path: <john@jlc.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07DD21F85EE for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 07:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.277 X-Spam-Level: X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQI2hE2pMa4G for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 07:10:44 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2121F85ED for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 07:10:42 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5974833C28; Fri, 27 Jan 2012 10:10:27 -0500 (EST) Date: Fri, 27 Jan 2012 10:10:27 -0500 From: John Leslie <john@jlc.net> To: S Moonesamy <sm+ietf@elandsys.com> Message-ID: <20120127151027.GA86451@verdi> References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> <6.2.5.6.2.20120123061715.09faec70@resistor.net> <20120123202634.GC36092@verdi> <6.2.5.6.2.20120123123554.0a88aca8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120123123554.0a88aca8@elandnews.com> User-Agent: Mutt/1.4.1i Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 15:10:49 -0000 S Moonesamy <sm+ietf@elandsys.com> wrote: > > Suggested text for Section 3.2: > > This informative section is to delineate the history of thinking about > Trace fields in mail-related specifications. > > [RFC4408] defines the "Received-SPF:" header field as a Trace field > and specifies that it is added above all other "Received-SPF:" > header fields. > > [RFC6376] specifies that the "DKIM-Signature:" header field is > treated as a Trace field and that it is not be reordered. It > mentions that the header field is prepended to the message. > DomainKeys Identified Mail (DKIM) relies on maintaining the ordering > of header fields as a change of any "DKIM signed" header field can > invalidate the DKIM signature. > > [RFC5451] defines an "Authentication-Results:" header field. It > mentions that the field is to be treated as a Trace field to get an > idea of how far away authentication checks, such as DKIM and Sender > Policy Framework [RFC4408] were done. > > [RFC5518] defines a "VBR-Info:" header field and mentions that a > message can contain multiple occurrences of these header fields. The > document relies on the terminology in [RFC5322] to say that the "VBR- > Info:" header field is a "trace header field". It also specifies > that the header fields is be added at the top of the header > fields. > > [RFC5436] defines an "Auto-Submitted:" header to be added to > notification messages generated by Sieve filtering rules. Section > 2.7.1 says "The "Auto-Submitted:" header field is considered a Trace > field, similar to "Received:" header fields (see [RFC5321])." > > For Section 4: > > The recommendation that trace header fields is to be kept in > blocks is not always followed. Some implementations add any new > header field at the top of the message block without determining > whether it is a Trace field. Works for me. -- John Leslie <john@jlc.net> From turners@ieca.com Fri Jan 27 06:50:16 2012 Return-Path: <turners@ieca.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0321F85BB for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 06:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1qVMWF7Qtt0 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 06:50:16 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.247.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6600721F85B9 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 06:50:16 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id B71FE4B8CFB6B; Fri, 27 Jan 2012 08:50:15 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id AC8E24B8CFB4B for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 08:50:15 -0600 (CST) Received: from [96.231.118.153] (port=42916 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <turners@ieca.com>) id 1Rqn83-0007w4-5L for apps-discuss@ietf.org; Fri, 27 Jan 2012 08:50:15 -0600 Message-ID: <4F22B9A6.1070303@ieca.com> Date: Fri, 27 Jan 2012 09:50:14 -0500 From: Sean Turner <turners@ieca.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120127133401.25242.24253.idtracker@ietfa.amsl.com> <877h0dcl99.fsf@latte.josefsson.org> In-Reply-To: <877h0dcl99.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-118-153.washdc.east.verizon.net (thunderfish.local) [96.231.118.153]:42916 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= X-Mailman-Approved-At: Fri, 27 Jan 2012 08:03:10 -0800 Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 14:50:17 -0000 Simon, The same kind of format is also used for keys: https://datatracker.ietf.org/doc/rfc5915/ https://datatracker.ietf.org/doc/rfc5958/ Is it worth pointing to the media types for the objects? If you're going to reference RFC 4648, then you need to specify which alphabet (the apps guys are always pointing this out). spt On 1/27/12 8:45 AM, Simon Josefsson wrote: > Folks, > > See announcement below for a document that attempts to describe the > de-facto deployed usage of so called "PEM encoding" of X.509 related > data blobs, including the '-----BEGIN CERTIFICATE-----' format. Many > applications and security libraries rely on these formats, but to my > knowledge they have never been standardized and there is unfortunately > some confusion and ambiguity as a result. > > https://tools.ietf.org/html/draft-josefsson-pkix-textual > > As usual, comments and suggestions are appreciated. I'm not certain > what fora is best for discussing the document, but I suspect the apps > area group may be an appropriate venue, thus I'm adding an appropriate > Mail-Followup-To header. If anyone believes discussion is inappropriate > there, I'm happy to move the discussion elsewhere. > > If someone remembers the history around how the format was created, > anecdotal or otherwise, that would also be helpful. > > Thanks, > Simon > > internet-drafts@ietf.org writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Text Encodings of Some Security Related Structures >> Author(s) : Simon Josefsson >> Filename : draft-josefsson-pkix-textual-00.txt >> Pages : 10 >> Date : 2012-01-27 >> >> This document describe and discuss the text encodings of Public-Key >> Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate >> Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7 >> structures, and Attribute Certificates. The text encodings are well- >> known, implemented by several applications and libraries, and is >> widely deployed. This document is intended to articulate the de- >> facto rules that existing implementations operate by, and to give >> recommendations that will promote interoperability going forward. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-josefsson-pkix-textual-00.txt > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From ietfc@btconnect.com Fri Jan 27 09:09:05 2012 Return-Path: <ietfc@btconnect.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66621F85BD for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBYkYz17jmYt for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:09:04 -0800 (PST) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4521F85C5 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 09:09:03 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr08.btconnect.com with SMTP id FZA05293; Fri, 27 Jan 2012 17:08:55 +0000 (GMT) Message-ID: <00ea01ccdd0e$08d59f00$4001a8c0@gateway.2wire.net> From: "t.petch" <ietfc@btconnect.com> To: "Murray S. Kucherawy" <msk@cloudmark.com>, <apps-discuss@ietf.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org><010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> Date: Fri, 27 Jan 2012 17:08:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F22DA27.0002, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.27.161222:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4F22DA27.00C6,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 17:09:05 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" <msk@cloudmark.com> To: <apps-discuss@ietf.org> Sent: Wednesday, January 25, 2012 8:43 PM > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of t.petch > > Sent: Wednesday, January 25, 2012 1:24 AM > > To: Paul Hoffman; Alexey Melnikov > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt > > > > And, to be expected really, this I-D fails to consider migration; what > > is going to happen now to those 15 X- headers and all the others that > > are in other e-mails? Where is your migration plan? > > I think it's there in plain sight: Drop the "X-" and register them. > > I think it's also clear that this can't affect deployed software that actually looks for "X-" fields, but rather encourages new implementations of things to avoid this practice. Seems perfectly reasonable to me. > > If the document doesn't already say something like that, I agree that it would be a useful thing to say. I do not see it in the I-D, about what, if anything, this I-D expects to change with the parameters currently in use. The sort of parameters I have in mind are those that appear in the header of the e-mail you originated, such as X-BigFish: X-Forefront-Antispam-Report: X-Original-To: X-Virus-Scanned: X-SpamScore: X-Spam-Flag: X-Spam-Score: X-Spam-Level: X-Spam-Status: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-BeenThere: X-Mailman-Version: X-FOPE-CRA-Verdict: As far as I know, none of them make any difference to what I experience as a mail user and I would be just as happy if a passing MTA stripped them all out - which with X- it might consider doing, whereas without, it could not take the risk. In fact, I would love to see them stripped out, reducing the amount of data I download and store:-) Tom Petch > > And what about all the other private portions of namespaces that are > > designated with something other than X-? Will you produce an edict > > prohibiting them as well? > > The abstract says that this "causes more problems than it solves." Do you envision some other solution to those problems? > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From dhc@dcrocker.net Fri Jan 27 09:33:22 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F314A21F85AF for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.621 X-Spam-Level: X-Spam-Status: No, score=-5.621 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_05=-1.11, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmKkFI4+kF4J for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:33:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1921F859E for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 09:33:21 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RHXEwd011057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 09:33:19 -0800 Message-ID: <4F22DFD4.2030403@dcrocker.net> Date: Fri, 27 Jan 2012 09:33:08 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "t.petch" <ietfc@btconnect.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org><010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> <00ea01ccdd0e$08d59f00$4001a8c0@gateway.2wire.net> In-Reply-To: <00ea01ccdd0e$08d59f00$4001a8c0@gateway.2wire.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]); Fri, 27 Jan 2012 09:33:19 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 17:33:22 -0000 On 1/27/2012 8:08 AM, t.petch wrote: > I do not see it in the I-D, about what, if anything, this I-D expects to change > with the parameters currently in use. If you think that's a problem, please explain why and offer some text to cover it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Jan 27 09:44:01 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6751621F85FD for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WclHwROVaCAP for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 09:44:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C321F85D1 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 09:44:01 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 09:44:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 27 Jan 2012 09:44:00 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Fri, 27 Jan 2012 09:43:59 -0800 Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: AczdFl7tS0SAUi87S0y+H2+AnqzfsQABNJ3Q Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DA11@EXCH-C2.corp.cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><FAD2FBBB-E679-4867-81E6-3F1C472BCF04@vpnc.org><010501ccdb43$16dd5ec0$4001a8c0@gateway.2wire.net> <F5833273385BB34F99288B3648C4F06F19C9A7D99E@EXCH-C2.corp.cloudmark.com> <00ea01ccdd0e$08d59f00$4001a8c0@gateway.2wire.net> In-Reply-To: <00ea01ccdd0e$08d59f00$4001a8c0@gateway.2wire.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 17:44:01 -0000 > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, January 27, 2012 8:09 AM > To: Murray S. Kucherawy; apps-discuss@ietf.org > Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt >=20 > I do not see it in the I-D, about what, if anything, this I-D expects > to change with the parameters currently in use. The sort of parameters > I have in mind are those that appear in the header of the e-mail you > originated, such as > [...] I think Peter responded to this point a couple of days ago. From paul.hoffman@vpnc.org Fri Jan 27 10:13:35 2012 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B24A21F863F for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNd67ZEPP-kJ for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:13:35 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE021F864E for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:13:35 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RIDW1u053822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 11:13:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman <paul.hoffman@vpnc.org> In-Reply-To: <4F1F1A72.1090302@isode.com> Date: Fri, 27 Jan 2012 10:13:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> To: Alexey Melnikov <alexey.melnikov@isode.com> X-Mailer: Apple Mail (2.1251.1) Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:13:35 -0000 After discussing this a bit more with Pete Resnick off-line, we found a = place where I missed a major assumption: this draft is only about = parameter names, not numbers. Pete believes that this changes things = hugely, but I am less sure. Regardless, we agreed it needs to be = clarified. Proposed text to be added after the second paragraph of Section 1: Note that this document only discusses parameters with text names; it = does not discuss parameters that are expressed with numbers. The = difference between these two is that text names of parameters (for = example, "hash-type" and "x-hash-type") tend to appear in administrative = and user interfaces much more often than numbers that identify = parameters (for example, 7 or 0xa007). The misuse of parameters with = text names and with numbers are similar; developers will try to get = experimental parameters standardized without changing the parameter = value, developers mis-use unassigned values without going through the = defined registration procedure, and so on. However, the more likely = exposure to administrators and users limits the focus of this document = only to named parameters. --Paul Hoffman From paul.hoffman@vpnc.org Fri Jan 27 10:20:50 2012 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2421F867D; Fri, 27 Jan 2012 10:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrlyerkvEQfu; Fri, 27 Jan 2012 10:20:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE621F8647; Fri, 27 Jan 2012 10:20:45 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RIKhO7054128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 11:20:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman <paul.hoffman@vpnc.org> In-Reply-To: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp> Date: Fri, 27 Jan 2012 10:20:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org> References: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp> To: Simon Josefsson <simon@josefsson.org> X-Mailer: Apple Mail (2.1251.1) Cc: PKIX <pkix@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:20:50 -0000 On Jan 27, 2012, at 10:11 AM, Martin Rex wrote: > the Label that is used within '-----BEGIN <some-label>----' > should be ignored on the receiver side, and all implemented formats > should be tried, that are applicable for the requested operation. This would cause things like private keys and public keys to be mixed = up. I propose this is not a good idea from a security perspective. = Instead, Simon might add some text saying that some applications = sometimes ignore the label in order to be more liberal, but in doing so = can cause problems with systems that assume those labels are important. >=20 > Normally, these PEM-framed base64 encodings are used for = administrative > interfaces used by humans that are used with a low frequency, > rather for authentication exchanges that are used with a high > frequency. For administrative user interfaces it is usually sensible = to > spend a few extra CPU cycles to improve the usability. >=20 > Strongly recommeding standardized labelling on output of these formats > is OK, and may facilitate troubleshooting. >=20 > But on input, e.g. when processing a certification response, the > administrative interface should IMO be tolerant to accept a single > certificate (provided the remaining certs required to build a > complete path are already present), accept a sequence of several > certificates, or a PKCS#7 container carry multiple certificates, > independent of what labels are used with BEGIN/END. These are all separate issues, but definitely worthy of discussion in = the document. "Some systems will accept multiple certificates in a = single text block, while others will reject the entire text block as = malformed if more than one certificate is included." > When the administrative interface has access to the PKI credentials > for which a certification response is to be processed, then it > can detect the end-entity cert automatically, compose the full > and correctly ordererd certificate chain automatically, and ignore > any superfluous/unrelated certs that may have been part of the input. >=20 >=20 > Btw. PKCS#7 can also be used as a carry bag for multiple CRLs, > which can be used to allow revocation checking in offline > scenarios or on isolated networks. Indeed. Just a thought: we define *new* labels that do what we think everyone = should do, such as multiple items in the block. There would not be much = uptake on those new labels in the short run, but could become the = standard 20 years from now. --Paul Hoffman From stpeter@stpeter.im Fri Jan 27 10:34:37 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033D21F85C5 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYsQINEF53NL for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:34:36 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9E87C21F8526 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:34:36 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA62040058; Fri, 27 Jan 2012 11:44:27 -0700 (MST) Message-ID: <4F22EE3A.9010801@stpeter.im> Date: Fri, 27 Jan 2012 11:34:34 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Hoffman <paul.hoffman@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> In-Reply-To: <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:34:37 -0000 On 1/27/12 11:13 AM, Paul Hoffman wrote: > After discussing this a bit more with Pete Resnick off-line, we found > a place where I missed a major assumption: this draft is only about > parameter names, not numbers. Pete believes that this changes things > hugely, but I am less sure. Regardless, we agreed it needs to be > clarified. That's been implicit in the document, but I agree that we need to make it explicit. > Proposed text to be added after the second paragraph of Section 1: > > Note that this document only discusses parameters with text names; it > does not discuss parameters that are expressed with numbers. The > difference between these two is that text names of parameters (for > example, "hash-type" and "x-hash-type") tend to appear in > administrative and user interfaces much more often than numbers that > identify parameters (for example, 7 or 0xa007). The misuse of > parameters with text names and with numbers are similar; developers > will try to get experimental parameters standardized without changing > the parameter value, developers mis-use unassigned values without > going through the defined registration procedure, and so on. However, > the more likely exposure to administrators and users limits the focus > of this document only to named parameters. Proposed text is always appreciated. :) It's not clear to me what function the third sentence serves; we don't talk elsewhere about the misuse of parameters. With some editing, I suggest: Because textual names of parameters (e.g., "hash-type" and "x-hash-type") tend to appear in administrative and user interfaces much more often than numbers that identify parameters (e.g., 7 or 0xa007), this document discusses only parameters with textual names, not parameters that are expressed with numbers. Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Fri Jan 27 10:40:24 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539E021F85FB for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7ED+puYsNJo for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:40:23 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2F9F21F85F0 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:40:23 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RIeHxB012841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 10:40:22 -0800 Message-ID: <4F22EF8B.9000509@dcrocker.net> Date: Fri, 27 Jan 2012 10:40:11 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Saint-Andre <stpeter@stpeter.im> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> In-Reply-To: <4F22EE3A.9010801@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 27 Jan 2012 10:40:23 -0800 (PST) Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:40:24 -0000 On 1/27/2012 10:34 AM, Peter Saint-Andre wrote: > Proposed text is always appreciated.:) > > It's not clear to me what function the third sentence serves; we don't > talk elsewhere about the misuse of parameters. With some editing, I suggest: > > Because textual names of parameters (e.g., "hash-type" and > "x-hash-type") tend to appear in administrative and user interfaces much > more often than numbers that identify parameters (e.g., 7 or 0xa007), > this document discusses only parameters with textual names, not > parameters that are expressed with numbers. In fact I'm unclear about what problem the added text solves. It seems to focus on issues that are out of scope for the draft. At best, an aid to the reader to understand that scope seems sufficient, along the lines of Paul's prefatory sentence: The specification only cover parameter names, not numbers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Fri Jan 27 10:41:21 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739F021F8604 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJehmVDCsgjA for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:41:21 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 03A4A21F85FB for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:41:21 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7D85040058; Fri, 27 Jan 2012 11:51:12 -0700 (MST) Message-ID: <4F22EFCF.3050607@stpeter.im> Date: Fri, 27 Jan 2012 11:41:19 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> In-Reply-To: <4F22EF8B.9000509@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:41:21 -0000 On 1/27/12 11:40 AM, Dave CROCKER wrote: > > > On 1/27/2012 10:34 AM, Peter Saint-Andre wrote: >> Proposed text is always appreciated.:) >> >> It's not clear to me what function the third sentence serves; we don't >> talk elsewhere about the misuse of parameters. With some editing, I >> suggest: >> >> Because textual names of parameters (e.g., "hash-type" and >> "x-hash-type") tend to appear in administrative and user interfaces much >> more often than numbers that identify parameters (e.g., 7 or 0xa007), >> this document discusses only parameters with textual names, not >> parameters that are expressed with numbers. > > > In fact I'm unclear about what problem the added text solves. It seems > to focus on issues that are out of scope for the draft. > > At best, an aid to the reader to understand that scope seems sufficient, > along the lines of Paul's prefatory sentence: > > The specification only cover parameter names, not numbers. Brevity is good. From stpeter@stpeter.im Fri Jan 27 10:44:31 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DE021F8618 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEqnFN8btRgg for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:44:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D48EE21F8604 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:44:30 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5689E4005B; Fri, 27 Jan 2012 11:54:22 -0700 (MST) Message-ID: <4F22F08D.4060902@stpeter.im> Date: Fri, 27 Jan 2012 11:44:29 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> In-Reply-To: <4F22EFCF.3050607@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:44:31 -0000 On 1/27/12 11:41 AM, Peter Saint-Andre wrote: > On 1/27/12 11:40 AM, Dave CROCKER wrote: >> >> >> On 1/27/2012 10:34 AM, Peter Saint-Andre wrote: >>> Proposed text is always appreciated.:) >>> >>> It's not clear to me what function the third sentence serves; we don't >>> talk elsewhere about the misuse of parameters. With some editing, I >>> suggest: >>> >>> Because textual names of parameters (e.g., "hash-type" and >>> "x-hash-type") tend to appear in administrative and user interfaces much >>> more often than numbers that identify parameters (e.g., 7 or 0xa007), >>> this document discusses only parameters with textual names, not >>> parameters that are expressed with numbers. >> >> >> In fact I'm unclear about what problem the added text solves. It seems >> to focus on issues that are out of scope for the draft. >> >> At best, an aid to the reader to understand that scope seems sufficient, >> along the lines of Paul's prefatory sentence: >> >> The specification only cover parameter names, not numbers. > > Brevity is good. I suggest slightly modifying the second paragraph of the introduction: Although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standard parameters and non-standard parameters, in practice the benefits have been outweighed by the costs associated with the leakage of non-standard parameters into the standards space. Therefore this document deprecates the "X-" convention for named parameters in application protocols and makes specific recommendations about how to proceed in a world without the distinction between standard and non-standard parameters. Note that this document covers named parameters only, not numbers. /psa From paul.hoffman@vpnc.org Fri Jan 27 10:47:30 2012 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E84821F84AA for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfUgzKeL-xxT for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 10:47:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2453321F84A3 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 10:47:30 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RIlR0S068323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 11:47:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman <paul.hoffman@vpnc.org> In-Reply-To: <4F22EFCF.3050607@stpeter.im> Date: Fri, 27 Jan 2012 10:47:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2033EA-73C5-432B-BAFB-D2B796B04582@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> To: Peter Saint-Andre <stpeter@stpeter.im> X-Mailer: Apple Mail (2.1251.1) Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:47:30 -0000 On Jan 27, 2012, at 10:41 AM, Peter Saint-Andre wrote: > On 1/27/12 11:40 AM, Dave CROCKER wrote: >>=20 >>=20 >> On 1/27/2012 10:34 AM, Peter Saint-Andre wrote: >>> Proposed text is always appreciated.:) >>>=20 >>> It's not clear to me what function the third sentence serves; we = don't >>> talk elsewhere about the misuse of parameters. With some editing, I >>> suggest: >>>=20 >>> Because textual names of parameters (e.g., "hash-type" and >>> "x-hash-type") tend to appear in administrative and user interfaces = much >>> more often than numbers that identify parameters (e.g., 7 or = 0xa007), >>> this document discusses only parameters with textual names, not >>> parameters that are expressed with numbers. >>=20 >>=20 >> In fact I'm unclear about what problem the added text solves. It = seems >> to focus on issues that are out of scope for the draft. >>=20 >> At best, an aid to the reader to understand that scope seems = sufficient, >> along the lines of Paul's prefatory sentence: >>=20 >> The specification only cover parameter names, not numbers. >=20 > Brevity is good. ...except when it excludes the reasoning for the text. As you say before, the document doesn't directly address the misuse of = parameters, although it hints at it. If you think only hinting is useful = (I don't), then not even hinting at why the document only covers names = is probably fine. I really think you are undershooting here. --Paul Hoffman From dhc@dcrocker.net Fri Jan 27 11:02:49 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2663321F8512 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 11:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvvsRnZAvK8a for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 11:02:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16B21F850F for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 11:02:48 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RJ2g0P013385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 11:02:48 -0800 Message-ID: <4F22F4CD.5020508@dcrocker.net> Date: Fri, 27 Jan 2012 11:02:37 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Hoffman <paul.hoffman@vpnc.org> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> <3D2033EA-73C5-432B-BAFB-D2B796B04582@vpnc.org> In-Reply-To: <3D2033EA-73C5-432B-BAFB-D2B796B04582@vpnc.org> 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, 27 Jan 2012 11:02:48 -0800 (PST) Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 19:02:49 -0000 On 1/27/2012 10:47 AM, Paul Hoffman wrote: > On Jan 27, 2012, at 10:41 AM, Peter Saint-Andre wrote: >>> The specification only cover parameter names, not numbers. >> >> Brevity is good. > > ...except when it excludes the reasoning for the text. This appears to be a different concern than the one you've offered text for. What 'reasoning' is missing and what text do you suggest for remedying it? > As you say before, the document doesn't directly address the misuse of > parameters, although it hints at it. If you think only hinting is useful (I > don't), then not even hinting at why the document only covers names is > probably fine. Whereas I believe this document has nothing at all to do with "abuse" or "misuse" and doesn't hint or pretend otherwise. It has to do with a well-intentioned convention that has been used reasonably but has proved counter-productive. > I really think you are undershooting here. And since I think your are significantly overshooting, do we cancel each other out? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mrex@sap.com Fri Jan 27 10:11:25 2012 Return-Path: <mrex@sap.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBFD21F866E; Fri, 27 Jan 2012 10:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.943 X-Spam-Level: X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTlwWshBA1mC; Fri, 27 Jan 2012 10:11:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CC6A621F8655; Fri, 27 Jan 2012 10:11:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0RIB65p020677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Jan 2012 19:11:06 +0100 (MET) From: Martin Rex <mrex@sap.com> Message-Id: <201201271811.q0RIB5Wu012578@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Fri, 27 Jan 2012 19:11:05 +0100 (MET) In-Reply-To: <877h0dcl99.fsf@latte.josefsson.org> from "Simon Josefsson" at Jan 27, 12 02:45:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Mailman-Approved-At: Fri, 27 Jan 2012 11:09:59 -0800 Cc: pkix@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 18:11:25 -0000 Simon, Simon Josefsson wrote: > > See announcement below for a document that attempts to describe the > de-facto deployed usage of so called "PEM encoding" of X.509 related > data blobs, including the '-----BEGIN CERTIFICATE-----' format. Many > applications and security libraries rely on these formats, but to my > knowledge they have never been standardized and there is unfortunately > some confusion and ambiguity as a result. > > https://tools.ietf.org/html/draft-josefsson-pkix-textual the Label that is used within '-----BEGIN <some-label>----' should be ignored on the receiver side, and all implemented formats should be tried, that are applicable for the requested operation. Normally, these PEM-framed base64 encodings are used for administrative interfaces used by humans that are used with a low frequency, rather for authentication exchanges that are used with a high frequency. For administrative user interfaces it is usually sensible to spend a few extra CPU cycles to improve the usability. Strongly recommeding standardized labelling on output of these formats is OK, and may facilitate troubleshooting. But on input, e.g. when processing a certification response, the administrative interface should IMO be tolerant to accept a single certificate (provided the remaining certs required to build a complete path are already present), accept a sequence of several certificates, or a PKCS#7 container carry multiple certificates, independent of what labels are used with BEGIN/END. When the administrative interface has access to the PKI credentials for which a certification response is to be processed, then it can detect the end-entity cert automatically, compose the full and correctly ordererd certificate chain automatically, and ignore any superfluous/unrelated certs that may have been part of the input. Btw. PKCS#7 can also be used as a carry bag for multiple CRLs, which can be used to allow revocation checking in offline scenarios or on isolated networks. -Martin From dhc@dcrocker.net Fri Jan 27 11:48:59 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC63A21F862B for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 11:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlEDFL3+rBxg for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 11:48:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD021F85F3 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 11:48:59 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RJmr2W014544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 11:48:58 -0800 Message-ID: <4F22FF9F.5040304@dcrocker.net> Date: Fri, 27 Jan 2012 11:48:47 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Saint-Andre <stpeter@stpeter.im> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> In-Reply-To: <4F22F08D.4060902@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 27 Jan 2012 11:48:59 -0800 (PST) Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 19:48:59 -0000 On 1/27/2012 10:44 AM, Peter Saint-Andre wrote: >> The specification only cover parameter names, not numbers. >> >> Brevity is good. Usually. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Jan 27 13:04:25 2012 Return-Path: <msk@cloudmark.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C78621F8631 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 13:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t3CryoLJ4ud for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 13:04:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 691D921F8617 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 13:04:24 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 13:04:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 27 Jan 2012 13:04:23 -0800 From: "Murray S. Kucherawy" <msk@cloudmark.com> To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Date: Fri, 27 Jan 2012 13:04:22 -0800 Thread-Topic: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt Thread-Index: AczdLLgPHzrtg7EURfynG2o/xv5TNwACnz/A Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DA23@EXCH-C2.corp.cloudmark.com> References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> In-Reply-To: <4F22FF9F.5040304@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 21:04:25 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Dave CROCKER > Sent: Friday, January 27, 2012 11:49 AM > To: Peter Saint-Andre > Cc: Paul Hoffman; apps-discuss@ietf.org > Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt >=20 > On 1/27/2012 10:44 AM, Peter Saint-Andre wrote: > >> The specification only cover parameter names, not numbers. > >> > >> Brevity is good. >=20 > Usually. +1 From dhc@dcrocker.net Fri Jan 27 13:30:54 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6955121F86A8 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 13:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keWy7waICLB6 for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 13:30:53 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D821F86A5 for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 13:30:53 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RLUmhN017509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 13:30:53 -0800 Message-ID: <4F231782.3000808@dcrocker.net> Date: Fri, 27 Jan 2012 13:30:42 -0800 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com> <6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org> <4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net> <4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> <F5833273385BB34F99288B3648C4F06F19C9A7DA23@EXCH-C2.corp.cloudmark.com> In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C9A7DA23@EXCH-C2.corp.cloudmark.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]); Fri, 27 Jan 2012 13:30:53 -0800 (PST) Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 21:30:54 -0000 >>>> Brevity is good. >> >> Usually. > > +1 ! d/ ps. full disclosure: that was murray's idea. -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Fri Jan 27 14:16:12 2012 Return-Path: <internet-drafts@ietf.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910EB21F86A8; Fri, 27 Jan 2012 14:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYaGvJgg8qn6; Fri, 27 Jan 2012 14:16:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D0621F8633; Fri, 27 Jan 2012 14:16:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127221612.3744.13276.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 14:16:12 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 27 Jan 2012 22:16:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-00.txt Pages : 12 Date : 2012-01-27 This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g. the originating IP number of a request or IP number of the proxy on the incoming side. Given a trusted path of proxying components, each subsequent component will have access to all IP numbers used in the chain of proxied HTTP requests. This document also standardizes ways for a proxy administrator to anonymize the origin of a request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-00.txt From mrex@sap.com Fri Jan 27 16:37:48 2012 Return-Path: <mrex@sap.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DA521F850F; Fri, 27 Jan 2012 16:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjJjNP1dXi2m; Fri, 27 Jan 2012 16:37:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A759421F84C9; Fri, 27 Jan 2012 16:37:47 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0S0bkw5004367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jan 2012 01:37:46 +0100 (MET) From: Martin Rex <mrex@sap.com> Message-Id: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Sat, 28 Jan 2012 01:37:45 +0100 (MET) In-Reply-To: <028B4903-E2C7-41BA-9C9A-B416A41C4E8F@vpnc.org> from "Paul Hoffman" at Jan 27, 12 10:20:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: simon@josefsson.org, apps-discuss@ietf.org, pkix@ietf.org Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Jan 2012 00:37:48 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > the Label that is used within '-----BEGIN <some-label>----' > > should be ignored on the receiver side, and all implemented formats > > should be tried, that are applicable for the requested operation. > > This would cause things like private keys and public keys to be mixed up. Not necessarily. If your ASN.1 decoder can not distinguish your private from your public key, then you have a whole different kind of problem. > > I propose this is not a good idea from a security perspective. Huh? That textual label is not integrity protected in any way, so how should this be a security problem? This is really only about convenience for admins. > > Instead, Simon might add some text saying that some applications > sometimes ignore the label in order to be more liberal, but in doing > so can cause problems with systems that assume those labels are important. HUH? How could being liberal on *INPUT* possibly cause problems? Any reasonable ASN.1 decoder can reliably tell apart - X.509 certificates - private keys - encrypted private keys - pkcs10 requests - crls - pkcs7/cms - pkcs7/cms as certificate bag - pkcs7/cms as crl bag - pkcs12 So any implementation that is ignoring the explicit label, will have to use the implicit label from successfuly ASN.1 decode of the types of objects that are applicable for the requested operation. Microsoft seems to ignore the label. If you double-click on a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent of what label is used. Same for certificate (.cer). I find it much more confusing when only a few, but non-unique labels are accepted: OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE" and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE" > > Just a thought: we define *new* labels that do what we think everyone > should do, such as multiple items in the block. There would not be much > uptake on those new labels in the short run, but could become the > standard 20 years from now. For OUTPUT we should try to find an reuse the most commonly used label, because the installed base is going to be with us another 10+ years. -Martin From paul.hoffman@vpnc.org Fri Jan 27 20:29:30 2012 Return-Path: <paul.hoffman@vpnc.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BC621F8508; Fri, 27 Jan 2012 20:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a--o+5S0Gyju; Fri, 27 Jan 2012 20:29:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA4A21F84FF; Fri, 27 Jan 2012 20:29:30 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0S4TRt7084777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jan 2012 21:29:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman <paul.hoffman@vpnc.org> In-Reply-To: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp> Date: Fri, 27 Jan 2012 20:29:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A5293F6-83A7-48CB-BAA6-FF85F0D6A903@vpnc.org> References: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: simon@josefsson.org, apps-discuss@ietf.org, pkix@ietf.org Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Jan 2012 04:29:30 -0000 On Jan 27, 2012, at 4:37 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> Martin Rex wrote: >>>=20 >>> the Label that is used within '-----BEGIN <some-label>----' >>> should be ignored on the receiver side, and all implemented formats >>> should be tried, that are applicable for the requested operation. >>=20 >> This would cause things like private keys and public keys to be mixed = up. >=20 > Not necessarily. If your ASN.1 decoder can not distinguish your = private > from your public key, then you have a whole different kind of problem. Indeed, but it is a new problem that you probably didn't plan for. There = is no need to introduce the problem at this late date. >> I propose this is not a good idea from a security perspective. >=20 > Huh? That textual label is not integrity protected in any way, > so how should this be a security problem? These blobs are often handed around out-of-band, so removing a bit of = information can indeed introduce a security problem. > This is really only about convenience for admins. That's one view, but not the only one. >> Instead, Simon might add some text saying that some applications >> sometimes ignore the label in order to be more liberal, but in doing >> so can cause problems with systems that assume those labels are = important. >=20 > HUH? How could being liberal on *INPUT* possibly cause problems? >=20 > Any reasonable ASN.1 decoder can reliably tell apart > - X.509 certificates > - private keys > - encrypted private keys > - pkcs10 requests > - crls > - pkcs7/cms=20 > - pkcs7/cms as certificate bag > - pkcs7/cms as crl bag > - pkcs12 >=20 > So any implementation that is ignoring the explicit label, will have = to > use the implicit label from successfuly ASN.1 decode of the types > of objects that are applicable for the requested operation. You are assuming, I believe incorrectly, that the ASN.1 decoding is = happening in the same part of the system as the base64 decoding. That's = not a safe assumption. In your code, it might be fine; it is probably = not fine in all code. Why throw away valuable information? > Microsoft seems to ignore the label. If you double-click on > a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded = independent > of what label is used. Same for certificate (.cer). Um, so? That's one implementation. > I find it much more confusing when only a few, but non-unique labels > are accepted: > OpenSSL seems to accept certs with "X509 CERTIFICATE" and = "CERTIFICATE" > and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE" Fully agree. That's why it is good that someone (Simon!) is doing this = work. >> Just a thought: we define *new* labels that do what we think everyone >> should do, such as multiple items in the block. There would not be = much >> uptake on those new labels in the short run, but could become the >> standard 20 years from now. >=20 > For OUTPUT we should try to find an reuse the most commonly used = label, > because the installed base is going to be with us another 10+ years. You and I live in different universes. --Paul Hoffman From yaojk@cnnic.cn Sat Jan 28 02:22:11 2012 Return-Path: <yaojk@cnnic.cn> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E674721F846E for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 02:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.596 X-Spam-Level: X-Spam-Status: No, score=-98.596 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2bPx-uKvdLZ for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 02:22:11 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 9C01E21F853A for <apps-discuss@ietf.org>; Sat, 28 Jan 2012 02:22:07 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 28 Jan 2012 18:22:05 +0800 Message-ID: <662D4412BFDE422285267DB54B3313E9@LENOVO47E041CF> From: "Jiankang YAO" <yaojk@cnnic.cn> To: <apps-discuss@ietf.org>, <john_brzozowski@cable.comcast.com>, <jf@jftremblay.com>, <jack.chen@twcable.com>, <tomasz.mrugalski@gmail.com> Date: Sat, 28 Jan 2012 18:21:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-dhc-dhcpv6-redundancy-consider-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Jan 2012 10:22:12 -0000 SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl IHJldmlld2VyIA0KZm9yIHRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs ZWFzZSANCnNlZSANCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lr aS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgDQopLiAgDQpQbGVhc2UgcmVzb2x2ZSB0aGVz ZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBjb21tZW50cyANCnlvdSBtYXkgcmVjZWl2 ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQpzaGVwaGVy ZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1yZWR1bmRhbmN5LWNvbnNpZGVyLTAyDQoNClRp dGxlOiANCkRIQ1B2NiBSZWR1bmRhbmN5IERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNCg0KUmV2 aWV3ZXI6IEppYW5rYW5nIFlhbw0KUmV2aWV3IERhdGU6IEphbiAyOCwgMjAxMg0KDQpTdW1tYXJ5 Og0KDQpUaGlzIGRyYWZ0IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBCQ1Au IEJ1dCBiZWZvcmUgcHVibGljYXRpb24sIHRoZSBmb2xsb3dpbmcgDQppc3N1ZXMgc2hvdWxkIGJl IGNvbnNpZGVyZWQgb3IgYWRkcmVzc2VkLg0KDQpNYWpvciBpc3N1ZToNCg0KMSkgVGhlIGRpc3Rp bmN0aW9uIGJldHdlZW4gZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSBwcm92aWRlciBtb2RlbCBh bmQgZGVmaW5pdGlvbiBvZiB0aGUgZW50ZXJwcmlzZSBtb2RlbCBhcmUgbm90IHZlcnkgY2xlYXIu DQoNCnNlY3Rpb24gMi4xIFNlcnZpY2UgcHJvdmlkZXIgbW9kZWwgc2FpZCANCiINCiAgIFRoZSBz ZXJ2aWNlIHByb3ZpZGVyIG1vZGVsIHJlcHJlc2VudHMgY2FzZXMsIHdoZXJlIGVuZC11c2VyIGRl dmljZXMNCiAgIG1heSBiZSBjb25maWd1cmVkIGRpcmVjdGx5LCB3aXRob3V0IGFueSBpbnRlcm1l ZGlhdGUgZGV2aWNlcyAobGlrZQ0KICAgaG9tZSByb3V0ZXJzIHVzZWQgaW4gc2VydmljZSBwcm92 aWRlciBtb2RlbCkuIA0KIg0Kc2VjdGlvbiAyLjEgRW50ZXJwcmlzZSBtb2RlbCBzYWlkICANCiAg ICJUaGUgZW50ZXJwcmlzZSBtb2RlbCByZXByZXNlbnRzIGNhc2VzIHdoZXJlIGVuZC11c2VyIGRl dmljZXMgYXJlIG1vc3QNCiAgIG9mdGVuIGNvbmZpZ3VyZWQgZGlyZWN0bHkgd2l0aG91dCBhbnkg aW50ZXJtZWRpYXRlIGRldmljZXMgKGxpa2UgaG9tZQ0KICAgcm91dGVycyB1c2VkIGluIHNlcnZp Y2UgcHJvdmlkZXIgbW9kZWwpLiANCiINClRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdv IGRpZmluaXRpb25zIGFyZSAibWF5IGJlIGNvbmZpZ3VyZWQiIGFuZCAib2Z0ZW4gY29uZmlndXJl ZCIuDQoNCkFjY29yZGluZyB0byB0aGUgY3VycmVudCBkZWZpbml0aW9uICJtYXkgYmUgY29uZmln dXJlZCIgYW5kICJvZnRlbiBjb25maWd1cmVkIg0KLCB0aGUgcmVhZGVyIGNhbiBub3QgZWFzaWx5 IGp1ZGdlICJ3aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG1vZGVsIGlzIiBvciAid2hhdCB0aGUg ZW50ZXJwcmlzZSBtb2RlbCBpcyIuDQoNCkFub3RoZXIgcHJvYmxlbSBmb3IgdGhlIGRlZmluaXRp b24gb2YgU2VydmljZSBwcm92aWRlciBtb2RlbCBpcyB0aGF0IA0KaXQgc2VlbXMgdG8gYmUgYSBj aXJjdWxhciBkZWZpbml0aW9uLiBXZSBkZWZpbmUgd2hhdCB0aGUgc2VydmljZSBwcm92aWRlciBt b2RlbCBpcywgYnV0IHRoZSBkZWZpbnRpb24gc2F5OiAobGlrZSBob21lIHJvdXRlcnMgdXNlZCBp biBzZXJ2aWNlIHByb3ZpZGVyIG1vZGVsKS4NCg0KDQpEaXNjdXNzaW9uIGlzc3VlOg0KDQoxKUlu IHNlY3Rpb24gNCwgdGhlcmUgaW50cm9kdWNlcyAzIHByZWZpeGVzOlNwbGl0IFByZWZpeGVzLE11 bHRpcGxlIFVuaXF1ZSBQcmVmaXhlcyBhbmQgSWRlbnRpY2FsIFByZWZpeGVzIGluIHBhcmFsbGVs IHdheS4NCg0KIEluIHNlY3Rpb24gNC4xLCBpdCBpbnRyb2R1Y2VzDQoiSW4gdGhlIHNwbGl0IHBy ZWZpeGVzIG1vZGVsLCBlYWNoIERIQ1B2NiBzZXJ2ZXIgaXMgY29uZmlndXJlZCB3aXRoIGENCiAg IHVuaXF1ZSwgbm9uLW92ZXJsYXBwaW5nIHJhbmdlIGRlcml2ZWQgZnJvbSB0aGUgLzY0IHByZWZp eCBkZXBsb3llZA0KICAgZm9yIHVzZSB3aXRoaW4gYW4gSVB2NiBuZXR3b3JrLiINCg0KIEluIHNl Y3Rpb24gNC4yLCBpdCBpbnRyb2R1Y2VzDQogICJJbiB0aGUgbXVsdGlwbGUgcHJlZml4IG1vZGVs LCBlYWNoIERIQ1B2NiBzZXJ2ZXIgaXMgY29uZmlndXJlZCB3aXRoIGENCiAgIHVuaXF1ZSwgbm9u LW92ZXJsYXBwaW5nIHByZWZpeC4gIEEgLzY0IHJhbmdlIGVxdWFsIHRvIHRoZSBwcmVmaXggaXMN CiAgIGNvbmZpZ3VyZWQgb24gZWFjaCBzZXJ2ZXIuICINCg0KQmFzZWQgb24gdGhlIGFib3ZlIGRl ZmluaXRpb25zLCB0aGUgbXVsdGlwbGUgcHJlZml4IG1vZGVsIHNlZW1zIHRvIGJlIGEgcGVjaWFs DQpjYXNlIG9mIHRoZSBzcGxpdCBwcmVmaXhlcyBtb2RlbC4NCg0KSWYgaXQgaXMsIEkgdGhpbmsg dGhhdCBzZWN0aW9uIDQuMSBhbmQgNC4yIG5lZWQgdG8gbWVyZ2UgdG9nZXRoZXIgYW5kIHJlc3Ry dWN0dXJlLg0KDQpRdWVzdGlvbiBpc3N1ZToNCg0KIFRoaXMgZG9jdW1lbnQgc2FpZCAiQXQgdGhl IHRpbWUgb2YgdGhpcyB3cml0aW5nIGEgc3RhbmRhcmRzLWJhc2VkIERIQ1B2NiByZWR1bmRhbmN5 IHByb3RvY29sIGFuZCBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCBhdmFpbGFibGUuICIgSSBhbSB3 b25kZXJpbmcNCndoeSB0aGUgc29sdXRpb24gaW4gdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgQkNQ LiBBcmUgdGhlcmUgYSBsb3Qgb2YgaW1wbGVtZW50YXRpb25zPyBJcyB0aGlzIG9uZSB0aGUgYmVz dCBvbmU/IA0KDQoNCk1pbm9yIElzc3VlczoNCg0KDQoxKSBUaGVyZSBhcmUgMTQgIm11c3QiIGlu IHRoaXMgZG9jdW1lbnQsYnV0IGFsbCBhcmUgaW4gbG93ZXIgY2FzZS4gSSBhbSBzdXJlDQp0aGF0 IHNvbWUgc2hvdWxkIGJlICJNVVNUIiwgcGxzIGNoZWNrIGl0Lg0KDQoyKSBJbiBzZWN0aW9uIDIu MSAiKENNVFMgZm9yIGNhYmxlIG9yIERTTEFNL0JSQVMgZm9yIERTTCBmb3IgZXhhbXBsZSkgIg0K DQpUaGUgYWJicmV2aWF0aW9uIG5lZWRzIHNvbWUgZXhwbGFpbmF0aW9uIG9yIHJlZmVyZW5jZS4g UGxzIGFsc28gY2hlY2sgb3RoZXIgYWJicmV2aWF0aW9ucyBpbiB0aGlzIGRvY3VtZW50LiANCg0K DQo= From yaojk@cnnic.cn Sat Jan 28 06:05:36 2012 Return-Path: <yaojk@cnnic.cn> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668B21F8571 for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.147 X-Spam-Level: X-Spam-Status: No, score=-99.147 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoX2d1hNiSPY for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 06:05:35 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id BB5CE21F8569 for <apps-discuss@ietf.org>; Sat, 28 Jan 2012 06:05:32 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 28 Jan 2012 22:05:26 +0800 Message-ID: <69E5876F8BFD40B081527DA2BEFDEC31@LENOVO47E041CF> From: "Jiankang YAO" <yaojk@cnnic.cn> To: =?utf-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo0JwuINCE0LLRgdGC0ZbRhNC10ZQ=?= =?utf-8?B?0LIpIg==?= <evnikita2@gmail.com>, "Barry Leiba" <barryleiba@computer.org> References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com><4EC40EC3.9080304@gmail.com><CAC4RtVB4Y2ozbBs=n1hwCMdvv-YinhLiGFGgwt4R=a7-8iyYmA@mail.gmail.com><4ED9B441.2020507@gmail.com><CALaySJLK3Qeoisair-C=TpT=RDh05WVroF5GCZ9w+jBiiQKqTA@mail.gmail.com> <4EDB41E5.7080604@gmail.com> Date: Sat, 28 Jan 2012 22:05:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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.6157 Cc: Apps-discuss list <apps-discuss@ietf.org> Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Jan 2012 14:05:36 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIiJNeWt5dGEgWWV2c3RpZmV5 ZXYgKNCcLiDQhNCy0YHRgtGW0YTQtdGU0LIpIiIgPGV2bmlraXRhMkBnbWFpbC5jb20+DQpUbzog IkJhcnJ5IExlaWJhIiA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQpDYzogIkFwcHMtZGlzY3Vz cyBsaXN0IiA8YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU2VudDogU3VuZGF5LCBEZWNlbWJlciAw NCwgMjAxMSA1OjQ4IFBNDQpTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi1hcHBzYXdnLWFib3V0LXVyaS1zY2hlbWUNCg0KDQo+IDAzLjEyLjIwMTEgMTY6 MjgsIEJhcnJ5IExlaWJhIHdyb3RlOg0KPj4gSSB0aGluayB0aGVyZSBhcmUgb25seSB0d28gbWlu b3IgdGhpbmdzIGxlZnQgdG8gcmVzcG9uZCB0byBoZXJlOg0KPj4NCj4+Pj4gSSBkb24ndCB0aGlu ayBpdCdzIGFwcHJvcHJpYXRlIHRvIHNwZWNpZnkgdGhlIGdlbmVyYWwgSUVURg0KPj4+PiBkaXNj dXNzaW9uIGxpc3QgYXMgdGhlIGNvbnRhY3QgcG9pbnQgKEF1dGhvci9DaGFuZ2UgY29udHJvbGxl cikuDQo+Pj4+IFB1dCBzb21ldGhpbmcgInJlYWwiIGluIHRoZXJlLg0KPj4+IEZvciBleGFtcGxl Pw0KPj4gRmFpciBxdWVzdGlvbi4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgdXN1YWxseSB1c2Ug ZWl0aGVyIHRoZSBkb2N1bWVudA0KPj4gYXV0aG9yL2VkaXRvciBvciB0aGUgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3QsIGFuZCBpbiB0aGlzIGNhc2UgdGhlDQo+PiBmb3JtZXIgaXNuJ3QgYXBw cm9wcmlhdGUsIGFuZCBJJ20gbm90IHN1cmUgYWJvdXQgdGhlIGxhdHRlci4gIEhtLi4uLg0KPj4N Cj4+IEkgc3VnZ2VzdCB0aGF0IHdlIGVpdGhlciB1c2U8YXBwcy1kaXNjdXNzQGlldGYub3JnPiAg b3INCj4+IDx1cmktcmV2aWV3QGlldGYub3JnPiwgYW5kIEknbSBub3Qgc3VyZSB3aGljaCBvbmUg aXMgcmlnaHQuICBQZXJoYXBzDQo+PiBvdGhlcnMgb24gYXBwcy1kaXNjdXNzLCBvciBwZXJoYXBz IHRoZSBBRHMsIHdpbGwgY29tbWVudC4NCj4gDQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGNob29zZSBB UFBTQVdHIGFzIEF1dGhvci9DaGFuZ2UgY29udHJvbGxlciBhbmQgDQo+IGNvcnJlc3BvbmRpbmds eSBzdXBwbHkgYXBwcy1kaXNjdXNzIGxpc3QgYXMgY29udGFjdCBwb2ludCwgYXMgbG9uZyBhcyAN Cj4gdGhpcyBkb2MgaXMgcHJvZHVjZWQgaW4gQVBQU0FXRyBhbmQgdGhlcmUgYXJlIG5vIHBsYW5z IHRvIGNsb3NlIGl0IGluIA0KPiB0aGUgbmVhcmVzdCBmdXR1cmUuDQo+IA0KDQpJIHBlcnNvbmFs bHkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgY2hvb3NlIEFQUFNBV0cgYXMgQXV0aG9yL0NoYW5nZSBj b250cm9sbGVyLg0KDQpKaWFua2FuZyBZYW8= From alexey.melnikov@isode.com Sat Jan 28 06:15:14 2012 Return-Path: <alexey.melnikov@isode.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E5F21F855B; Sat, 28 Jan 2012 06:15:14 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYmBAp3QyGZl; Sat, 28 Jan 2012 06:15:13 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B121F8503; Sat, 28 Jan 2012 06:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327760111; d=isode.com; s=selector; i=@isode.com; bh=EPyg7LE2c3Y38e9y5UY3ZPpJlRGEgZvyaFkma4704Cw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oTX21i3I0WMWxi1Hayp3OavqwYmtbumPTzTvRwSiR9dZO6a0RlLYPxJ1XyJoyl9ovviMzf w+vKXi+bq+oEiALSqBoK85lKAviTRGwQB2vAYWu4FMRJ0/dAqNmfWmVtA3QdYIoRcKKi6P EhOdg695/2jthoMz2/wcxbmrX/hcnQ0=; Received: from [188.29.1.112] (188.29.1.112.threembb.co.uk [188.29.1.112]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TyQC3gAV5xrD@rufus.isode.com>; Sat, 28 Jan 2012 14:15:05 +0000 Message-ID: <4F23EDED.4030505@isode.com> Date: Sat, 28 Jan 2012 12:45:33 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Glenn Parsons <glenn.parsons@ericsson.com> References: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se> In-Reply-To: <D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070008050407090206080306" Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" <draft-melnikov-smtp-priority.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org> Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 28 Jan 2012 14:15:14 -0000 This is a multi-part message in MIME format. --------------070008050407090206080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Glenn, To answer your question about the number of priority levels: On 10/01/2012 21:10, Glenn Parsons wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > _http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate_). > > 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-melnikov-smtp-priority-04 > Title: Simple Mail Transfer Protocol extension for Message Priorities > Reviewer: Glenn Parsons > Review Date: January 10, 2012 > Summary: > This draft is not ready for publication as a Proposed Standard and > should be revised before publication > Major Issues: [...] > 5. The priority level definition is not clear. There are 200 possible > values. The document originally had 5 fixed levels. I received comments from some people that they would like to use this extension, but for their environment they wanted to use N levels (N > 5), or maybe M levels, but they were not quite the same as the one recommended in the draft. One proposal asked for having a language for expressing policy associated with each priority level and use names instead of numbers. I felt that use of names for priority levels was overkill, so instead I've expanded the range of allowed numeric priorities. The main nice property of this is that the range of allowed priorities allows an implementation to insert additional priority levels in gaps between recommended priorities (e.g. if -8, -6,-2,0,+2,+6,+10 are defined, one can define a new priority level of +7 if really needed). > But there MUST be at least 6 supported. OK that seems like overkill > -- why can't it be from -9 to 9 then? I think this will work. I was certainly not thinking that all 200 distinct priority levels should be implemented. > Anyway, is that 6 distinct numbers, 6 distinct numbers from the range > shown, or any number for the range shown? Any number from the range shown, but at least 6 of them. > Further I would suggest that a default value should be specified for > these 6 levels and the default mapping ranges -- all in a table. **Ok. So it looks like I need to (a) reduce the number of allowed priorities, (b) clarified how they are to be used and why there are more than 6 and (c) recommend a default mapping. --------------070008050407090206080306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Glenn,<br> To answer your question about the number of priority levels:<br> <br> On 10/01/2012 21:10, Glenn Parsons wrote: <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style> <font face="Times New Roman, serif" size="3"> <div style="margin-top: 5pt; margin-bottom: 5pt; ">I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see <a moz-do-not-send="true" href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate"><font color="#0000FF"><u>http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate</u></font></a>). </div> <div style="margin-top: 5pt; margin-bottom: 5pt; ">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.</div> <div style="margin-top: 5pt; margin-bottom: 5pt; ">Document: <font face="Courier New, monospace" size="2">draft-melnikov-smtp-priority-04<br> </font>Title: Simple Mail Transfer Protocol extension for Message Priorities <br> Reviewer: Glenn Parsons<br> Review Date:  January 10, 2012<br> </div> <div style="margin-top: 5pt; margin-bottom: 5pt; ">Summary: </div> <div style="margin-top: 5pt; margin-bottom: 5pt; ">This draft is not ready for publication as a Proposed Standard and should be revised before publication</div> <div style="margin-top: 5pt; margin-bottom: 5pt; ">Major Issues:</div> </font></blockquote> <font size="3"><font face="Times New Roman, serif"> [...]<br> </font></font> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"><font face="Times New Roman, serif" size="3"> <div style="margin-top: 5pt; margin-bottom: 5pt;">5. The priority level definition is not clear.  There are 200 possible values.</div> </font></blockquote> <font size="3"><font face="Times New Roman, serif">The document originally had 5 fixed levels. I received comments from some people that they would like to use this extension, but for their environment they wanted to use N levels (N > 5), or maybe M levels, but they were not quite the same as the one recommended in the draft. One proposal asked for having a language for expressing policy associated with each priority level and use names instead of numbers. I felt that use of names for priority levels was overkill, so instead I've expanded the range of allowed numeric priorities. The main nice property of this is that the range of allowed priorities allows an implementation to insert additional priority levels in gaps between recommended priorities (e.g. if -8, -6,-2,0,+2,+6,+10 are defined, one can define a new priority level of +7 if really needed).<br> </font></font> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"><font face="Times New Roman, serif" size="3"> <div style="margin-top: 5pt; margin-bottom: 5pt;">But there MUST be at least 6 supported.  OK that seems like overkill -- why can't it be from -9 to 9 then?</div> </font></blockquote> I think this will work. I was certainly not thinking that all 200 distinct priority levels should be implemented. <br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"><font face="Times New Roman, serif" size="3"> <div style="margin-top: 5pt; margin-bottom: 5pt;">Anyway, is that 6 distinct numbers, 6 distinct numbers from the range shown, or any number for the range shown?</div> </font></blockquote> Any number from the range shown, but at least 6 of them.<br> <blockquote cite="mid:D9DBDA6E6E3A9F438D9F76F0AF9D7AE33B3EEA96F2@EUSAACMS0714.eamcs.ericsson.se" type="cite"><font face="Times New Roman, serif" size="3"> <div style="margin-top: 5pt; margin-bottom: 5pt; "> Further I would  suggest that a default value should be specified for these 6 levels and the default mapping ranges -- all in a table.</div> </font></blockquote> <b></b><font size="3"><font face="Times New Roman, serif">Ok.<br> <br> So it looks like I need to (a) reduce the number of allowed priorities, (b) clarified how they are to be used and why there are more than 6 and (c) recommend a default mapping.<br> <br> </font></font> </body> </html> --------------070008050407090206080306-- From ned.freed@mrochek.com Sat Jan 28 19:13:34 2012 Return-Path: <ned.freed@mrochek.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6333921F85C2 for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 19:13:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAFmeet49uPY for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 19:13:33 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A64B921F85BE for <apps-discuss@ietf.org>; Sat, 28 Jan 2012 19:13:33 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBBYC8SJWW000DR3@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 28 Jan 2012 19:13:28 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OB7OO3V69C00ZUIL@mauve.mrochek.com>; Sat, 28 Jan 2012 19:13:21 -0800 (PST) Message-id: <01OBBYC42YGW00ZUIL@mauve.mrochek.com> Date: Sat, 28 Jan 2012 19:13:03 -0800 (PST) From: Ned Freed <ned.freed@mrochek.com> In-reply-to: "Your message dated Sun, 22 Jan 2012 22:02:29 +0000" <20120122220229.87477.qmail@joyce.lan> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120122220229.87477.qmail@joyce.lan> To: John Levine <johnl@taugh.com> Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 29 Jan 2012 03:13:34 -0000 > As promised, I smooshed S.M.'s draft and mine together, so here's one that has > both his narrative text and my registry additions. Looks good to me! Ned > R's, > John > PS: This is unrelated to Murray's draft, which I think is an entirely reasonable > application of a new Received: clause. > -------------------------------------------------------------- > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : Mail Header Trace Fields > Author(s) : Taughannock Networks > S. Moonesamy > Filename : draft-levine-trace-header-registry-01.txt > Pages : 6 > Date : 2012-01-22 > SMTP mail software adds trace fields to messages as they pass through > the mail system. This memo provides background information about > trace fields in mail standards. It discusses the use of trace fields > in mail-related specifications. It updates the definition of trace > header fields, and adds trace field information to the relevant > registries. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-levine-trace-header-registry-01.txt > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Sun Jan 29 07:44:07 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CFE21F84D1 for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.149 X-Spam-Level: X-Spam-Status: No, score=-104.149 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWeqyhDveHUt for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 07:44:07 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E14AB21F84D0 for <apps-discuss@ietf.org>; Sun, 29 Jan 2012 07:44:06 -0800 (PST) Received: (qmail invoked by alias); 29 Jan 2012 15:44:03 -0000 Received: from p3EE276D7.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.118.215] by mail.gmx.net (mp033) with SMTP; 29 Jan 2012 16:44:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX197syddPsh7+0zdp65z9E37VfWdqkJ7e8K93yJhOC d7Gwmd7Y0n+OwA Message-ID: <4F25693C.1050701@gmx.de> Date: Sun, 29 Jan 2012 16:43:56 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF Apps Discuss <apps-discuss@ietf.org> References: <4F2567DA.3060608@gmx.de> In-Reply-To: <4F2567DA.3060608@gmx.de> X-Forwarded-Message-Id: <4F2567DA.3060608@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] Fwd: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 29 Jan 2012 15:44:07 -0000 (FYI) -------- Original Message -------- Subject: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt Date: Sun, 29 Jan 2012 16:38:02 +0100 From: Julian Reschke <julian.reschke@gmx.de> To: HTTP Working Group <ietf-http-wg@w3.org> Hi there, I just submitted a new revision of d draft-reschke-basicauth-enc - see below (HTML version at <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-04.html>; this version also includes new hooks for providing feedback; please try!). At this point, I'd like to solicit additional feedback before I proceed; in particular: should this potentially be an Applications Area WG deliverable? With respect to intended status: in theory, this is a candidate for Experimental. However, Basic Authentication (as defined in RFC 2617) doesn't have a registry for extension parameters, so the cleanest approach appears to say "Updates 2617", which IMHO requires a standards track document. Best regards, Julian -------- Original Message -------- Subject: I-D Action: draft-reschke-basicauth-enc-04.txt Date: Sun, 29 Jan 2012 07:28:40 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Encoding Parameter for HTTP Basic Authentication Author(s) : Julian F. Reschke Filename : draft-reschke-basicauth-enc-04.txt Pages : 9 Date : 2012-01-29 The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From julian.reschke@gmx.de Sun Jan 29 07:39:52 2012 Return-Path: <julian.reschke@gmx.de> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6485F21F8581 for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 07:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.149 X-Spam-Level: X-Spam-Status: No, score=-104.149 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0xhxZJ7p6DX for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 07:39:51 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DE37E21F8546 for <apps-discuss@ietf.org>; Sun, 29 Jan 2012 07:39:50 -0800 (PST) Received: (qmail invoked by alias); 29 Jan 2012 15:39:49 -0000 Received: from p3EE276D7.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.118.215] by mail.gmx.net (mp069) with SMTP; 29 Jan 2012 16:39:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+6XgIxqIy6fionB4feiUpmu7P33xkcUCERSU+zV4 EvuoDyWAJQtVBg Message-ID: <4F256840.4070403@gmx.de> Date: Sun, 29 Jan 2012 16:39:44 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> References: <4F2567DA.3060608@gmx.de> In-Reply-To: <4F2567DA.3060608@gmx.de> X-Forwarded-Message-Id: <4F2567DA.3060608@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sun, 29 Jan 2012 08:04:41 -0800 Subject: [apps-discuss] Fwd: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 29 Jan 2012 15:39:52 -0000 (FYI) -------- Original Message -------- Subject: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt Date: Sun, 29 Jan 2012 16:38:02 +0100 From: Julian Reschke <julian.reschke@gmx.de> To: HTTP Working Group <ietf-http-wg@w3.org> Hi there, I just submitted a new revision of d draft-reschke-basicauth-enc - see below (HTML version at <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-04.html>; this version also includes new hooks for providing feedback; please try!). At this point, I'd like to solicit additional feedback before I proceed; in particular: should this potentially be an Applications Area WG deliverable? With respect to intended status: in theory, this is a candidate for Experimental. However, Basic Authentication (as defined in RFC 2617) doesn't have a registry for extension parameters, so the cleanest approach appears to say "Updates 2617", which IMHO requires a standards track document. Best regards, Julian -------- Original Message -------- Subject: I-D Action: draft-reschke-basicauth-enc-04.txt Date: Sun, 29 Jan 2012 07:28:40 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Encoding Parameter for HTTP Basic Authentication Author(s) : Julian F. Reschke Filename : draft-reschke-basicauth-enc-04.txt Pages : 9 Date : 2012-01-29 The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From sm@resistor.net Sun Jan 29 09:44:38 2012 Return-Path: <sm@resistor.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C96F21F84C8 for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPDeDXz6p1AM for <apps-discuss@ietfa.amsl.com>; Sun, 29 Jan 2012 09:44:35 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FCE21F84B5 for <apps-discuss@ietf.org>; Sun, 29 Jan 2012 09:44:35 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0THiQC0011390; Sun, 29 Jan 2012 09:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327859072; i=@resistor.net; bh=l2ZPtOSr0XSuk3aQxjJ0n/qtFO5Hz+Q3iRiwwffvnXE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=mxnmhpeUmaNYtYtawOLfrgUuGn/Q53zfLV9yZ5zzDVefMoAXyEF1nWuzol+xmuens 03j3iTIX+OR8wmddukM/hxwO9nDAQvHQXq6ISQSO03C8K9eO3KAiuIgQ7YCElhAiJQ 8QPz7KSWVwz7DI7QqrhDGvvJ3ujmYiDkRFYqRS/Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327859072; i=@resistor.net; bh=l2ZPtOSr0XSuk3aQxjJ0n/qtFO5Hz+Q3iRiwwffvnXE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=weQ5O1awaqmW1tGFsXrK7NnU/pA3ErkUVjVjaBNP3CXInQqH/OuIFmiJeNtJwLehe xqu00vpFOBLgBJtpsgIC4mFBooNhScR5UGbZWulZuRbmaB+hlhb60W/SOsSlt1lVpV 8I6+1/OXfhKftjACVYUYjmnI2OzFJ0UO6FXzLWsE= Message-Id: <6.2.5.6.2.20120129082227.0630b9c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 29 Jan 2012 08:42:42 -0800 To: Julian Reschke <julian.reschke@gmx.de> From: SM <sm@resistor.net> In-Reply-To: <4F25693C.1050701@gmx.de> References: <4F2567DA.3060608@gmx.de> <4F25693C.1050701@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF Apps Discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] Fwd: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 29 Jan 2012 17:44:38 -0000 Hi Julian, At 07:43 29-01-2012, Julian Reschke wrote: >At this point, I'd like to solicit additional feedback before I proceed; >in particular: should this potentially be an Applications Area WG >deliverable? I'll volunteer to review the draft. >With respect to intended status: in theory, this is a candidate for >Experimental. However, Basic Authentication (as defined in RFC 2617) >doesn't have a registry for extension parameters, so the cleanest >approach appears to say "Updates 2617", which IMHO requires a standards >track document. I'd say go to Proposed Standard. BTW, the "Updates 2617" does not require a standard track document. Regards, -sm From tmiller@mitre.org Mon Jan 30 05:06:29 2012 Return-Path: <tmiller@mitre.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047921F86D1; Mon, 30 Jan 2012 05:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffY4rm1sEeSZ; Mon, 30 Jan 2012 05:06:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 783BB21F86C4; Mon, 30 Jan 2012 05:06:28 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C964421B0926; Mon, 30 Jan 2012 08:06:27 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BABB721B094C; Mon, 30 Jan 2012 08:06:27 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 30 Jan 2012 08:06:27 -0500 From: "Miller, Timothy J." <tmiller@mitre.org> To: "mrex@sap.com" <mrex@sap.com>, Paul Hoffman <paul.hoffman@vpnc.org> Thread-Topic: [pkix] PKIX text encodings Thread-Index: AQHM3VUNcMLmsjko+UWci5xLcgDxQpYk1JcA Date: Mon, 30 Jan 2012 13:06:26 +0000 Message-ID: <CB4BF105.3DF9%tmiller@mitre.org> In-Reply-To: <201201280037.q0S0bjqe004577@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.0.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E6AEC8B15E8824ABDABAAF9370EC85B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 30 Jan 2012 08:03:36 -0800 Cc: "simon@josefsson.org" <simon@josefsson.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "pkix@ietf.org" <pkix@ietf.org> Subject: Re: [apps-discuss] [pkix] PKIX text encodings X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Jan 2012 13:06:29 -0000 > Any reasonable ASN.1 decoder can reliably tell apart [...] While any ASN.1 decoder + a little logic can discern one ASN.1 encoded object from another, it would *really* help *non-decoding* applications to have simple magic numbers when serializing ASN.1 to a file. This has been a long-standing pet peeve of mine since I was asked to write a scanner to find PKCS#12 files. There's enough variation in encoding that it's a real PITA to do a lightweight decode and still have a reasonable false positive rate. -- T On 1/27/12 6:37 PM, "Martin Rex" <mrex@sap.com> wrote: >Paul Hoffman wrote: >>=20 >> Martin Rex wrote: >> > >> > the Label that is used within '-----BEGIN <some-label>----' >> > should be ignored on the receiver side, and all implemented formats >> > should be tried, that are applicable for the requested operation. >>=20 >> This would cause things like private keys and public keys to be mixed >>up. > >Not necessarily. If your ASN.1 decoder can not distinguish your private >from your public key, then you have a whole different kind of problem. > > >> >> I propose this is not a good idea from a security perspective. > >Huh? That textual label is not integrity protected in any way, >so how should this be a security problem? > >This is really only about convenience for admins. > > >> >> Instead, Simon might add some text saying that some applications >> sometimes ignore the label in order to be more liberal, but in doing >> so can cause problems with systems that assume those labels are >>important. > >HUH? How could being liberal on *INPUT* possibly cause problems? > >Any reasonable ASN.1 decoder can reliably tell apart > - X.509 certificates > - private keys > - encrypted private keys > - pkcs10 requests > - crls > - pkcs7/cms=20 > - pkcs7/cms as certificate bag > - pkcs7/cms as crl bag > - pkcs12 > >So any implementation that is ignoring the explicit label, will have to >use the implicit label from successfuly ASN.1 decode of the types >of objects that are applicable for the requested operation. > > >Microsoft seems to ignore the label. If you double-click on >a pkcs7 file (extension .p7s or .p7b) it will be PEM-decoded independent >of what label is used. Same for certificate (.cer). > > >I find it much more confusing when only a few, but non-unique labels >are accepted: >OpenSSL seems to accept certs with "X509 CERTIFICATE" and "CERTIFICATE" >and PKCS7 as "PKCS7" or "CERTIFICATE" but _not_ "X509 CERTIFICATE" > > >>=20 >> Just a thought: we define *new* labels that do what we think everyone >> should do, such as multiple items in the block. There would not be much >> uptake on those new labels in the short run, but could become the >> standard 20 years from now. > >For OUTPUT we should try to find an reuse the most commonly used label, >because the installed base is going to be with us another 10+ years. > > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From enrico.marocco@telecomitalia.it Mon Jan 30 08:10:44 2012 Return-Path: <enrico.marocco@telecomitalia.it> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B921F873E for <apps-discuss@ietfa.amsl.com>; Mon, 30 Jan 2012 08:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.474 X-Spam-Level: X-Spam-Status: No, score=-100.474 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwRynaiSZIoe for <apps-discuss@ietfa.amsl.com>; Mon, 30 Jan 2012 08:10:44 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02A21F8740 for <apps-discuss@ietf.org>; Mon, 30 Jan 2012 08:10:43 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 30 Jan 2012 17:10:42 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 30 Jan 2012 17:10:41 +0100 Message-ID: <4F26C151.8020602@telecomitalia.it> Date: Mon, 30 Jan 2012 17:12:01 +0100 From: Enrico Marocco <enrico.marocco@telecomitalia.it> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> References: <4F26BD49.8000009@telecomitalia.it> In-Reply-To: <4F26BD49.8000009@telecomitalia.it> X-Forwarded-Message-Id: <4F26BD49.8000009@telecomitalia.it> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060409030005040108030209" Subject: [apps-discuss] Fwd: ALTO extensions: new list + problem statement X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Jan 2012 16:10:44 -0000 --------------ms060409030005040108030209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI -- ALTO is currently an HTTP-based protocol and some of the very preliminary extension proposals that came out in recent discussions included ALTO-over-XMPP. If only for that, people here may want to keep an eye on it. Enrico -------- Original Message -------- Subject: ALTO extensions: new list + problem statement Date: Mon, 30 Jan 2012 16:54:49 +0100 From: Enrico Marocco <enrico.marocco@telecomitalia.it> To: alto@ietf.org <alto@ietf.org> Hi folks, the new altoext@ietf.org mailing list has just been created to discuss possible extensions to the about-to-be-finished ALTO protocol. We have also recently submitted a draft trying to summarize the previous discussions on the subject: http://tools.ietf.org/html/draft-marocco-alto-next In a nutshell: the possible extensions, primarily intended to better address the CDN/datacenter and server-to-server use cases, mainly concern: + a server-to-client notification mechanism; + additional types of information, such as: o network link load (average, over some recent timeframe); o server load (average, over some recent timeframe); o availability of resources such as memory, content, installed applications. The new mailing list has been created in order to get broader feedback and to get together people with experience in different areas. If you have an opinion on whether and why the proposed (and possibly further) extensions will be a good or a bad idea, you can join the discussion at: https://www.ietf.org/mailman/listinfo/altoext --=20 Ciao, Enrico --------------ms060409030005040108030209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC 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 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwMTMwMTYxMjAxWjAjBgkqhkiG9w0BCQQxFgQUXdGeUJr3vo9pS7wc7L/buDy3IkgwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEAjqRewTY0VlXHrB2aGJjAI6g8fA24sKTJsg9k0DuXaTKz/u/p ejs/0OKHZJDy/h3uPtjD1z7izwapZfReEPuhWSxuZZZb7wz6eSCNwrILcJH58RYDKLpj6pdb gv84488cTQXFIeJY1NeJCjIVYk58Re1xLHmUEa2X2sSiHFTUcdT03S8jbg6lUiXyWgMdRqi4 ndcs0mdkNrnAQEvCPB2D1uw1dv6La0cJHmoQniAa3NNA1u6d/yW0+K11v25IHuWxv0MuUotP Qr85WMsHnjCvh9z+b4O1YzyZsEyqw6YcDUWcP7o69SgPIkdEMiJ2ffCBJ3U85eXBWKzWopiW sC1ZlwAAAAAAAA== --------------ms060409030005040108030209-- From lisa.dusseault@gmail.com Mon Jan 30 10:03:37 2012 Return-Path: <lisa.dusseault@gmail.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFC711E8086; Mon, 30 Jan 2012 10:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-TmnBUjNOBr; Mon, 30 Jan 2012 10:03:36 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8260C11E8081; Mon, 30 Jan 2012 10:03:33 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so3776964bkb.31 for <multiple recipients>; Mon, 30 Jan 2012 10:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VrDhRwiJCzzfvMVJQiTn3j1OFDYayUTYIsuOUnQ7024=; b=cWy2OM8ZRyQOPjRDX1qoDQ4nASZGnEC//GwbOhoTJ3Cq7z9fF0uHtizStYtrhm1HUq jlLmMfS5HKyS8E1gk0DU20S2ZQIMocEMJ3AiEaBz3sAtSQbovxSqhF+TevAtke1w89lV c3BLkLqYT0iQZ1iqSifnFgO4PDgQBwiZlCM7Q= MIME-Version: 1.0 Received: by 10.205.137.14 with SMTP id im14mr5803808bkc.133.1327946612584; Mon, 30 Jan 2012 10:03:32 -0800 (PST) Received: by 10.204.232.13 with HTTP; Mon, 30 Jan 2012 10:03:32 -0800 (PST) Date: Mon, 30 Jan 2012 10:03:32 -0800 Message-ID: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com> From: Lisa Dusseault <lisa.dusseault@gmail.com> To: apps-discuss@ietf.org, draft-ietf-sidr-rpki-rtr.all@tools.ietf.org Content-Type: multipart/alternative; boundary=000e0cdfdb601fb2f804b7c2aa4e Cc: IESG <iesg@ietf.org> Subject: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Jan 2012 18:03:37 -0000 --000e0cdfdb601fb2f804b7c2aa4e Content-Type: text/plain; charset=ISO-8859-1 Document: draft-ietf-sidr-rpki-rtr-25 Title: The RPKI/Router Protocol Reviewer: Lisa Dusseault Review Date: Jan 30 IETF Last Call Date: Nov 29 2011 IESG Telechat Date: Feb 2 2012? Summary: Ready for publication on the standards track. I reviewed draft-ietf-sidr-rpki-rtr-25 for the Apps Area group. I noted that this draft is clear and mature for a v0 protocol. It describes a protocol that has been implemented at least in part in five different implementations. It has undergone lively discussion in an active WG and in IETF Last Call. The latest document iterations show a great deal of stability. This all suggests to me that if any flaws in architecture or suitability exist, I am not going to be good at identifying them, as I am not a routing domain expert. Thus, I reviewed this document mostly from the point of view of an outsider (can a reader with general Internet expertise understand the document?) and I looked for general issues such as IANA registry issues. Section 7 (Transport) I'm not qualified to judge the tradeoffs between supporting unprotected TCP, waiting for TCP-AO, or doing something else, but I did note this had been extensively discussed during IETF last call. I read this section and then made some inferences: - Only a human administrator can tell if a collection of routers and caches using RPKI are "on the same trusted and controlled network" - A human administrator would configure the routers and caches to use TCP, based on their trust of the local network. - A router would not attempt to use the RPKI-rtr port with unprotected TCP unless it was configured by the human administrator to do so - Thus, there is not a downgrade attack unless a human is involved in the decision to downgrade the security configuration I also infer that while a cache implementation MUST generically implement unprotected TCP as a transport, that an instance of a cache may well be configured simply not to respond to TCP requests on the RPKI-rtr port. If these inferences are wrong, then I do have concerns about the possibility of a downgrade attack. However, I believe these inferences are correct (and supported by text in section 11, e.g. "must rely on network design and operational controls to provide protection") and are probably the inferences any reasonably informed reader would make. I did read the architecture draft referenced in the introduction, but did not read all the other WG drafts relating to RPKI. Section 7.2 (TLS transport) It's not clear to me why routers would need to provide a client certificate to caches, because I had not assumed that the data transported in RPKI-RTR was sensitive, only that it needed to be valid and authorized. I'm guessing it has something to do with being able to manage load on very central caches by dropping requests from unauthorized routers, which would be either maliciously or unintentionally configured to use a cache that was not set up to handle the load of those unauthorized routers. If this is a correct guess, I wonder if it would be helpful to be a bit more explicit about this possibility? Will there need to be an error code added, to be used when a cache has to reject an unauthorized router request? Section 11 (security considerations) Except for my confusion around why routers need to identify themselves to caches (what's the threat model for needing that), I appreciate the clarity of this section. Lisa D. --000e0cdfdb601fb2f804b7c2aa4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><span style=3D"font-family:'Times New Roman',times,serif;font-= size:15px">Document:=A0</span>draft-ietf-sidr-rpki-rtr-25</div><p style=3D"= font-size:15px;font-family:'Times New Roman',times,serif">Title:<sp= an style=3D"font-size:1em;line-height:0pt;font-weight:bold">=A0The RPKI/Rou= ter Protocol</span><br> Reviewer: Lisa Dusseault<br>Review Date: Jan 30<br>IETF Last Call Date: Nov= 29 2011<br>IESG Telechat Date: Feb 2 2012?=A0<br></p><div>Summary: Ready f= or publication on the standards track.</div><div><br></div><div>I reviewed = draft-ietf-sidr-rpki-rtr-25 for the Apps Area group. =A0</div> <div><br></div><div>I noted that this draft is clear and mature for a v0 pr= otocol. =A0It describes a protocol that has been implemented at least in pa= rt in five different implementations. =A0It has undergone lively discussion= in an active WG and in IETF Last Call. =A0The latest document iterations s= how a great deal of stability. =A0This all suggests to me that if any flaws= in architecture or suitability exist, I am not going to be good at identif= ying them, as I am not a routing domain expert. =A0Thus, I reviewed this do= cument mostly from the point of view of an outsider (can a reader with gene= ral Internet expertise understand the document?) and I looked for general i= ssues such as IANA registry issues.</div> <div><br></div><div>Section 7 (Transport)</div><div><br></div><div>I'm = not qualified to judge the tradeoffs between supporting unprotected TCP, wa= iting for TCP-AO, or doing something else, but I did note this had been ext= ensively discussed during IETF last call.</div> <div><br></div><div>I read this section and then made some inferences:</div= ><div><br></div> <div>=A0- Only a human administrator can tell if a collection of routers an= d caches using RPKI are "on the same trusted and controlled network&qu= ot;</div><div>=A0- A human administrator would configure the routers and ca= ches to use TCP, based on their trust of the local network.</div> <div>=A0- A router would not attempt to use the RPKI-rtr port with unprotec= ted TCP unless it was configured by the human administrator to do so</div><= div>=A0- Thus, there is not a downgrade attack unless a human is involved i= n the decision to downgrade the security configuration</div> <div><br></div><div>I also infer that while a cache implementation MUST gen= erically implement unprotected TCP as a transport, that an instance of a ca= che may well be configured simply not to respond to TCP requests on the RPK= I-rtr port.</div> <div><br></div><div>If these inferences are wrong, then I do have concerns = about the possibility of a downgrade attack. =A0However, I believe these in= ferences are correct (and supported by text in section 11, e.g. "<span= style=3D"font-size:1em">must rely on network design and=A0</span><span sty= le=3D"font-size:1em">operational controls to provide protection") and = are probably the inferences any reasonably informed reader would make. =A0I= did read the architecture draft referenced in the introduction, but did no= t read all the other WG drafts relating to RPKI.</span></div> <div><br></div><div>Section 7.2 (TLS transport)</div><div><br></div><div>It= 's not clear to me why routers would need to provide a client certifica= te to caches, because I had not assumed that the data transported in RPKI-R= TR was sensitive, only that it needed to be valid and authorized. I'm g= uessing it has something to do with being able to manage load on very centr= al caches by dropping requests from unauthorized routers, which would be ei= ther maliciously or unintentionally configured to use a cache that was not = set up to handle the load of those unauthorized routers. =A0If this is a co= rrect guess, I wonder if it would be helpful to be a bit more explicit abou= t this possibility? =A0Will there need to be an error code added, to be use= d when a cache has to reject an unauthorized router request?</div> <div><br></div><div>Section 11 (security considerations)</div><div><br></di= v><div>Except for my confusion around why routers need to identify themselv= es to caches (what's the threat model for needing that), I appreciate t= he clarity of this section.=A0</div> <div><br></div><div>Lisa D.</div> --000e0cdfdb601fb2f804b7c2aa4e-- From randy@psg.com Mon Jan 30 15:27:59 2012 Return-Path: <randy@psg.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0411E80D6; Mon, 30 Jan 2012 15:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUu1yNrQtA5h; Mon, 30 Jan 2012 15:27:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0C911E80C4; Mon, 30 Jan 2012 15:27:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1Rs0dg-000Nry-7O; Mon, 30 Jan 2012 23:27:56 +0000 Date: Tue, 31 Jan 2012 08:27:54 +0900 Message-ID: <m2k448ojnp.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Lisa Dusseault <lisa.dusseault@gmail.com> In-Reply-To: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com> References: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-rpki-rtr.all@tools.ietf.org, apps-discuss@ietf.org, IESG <iesg@ietf.org> Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Jan 2012 23:27:59 -0000 < irrelevant soapbox > hi lisa, will respond in general when both i and rob can sync across ten time zones. but i am gonna put my foot in it here, because you pushed a religious button of mine. it is not particularly relevant to the document, but i am not one to ignore an offered soapbox :) > - Only a human administrator can tell if a collection of routers and > caches using RPKI are "on the same trusted and controlled network" > - A human administrator would configure the routers and caches to use TCP, > based on their trust of the local network. > - A router would not attempt to use the RPKI-rtr port with unprotected TCP > unless it was configured by the human administrator to do so > - Thus, there is not a downgrade attack unless a human is involved in the > decision to downgrade the security configuration there exist automated configuration generation systems where no human configures the router at all. this is a very good practice and has been deployed in some large isps for a decade or more. the security folk have recently (the last three or four years or so) taken an interest and are using this to build the theory and tool framework to generate network (yes, network, not router!) configurations with known security properties. this is downright delicious. i have found the work of geoffrey xie and sanjai narain to be among the more interesting. but the field is becoming popular. randy From internet-drafts@ietf.org Mon Jan 30 17:11:17 2012 Return-Path: <internet-drafts@ietf.org> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB58121F84DA; Mon, 30 Jan 2012 17:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NS+tMjGGrqV; Mon, 30 Jan 2012 17:11:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4D21F8494; Mon, 30 Jan 2012 17:10:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120131011044.6631.95384.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 17:10:44 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 Jan 2012 01:11:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-greylisting-02.txt Pages : 12 Date : 2012-01-30 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-02.txt From ietfc@btconnect.com Tue Jan 31 08:33:40 2012 Return-Path: <ietfc@btconnect.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E002E21F8596 for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 08:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.932 X-Spam-Level: X-Spam-Status: No, score=0.932 tagged_above=-999 required=5 tests=[AWL=-2.900, BAYES_50=0.001, DATE_IN_PAST_24_48=1.219, FAKE_REPLY_C=2.012, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seM+snO5dWwv for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 08:33:39 -0800 (PST) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id EB26921F8593 for <apps-discuss@ietf.org>; Tue, 31 Jan 2012 08:33:35 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr07.btconnect.com with SMTP id GBW26184; Tue, 31 Jan 2012 16:33:25 +0000 (GMT) Message-ID: <002501ccdf64$8db56220$4001a8c0@gateway.2wire.net> From: "t.petch" <ietfc@btconnect.com> To: <dcrocker@bbiw.net> Date: Mon, 30 Jan 2012 16:33:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F2817D4.0072, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4F2817D5.0187,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: apps-discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 Jan 2012 16:33:41 -0000 ----- Original Message ----- From: "Dave CROCKER" <dhc@dcrocker.net> To: "t.petch" <ietfc@btconnect.com> Cc: <apps-discuss@ietf.org> Sent: Friday, January 27, 2012 6:33 PM > On 1/27/2012 8:08 AM, t.petch wrote: > I do not see it in the I-D, about what, if anything, this I-D expects to change > with the parameters currently in use. > > If you think that's a problem, please explain why and offer some text to cover it. Add at the end of the Introduction paragraph 2 'This document makes no recommendation as to whether existing X- parameters should continue to be used or should be migrated to a format without the X-." because otherwise this obvious question is left in midair. Tom Petch > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > . From dhc@dcrocker.net Tue Jan 31 08:42:19 2012 Return-Path: <dhc@dcrocker.net> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E592021F85B5 for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 08:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl03FJRMLVGN for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 08:42:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1321F84D8 for <apps-discuss@ietf.org>; Tue, 31 Jan 2012 08:42:19 -0800 (PST) Received: from [10.0.0.26] (mail.pir.org [72.44.190.134]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0VGg85E011508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 08:42:16 -0800 Message-ID: <4F2819DD.8060008@dcrocker.net> Date: Tue, 31 Jan 2012 11:42:05 -0500 From: Dave CROCKER <dhc@dcrocker.net> Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "t.petch" <ietfc@btconnect.com> References: <002501ccdf64$8db56220$4001a8c0@gateway.2wire.net> In-Reply-To: <002501ccdf64$8db56220$4001a8c0@gateway.2wire.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]); Tue, 31 Jan 2012 08:42:17 -0800 (PST) Cc: apps-discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 Jan 2012 16:42:20 -0000 wfm. d/ On 1/30/2012 10:33 AM, t.petch wrote: > ----- Original Message ----- > From: "Dave CROCKER"<dhc@dcrocker.net> > To: "t.petch"<ietfc@btconnect.com> > Cc:<apps-discuss@ietf.org> > Sent: Friday, January 27, 2012 6:33 PM >> On 1/27/2012 8:08 AM, t.petch wrote: >> I do not see it in the I-D, about what, if anything, this I-D expects to > change >> with the parameters currently in use. >> >> If you think that's a problem, please explain why and offer some text to cover > it. > > Add at the end of the Introduction paragraph 2 > 'This document makes no recommendation as to whether existing X- parameters > should continue to be used or should be migrated to a format without the X-." > > because otherwise this obvious question is left in midair. > > Tom Petch >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> >> . > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Tue Jan 31 10:11:16 2012 Return-Path: <stpeter@stpeter.im> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EBE21F8512 for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 10:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-sJfS1-md2k for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 10:11:15 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2E21F84FE for <apps-discuss@ietf.org>; Tue, 31 Jan 2012 10:11:13 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5AEB440058; Tue, 31 Jan 2012 11:21:17 -0700 (MST) Message-ID: <4F282EBF.60800@stpeter.im> Date: Tue, 31 Jan 2012 11:11:11 -0700 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <002501ccdf64$8db56220$4001a8c0@gateway.2wire.net> <4F2819DD.8060008@dcrocker.net> In-Reply-To: <4F2819DD.8060008@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss <apps-discuss@ietf.org> Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 Jan 2012 18:11:16 -0000 Fine with me as well, added to my working copy. On 1/31/12 9:42 AM, Dave CROCKER wrote: > wfm. > > d/ > > On 1/30/2012 10:33 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Dave CROCKER"<dhc@dcrocker.net> >> To: "t.petch"<ietfc@btconnect.com> >> Cc:<apps-discuss@ietf.org> >> Sent: Friday, January 27, 2012 6:33 PM >>> On 1/27/2012 8:08 AM, t.petch wrote: >>> I do not see it in the I-D, about what, if anything, this I-D expects to >> change >>> with the parameters currently in use. >>> >>> If you think that's a problem, please explain why and offer some text >>> to cover >> it. >> >> Add at the end of the Introduction paragraph 2 >> 'This document makes no recommendation as to whether existing X- >> parameters >> should continue to be used or should be migrated to a format without >> the X-." >> >> because otherwise this obvious question is left in midair. >> >> Tom Petch >>> >>> d/ >>> -- >>> >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> >>> From randy@psg.com Tue Jan 31 13:28:16 2012 Return-Path: <randy@psg.com> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5821F856A; Tue, 31 Jan 2012 13:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnLyrekxFlsP; Tue, 31 Jan 2012 13:28:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E270121F8569; Tue, 31 Jan 2012 13:28:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1RsLFM-0000kJ-Pr; Tue, 31 Jan 2012 21:28:12 +0000 Date: Wed, 01 Feb 2012 06:28:11 +0900 Message-ID: <m2y5snlfys.wl%randy@psg.com> From: Randy Bush <randy@psg.com> To: Lisa Dusseault <lisa.dusseault@gmail.com> In-Reply-To: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com> References: <CAEi+uC6repb=dgZ9wr4bJDX--5-n+RN1p4vNr7aqHyyDGBR5SQ@mail.gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-rpki-rtr.all@tools.ietf.org, apps-discuss@ietf.org, IESG <iesg@ietf.org> Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 31 Jan 2012 21:28:16 -0000 hi lisa, > I noted that this draft is clear and mature for a v0 protocol. thanks > I'm not qualified to judge the tradeoffs between supporting unprotected > TCP, waiting for TCP-AO, or doing something else, but I did note this had > been extensively discussed during IETF last call. > > I read this section and then made some inferences: > > - Only a human administrator can tell if a collection of routers and > caches using RPKI are "on the same trusted and controlled network" > - A human administrator would configure the routers and caches to use TCP, > based on their trust of the local network. > - A router would not attempt to use the RPKI-rtr port with unprotected TCP > unless it was configured by the human administrator to do so > - Thus, there is not a downgrade attack unless a human is involved in the > decision to downgrade the security configuration you are basically correct. > I also infer that while a cache implementation MUST generically implement > unprotected TCP as a transport, that an instance of a cache may well be > configured simply not to respond to TCP requests on the RPKI-rtr port. definitely > Section 7.2 (TLS transport) > > It's not clear to me why routers would need to provide a client certificate > to caches, because I had not assumed that the data transported in RPKI-RTR > was sensitive, only that it needed to be valid and authorized. I'm guessing > it has something to do with being able to manage load on very central > caches by dropping requests from unauthorized routers, which would be > either maliciously or unintentionally configured to use a cache that was > not set up to handle the load of those unauthorized routers. exactly. > If this is a correct guess, I wonder if it would be helpful to be a > bit more explicit about this possibility? Will there need to be an > error code added, to be used when a cache has to reject an > unauthorized router request? no error code as no session to transport it. but explaining why the defense would be good. thanks. but, truth be told, no implementors are playing tls. given peter's concerns about tls, we would consider just dropping it if it is not too much of a change at this late date. randy From yaojk@cnnic.cn Tue Jan 31 16:51:51 2012 Return-Path: <yaojk@cnnic.cn> X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43221F84CF for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 16:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.831 X-Spam-Level: X-Spam-Status: No, score=-99.831 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAKwGvutqb-f for <apps-discuss@ietfa.amsl.com>; Tue, 31 Jan 2012 16:51:51 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id F2EED21F84C8 for <apps-discuss@ietf.org>; Tue, 31 Jan 2012 16:51:49 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 01 Feb 2012 08:51:47 +0800 Message-ID: <CD7FEE793213438390EA4583613C109E@LENOVO47E041CF> From: "Jiankang YAO" <yaojk@cnnic.cn> To: <apps-discuss@ietf.org> References: <20111209150834.9990.60560.idtracker@ietfa.amsl.com> Date: Wed, 1 Feb 2012 08:51:49 +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.6157 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss> List-Post: <mailto:apps-discuss@ietf.org> List-Help: <mailto:apps-discuss-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 01 Feb 2012 00:51:52 -0000 SSBsb29rZWQgdGhyb3VnaCB0aGUgZHJhZnQuDQpUaGUgZWRpdG9yIHBvaW50ZWQgb3V0IHRoZSBm b2xsb3dpbmcgdHdvIGlzc3VlcyBpbiB0aGUgZHJhZnQsIHdoaWNoIG5lZWQgdGhlIFdHIHRvIHNv bHZlLg0KDQpJc3N1ZSAxKUluIHRoZSBzZWN0aW9uIDIuMSBvZiB0aGUgZHJhZnQsDQoNCiAgICAg YWJvdXQtdG9rZW4gPSAqKCB1bnJlc2VydmVkIC8gcGN0LWVuY29kZWQgKQ0KICAgICAgICAgICAg ICAgOyBmb3IgdGhlIFdHIGRpc2N1c3Npb246IHRoZSBwb3NzaWJsZSB2YXJpYW50cyBhcmU6DQog ICAgICAgICAgICAgICA7ID0gKnBjaGFyICAgICBvciA9IHNlZ21lbnQNCiAgICAgICAgICAgICAg IDsgPSAxKnBjaGFyICAgIG9yID0gc2VnbWVudC1ueg0KICAgICAgICAgICAgICAgOyA9IHNlZ21l bnQtbnotbmMNCiAgICAgICAgICAgICAgIDsgdGhpcyBpcyB0byBiZSBkZWNpZGVkIGJ5IFdHLg0K DQogIFRoZSBlZGl0b3Igc3VnZ2VzdHMgdGhlIHdnIHRvIHNvbHZlIGl0Lg0KDQoNCklzc3VlIDIp IEZvciB0aGUgaWFuYSBjb25zaWRlcmF0aW9uOiA0LjIgQSBSZWdpc3RyeSBmb3IgUmVnaXN0ZXJl ZCBUb2tlbnMsDQp0aGUgZWRpdG9yIGFza3M6DQogIFtbZm9yIHRoZSBXRyBkaXNjdXNzaW9uOiAg SSwgYXMgdGhlIFdHIHBhcnRpY2lwYW50LCBhbSBjb252aW5jZWQgdGhhdA0KICAgd2UgZG8gbmVl ZCBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIGhlcmUuICBUaGlzIGlzIGEgYnVyZGVuLCBidXQgdGhp cw0KICAgKGFuZCB0aGUgZXhwZXJ0KSB3aWxsIGdpdmUgdXMgYSB3YXJyYW50eSB0aGF0IHRoZSBy ZWdpc3RlcmVkIHRva2VuIGlzDQogICByZWFsbHkgdXNlZnVsIGFuZCBpcyByZWFsbHkgcGFydCBv ZiBzb21lIHNlcmlvdXMgcHJvamVjdCwgcHJvYmFibHkNCiAgIHN0YW5kYXJkaXphdGlvbiBlZmZv cnQuICBJJ2QgbGlrZSB0aGlzIGFsc28gd291bGQgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KICAgV0cs IGFuZCB0aGUgV0cgd291bGQgY2hhbmdlIGl0cyBtaW5kLiAgKE1vcmVvdmVyLCBhcyBJIGRvbid0 IGV4cGVjdA0KICAgdGhlIHJlZ2lzdHJhdGlvbnMgdG8gYmUgdmVyeSBvZnRlbiwgdGhpcyB3b24n dCB0YWtlIGEgZ3JlYXQgZGVhbCBvZg0KICAgZXhwZXJ0cycgdGltZS4pXV0NCg0KDQpBbnkgY29t bWVudHMgYWJvdXQgdGhlc2UgMiBpc3N1ZXM/DQoNClRoYW5rcy4NCg0KSmlhbmthbmcgWWFvDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQpUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiA8YXBwcy1kaXNjdXNz QGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwOSwgMjAxMSAxMTowOCBQTQ0KU3Vi amVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLWFib3V0LXVyaS1zY2hlbWUtMDEu dHh0DQoNCg0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQo+IA0KPiBUaXRsZSAgICAgICAgICAgOiBUaGUgImFib3V0IiBVUkkg U2NoZW1lDQo+IEF1dGhvcihzKSAgICAgICA6IExhY2hsYW4gSHVudA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgTXlreXRhIFlldnN0aWZleWV2DQo+IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtYXBwc2F3Zy1hYm91dC11cmktc2NoZW1lLTAxLnR4dA0KPiBQYWdlcyAgICAgICAgICAg OiA3DQo+IERhdGUgICAgICAgICAgICA6IDIwMTEtMTItMDkNCj4gDQo+ICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgdGhlICJhYm91dCIgVVJJIHNjaGVtZSwgdGhhdCBpcyB3aWRlbHkgdXNlZA0K PiAgIGJ5IFdlYiBicm93c2VycyBhbmQgc29tZSBvdGhlciBhcHBsaWNhdGlvbnMgdG8gZGVzaWdu YXRlIGFjY2VzcyB0bw0KPiAgIHRoZWlyIGludGVybmFsIHJlc291cmNlcywgc3VjaCBhcyBzZXR0 aW5ncywgYXBwbGljYXRpb24gaW5mb3JtYXRpb24sDQo+ICAgaGlkZGVuIGJ1aWx0LWluIGZ1bmN0 aW9uYWxpdHksIGFuZCBzbyBvbi4NCj4gDQo+IA0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1E cmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1hcHBzYXdnLWFib3V0LXVyaS1zY2hlbWUtMDEudHh0DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSBy ZXRyaWV2ZWQgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1hcHBzYXdnLWFib3V0LXVyaS1zY2hlbWUtMDEudHh0DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmll czogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiBvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA==