From nobody Fri Aug 1 00:09:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362551A0417; Fri, 1 Aug 2014 00:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p97JqbBnq4YR; Fri, 1 Aug 2014 00:09:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6E1A0428; Fri, 1 Aug 2014 00:09:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801070908.13242.36774.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 00:09:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ns7O5BgKnoYMwuT68o1Z9D3k0g0 Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 07:09:17 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Aug 1 04:43:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D061A0AA2 for ; Fri, 1 Aug 2014 04:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBpnLzI318HC for ; Fri, 1 Aug 2014 04:43:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C60B1A0A99 for ; Fri, 1 Aug 2014 04:43:36 -0700 (PDT) Received: from pc6 (86.144.255.226) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 1 Aug 2014 11:43:33 +0000 Message-ID: <00ae01cfad7d$3eaa5020$4001a8c0@gateway.2wire.net> From: t.petch To: "Black, David" , , References: <8D3D17ACE214DC429325B2B98F3AE712077860DD21@MX15A.corp.emc.com> Date: Fri, 1 Aug 2014 12:39:19 +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-Originating-IP: [86.144.255.226] X-ClientProxiedBy: AM3PR03CA039.eurprd03.prod.outlook.com (10.141.191.167) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 029097202E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(164054003)(41584004)(51704005)(13464003)(377454003)(199002)(189002)(106356001)(4396001)(77156001)(42186005)(81542001)(81342001)(77096002)(62966002)(20776003)(95666004)(74502001)(64706001)(61296003)(76176999)(47776003)(83072002)(66066001)(104166001)(15202345003)(15975445006)(84392001)(33646002)(81686999)(2201001)(101416001)(21056001)(83322001)(89996001)(87286001)(86362001)(77982001)(88136002)(87976001)(99396002)(93916002)(50466002)(50986999)(102836001)(23756003)(92566001)(19580395003)(62236002)(44736004)(31966008)(575784001)(44716002)(85852003)(80022001)(105586002)(76482001)(46102001)(92726001)(74662001)(19580405001)(14496001)(85306004)(81816999)(79102001)(107046002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iwzzvOkVgzcxIeQUkU2HUxmkqdY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Gen-ART and OPS-Dir review ofdraft-ietf-appsawg-nullmx-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 11:43:40 -0000 ----- Original Message ----- From: "Black, David" To: ; ; ; Cc: "Black, David" ; ; Sent: Friday, July 25, 2014 3:45 PM Subject: [apps-discuss] Gen-ART and OPS-Dir review ofdraft-ietf-appsawg-nullmx-06 The -06 version of this draft addresses the topics raised in the Gen-ART review of the -05 version, except that Section 1 is still missing from the Table of Contents (possible xml2rfc problem?). Well it does say
so Section 1 is wilfully excluded. As to why, that I cannot determine:-) Tom Petch Summary: Ready with nits. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, July 17, 2014 12:39 AM > To: standards@taugh.com; mx0dot@yahoo.com; General Area Review Team (gen- > art@ietf.org); ops-dir@ietf.org > Cc: apps-discuss@ietf.org; ietf@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05 > > This is a combined Gen-ART and OPS-DIR review. > Boilerplate for both follows ... > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > Document: draft-ietf-appsawg-nullmx-05 > Reviewer: David L. Black > Review Date: July 16, 2014 > IETF LC End Date: July 17, 2014 > IESG Telechat Date: August 7, 2014 > > Summary: This draft is on the right track, but has open issues > described in the review. > > This draft is a short specification of a NULL MX resource record whose > publication in the DNS indicates that a domain does not accept email. > > I found one relatively minor issue. > > Minor Issues: > > Something is wrong with this paragraph in the Security Considerations section: > > In the unlikely event that a domain legitimately sends email but does > not want to receive email, SMTP servers that reject mail from domains > that advertise a NULL MX risk losing email from those domains. The > normal way to send mail for which a sender wants no responses remains > unchanged, by using an empty RFC5321.MailFrom address. > > Why is that treated as a security consideration? In light of the first > paragraph in Section 4.3 stating that it's acceptable for SMTP clients to > not send email to domains that publish NULL MX records, this text ought to > be recommending that such a domain (legitimately sends email but does not > want to receive email) SHOULD NOT publish a NULL MX record and SHOULD provide > an SMTP server that promptly rejects all email delivery attempt. It can > then further explain that not following the "SHOULD NOT" causes lost email > as described in the quoted text, and not following the "SHOULD" causes long > delivery timeouts as described in Section 2. I'd also suggest moving this > discussion to Section 4.3 so that it follows the first paragraph there. > > Nits: > > Section 1 is missing from Table of Contents. > > First paragraph in Section 4.1: > "address is not deliverable" -> "the email is not deliverable" > > Second paragraph in Section 4.1 assumes that all or most domains that > do not accept email also publish NULL MX records. That assumption should > be stated as part of the first sentence of the paragraph, as the immediately > preceding paragraph is about the benefits of individual domains publishing > NULL MX records. > > In Section 4.3, please provide text descriptions of the 550 reply code and > 5.1.2 enhanced status code. > > OLD > 550 reply code > NEW > 550 reply code (Requested action not taken: mailbox unavailable) [RFC5321] > > OLD > 5.1.2 enhanced status code > NEW > 5.1.2 enhanced status code (Permanent Failure, Bad destination system > address) > > idnits 2.13.01 didn't find anything to complain about. > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > A.1.1 Has deployment been discussed? > > Yes, and NULL MX records are already deployed in the DNS. > > A.1.5. Has the impact on network operation been discussed? > > Yes, in general, NULL MX records have significant operational > benefits as described in the draft. > > A.2. Do you anticipate any manageability issues with the specification? > > No. This is a minor extension to an existing use of DNS resource > records. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Aug 1 04:57:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F386E1A0ADC for ; Fri, 1 Aug 2014 04:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNjxq27SGxSm for ; Fri, 1 Aug 2014 04:57:03 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B441A0ABF for ; Fri, 1 Aug 2014 04:56:59 -0700 (PDT) Received: (qmail 63189 invoked from network); 1 Aug 2014 11:56:58 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Aug 2014 11:56:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e5.53db808a.k1407; i=johnl@user.iecc.com; bh=fCvt/jJZCAWCfVaGOvD5OG4xCQy4PFOg8GhTK3XLdXg=; b=V+lXRsAr9VCnVmS8TUHX8GEA0bTMiM6B+4Vd9MMtXbj4teiVMkbZc/PeiQSFNC1zbxMjBno/7qR6Z9cuTTUUNLJYdbW+56N+v8drj41Vmpeoz+MWNuajYZVUbuKgP7ZMgOl5ePe9Ek7BRPC8GPj99skhqRxveLsH6OnOw6xHSBesvGZVmFefg1BMYLzlmW4LobWC+Y+oc35VXmDL2atC1UoKNe5kRew2sby1qGrh2lRTTvJOmrFePibiv52uPj7f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e5.53db808a.k1407; olt=johnl@user.iecc.com; bh=fCvt/jJZCAWCfVaGOvD5OG4xCQy4PFOg8GhTK3XLdXg=; b=PbTt0CqkL0/09UHnRbXHLAH0IRo30ULUtN6D6qvj1PhE0idQk5ie2Lj/3n5W5WQqYtXLmRoM3pirnBE1LVju/VCm4KmD0Jf9HgJ8ejV6Db+0mHm9M9M6B0vgIIDMMSNZd3Ul7Ev2OyOLiK2KQ1a/xd+tJFCsizLX15dDxM83FC865w6TAM9EBBGbBITXGD62EaLaa2btDRC1h/lFzIGzvSZ+JB4CUR8rTcVT3USwUu0zUJbDbc9iSMdF4FgzXXXe Date: 1 Aug 2014 11:56:35 -0000 Message-ID: <20140801115635.20964.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <00ae01cfad7d$3eaa5020$4001a8c0@gateway.2wire.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/g93hfjhcGECrjjchbD_5VLmSQBg Subject: Re: [apps-discuss] Gen-ART and OPS-Dir review ofdraft-ietf-appsawg-nullmx-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 11:57:06 -0000 >
> >so Section 1 is wilfully excluded. As to why, that I cannot determine:-) I was under the impression that Conventions sections aren't usually in the TOC. But I am sure that our skilled and diligent RFC production center staff will make the style match whatever it's supposed to be. R's, John From nobody Fri Aug 1 06:36:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A5B1ABB31 for ; Fri, 1 Aug 2014 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj9BDPOV5XmF for ; Fri, 1 Aug 2014 06:36:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF6E1A0024 for ; Fri, 1 Aug 2014 06:36:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 21EA4FA00D5; Fri, 1 Aug 2014 13:36:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1406900160-23500-23499/12/21; Fri, 1 Aug 2014 13:36:00 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Fri, 1 Aug 2014 15:36:00 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <7BAE4A96-465C-47C4-9D09-4682D43784E1@isdg.net> References: <20140729174608.56886.qmail@joyce.lan> <136F89A6-26EB-4876-9678-BCBEF7645F95@isdg.net> <60474842-fc88-4e9c-92ce-129d53c24656@gulbrandsen.priv.no> <7BAE4A96-465C-47C4-9D09-4682D43784E1@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1rruNBYaHWtB0Q-mxGDqA3IOhJc Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 13:36:05 -0000 It's a fair point: Charters can be too restrictive. In this case I think that a restrictive charter is important to help prevent cancerous growth. That risk seems uncomfortably high even with a tight charter, so I think I'm going to ignore this draft, myself, and this is my last message on the subject. Arnt From nobody Fri Aug 1 11:08:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E11A02DB; Fri, 1 Aug 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVUm4Uk4NaS7; Fri, 1 Aug 2014 11:08:32 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8521B2796; Fri, 1 Aug 2014 11:08:31 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so4665696wgg.28 for ; Fri, 01 Aug 2014 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3kpjEZi3cGQCvz9O00B64Vt13SS4fNgX1fHstkAB3co=; b=Vqovyw1VcNznWTnplaT4KaS4HsWKHztMIYLTab5B7PURxuXy+tHg8M05P5+K5omjzI dgQz9ThTziirKzBZAlFBv5e1EDh1sZ5+Kd9nMT0/gJ1EaSOVb6yfMgAqmDponv8kkWC8 5GqHInxhZiS71ZAhmUbrVDvp+Owlm+UvE49dzuHfxtpxkUp+RJpNexccJLdXUPfNQo4D S1I5BZrQqrvl9n6O0Jm5fVxKu5uHCh3GIuWc7qPifPU+keJg4Easu1V04QEWJUh+N9hQ hc5/RvrELUDhfQMKQmCUpc7TSrt58tLfS1NsQV0H0TenpWYu/kNIRiDrplH9+iNnbkDk G6EA== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr10485263wja.37.1406916509385; Fri, 01 Aug 2014 11:08:29 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Fri, 1 Aug 2014 11:08:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Aug 2014 11:08:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7b450a7cc54d7b04ff954650 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KAA13ZUsw186W84b7PSOeCIaF1E Cc: draft-ietf-appsawg-email-auth-codes.all@tools.ietf.org, The IESG , IETF Apps Discuss , "secdir@ietf.org" Subject: Re: [apps-discuss] Secdir review of draft-ietf-appsawg-email-auth-codes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Aug 2014 18:08:39 -0000 --047d7b450a7cc54d7b04ff954650 Content-Type: text/plain; charset=UTF-8 Hi Paul, thanks for the review. On Fri, Aug 1, 2014 at 8:28 AM, Paul Wouters wrote: > I do have one question with respect to the temporary failure codes. > > For SPF Failure Codes, a distinction is made between an SPF validation > failure (X.7.22) and an SPF validation error (X.7.23). > > A failure is the result of a successful (SPF) check method to mark the > email message as failed. An error means the (SPF) method to check for > failure did not run successfully and it could not determine whether the > message should pass or fail. For example, an error in the (SPF) check > could be due to a temporary DNS problem. > > For the DKIM and Reverse DNS, which like SPF depends on a working DNS > resolver for the mail server, there is no such split made. These can > only return failures, not errors in determining success or failure. > > If there is value in indicating this distinction for SPF, I would assume > the same distinction would be useful for DKIM and Reverse DNS. If there > are good reasons not to do this, perhaps it would be good to explain > those reasons in the document along with some advise for implementors > on what (existing) extended message code to return in the case of > temporary DNS failures in the DKIM and Reverse DNS case. I think the case of interest for both is what to do when something malformed is discovered. In that respect, the two communities operate a little differently. Specifically, if a malformed SPF record is found in the DNS, the intent here is to reject the message with the newly-registered error code rather than something less precise. For DKIM, however, a malformed signature or key record typically leads to the message being delivered with an annotation (RFC7001, for example) that there was no valid signature on the message, rather than rejecting it. For rDNS, I suspect most MTAs use x.4.3 to report that condition, which is already registered. I imagine there's no harm in adding an error code for DKIM and maybe for rDNS. As the document already says, there's no compulsion to use them if operators choose to continue using whatever they're using today. -MSK --047d7b450a7cc54d7b04ff954650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul, thanks for the review.

On Fri, Aug 1, 2014 at 8:28 AM, Pau= l Wouters <paul@nohats.ca> wrote:
I do have one question with respect to the t= emporary failure codes.

For SPF Failure Codes, a distinction is made between an SPF validation
failure (X.7.22) and an SPF validation error (X.7.23).

A failure is the result of a successful (SPF) check method to mark the
email message as failed. An error means the (SPF) method to check for
failure did not run successfully and it could not determine whether the
message should pass or fail. For example, an error in the (SPF) check
could be due to a temporary DNS problem.

For the DKIM and Reverse DNS, which like SPF depends on a working DNS
resolver for the mail server, there is no such split made. These can
only return failures, not errors in determining success or failure.

If there is value in indicating this distinction for SPF, I would assume the same distinction would be useful for DKIM and Reverse DNS. If there
are good reasons not to do this, perhaps it would be good to explain
those reasons in the document along with some advise for implementors
on what (existing) extended message code to return in the case of
temporary DNS failures in the DKIM and Reverse DNS case.

I think the case of interest for both is what to do when something malf= ormed is discovered.=C2=A0 In that respect, the two communities operate a l= ittle differently.=C2=A0 Specifically, if a malformed SPF record is found i= n the DNS, the intent here is to reject the message with the newly-register= ed error code rather than something less precise.=C2=A0 For DKIM, however, = a malformed signature or key record typically leads to the message being de= livered with an annotation (RFC7001, for example) that there was no valid s= ignature on the message, rather than rejecting it.

For rDNS, I suspect most MTAs use x.4.= 3 to report that condition, which is already registered.

I imagine there's no harm in adding an error code= for DKIM and maybe for rDNS.=C2=A0 As the document already says, there'= ;s no compulsion to use them if operators choose to continue using whatever= they're using today.

-MSK
--047d7b450a7cc54d7b04ff954650-- From nobody Sat Aug 2 06:47:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16D31A0AAD for ; Sat, 2 Aug 2014 06:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh85dhcozgFY for ; Sat, 2 Aug 2014 06:46:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA361A0AA3 for ; Sat, 2 Aug 2014 06:46:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s72DkqxE018159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Aug 2014 06:46:55 -0700 Message-ID: <53DCEB4E.3040304@dcrocker.net> Date: Sat, 02 Aug 2014 06:44:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140718160344.52645.qmail@joyce.lan> In-Reply-To: <20140718160344.52645.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 02 Aug 2014 06:46:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qS4YkpJcbWRjWvCFNkwP-VqgqkY Cc: ned.freed@mrochek.com, John Levine Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 13:46:57 -0000 On 7/18/2014 9:03 AM, John Levine wrote: >>> I don't recall reading this in the document. It's a good point. IM personal >>> O it's more important than either 4.1, 4.2 and 4.3. Add it, please. >> >> I agree with Arnt here. Not having a code for this is an obvious omission, >> and this is chance to address it. > > Please send text, or at least a three part number. Shepherd hat: I haven't seen any follow-up to John's request, although support for adding an extended code looks pretty solid. It really would help for someone who is strongly in favor of adding the code to write up the necessary text, to be added to the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 3 09:49:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347231A0AE8 for ; Sun, 3 Aug 2014 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uCwHvk7mD6Y for ; Sun, 3 Aug 2014 09:49:40 -0700 (PDT) Received: from groups.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 913911A0AE7 for ; Sun, 3 Aug 2014 09:49:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3434; t=1407084577; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/9t+c4b8P/REgKpHXvkl+u00Bqg=; b=Z0AzEL5mWJpoSlRDEggP bofOmFfrCgFJpmnNVzH6hZmLzeeOsLkKyHVNfYZ3ACew4xen/ZlsxK92WclHxixd ngtocWK3Veta0fp+QqJGjarzTvDFtpx7N3faMlcHrSTAKEJZimf5r4d2fLKTSa2/ 4vshUqWLkE4UP5uGQzZTSt0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 03 Aug 2014 12:49:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2269679483.6846.3088; Sun, 03 Aug 2014 12:49:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3434; t=1407084313; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=72J1CX+ ZTAk7vNHc5ifPiZfJC8wO2/FxWH5biqARv0c=; b=aVqYDkm9r27q9qfOgQTnp8v AKSzl8IhbR2gM6fMXmWgWKXNMediXMZZ4Qn1bxmWVmUn4M3yhvmTj41E5ykG0+cq kLUFIFNIw/dZym6AyR5Eay16JRbFNesKAas4dwwLSmVdQUTmN+Hs8HdcuR18kxOk VSjQzvZ37QPOeRubNIcM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 03 Aug 2014 12:45:13 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 862160593.9.4852; Sun, 03 Aug 2014 12:45:12 -0400 Message-ID: <53DE681C.4080607@isdg.net> Date: Sun, 03 Aug 2014 12:49:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, apps-discuss@ietf.org References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> In-Reply-To: <53DCEB4E.3040304@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8N5fbRsUs0eu69PRvvgZGCS0wjc Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2014 16:49:45 -0000 On 8/2/2014 9:44 AM, Dave Crocker wrote: > On 7/18/2014 9:03 AM, John Levine wrote: >>>> I don't recall reading this in the document. It's a good point. IM personal >>>> O it's more important than either 4.1, 4.2 and 4.3. Add it, please. >>> >>> I agree with Arnt here. Not having a code for this is an obvious omission, >>> and this is chance to address it. >> >> Please send text, or at least a three part number. > > > Shepherd hat: > > I haven't seen any follow-up to John's request, although support for > adding an extended code looks pretty solid. > > It really would help for someone who is strongly in favor of adding > the code to write up the necessary text, to be added to the draft. > Currently, SMTP (RFC5321) current recommends 550 or 553. Reasons explained below, but 554 may be the better match based on documented specs. First some background ........ There has always been a long time resistance (for good reason) towards SMTP-based CBV "Call Back Verifiers" methods where a small footprint SMTP client is used to verify the validity of the 5321.Mail From address a.k.a Return Path or reverse-path at the SMTP transaction level. The NULL MX can be used as short circuiting method to minimize the CBV overhead where it is used. Currently, the CBV is one the highest payoff for fraud detection and can be found to be used abeit at the smaller scale despite the obvious IETF concerns about it. Our CBV currently uses a straight forward 550 rejection when the return path can not be validated. Based on 11 years of CBV usage, IMO, what would be more important to convey is *WHEN* the NULL MX can be performed; at the MAIL FROM state or the RCPT TO state. Each receiver site has a different rate of 55x user rejections at the RCPT TO level. For our site, since 2003, it can be a consistently high 50-60%. This translates to the 50-60% reduction in DNS MX lookup overhead when any DNS-based check can be delayed from MAIL FROM to RCPT TO, and that includes the SPF check where this optimization need was first discovered. However, this idea of delaying the return path check until the forwarding address is known was discussed in RFC5321 section 3.3: 3.3. Mail Transactions Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. In short, this is the closest thing we have to an IETF "sanctioned" logistic for checking reverse-path with a recommended response code. However, according to SMTP, probably 554 is a closer match for a NULL MX reason: SMTP (RFC5321) has the following example definitions for the three codes: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") So probably 554 would be the proper code for a a "No SMTP Service Here" NULL MX check operation. -- HLS From nobody Sun Aug 3 11:07:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE61A8BAF for ; Sun, 3 Aug 2014 11:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXQBElkoBUfg for ; Sun, 3 Aug 2014 11:07:20 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8B61A0B14 for ; Sun, 3 Aug 2014 11:07:20 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5A8A3FA013F; Sun, 3 Aug 2014 18:07:17 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1407089235-3336-3335/12/6; Sun, 3 Aug 2014 18:07:15 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Sun, 3 Aug 2014 20:07:15 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <53DCEB4E.3040304@dcrocker.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SD7PXKmmPEfNACuyjzT5c-ugDQY Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2014 18:07:23 -0000 I've changed my mind, btw. I haven't changed my mind in principle, but since I've said more than once that we obsess too much over minor matters of wording, I should restrain myself in such matters. Sorry. I think the text as it stands is good enough, and being good enough is what matters. That said, I'll suggest wording for response codes: Code: X.1.10 Sample Text: Recipient address has null MX Associated basic status code: 501 Description: This status code is returned when the associated address is marked as invalid using a null MX. Reference: [this document] Submitter: [author of this document] Change controller: IESG Code: X.7.26 Sample Text: Sender address has null MX Associated basic status code: 550 Description: This status code is returned when the associated sender address has a null MX, and the SMTP receiver is configured to reject mail from such sender (e.g. because it could not return a DSN). Reference: [this document] Submitter: [author of this document] Change controller: IESG Arnt From nobody Sun Aug 3 11:24:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4867B1A0B05 for ; Sun, 3 Aug 2014 11:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bURykFQu4qlx for ; Sun, 3 Aug 2014 11:24:10 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A91A0538 for ; Sun, 3 Aug 2014 11:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407090249; d=isode.com; s=selector; i=@isode.com; bh=8W5QwCM/eYaM1k3XKElpnrVQ8oOR27EO69HBO5bMTnw=; 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=PG8IL+IvTFqYGZ8DLnXm2o0GrnnRFsPJAw8LrMmWmu4cxdgQT3WdO0/yqCz0zP0Q2bftTn H1V5I7gbLJT6jWmD4Z92K4WzGxFjyzkOjCP4NL4uR7FxBkilj4SDgLjWyKS9HWORwkw3JI 0Ds0vYgm9pSOPqe61VEqA8meWVXjbpg=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 3 Aug 2014 19:24:09 +0100 Message-ID: <53DE7DA1.6060806@isode.com> Date: Sun, 03 Aug 2014 19:21:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: IETF Apps Discuss References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Eh2KPEV0XfsCoMWT95ROEPGqOzc Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2014 18:24:12 -0000 On 21/07/2014 17:32, Murray S. Kucherawy wrote: > Call For Adoption: draft-nottingham-http-problem > > Colleagues, > > This note begins a Call For Adoption for the above document to be > adopted as an APPSAWG working group item. The Call ends on August 8, > 2014. Colleagues, There was very little support for this document so far. Are people interested in working on this document in the APPSAWG? Thank you, Alexey, as a co-chair. > > Keep in mind that adoption of a document does not mean the document > as-is is ready for publication. It is merely acceptance of the > document as a starting point for what will be some later final product > of APPSAWG. The working group is free to make changes to the document > according to the normal consensus process. > > There was some favorable discussion toward adoption of this document > at IETF 90 in Toronto. We will factor this into the decision at the > close of this Call. > > Please reply on this thread with expressions of support or opposition, > preferably with comments, regarding accepting this as a work item of > APPSAWG (as opposed to some other venue). Feel free to include > discussion of constraints that the WG should consider with respect to > its mini-charter. From nobody Sun Aug 3 14:23:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF3F1B2796 for ; Sun, 3 Aug 2014 14:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUyJ7otBidmF for ; Sun, 3 Aug 2014 14:23:51 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E4B1B2792 for ; Sun, 3 Aug 2014 14:23:51 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so6084313qae.6 for ; Sun, 03 Aug 2014 14:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0R1HjeXwmbC/P9abInA+2OhhCaoeBxXIfBImiueWK+Q=; b=RQM/hc8/AjF/Imd3HLKmWO/+D+duj8Yk/YIYVdrh/sw7EOS4ess2D5eSSkLkixxd7o DSTGAWWWkS4GWmJ0zKmDzeeX5if0yJaDlAXyKSyUCl3Yg/7L0Z/EORSjZp3Zw83iE4Ph PGhC7n5fIziyyruuTJiMgtd0sn3Zy4IWkiYQe7P1rO9qLUy7dEPSEh9zscZk/xyLCFZ1 K/VRrdDBjAFfMDsX3s58lNpQRAN8vJxdY3s8O0lkVhQlpKdYhDVaPDbY05WS46GLt4t4 flXlkToo6C+nXbZs2orfL8Y2UDE/VnoSdte/hb9ncfGhT9NXE3ZD36A6D57UjPkdBSXk UrtA== MIME-Version: 1.0 X-Received: by 10.140.106.74 with SMTP id d68mr28664511qgf.103.1407101030754; Sun, 03 Aug 2014 14:23:50 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.139 with HTTP; Sun, 3 Aug 2014 14:23:50 -0700 (PDT) In-Reply-To: <53DE7DA1.6060806@isode.com> References: <53DE7DA1.6060806@isode.com> Date: Mon, 4 Aug 2014 07:23:50 +1000 X-Google-Sender-Auth: FhUOYpBJ0eZre6RTbftZDZ5a0XA Message-ID: From: Matthew Kerwin To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3LsvO2BE6LDRDfiHh9sCHafTO4o Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2014 21:23:54 -0000 On 04/08/2014, Alexey Melnikov wrote: > On 21/07/2014 17:32, Murray S. Kucherawy wrote: >> Call For Adoption: draft-nottingham-http-problem >> >> Colleagues, >> >> This note begins a Call For Adoption for the above document to be >> adopted as an APPSAWG working group item. The Call ends on August 8, >> 2014. > Colleagues, > There was very little support for this document so far. Are people > interested in working on this document in the APPSAWG? > This is my first post to the wg. I support adopting the draft; I've even implemented it in past APIs. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Sun Aug 3 16:25:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91351A0016 for ; Sun, 3 Aug 2014 16:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwgHjJBetYtg for ; Sun, 3 Aug 2014 16:25:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2931A0012 for ; Sun, 3 Aug 2014 16:25:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAY7SZ0BWW0001JS@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 3 Aug 2014 16:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407108041; bh=4lVigl6NzOMCkTBV4zKuO6FdScOyp2+XWtSzMdSR+J4=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=UbYviDXXfrJxsHLeGHH5+nybmesyXHI+9pUOPyPMyYW4pu+UG1IkWYgsCj+KdauEM fmbrLJa8Idd0HJ6QM3d+c6+9upLwyazDakLSwtH7Sq4/fvYMpsI88DLMGe4DQpKUBW +gSHsqaDQvI9xBzGw62xVCONWMPAPt48FAc/inmA= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAXUAI78RK0000XX@mauve.mrochek.com>; Sun, 03 Aug 2014 16:20:32 -0700 (PDT) Message-id: <01PAY7SXC9G80000XX@mauve.mrochek.com> Date: Sun, 03 Aug 2014 14:48:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 03 Aug 2014 20:07:15 +0200" References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VUX0ZvJYsN3ndavh0Jvl0AXmXUY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Aug 2014 23:25:39 -0000 > That said, I'll suggest wording for response codes: > Code: X.1.10 I have a mild reference for a X.4.Y code, but it's so mild I'm not going to bother making a case for it. > Sample Text: Recipient address has null MX > Associated basic status code: 501 This, OTOH, does need to change. RFC 1846 specifically defined the 521 code for the "host does not accept mail" case. I see no reason not to use it here. > Description: This status code is returned when the associated > address is marked as invalid using a null MX. > Reference: [this document] > Submitter: [author of this document] > Change controller: IESG > Code: X.7.26 > Sample Text: Sender address has null MX > Associated basic status code: 550 > Description: This status code is returned when the associated > sender address has a null MX, and the SMTP receiver > is configured to reject mail from such sender (e.g. > because it could not return a DSN). > Reference: [this document] > Submitter: [author of this document] > Change controller: IESG This one is hard to classify from a code perspective, but 7 looks as good as any other choice. Ned From nobody Sun Aug 3 22:39:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB021B286D for ; Sun, 3 Aug 2014 22:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.303 X-Spam-Level: X-Spam-Status: No, score=-12.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S24a03EKk3B8 for ; Sun, 3 Aug 2014 22:39:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260D51B2863 for ; Sun, 3 Aug 2014 22:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1125; q=dns/txt; s=iport; t=1407130761; x=1408340361; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/O4+w8VvIZ6Qc5V+dnzSEbEf4i3sPA0owRf4ret7KpU=; b=DAadRjS7eQ9FTUa3VppmBkRuQu656vL4cAs4YFG2agkEfG/ANIVmzYZy ej77gW1vLGniXaas45hG5Y01Tpv2Q7qoV0kMN//2jQ8FU9dmIzZGqGUWd +2eH13ZZHqvoX1kwjsxvfbAAQLV3hLAmGS5YlVVAkKM2ID5DjwFLGbva6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAAkc31OtJssW/2dsb2JhbABbDocg0HABgS53hAMBAQEDAR0GDwFFEQsYAgIFFgsCAgkDAgECAUUGAQwIAQGINgiue5ZtF4EsjT4QAgFWgnmBUgEEnAaHI408gwtEOw X-IronPort-AV: E=Sophos;i="5.01,796,1400025600"; d="scan'208";a="131727430" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 04 Aug 2014 05:39:18 +0000 Received: from [10.61.194.69] ([10.61.194.69]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s745dHxR026859; Mon, 4 Aug 2014 05:39:18 GMT Message-ID: <53DF1C8B.3070604@cisco.com> Date: Mon, 04 Aug 2014 07:39:23 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , John Levine , apps-discuss@ietf.org References: <20140724145814.38511.qmail@joyce.lan> <53D1AC5C.3050706@it.aoyama.ac.jp> In-Reply-To: <53D1AC5C.3050706@it.aoyama.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4jUr1k9SEMYtJzIw-J5xSdGv-RM Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 05:39:23 -0000 Martin, On 7/25/14, 3:01 AM, "Martin J. Dürst" wrote: > I know that two efforts in this space at W3C have produced specs, but > not much in terms of deployment as far as I know. I have learned from > Ted that earlier efforts at IETF also didn't work out well. In fact it was Ted's note that generated the myriad of mail you complain about below. Do you have any comments about the substance of those responses? > > But independent from this, having observed the discussion over the > past few days, I think that the topic already has and will continue to > generate too much mail to be appropriate for the WG and this list, and > take away valuable resources from other work. > > I therefore oppose adoption of this document by the WG. If your argument is that the work is unimportant or technically unsound, then that is one thing. But judging adoption solely by volume of email messages says nothing to its technical suitability for adoption, and the volume of email perhaps argues precisely the opposite, that this is an important area to many people (otherwise nobody would care). Eliot From nobody Sun Aug 3 23:08:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC91B286D for ; Sun, 3 Aug 2014 23:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UujcBMS2Ev5 for ; Sun, 3 Aug 2014 23:08:20 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908A01B2868 for ; Sun, 3 Aug 2014 23:08:20 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so7044243wev.26 for ; Sun, 03 Aug 2014 23:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LK3MPP7RXFNi1ujqVfZQir/sNXlmftR5tIvNKEtc4ms=; b=jsoj6scz58Nm2kRCW3U8p4+kVw03ndwF+mYNF8hrxkH4se1UsnVu/2RfeuCjWiWa6e 9Yz7rbNh8X+c7DFhqrkC+QiSzUIPza4pU5PqVLOd0/VvoQOKYyT1auF+6rQaBaZDwIwh oKa6fM09vsUcQUTYNVmdICzk4f0yMgmeDwfNfY0J2oK6ifwNNMDHtKZNTzsVZi538JGn 7J8O+HRrO2Oqob3MnuW8cIZ3AkWfzIEmVORDblK9/f1SREGmaH7bGMCyBfXIcS3FiG5Z 0//HiBeOdinplB25vWxETPvPQcBeOg+UrNxglsB++q8VsVABeSiKIoWQW98/EjqJx5xX fcaQ== MIME-Version: 1.0 X-Received: by 10.180.10.166 with SMTP id j6mr26855208wib.73.1407132499114; Sun, 03 Aug 2014 23:08:19 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Sun, 3 Aug 2014 23:08:18 -0700 (PDT) In-Reply-To: <53DF1C8B.3070604@cisco.com> References: <20140724145814.38511.qmail@joyce.lan> <53D1AC5C.3050706@it.aoyama.ac.jp> <53DF1C8B.3070604@cisco.com> Date: Sun, 3 Aug 2014 23:08:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11c24412c3011904ffc7906a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nhYAFvYLxzlhaingWjwCvbjLWLk Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 06:08:23 -0000 X-List-Received-Date: Mon, 04 Aug 2014 06:08:23 -0000 --001a11c24412c3011904ffc7906a Content-Type: text/plain; charset=UTF-8 On Sun, Aug 3, 2014 at 10:39 PM, Eliot Lear wrote: > > I therefore oppose adoption of this document by the WG. > > If your argument is that the work is unimportant or technically unsound, > then that is one thing. But judging adoption solely by volume of email > messages says nothing to its technical suitability for adoption, and the > volume of email perhaps argues precisely the opposite, that this is an > important area to many people (otherwise nobody would care). > I took Martin's comment as meaning the scope of this work is bigger than what's intended in terms of APPSAWG's charter, not that the work is unimportant or the proposal unsound. Indeed, in retrospect, taking on WebFinger as an APPSAWG item might not have been such a great idea because it turned out to be a large project rather than a small one; it may have warranted its own working group, especially since our current ADs like the idea of spinning up dedicated, short-lived working groups for such projects. -MSK --001a11c24412c3011904ffc7906a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 3, 2014 at 10:39 PM, Eliot Lear <lear@cisco.com<= /a>> wrote:
> I therefore oppose adoption of this document by the WG.

If your argument is that the work is unimportant or technically unsou= nd,
then that is one thing. =C2=A0But judging adoption solely by volume of emai= l
messages says nothing to its technical suitability for adoption, and the volume of email perhaps argues precisely the opposite, that this is an
important area to many people (otherwise nobody would care).

I took Marti= n's comment as meaning the scope of this work is bigger than what's= intended in terms of APPSAWG's charter, not that the work is unimporta= nt or the proposal unsound.=C2=A0 Indeed, in retrospect, taking on WebFinge= r as an APPSAWG item might not have been such a great idea because it turne= d out to be a large project rather than a small one; it may have warranted = its own working group, especially since our current ADs like the idea of sp= inning up dedicated, short-lived working groups for such projects.

-MSK
--001a11c24412c3011904ffc7906a-- From nobody Sun Aug 3 23:12:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66E1A0AC3 for ; Sun, 3 Aug 2014 23:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRXbyNW40G4B for ; Sun, 3 Aug 2014 23:12:23 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DECF1A0183 for ; Sun, 3 Aug 2014 23:12:23 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so6937264wgh.13 for ; Sun, 03 Aug 2014 23:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wUUHPEFjJts+Z/xHc+kPlniZukcitKwC3QjZ3BMinSY=; b=KxRuuPxsOjZfPLxqHzPctS2XXl0QjcAujCdm+TRuO5jXvNTR/KX8/sp6DXnEqOrp2X iyoL7030NFja0QFNh1qV/rjC/8JMV56Zznb2r6PYUpoQZtZ0E7n5gfPDH6mb7/J9AzcT cw5GfQgmGdTfOfBNRtMoJiJL7VT0X2Kg9yNYXritE1KvMGbw1P96JEVYxMhcAyUb2SHb OrqKmDm1VAvLopikxciW5V1lWfXM9P6OpiwrFyCvJMD/XsFnY4+HlFuCuzSRUL16wTdW INjJkyZmDUIM4rI6ukJJUSTFutzNxStZh7UmGbWlQsNML06gTGSzIz/SKqiv3UPAxD69 0W+w== MIME-Version: 1.0 X-Received: by 10.180.10.166 with SMTP id j6mr26882787wib.73.1407132741990; Sun, 03 Aug 2014 23:12:21 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Sun, 3 Aug 2014 23:12:21 -0700 (PDT) In-Reply-To: <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> Date: Sun, 3 Aug 2014 23:12:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c244123d01d604ffc79f54 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/maKbZ-MbIVXg8gHvfScDQVP32Ng Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 06:12:25 -0000 --001a11c244123d01d604ffc79f54 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard wrote: > Just wanted to add some observations that I made at the APPSAWG > presentation: > While reviewing our open calls for adoption, I just noticed that this document currently requests Informational status. Why not Proposed Standard? -MSK --001a11c244123d01d604ffc79f54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard <dev+iet= f@seantek.com> wrote:
Just wanted to add some observations that I = made at the APPSAWG presentation:

While= reviewing our open calls for adoption, I just noticed that this document c= urrently requests Informational status.=C2=A0 Why not Proposed Standard?
-MSK
--001a11c244123d01d604ffc79f54-- From nobody Sun Aug 3 23:53:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CF41B287B for ; Sun, 3 Aug 2014 23:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeG-D5E8IGyr for ; Sun, 3 Aug 2014 23:53:43 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1BC1B2881 for ; Sun, 3 Aug 2014 23:53:40 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5D06DFA010B; Mon, 4 Aug 2014 06:53:37 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1407135216-3336-3335/12/7; Mon, 4 Aug 2014 06:53:36 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 4 Aug 2014 08:53:36 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <01PAY7SXC9G80000XX@mauve.mrochek.com> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oHCyeNmlczwWSKi3HKrMckJlXlQ Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 06:53:44 -0000 Ned Freed answers me: >> Sample Text: Recipient address has null MX >> Associated basic status code: 501 > > This, OTOH, does need to change. RFC 1846 specifically defined > the 521 code for > the "host does not accept mail" case. I see no reason not to use it here. 501 was actually a typo (I looked at what 5.1.2 does and misread the table I was looking at). I agree that 521 is better. Arnt From nobody Mon Aug 4 01:11:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D11B28B7 for ; Mon, 4 Aug 2014 01:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvJS3n4SsFHe for ; Mon, 4 Aug 2014 01:10:55 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 470C61B28AE for ; Mon, 4 Aug 2014 01:10:54 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 5D4C932E52A; Mon, 4 Aug 2014 17:10:51 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4e48_eb08_3598e25c_3897_4246_8d5c_1fa170d368f3; Mon, 04 Aug 2014 17:10:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8C4DCBF4BA; Mon, 4 Aug 2014 17:10:50 +0900 (JST) Message-ID: <53DF3FF9.5030403@it.aoyama.ac.jp> Date: Mon, 04 Aug 2014 17:10:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Eliot Lear References: <20140724145814.38511.qmail@joyce.lan> <53D1AC5C.3050706@it.aoyama.ac.jp> <53DF1C8B.3070604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ayhrKECa_JHkn7SZMIXbS_R8lt8 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 08:11:01 -0000 On 2014/08/04 15:08, Murray S. Kucherawy wrote: > On Sun, Aug 3, 2014 at 10:39 PM, Eliot Lear wrote: > >>> I therefore oppose adoption of this document by the WG. >> >> If your argument is that the work is unimportant or technically unsound, >> then that is one thing. But judging adoption solely by volume of email >> messages says nothing to its technical suitability for adoption, and the >> volume of email perhaps argues precisely the opposite, that this is an >> important area to many people (otherwise nobody would care). > I took Martin's comment as meaning the scope of this work is bigger than > what's intended in terms of APPSAWG's charter, not that the work is > unimportant or the proposal unsound. Indeed, in retrospect, taking on > WebFinger as an APPSAWG item might not have been such a great idea because > it turned out to be a large project rather than a small one; it may have > warranted its own working group, especially since our current ADs like the > idea of spinning up dedicated, short-lived working groups for such projects. Well, I didn't want to add more email to this topic, but just for the record, my personal preferences are: - Individual submission or independent stream (if we think that the document is just about describing a deployed 'solution') - Dedicated WG (if we think that this needs more work) - not proceeding at all (if we can't agree on either of the above) (mostly in this order) And yes, I acknowledge that the motivation (safe content for children,...) is important to many people. This includes me. But that doesn't mean that it's therefore automatically suitable for adoption as a work item for this WG. Regards, Martin. From nobody Mon Aug 4 02:21:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878871B2948 for ; Mon, 4 Aug 2014 02:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f31Z6ecRbk9S for ; Mon, 4 Aug 2014 02:20:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32C31B2946 for ; Mon, 4 Aug 2014 02:20:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEEMn-000FVo-9V; Mon, 04 Aug 2014 05:15:41 -0400 Date: Mon, 04 Aug 2014 05:20:42 -0400 From: John C Klensin To: Ned Freed , app-ads@tools.ietf.org Message-ID: <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> In-Reply-To: <01PAY7SXC9G80000XX@mauve.mrochek.com> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G5shU1-rB1i2O7DV0lvF4waLFE0 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Request to reclassify RFC 1846 to standard track (was: Re: Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 09:20:59 -0000 Hi. Ned's point about the use of code 521 has come up before and the use of a special code for "does not accept mail" seems, to put it mildly, obvious. RFC 1846, published in 1995, has been widely implemented and ceased being, in any sense, an experiment 15 or 18 years ago. Moving 1846 from Experimental to Standards Track seems to me to be closer to orderly housekeeping than a significant change in status. I suggest that, with the exception of being classified as Experimental today, RFC 1846 meets all of the criteria for a full standard. Noting that there are no outstanding errata, it might even be worthwhile for the IESG to save itself and the community time and energy by issuing a single Last Call, for advancement to Proposed Standard now and for automatic advancement to Internet Standard after the waiting period expired if no substantive errata appeared in that interval. In retrospect, I have no idea why we didn't just simply pick 521 up during DRUMS and incorporate it into RFC 2821. john p.s. the use of the generic 550 code for this seems inappropriate, especially if the whole idea of "null MX" seems important enough to standardize. --On Sunday, August 03, 2014 14:48 -0700 Ned Freed wrote: >> That said, I'll suggest wording for response codes: > >> Code: X.1.10 > > I have a mild reference for a X.4.Y code, but it's so mild I'm > not going > to bother making a case for it. > >> Sample Text: Recipient address has null MX >> Associated basic status code: 501 > > This, OTOH, does need to change. RFC 1846 specifically defined > the 521 code for > the "host does not accept mail" case. I see no reason not to > use it here. > >> Description: This status code is returned when >> the associated address is marked as invalid using a >> null MX. Reference: [this >> document] >> Submitter: [author of this document] >> Change controller: IESG > >> Code: X.7.26 >> Sample Text: Sender address has null MX >> Associated basic status code: 550 >> Description: This status code is returned when >> the associated sender address has a null MX, and the >> SMTP receiver is configured to >> reject mail from such sender (e.g. >> because it could not return a DSN). >> Reference: [this document] >> Submitter: [author of this document] >> Change controller: IESG > > This one is hard to classify from a code perspective, but 7 > looks as good > as any other choice. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 06:26:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693BE1B2AE4 for ; Mon, 4 Aug 2014 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_6Hbtxe5XVy for ; Mon, 4 Aug 2014 06:26:49 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D53C1B2ADF for ; Mon, 4 Aug 2014 06:26:48 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so7630547wgg.28 for ; Mon, 04 Aug 2014 06:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=abik75xH324ZLkF/OVRO4Y0nANUlCztdSMVhS1O6n74=; b=i9RMzi4Eb0NFL5z0+suqnyZaBGYQbf96p8f6d7BIb3pcgfGY0QKWhG4bafctbIt4yX UCIDlmSbuFmf6qGIGMZCA2roM79IiNsYU71+OcovzUr1IrKiSfnkiYoj5p3DL4PuJlnN iV9hvCUbA1+EiTHXtiBOV3R3IXdildORTuVFw6gG34hJVeDX45JjOXGoZAVlGTAjUYhX zWcvs8C+cP4nQdQ2ougo7VE9qzBcIotFdTfC0N3K2K+ipaYLwF4wZ9Dg8JKYGtW1Bw8z FXi8ExiLIC/20i/AWkwEvxDtrRdytDXfFpSuHR8UkF296JhJUpeNhhzVlOz+UsQHOtqI xR3A== MIME-Version: 1.0 X-Received: by 10.180.21.208 with SMTP id x16mr29674211wie.73.1407158806940; Mon, 04 Aug 2014 06:26:46 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 06:26:46 -0700 (PDT) In-Reply-To: <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> Date: Mon, 4 Aug 2014 06:26:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: John C Klensin Content-Type: multipart/alternative; boundary=047d7bb70cbed4927a04ffcdb010 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gSCHJbUChy4RhXWoeg7IKy5Q3fc Cc: Ned Freed , IETF Apps Discuss , "app-ads@tools.ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track (was: Re: Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 13:26:51 -0000 --047d7bb70cbed4927a04ffcdb010 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 2:20 AM, John C Klensin wrote: > Hi. > Ned's point about the use of code 521 has come up before and the > use of a special code for "does not accept mail" seems, to put > it mildly, obvious. RFC 1846, published in 1995, has been > widely implemented and ceased being, in any sense, an experiment > 15 or 18 years ago. > > Moving 1846 from Experimental to Standards Track seems to me to > be closer to orderly housekeeping than a significant change in > status. > > I suggest that, with the exception of being classified as > Experimental today, RFC 1846 meets all of the criteria for a > full standard. Noting that there are no outstanding errata, it > might even be worthwhile for the IESG to save itself and the > community time and energy by issuing a single Last Call, for > advancement to Proposed Standard now and for automatic > advancement to Internet Standard after the waiting period > expired if no substantive errata appeared in that interval. > > In retrospect, I have no idea why we didn't just simply pick 521 > up during DRUMS and incorporate it into RFC 2821. > As I understand it, we can't just reclassify it in-place but would instead need to publish a new version as a Proposed Standard and then promote it in the usual way. The main reason I think that is that this should officially update RFC 5321. Is that correct? -MSK --047d7bb70cbed4927a04ffcdb010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2014 at 2:20 AM, John C Klensin <john-ie= tf@jck.com> wrote:
Hi.
Ned's point about the use of code 521 has come up before and the
use of a special code for "does not accept mail" seems, to put it mildly, obvious. =C2=A0RFC 1846, published in 1995, has been
widely implemented and ceased being, in any sense, an experiment
15 or 18 years ago.

Moving 1846 from Experimental to Standards Track seems to me to
be closer to orderly housekeeping than a significant change in
status.

I suggest that, with the exception of being classified as
Experimental today, RFC 1846 meets all of the criteria for a
full standard. =C2=A0Noting that there are no outstanding errata, it
might even be worthwhile for the IESG to save itself and the
community time and energy by issuing a single Last Call, for
advancement to Proposed Standard now and for automatic
advancement to Internet Standard after the waiting period
expired if no substantive errata appeared in that interval.

In retrospect, I have no idea why we didn't just simply pick 521
up during DRUMS and incorporate it into RFC 2821.

=
As I understand it, we can't just reclassify it in-place but= would instead need to publish a new version as a Proposed Standard and the= n promote it in the usual way.=C2=A0 The main reason I think that is that t= his should officially update RFC 5321.=C2=A0 Is that correct?

-MSK
--047d7bb70cbed4927a04ffcdb010-- From nobody Mon Aug 4 06:45:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741201B2AFE; Mon, 4 Aug 2014 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3clGwyVJONHp; Mon, 4 Aug 2014 06:45:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 105FA1B2AF9; Mon, 4 Aug 2014 06:45:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804134532.27255.4505.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 06:45:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-zOEsb4NshFpN8YUtBw0cqUx5Ko Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Brian Haberman's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:45:33 -0000 Brian Haberman has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for including the RFC 6982 section! From nobody Mon Aug 4 07:18:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E979A1B2B29 for ; Mon, 4 Aug 2014 07:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeZsGrP4F1Zi; Mon, 4 Aug 2014 07:18:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3251B2B15; Mon, 4 Aug 2014 07:17:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804141748.13495.89254.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 07:17:48 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X18J2967MxTaWlaRunbCzXjNYIU Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 14:18:21 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ From nobody Mon Aug 4 07:19:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031761B2B20 for ; Mon, 4 Aug 2014 07:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVsvjep_NLPc for ; Mon, 4 Aug 2014 07:19:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465F21B2B1A for ; Mon, 4 Aug 2014 07:18:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.9/8.14.7) with ESMTP id s74EIrsj009206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 07:18:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Mon, 4 Aug 2014 07:18:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140724145814.38511.qmail@joyce.lan> <53D1AC5C.3050706@it.aoyama.ac.jp> <53DF1C8B.3070604@cisco.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DuqwyCFy2jrAuv3-EK3217TCwx8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 14:19:07 -0000 On Aug 3, 2014, at 11:08 PM, Murray S. Kucherawy = wrote: > I took Martin's comment as meaning the scope of this work is bigger = than what's intended in terms of APPSAWG's charter, not that the work is = unimportant or the proposal unsound. Indeed, in retrospect, taking on = WebFinger as an APPSAWG item might not have been such a great idea = because it turned out to be a large project rather than a small one; it = may have warranted its own working group, especially since our current = ADs like the idea of spinning up dedicated, short-lived working groups = for such projects. Except that most of the people on the thread don't seem to think that = the work is big. The "sure, let's publish it" group believe what the = author says, and that it is indeed small. The smaller number of people = who are objecting are the ones saying it is bigger; well, they're saying = it will be bigger if we give it a chance to be. FWIW, I'm definitely in the first group. It feels like people in the = second group are searching for danger and, because they are searching, = finding it. --Paul Hoffman= From nobody Mon Aug 4 07:23:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3851B2B15 for ; Mon, 4 Aug 2014 07:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahsqbXroc70Q for ; Mon, 4 Aug 2014 07:23:10 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639901B2B11 for ; Mon, 4 Aug 2014 07:23:10 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so11005434vcb.22 for ; Mon, 04 Aug 2014 07:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+i94zbi7rHIudzVAt5G2EC0Q0tk7PcaZri4H+7rFj+s=; b=fvCMkUBjFIOsvG5P7a0Nhh+xk7C/mOkyUv/mPnImyLVlSmBoiy1BJKXd2ilNcdguhr cRAWbUoRkC8Xf+gjgXvBOsm59Ollm75BnvQ2fc/LsLPmri3RKtkAR75rQKX5sCVJ1Nnn OH9gA1iOBDOHtGOMHeAp9PqpVzkaRMw5E9Vo2Gq/hbuEOqlRs4cW6ml5ChwCnhEc/IJA TSzQT3gVfBz+rffWl1g9zmzRUe7FHp3YgvnwEMSYleRLbjX8ZecxgN2+HKG42rp2MBXD sT0TlYiV9gXYQwwb8CRFDJuDTc9WPY5BntV68WV20wSokluVdPMYp5Ll5wxiGjT8CAsE PzTA== MIME-Version: 1.0 X-Received: by 10.220.144.147 with SMTP id z19mr23473627vcu.26.1407161773265; Mon, 04 Aug 2014 07:16:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Mon, 4 Aug 2014 07:16:13 -0700 (PDT) In-Reply-To: <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> Date: Mon, 4 Aug 2014 10:16:13 -0400 X-Google-Sender-Auth: WOUK7UGtbYTwR7i6-iEW0r6TkZ0 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6i7A-YlEHComvzN59pnQuYWL0tc Cc: Ned Freed , "apps-discuss@ietf.org" , app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track (was: Re: Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 14:23:13 -0000 John says: > I suggest that, with the exception of being classified as > Experimental today, RFC 1846 meets all of the criteria for a > full standard. Noting that there are no outstanding errata, it > might even be worthwhile for the IESG to save itself and the > community time and energy by issuing a single Last Call, for > advancement to Proposed Standard now and for automatic > advancement to Internet Standard after the waiting period > expired if no substantive errata appeared in that interval. This seems reasonable, and I can use this note to create a status-change document to make the request. A couple of points: 1. My reading of RFC 6410, Section 2.2, tells me that there is no longer a waiting period. Indeed, this document has waited long enough, having effectively been PS for years. I will consult with the IESG about whether that view is generally held, and whether we can do one four-week last call to go directly to IS (technically, to PS and to IS as one dual action), or we think we need two back-to-back last calls (I think that would be pointless, but some like to dot T's and cross I's differently). Murray says: > As I understand it, we can't just reclassify it in-place but would instead > need to publish a new version as a Proposed Standard and then promote it in > the usual way. The main reason I think that is that this should officially > update RFC 5321. Is that correct? 2a. If it does "update" 5321, that's just metadata, and that can be changed at the same time. If there are no substantive updates to the document, there's no reason to publish a revision. 2b. The reason it would "update" 5321, in the RFC-metadata meaning, would be if it said that all new implementations of SMTP MUST do this. If it's still an option, it doesn't update 5321. All that said, we have to decide whether we want to change the boilerplate, which currently says this: This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. We might decide that it's weird to have an Internet Standard with that boilerplate in it. Barry On Mon, Aug 4, 2014 at 5:20 AM, John C Klensin wrote: > Hi. > Ned's point about the use of code 521 has come up before and the > use of a special code for "does not accept mail" seems, to put > it mildly, obvious. RFC 1846, published in 1995, has been > widely implemented and ceased being, in any sense, an experiment > 15 or 18 years ago. > > Moving 1846 from Experimental to Standards Track seems to me to > be closer to orderly housekeeping than a significant change in > status. > > I suggest that, with the exception of being classified as > Experimental today, RFC 1846 meets all of the criteria for a > full standard. Noting that there are no outstanding errata, it > might even be worthwhile for the IESG to save itself and the > community time and energy by issuing a single Last Call, for > advancement to Proposed Standard now and for automatic > advancement to Internet Standard after the waiting period > expired if no substantive errata appeared in that interval. > > In retrospect, I have no idea why we didn't just simply pick 521 > up during DRUMS and incorporate it into RFC 2821. > > john > > p.s. the use of the generic 550 code for this seems > inappropriate, especially if the whole idea of "null MX" seems > important enough to standardize. > > > --On Sunday, August 03, 2014 14:48 -0700 Ned Freed > wrote: > >>> That said, I'll suggest wording for response codes: >> >>> Code: X.1.10 >> >> I have a mild reference for a X.4.Y code, but it's so mild I'm >> not going >> to bother making a case for it. >> >>> Sample Text: Recipient address has null MX >>> Associated basic status code: 501 >> >> This, OTOH, does need to change. RFC 1846 specifically defined >> the 521 code for >> the "host does not accept mail" case. I see no reason not to >> use it here. >> >>> Description: This status code is returned when >>> the associated address is marked as invalid using a >>> null MX. Reference: [this >>> document] >>> Submitter: [author of this document] >>> Change controller: IESG >> >>> Code: X.7.26 >>> Sample Text: Sender address has null MX >>> Associated basic status code: 550 >>> Description: This status code is returned when >>> the associated sender address has a null MX, and the >>> SMTP receiver is configured to >>> reject mail from such sender (e.g. >>> because it could not return a DSN). >>> Reference: [this document] >>> Submitter: [author of this document] >>> Change controller: IESG >> >> This one is hard to classify from a code perspective, but 7 >> looks as good >> as any other choice. >> >> Ned >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 07:25:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD371B2B15 for ; Mon, 4 Aug 2014 07:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXICmkvct3aL for ; Mon, 4 Aug 2014 07:25:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03EC1B2B11 for ; Mon, 4 Aug 2014 07:25:49 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04AF7509B8; Mon, 4 Aug 2014 10:25:47 -0400 (EDT) Message-ID: <53DF979D.8040500@seantek.com> Date: Mon, 04 Aug 2014 07:24:29 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tawlv1R7-AhtepQh3GgQuVIWgw0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 14:25:51 -0000 On 8/3/2014 11:12 PM, Murray S. Kucherawy wrote: > On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard > wrote: > > Just wanted to add some observations that I made at the APPSAWG > presentation: > > > While reviewing our open calls for adoption, I just noticed that this > document currently requests Informational status. Why not Proposed > Standard? > I am okay with Proposed Standard/Standards-Track status. However, I am also okay with Informational status. Section 3.1 of RFC 6838 effectively says that the registration proposal for a standards-tree registration (i.e., text/markdown) MUST be published as an RFC, which can be Standards Track or Informational (or BCP or Experimental). Informational is a somewhat lower bar than Standards-Track, and I would rather have a registration than have the doc mired in techno-politics and bikeshedding. :) Ned Freed (and others) made several good points about the nebulous-ness of the Markdown format. There is no canonical Markdown format that everybody agrees upon and looks to; the original Gruber specification leaves much ambiguous. But this proposal avoids adopting work on the Markdown format. If another person or organization can herd the cats, good for them. This proposal is primarily about getting the media type (and parameters) standardized, which would be useful to the community. If that fits in Standards-Track, then great. Otherwise, Informational will do just fine. Cheers, Sean From nobody Mon Aug 4 08:06:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374B31B2B2A for ; Mon, 4 Aug 2014 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jitG5dvXd9FF for ; Mon, 4 Aug 2014 08:06:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BEF1B2B07 for ; Mon, 4 Aug 2014 08:06:22 -0700 (PDT) Received: (qmail 40027 invoked from network); 4 Aug 2014 15:06:21 -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:user-agent; s=9c5a.53dfa16d.k1408; bh=/WAofG2kDSK0kzJBTtt5zFnI6WGS8Ey9gBq2vl1VLSU=; b=dfhy7iZfu2jNRSaPdssk8KUC3YwzYzWJsMdhRbZBSOtBYt5yyTguYdfdT6RBu+ldksaEdOBLyGxiuiGu9LD9fB78Ah/WILENdzUEZH04pu3gC3Ty31RwOa5ti8HKExNikmgPGdQKTMPViyRl6tAi5IIo2352hRb44XX3j9S3Pr6pNLFAnprEg4hc04WV3fn+Gf9h2wfsQ6p58Us56XEXNL72gp0Nk4Tc92sycD+tx49Uy14HZMGlut8WRZlm/hBs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9c5a.53dfa16d.k1408; bh=/WAofG2kDSK0kzJBTtt5zFnI6WGS8Ey9gBq2vl1VLSU=; b=MSSBmp7yX6+yatf1h1CX81kprq4+Cf9JerMCwHmO2ERWg2Y4Vk08yzefr2xDVTuGMPuITu0N+mSsosMrrmZqpa9n/BHt2hy1D0uZVaU7w1Jd7aZhdbwwaAhtd/+mD0cKT19be7nXS5gW6KQR/OaDjU7xyxwGrf0ywTmOQcKQShYNltLk01JbDYx+wV+1k0AFE/YmQqlvO/mKIaLHczBqX6Rq4VLy3mS4nT01C+CH2PQ1bWt/hOksMQfei1dSiNO7 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 04 Aug 2014 15:06:21 -0000 Date: 4 Aug 2014 11:06:21 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20140724145814.38511.qmail@joyce.lan> <53D1AC5C.3050706@it.aoyama.ac.jp> <53DF1C8B.3070604@cisco.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4GOX3Jc69PEPL6W7qjTNKR7MQ98 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 15:06:26 -0000 > I took Martin's comment as meaning the scope of this work is bigger than > what's intended in terms of APPSAWG's charter, ... There seem to be two very different responses to this draft. One is to take it as is, an existing one-bit flag that we can document as already implemented, the other is to take it as a starting point for yet another set of fine-grained content flags. (You can probably tell which one I prefer.) If we agree that it makes sense to do it the first way, we could easily do it in appsawg. Personally, I don't think the second approach is workable for reasons already discussed, but if we were to try, it'd be a swamp and a separate WG would keep it from drowning appsawg. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Aug 4 08:07:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A591B2B41; Mon, 4 Aug 2014 08:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TbfIHeiMbY5; Mon, 4 Aug 2014 08:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6731B2B40; Mon, 4 Aug 2014 08:06:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804150656.22944.73223.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 08:06:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/B9DZatFKuf2asb7-KgEvbalAHXQ Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:07:01 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objection to the publication of this document, but please consider my one suggestion below. (Also a homily for the delectation of future generations.) --- In section 1 This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] To the contrary, I think you should retain this paragraph and use it to record how/why this document obsoletes 6327 with the inclusion of a forward-pointer to section 8. --- I appreciate your use of RFC 6982 (because I get commission), but the information you included is not overwhelming or very detailed. Nothing to be done at this stage, but next time... From nobody Mon Aug 4 08:10:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072D31B2B4A; Mon, 4 Aug 2014 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CPIMJZP1VdV; Mon, 4 Aug 2014 08:10:52 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C2D1B2B48; Mon, 4 Aug 2014 08:10:51 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so5421770lbj.5 for ; Mon, 04 Aug 2014 08:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HMWa1oTUNtzLIoETtlkD2YDzEWGJmzeWuA402ogC/hE=; b=yB/d3WSIB4OYjj3CRGNelwU9Xh10bwAWGCOd5kaA6xHk/ODBarFQX6t4Hjli4x+RhK TXneuNJbxYQjwzXf5fwxROWRAskXc37nMzfY2Bt6ujPu3IXkMIrrZQWzqhyYDDrZvsZi jGu2nyWtJonOgZWMyrQdztem0hk1p/hhwWEvvIfrE+lf/JPPaPzSpntfeQAhWgZ6kws1 +sOBOQDvl4mYu0NhMlzPypzWXoOhzzO216hk664o4Dl0o2SxFiRrk2HKmrR8dg2N/Zhc 1uUwzUSyj17b0B/Kj77/NvYz1/EhUEe4lOGus+cpNsJdRG102kFTb1Ipr3q7Bx0bs1Xz BG4w== MIME-Version: 1.0 X-Received: by 10.153.4.37 with SMTP id cb5mr24628325lad.3.1407165049669; Mon, 04 Aug 2014 08:10:49 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Mon, 4 Aug 2014 08:10:49 -0700 (PDT) In-Reply-To: <20140804150656.22944.73223.idtracker@ietfa.amsl.com> References: <20140804150656.22944.73223.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 11:10:49 -0400 X-Google-Sender-Auth: 28-ZB46vQQ_jnWmsF_IQsOUPXfE Message-ID: From: Barry Leiba To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/G2q_o1mzAnASHpl3HDIHqEQ4ipY Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 15:10:53 -0000 > This extension was previously published as experimental. There is > now implementation experience, giving confidence in the protocol, so > this document puts the extension on the Standards Track, with some > minor updates that were informed by the implementation experience. > [[RFC Editor: Please remove this paragraph at publication.]] > > To the contrary, I think you should retain this paragraph and use it to > record how/why this document obsoletes 6327 with the inclusion of a > forward-pointer to section 8. Sure; if you think it's useful to retain, I have no objection to retaining it. So let it be written; so let it be done. > I appreciate your use of RFC 6982 (because I get commission), but the > information you included is not overwhelming or very detailed. Nothing > to be done at this stage, but next time... Yeh, unfortunately, that's all the information we had that could be included. Apparently some NDAs are involved, for reasons I can't fathom. Barry From nobody Mon Aug 4 08:37:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC671B2B7D for ; Mon, 4 Aug 2014 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx2bPKiB7WtV for ; Mon, 4 Aug 2014 08:36:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FF01B2B63 for ; Mon, 4 Aug 2014 08:36:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEKJW-000GJM-32; Mon, 04 Aug 2014 11:36:42 -0400 Date: Mon, 04 Aug 2014 11:36:37 -0400 From: John C Klensin To: Barry Leiba Message-ID: <49A3689A845833A378C22A26@JcK-HP8200.jck.com> In-Reply-To: References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V2ljQb2GhjHYxpLt-GaPD2_zyQU Cc: Ned Freed , apps-discuss@ietf.org, app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track (was: Re: Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 15:37:02 -0000 --On Monday, August 04, 2014 10:16 -0400 Barry Leiba wrote: > John says: >> I suggest that, with the exception of being classified as >> Experimental today, RFC 1846 meets all of the criteria for a >> full standard. Noting that there are no outstanding errata, >> it might even be worthwhile for the IESG to save itself and >> the community time and energy by issuing a single Last Call, >> for advancement to Proposed Standard now and for automatic >> advancement to Internet Standard after the waiting period >> expired if no substantive errata appeared in that interval. > > This seems reasonable, and I can use this note to create a > status-change document to make the request. A couple of > points: > > 1. My reading of RFC 6410, Section 2.2, tells me that there is > no longer a waiting period. Indeed, this document has waited > long enough, having effectively been PS for years. I will > consult with the IESG about whether that view is generally > held, and whether we can do one four-week last call to go > directly to IS (technically, to PS and to IS as one dual > action), or we think we need two back-to-back last calls (I > think that would be pointless, but some like to dot T's and > cross I's differently). When I read it last evening, I thought I saw a continuing waiting period requirement. I can no longer find it, and certainly prefer your interpretation (and any other interpretation that would avoid obviously pointless steps) > Murray says: >> As I understand it, we can't just reclassify it in-place but >> would instead need to publish a new version as a Proposed >> Standard and then promote it in the usual way. The main >> reason I think that is that this should officially update RFC >> 5321. Is that correct? > > 2a. If it does "update" 5321, that's just metadata, and that > can be changed at the same time. If there are no substantive > updates to the document, there's no reason to publish a > revision. > > 2b. The reason it would "update" 5321, in the RFC-metadata > meaning, would be if it said that all new implementations of > SMTP MUST do this. If it's still an option, it doesn't update > 5321. That is consistent with my interpretation. More important, the list of reply codes in 5321 (and 2821 and 821) has never been considered exclusive. That was, at least according to Postel long ago, the reason for the long discussion about code theory (now in RFC 5321 Section 4.2.1) is there. The introduction to Section 4.2 also says "An SMTP server SHOULD send only the reply codes listed in this document." but also "The list of codes that appears below MUST NOT be construed as permanent. While the addition of new codes should be a rare and significant activity, with supplemental information in the textual part of the response being preferred, new codes may be added as the result of new Standards or Standards-Track specifications." Those are obviously not completely consistent and I made a note a few years ago in the editing copy of 5321bis to clarify it. But I think the intent is still clear -- 5321 need not be replaced or updated to add a code. In any event, if 521 has appropriate standardization status by the time 5321bis appears, it is safe to assume that the code will be listed and discussed there, presumably obsoleting this document (another reason I hope to minimize time-wasting rituals). > All that said, we have to decide whether we want to change the > boilerplate, which currently says this: > > This memo defines an Experimental Protocol for the Internet > community. This memo does not specify an Internet standard > of any kind. > > We might decide that it's weird to have an Internet Standard > with that boilerplate in it. If that is the decision, I'll take the action to spin up a new version unless the original authors are inclined to do so. If we go to the trouble to generate a new version to fix the boilerplate, it should almost certainly explicitly update 5321 for hygienic reasons (in part because it would have a later date then 5321). I just don't think it is worth spinning up a new draft (and raising additional questions about fast-tracking the document into Internet Standard) for the purpose of noting the addition to the 5321 code list. Again, this all seems to me to be a housekeeping activity, not a substantive one. Please advise. john From nobody Mon Aug 4 08:53:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71F1A0362 for ; Mon, 4 Aug 2014 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk-Sedzrrkrt for ; Mon, 4 Aug 2014 08:53:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F1B1A0356 for ; Mon, 4 Aug 2014 08:53:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s74FrCdS030679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 08:53:15 -0700 Message-ID: <53DFABE6.8070004@dcrocker.net> Date: Mon, 04 Aug 2014 08:51:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> In-Reply-To: <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 04 Aug 2014 08:53:15 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bnXS67MTM4qxUNHKoyRLB854eJc Cc: apps-discuss@ietf.org, app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:53:18 -0000 Changed Subject notwithstanding, this sub-thread to the nullmx Last Call does not appear to contain any comments relevant to last call. If I've missed a request for specific action, concerning the nullmx draft, perhaps it could be repeated separately? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 4 08:55:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150921A037D; Mon, 4 Aug 2014 08:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKh6gv_rcp1V; Mon, 4 Aug 2014 08:55:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 501EF1A0376; Mon, 4 Aug 2014 08:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804155544.25477.94663.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 08:55:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iks4X3AbmeU4LoxC-o4m71Y0TCY Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:55:46 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-appsawg-email-auth-codes-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objeciton to the publication of this document. Here are two small editorial points you may want to consider. --- Whenever I see an Abstract like this one (and the corresponding paragraph in the Introduction) I wonder how it will read as an RFC rather than as an Internet-Draft. As part of an I-D it is fine to say "there is at present..." but in five years time, when you read the RFC it will seem really odd. Why not go for the more simple statement... This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures. --- I would prefer that the Abstract also indicated how this document updates RFC 7208. Thus... This document updates RFC 7208 to register code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures. From nobody Mon Aug 4 08:56:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBC91A038E; Mon, 4 Aug 2014 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2s0rbIMW2a8; Mon, 4 Aug 2014 08:56:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA81A037B; Mon, 4 Aug 2014 08:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804155624.25473.62108.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 08:56:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VNWaS0fJOjQN4gBg4UAak3GbZFY Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Brian Haberman's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:56:26 -0000 Brian Haberman has entered the following ballot position for draft-ietf-appsawg-email-auth-codes-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this document, but I have one comment that I would like considered. It may be useful to provide an explicit link to the IANA registry being updated. That could easily be done by including http://www.iana.org/assignments/smtp-enhanced-status-codes in the IANA Considerations section. It would also be clearer of section 6 referred to the SMTP Enumerated Status Codes registry rather than the SMTP Enhanced Status Code Registry. From nobody Mon Aug 4 09:29:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3081B2B9C for ; Mon, 4 Aug 2014 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh42xgz3BxSN for ; Mon, 4 Aug 2014 09:29:47 -0700 (PDT) Received: from catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C7FB41B2B9A for ; Mon, 4 Aug 2014 09:29:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1195; t=1407169776; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=a7GQ12K qDMhIvKSjYaM44eXn92k=; b=jSSd0Rhdp5JKtph8Y7bCf2/8yxGbdjDBCDF9KV5 TLBrr1hPLTfKKWy0VqhNW+EmkMM/HIgbteyaQZgEd3Iyt7Olo+Hox46dVsJW+gHW KnvK/vkjSP7f3nAohUjJuruaD3gPFShcqu599SZ2BISTSM/hu9JWR226SwL5b6CD BtC4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 04 Aug 2014 12:29:36 -0400 Received: from [192.168.1.162] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2354877073.7809.1508; Mon, 04 Aug 2014 12:29:35 -0400 References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <60783417-737F-4D74-9957-B43D6BDC43AB@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 4 Aug 2014 12:29:31 -0400 To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QxN-NNX7Zg_dAL3jiTuDZgVS9r4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 16:29:49 -0000 For the record, if we use the concept of "no mail/SMTP service" for this pro= tocol, then rfc5321 already has a 554 description: 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") Whether it's appropriate or not, this is what people will see and use as the= closest "reply code" unless this new null mx spec is specific. Let's keep i= n mind that extend reply codes is still OPTIONAL.=20 -- Hector Santos http://www.santronics.com > On Aug 4, 2014, at 2:53 AM, Arnt Gulbrandsen wr= ote: >=20 > Ned Freed answers me: >>> Sample Text: Recipient address has null MX >>> Associated basic status code: 501 >>=20 >> This, OTOH, does need to change. RFC 1846 specifically defined the 521 co= de for >> the "host does not accept mail" case. I see no reason not to use it here.= >=20 > 501 was actually a typo (I looked at what 5.1.2 does and misread the table= I was looking at). I agree that 521 is better. >=20 > Arnt >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From nobody Mon Aug 4 09:56:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1E21B2B13 for ; Mon, 4 Aug 2014 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t_Tqy6K3K02 for ; Mon, 4 Aug 2014 07:26:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E86491B2B15 for ; Mon, 4 Aug 2014 07:26:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E26384758A for ; Mon, 4 Aug 2014 14:26:47 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D5C3047584 for ; Mon, 4 Aug 2014 14:26:47 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 97AC22027 for ; Mon, 4 Aug 2014 14:26:47 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 4 Aug 2014 10:26:47 -0400 From: "Stevens, Matt" To: "apps-discuss@ietf.org" Date: Mon, 4 Aug 2014 10:26:41 -0400 Thread-Topic: draft-nottingham-http-problem in practice at Akamai Thread-Index: Ac+v8B723Uf6fqrOSjS3q0gyD22yYw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/axVFRHem2SS0KhlYVcQ4wTm-Abc X-Mailman-Approved-At: Mon, 04 Aug 2014 09:55:53 -0700 Subject: [apps-discuss] draft-nottingham-http-problem in practice at Akamai X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 14:26:51 -0000 regarding =B3Call for Adoption=B2 posting https://mailarchive.ietf.org/arch/msg/apps-discuss/2AI4dwxLgScBGax1n8mBBJ0q dm4 Akamai Technologies has adopted HTTP Problem specification internally and externally as a convention in our Platform web resource representations as published at https://developer.akamai.com/ We had previously issued error representations as application/json and are transitioning to application/problem+json For example: https://some-service-consumer.luna.akamaiapis.net/some-endpoint/some-resour ce HTTP/1.1 400 Bad Request Content-Length: 395 Date: Mon, 04 Aug 2014 14:07:40 GMT Connection: close Content-Type: application/problem+json { "type": "https://problems.luna.akamaiapis.net/-/pep-authn/request-error", "title": "Bad request", "status": 400, "detail": "Invalid endpoint", "instance":=20 "https://some-service-consumer.luna.akamaiapis.net/some-endpoint/some-resou rce", "method": "GET", "serverIp": "72.246.153.146", "clientIp": "80.67.64.116", "requestId": =B3123", "requestTime": "2014-08-04T14:07:40Z" } We have been using HTTP Problem in practice for a year externally and since early 2013 internally. regards, Matt Stevens Akamai Technologies From nobody Mon Aug 4 09:59:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCA1A0023 for ; Mon, 4 Aug 2014 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Nhbnkydo7Y for ; Mon, 4 Aug 2014 09:59:12 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007081A0019 for ; Mon, 4 Aug 2014 09:59:11 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XELbD-000GSe-KU; Mon, 04 Aug 2014 12:59:03 -0400 Date: Mon, 04 Aug 2014 12:58:58 -0400 From: John C Klensin To: dcrocker@bbiw.net Message-ID: In-Reply-To: <53DFABE6.8070004@dcrocker.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_3hfzQq4SQf9BEWgxz1pVSpjF08 Cc: apps-discuss@ietf.org, app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 16:59:14 -0000 --On Monday, August 04, 2014 08:51 -0700 Dave Crocker wrote: > Changed Subject notwithstanding, this sub-thread to the nullmx > Last Call does not appear to contain any comments relevant to > last call. The shift in focus is why I made the effort to change the subject line. The linkage is that the proposal to use 550 as the response code for this case was, I assume (perhaps incorrectly) because the nullmx spec authors did not consider 521 appropriate because of its nominal experimental status. After reading Ned's note and those of others, I felt it was time to clear up any further ambiguity by changing the status of RFC 1846. If anyone involved in nullmx believes that use of 521 requires a normative reference from it to 1846, so be it, but I have also already explained why I think that is unnecessary. If there is some part of the above you consider inappropriate, I'd appreciate an explanation as to why. > If I've missed a request for specific action, concerning the > nullmx draft, perhaps it could be repeated separately? The specific actions, both discussed in Ned's note in the original thread, were * To use the 521 code, not the 550 one. * An analysis about the subcode situation and a suggestion about the code to be used. I agree with Ned's analysis and did not feel a need to elaborate on it further. john From nobody Mon Aug 4 09:59:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332B11A003A; Mon, 4 Aug 2014 09:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7DEV2o7ttm2; Mon, 4 Aug 2014 09:59:15 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE641A0019; Mon, 4 Aug 2014 09:59:15 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so8083898wes.31 for ; Mon, 04 Aug 2014 09:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FqdAVx4B8GKyw2CXgNFZM3JSL5FZlMdqOHxMFPLbv7s=; b=W2Jrc1nOaEHu/x5835vWccMw66v+EfK0v7XbQ88ZDYlBpFSv22WZZr3rCEAhRvkF1j sxQtsbTD4cgjLqDTEREuNDKmZUQ+kXwrKtMCxoMPlTXHxyAgNgyJK0cGj9X/4d9Ur6nr LhsqAvqeLnQODuGSxiBOELGMi8QFQH0arEQl1PmFCxjVLocc8ygApiecV5wBZ9s9fkdp SVeAkQRjAFzknVE0/6iPLLhTG3XEAjupdb5aWqdWj8869mSUHIIvZLVpb1Dbo7h9GXun 6tP8QN7QMPhtqDf8DHRKAuGrVpa0sIWW6GqJyZmKqIQ61QdKsi/0q87aUsTRbDySI1Ia TEBg== MIME-Version: 1.0 X-Received: by 10.180.104.163 with SMTP id gf3mr31303951wib.24.1407171553464; Mon, 04 Aug 2014 09:59:13 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 09:59:13 -0700 (PDT) In-Reply-To: <20140804155544.25477.94663.idtracker@ietfa.amsl.com> References: <20140804155544.25477.94663.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 09:59:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Adrian Farrel Content-Type: multipart/alternative; boundary=14dae9cc914e951c0904ffd0a8dc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/icCUZvqELfpW0KM_BsKMF-XU0OM Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 16:59:17 -0000 --14dae9cc914e951c0904ffd0a8dc Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 8:55 AM, Adrian Farrel wrote: > > Why not go for the more simple statement... > > This document registers code points to allow status codes to be > returned to an email client to indicate that a message is being > rejected of deferred specifically because of email authentication > failures. > > Fine with me. > I would prefer that the Abstract also indicated how this document > updates RFC 7208. Thus... > > This document updates RFC 7208 to register code points to allow > status codes to be returned to an email client to indicate that a > message is being rejected of deferred specifically because of email > authentication failures. > Something like this would be fine with me, but SPF isn't the only affected protocol, so I'd probably just copy (or almost copy) the sentence at the end of Section 1 into the Abstract. Good enough? -MSK --14dae9cc914e951c0904ffd0a8dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2014 at 8:55 AM, Adrian Farrel <adrian@o= lddog.co.uk> wrote:

Why not go for the more simple statement...

=C2=A0 =C2=A0This document registers code points to allow status codes to b= e
=C2=A0 =C2=A0returned to an email client to indicate that a message is bein= g
=C2=A0 =C2=A0rejected of deferred specifically because of email authenticat= ion
=C2=A0 =C2=A0failures.


Fine with me.
=C2=A0
I would prefer that the Abstract also indicated how this document
updates RFC 7208. Thus...

=C2=A0 =C2=A0This document updates RFC 7208 to register code points to allo= w
=C2=A0 =C2=A0status codes to be returned to an email client to indicate tha= t a
=C2=A0 =C2=A0message is being rejected of deferred specifically because of = email
=C2=A0 =C2=A0authentication failures.

S= omething like this would be fine with me, but SPF isn't the only affect= ed protocol, so I'd probably just copy (or almost copy) the sentence at= the end of Section 1 into the Abstract.=C2=A0 Good enough?

-MSK
--14dae9cc914e951c0904ffd0a8dc-- From nobody Mon Aug 4 10:00:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6EE1A0023; Mon, 4 Aug 2014 10:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neb2_H-w1fR5; Mon, 4 Aug 2014 10:00:26 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173DB1A0019; Mon, 4 Aug 2014 10:00:25 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so8044494wes.14 for ; Mon, 04 Aug 2014 10:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w3A7QSbjWkRtQN/YVJnC58SrQYK7D2ivfx33GR7b2RI=; b=jZgLM6SkM02c9beTTWR7/cUD24lr+Lnd3hPcxPPHQuGYx02EH2VW0BRLDXUy+oqsXS 7JnzRXjbZCUSTqSUZXcZXRewF78420ecVdJy4EXkWNXmobXP+dKSq0LlBXUq5eoV82s2 588EoUvs3r5oZOTMRfCKIbuB7Bz57o03076cBND3AdNwcLyziqlrRIHoRVDdJTrhb3EL JRH6gSxdrqQQc7DTrUmCzOsmR/6uqdSEDRfptmfMjuLZagt9miXaF2ybYwpAnZFFJ0xs jBliNOYLtYzGq9IhTMgBTN0M0WrHWpT2seBjgcev1CZf8z/KQhC1Mr/5fhkIYnyPjN+/ cPpQ== MIME-Version: 1.0 X-Received: by 10.194.62.67 with SMTP id w3mr9165472wjr.32.1407171621398; Mon, 04 Aug 2014 10:00:21 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 10:00:21 -0700 (PDT) In-Reply-To: <20140804155624.25473.62108.idtracker@ietfa.amsl.com> References: <20140804155624.25473.62108.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 10:00:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b872e9aa1b00204ffd0acff Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RZc8dwLrs1YAlUDWjZZx_bN-kRE Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Brian Haberman's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 17:00:28 -0000 --047d7b872e9aa1b00204ffd0acff Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 8:56 AM, Brian Haberman wrote: > > It may be useful to provide an explicit link to the IANA registry being > updated. That could easily be done by including > http://www.iana.org/assignments/smtp-enhanced-status-codes in the IANA > Considerations section. It would also be clearer of section 6 referred > to the SMTP Enumerated Status Codes registry rather than the SMTP > Enhanced Status Code Registry. > > The former is a sub-registry of the latter, so it's probably better to name both. I haven't seen the URL appear in an RFC before (doesn't mean it hasn't happened). Has that become normal practice? -MSK --047d7b872e9aa1b00204ffd0acff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --047d7b872e9aa1b00204ffd0acff-- From nobody Mon Aug 4 10:14:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D61A005C for ; Mon, 4 Aug 2014 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTFgY00n0B80 for ; Mon, 4 Aug 2014 10:14:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3B11A0049 for ; Mon, 4 Aug 2014 10:14:34 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s74HEUjL012829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 10:14:33 -0700 Message-ID: <53DFBEF5.5060506@dcrocker.net> Date: Mon, 04 Aug 2014 10:12:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 04 Aug 2014 10:14:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mKikVVmT7JmLTH8kH8kYZFx6au8 Cc: apps-discuss@ietf.org, app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:14:38 -0000 On 8/4/2014 9:58 AM, John C Klensin wrote: > > > --On Monday, August 04, 2014 08:51 -0700 Dave Crocker > wrote: > >> Changed Subject notwithstanding, this sub-thread to the nullmx >> Last Call does not appear to contain any comments relevant to >> last call. ... > If there is some part of the above you consider inappropriate, > I'd appreciate an explanation as to why. > >> If I've missed a request for specific action, concerning the >> nullmx draft, perhaps it could be repeated separately? Ned's suggestion came before the re-labeling of the Subject line. My query was about the sub-thread with a new Subject line. I have not seen an action for nullmx requested in that sub-thread, other than a quick comment agreeing with Ned. However the sub-thread is about a separate document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 4 10:18:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A641A005C for ; Mon, 4 Aug 2014 10:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRrX1fHeNMiO for ; Mon, 4 Aug 2014 10:18:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16ECB1A0026 for ; Mon, 4 Aug 2014 10:18:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.9/8.14.7) with ESMTP id s74HIcq2032132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 10:18:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <53DE7DA1.6060806@isode.com> Date: Mon, 4 Aug 2014 10:18:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <865647D6-F491-4B71-8559-FCC41143B3A2@vpnc.org> References: <53DE7DA1.6060806@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eEPcJAAzaRoiGSz2I0mDORj9sQ0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 17:18:42 -0000 On Aug 3, 2014, at 11:21 AM, Alexey Melnikov = wrote: > There was very little support for this document so far. Are people = interested in working on this document in the APPSAWG? Sorry for the late reply. This seems like a fine, easy document for the = WG. I'm happy to review it. --Paul Hoffman= From nobody Mon Aug 4 10:25:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2CC1A0019 for ; Mon, 4 Aug 2014 10:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VjmI73DvV5v for ; Mon, 4 Aug 2014 10:25:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559581A0072 for ; Mon, 4 Aug 2014 10:25:10 -0700 (PDT) Received: (qmail 62108 invoked from network); 4 Aug 2014 17:25:06 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Aug 2014 17:25:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9dd.53dfc1f3.k1408; i=johnl@user.iecc.com; bh=Qak2gJDjt5WWwaTTebK8wrRFYiHw3grAFrbgNvrA0/E=; b=AmdrpNG2J4p03zYhQsTcOkvTTQZg7r1+oDfP7+0/84TepgtmLNi3EZd/bsijfh4+tr2YacTUwcNqvZIGFA0sxD4HFtII+N03woRbSvmB3Nc3dBhFDO5qcpGMpZC52PM5vaePdybJa9Dm/9IhaauWkDqCPcm5c124JVNydXvf7Bwb9s97CfnFcUN95IvNZNn7/npyb7jdz/+Pp01/yjRGGFCyllJu4Rf/7Oz3veSJW2YK1l+IbWnK5A25+UfdSMtb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9dd.53dfc1f3.k1408; olt=johnl@user.iecc.com; bh=Qak2gJDjt5WWwaTTebK8wrRFYiHw3grAFrbgNvrA0/E=; b=bnyG81/yn/0nfFtupw4RWEdSXJktZoYnKj1y6oQeLoWFLIn1ixzP7GRrYZ5vKxDUTt8/u/ZBQuaGM7qNIlW9G0AEWZUkLfTmBMPQLB/siiID8iZSSU5+c6zq4/+QMjeCzzR6c4ZMLZo2khBX9OJ82FOSQHfOQ6DEQzbWF6fpjeDWzXZ0KMmN8wtev4E8BgL2piOT0s9FLzzWBOxxowESIZV7D4W5y52Jbzw8FwAqwadL1j84a+WvfCd1dn0XMoqw Date: 4 Aug 2014 17:24:44 -0000 Message-ID: <20140804172444.2524.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <53DFABE6.8070004@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/piSD17lEG6Cx0Uz3K7u2OiUg5Gw Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 17:25:12 -0000 In article <53DFABE6.8070004@dcrocker.net> you write: > >Changed Subject notwithstanding, this sub-thread to the nullmx Last Call >does not appear to contain any comments relevant to last call. > >If I've missed a request for specific action, concerning the nullmx >draft, perhaps it could be repeated separately? The suggestion is to change section 4.1 so mail sent to a nullmx'ed domain gets a 521 rather than 550 rejection (e.g. at submission time.) That seems reasonable to me. As I understand it, if Barry can change RFC 1846 to standards track, I can refer to it without a downref issue. R's, John From nobody Mon Aug 4 10:31:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38201A004D; Mon, 4 Aug 2014 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiPJA3lYrqHZ; Mon, 4 Aug 2014 10:30:59 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C571A0019; Mon, 4 Aug 2014 10:30:58 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s74HUekl026945; Mon, 4 Aug 2014 18:30:40 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s74HUb2A026930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 18:30:38 +0100 From: "Adrian Farrel" To: "'Murray S. Kucherawy'" References: <20140804155544.25477.94663.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 4 Aug 2014 18:30:43 +0100 Message-ID: <052301cfb009$d2569e80$7703db80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0524_01CFB012.349F51B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG462pawuwkdP60ily5hoVlecAcBgNYqe9um9N3T7A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20860.000 X-TM-AS-Result: No--29.024-10.0-31-10 X-imss-scan-details: No--29.024-10.0-31-10 X-TMASE-MatchedRID: hwsFDxVJcFljDV//SvkH3sAmcZEx8XHJmU/t0AE6+TJ/sUNganJerSLN ypzUCknM314+hM1bAGum+APOZNZ+w0FP3WnsH2rKlVHM/F6YkvQfbG+50hrCQ1QM54jP4h792d8 mtRIRsUNipN+6GWfWqu6DaUCdUbEeYwXAgt8PtiB8Uw4r8ep8BoB84MMvKleaHEF4M2lVxHI8a1 q4OK4oC5RdJvk6Y2XpWqWOgjucQgVdoH9yElve02gws6g0ewz2IcCiCHZJTldB6C97myJg6+//v bMLiEkVnfCgnZR65gXocyiWIpet6KoO96Tfmapcndu3heVAxaMP4vBWNr0zgSA6eO+NDmAxJZ3D 0zKPh7H10yQNuo1OJZfucML7iAp6c1BeS/J6aN9dMrg609R9BKO4XjVpMlFdn+lpJmYuEaN7ltq yJvHgp/JOjUaxKXKqGSKDIgjU9nky499dCbQy8IoLoibgjVEX1WPYxCHVrqdgHzfrfdHEt4c0B5 OUL/u1M5qWMflCo4dwtismKfx+71mKiy1F9pgLuIwLnB3Aqp13Bf9JIqsoeA8YwboCQc88CE7se pEW6CvzbeV2VN8Li3ZBE86uj+Htoi8K/V7jzhlNVr4vdmCpztFpembubBCcuRjdZTD8Hxe7yLIk LI23qXb4Bm7FqQnLeKdvzrQKtCjA+jwY/tNg2xlLm7Fc/E3puacNrbMY+LT2CSbxI1C154dQPKM baT4RbDJKq/gJwbmkLSzpHNTR2kXs1WbxNtVLDrDTQZ5YEVp9LQinZ4QefK9dKZJ2VxiamTDwp0 zM3zp5ILrkKK3IDPOIcTdPr/txa4PS5F+3/FkZxVxDj3xSl7D+oldQRGSNftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zWXdqzT1eOINxZT2nTPqINBLXg0 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, 'The IESG' , 'IETF Apps Discuss' , 'SM' Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:31:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0524_01CFB012.349F51B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, please make the correct change, not just the one I dreamed up from = my limited understanding. =20 A =20 From: Murray S. Kucherawy [mailto:superuser@gmail.com]=20 Sent: 04 August 2014 17:59 To: Adrian Farrel Cc: The IESG; appsawg-chairs@tools.ietf.org; = draft-ietf-appsawg-email-auth-codes@tools.ietf.org; SM; IETF Apps = Discuss Subject: Re: [apps-discuss] Adrian Farrel's No Objection on = draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) =20 On Mon, Aug 4, 2014 at 8:55 AM, Adrian Farrel = wrote: Why not go for the more simple statement... This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures. =20 Fine with me. =20 I would prefer that the Abstract also indicated how this document updates RFC 7208. Thus... This document updates RFC 7208 to register code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures. =20 Something like this would be fine with me, but SPF isn't the only = affected protocol, so I'd probably just copy (or almost copy) the = sentence at the end of Section 1 into the Abstract. Good enough?=20 -MSK ------=_NextPart_000_0524_01CFB012.349F51B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, please make the correct = change, not just the one I dreamed up from my limited = understanding.

 

A

 

From: Murray S. = Kucherawy [mailto:superuser@gmail.com]
Sent: 04 August 2014 = 17:59
To: Adrian Farrel
Cc: The IESG; = appsawg-chairs@tools.ietf.org; = draft-ietf-appsawg-email-auth-codes@tools.ietf.org; SM; IETF Apps = Discuss
Subject: Re: [apps-discuss] Adrian Farrel's No = Objection on draft-ietf-appsawg-email-auth-codes-05: (with = COMMENT)

 

On Mon, = Aug 4, 2014 at 8:55 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:


Why not go for the more simple = statement...

   This document registers code points to = allow status codes to be
   returned to an email client to = indicate that a message is being
   rejected of deferred = specifically because of email authentication
  =  failures.

 

Fine with = me.
 

I would = prefer that the Abstract also indicated how this document
updates RFC = 7208. Thus...

   This document updates RFC 7208 to = register code points to allow
   status codes to be = returned to an email client to indicate that a
   message = is being rejected of deferred specifically because of email
  =  authentication failures.

 

Something like this would be fine with = me, but SPF isn't the only affected protocol, so I'd probably just copy = (or almost copy) the sentence at the end of Section 1 into the = Abstract.  Good enough?

-MSK

= ------=_NextPart_000_0524_01CFB012.349F51B0-- From nobody Mon Aug 4 10:39:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533F1A008C; Mon, 4 Aug 2014 10:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOa8cuYSDwu4; Mon, 4 Aug 2014 10:39:05 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEB41A0087; Mon, 4 Aug 2014 10:39:05 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so5725852lab.35 for ; Mon, 04 Aug 2014 10:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aLRsj3WLlmMLR+2Onho0I9t6vX+FBf8AYsNRGxWAV7M=; b=ewM6P4wN/FiTYimB6fpIKB6atlZtf//5Mqys6a1OrOY0wBN2SjY/RYfn94+kbaQyRX F3rTiw3ZRzyNuc+n2/p+Fix38geVroouIJk/YhsGnXw9MErWlawhAB60oKbA8/2YQPwl tGSqKSzXGgX44xtMgz+1qv4dsyz+YUCh/xuqfpj6F33y+ZIACOtPGRrEIFitJnlz7Gdt wkKRNM2LDaZsEvB9vt4jXkiJxlNxqUWV6viTM5SD4Xo5F6AYYVE/QtVKA/Sel6q8BXaM dQGde1uP8pjbsTZyMKE9/O8mpNpxkn0mAyL4UA4Lkgkuf6yRVDd6ghVVqv2ItABNnphU jiPQ== MIME-Version: 1.0 X-Received: by 10.112.161.201 with SMTP id xu9mr23618079lbb.59.1407173943510; Mon, 04 Aug 2014 10:39:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Mon, 4 Aug 2014 10:39:03 -0700 (PDT) In-Reply-To: References: <20140804155624.25473.62108.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 13:39:03 -0400 X-Google-Sender-Auth: -AjqlbMTv2Igu91ROcdorltkTqM Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q2tB2kkKrkJWBosz2L5f60DbXBo Cc: Brian Haberman , IETF Apps Discuss , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Brian Haberman's No Objection on draft-ietf-appsawg-email-auth-codes-05: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 17:39:06 -0000 > The former is a sub-registry of the latter, so it's probably better to name > both. That would be fine, though the URI would be sufficient to identify the main registry. > I haven't seen the URL appear in an RFC before (doesn't mean it hasn't > happened). Has that become normal practice? They're all over the place; sometimes they're used, and sometimes they're not. 5226bis actually suggest using them, to make it absolutely clear what registry you want -- and I suppose it also makes it easier for readers to find the registry. When we use them, we have to be sure to use the right one, which IANA says won't change. Brian gave the correct one. Barry From nobody Mon Aug 4 10:49:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A3D1A009C for ; Mon, 4 Aug 2014 10:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsMOAGptf5w1 for ; Mon, 4 Aug 2014 10:49:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5491A004D for ; Mon, 4 Aug 2014 10:49:18 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s74HnENs018422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 10:49:18 -0700 Message-ID: <53DFC719.8010004@dcrocker.net> Date: Mon, 04 Aug 2014 10:47:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20140804172444.2524.qmail@joyce.lan> In-Reply-To: <20140804172444.2524.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 04 Aug 2014 10:49:18 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bf6bgcllmek3R1Ok8k__4Miv1Hw Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:49:23 -0000 On 8/4/2014 10:24 AM, John Levine wrote: > The suggestion is to change section 4.1 so mail sent to a nullmx'ed > domain gets a 521 rather than 550 rejection (e.g. at submission time.) > That seems reasonable to me. > > As I understand it, if Barry can change RFC 1846 to standards track, > I can refer to it without a downref issue. This leads to a decision-three question: Is use of the code by the current draft worth making the /possible and eventual/ change in status of RFC 1846 worth the indeterminate delay for the current draft? Is it that important? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 4 10:57:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27F61A0091; Mon, 4 Aug 2014 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCACLfq_Jlsa; Mon, 4 Aug 2014 10:57:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD11C1A00A8; Mon, 4 Aug 2014 10:57:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804175709.16230.21454.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 10:57:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zJH7ommbStfxzEsdcE4u8xFXCVI Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:57:11 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2: "A server that supports this extension includes "MULTISEARCH" in its IMAP capability string." This jumped out at me as I would have expected a statement like this to be a normative requirement, rather than a statement of fact. From nobody Mon Aug 4 11:12:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2991A00FA; Mon, 4 Aug 2014 11:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5RkCrGt_I0T; Mon, 4 Aug 2014 11:12:17 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869641A00E6; Mon, 4 Aug 2014 11:11:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id e16so5810403lan.3 for ; Mon, 04 Aug 2014 11:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DlgTzLY4airX2QJizlLfqWbkmQHpci+VB3oZWE7C+FQ=; b=J3TZjEfw4UHC2bHxkynvs6CxvpkEzjF99skrquhhuU3ec9V3RTQq+RBCcI4n+6WXlW imGp7ecUCXfsUZ1oZSK3Go91Hw6YqT57oeP0jC5aK9JHNa9XRV2RBGZs8VVSBOdssEpE 1lTCp/XLVSFJjn4LO2HhaK3/0pEnAwkd6tH/FsPhL5ihs7Tavmyyss36nSKr3RJNAa9+ nfDJ5N1uB5hqZDCyaA98xLU8hglggaAsD1yAIpZWWNGB+Z6g2oDXsIvFrMXpIHubYVFx jA/BFhV/f+/1i0uke7scD0HPAjza6AKlzvsi9XzBeIxrfGAPgMHPLSPUQjdt9cw6cGQz 9jcw== MIME-Version: 1.0 X-Received: by 10.152.206.98 with SMTP id ln2mr25615724lac.45.1407175915838; Mon, 04 Aug 2014 11:11:55 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Mon, 4 Aug 2014 11:11:55 -0700 (PDT) In-Reply-To: <20140804175709.16230.21454.idtracker@ietfa.amsl.com> References: <20140804175709.16230.21454.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 14:11:55 -0400 X-Google-Sender-Auth: -cu-okcsULC8LqVLTOF0JVmvLMg Message-ID: From: Barry Leiba To: Alissa Cooper Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7BMI9j6R4LL2y2ACj949D5dw49Y Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 18:12:19 -0000 > "A server that supports this extension includes "MULTISEARCH" in its IMAP > capability string." > > This jumped out at me as I would have expected a statement like this to > be a normative requirement, rather than a statement of fact. Why is that not a normative requirement? It tells how the protocol works. If you don't do that, you're not doing this protocol. Maybe Pete and I should have a chat with you in Honolulu.... :-) Barry From nobody Mon Aug 4 11:34:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86E51A00DF for ; Mon, 4 Aug 2014 11:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id symr9ba19nDi for ; Mon, 4 Aug 2014 11:34:26 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6598C1A00D7 for ; Mon, 4 Aug 2014 11:34:26 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAZBX8U8PS000BBW@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 4 Aug 2014 11:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407176969; bh=EZFJzXKHT/CKlwDbGN6ePa6cQspnwFDS5IUtyVPZI3U=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=OMBUkMDBoGwWA4PchlhwR5QVMVo9lO3LABsahiwDJCosg4hptVN4KjSM+7wBqsyTL ROau8h6hGg3rgPR+t1UocmlJdD+Cs3Y7EYJ+D8HwxhGtOis3ywGBkHzwyhpFfvDPvf ZV7mFasm88cd1EoKY7aTNmZEHDB2CoTn71E1fzOg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAXSNMGRHC0000SM@mauve.mrochek.com>; Mon, 04 Aug 2014 11:29:17 -0700 (PDT) Message-id: <01PAZBX664E20000SM@mauve.mrochek.com> Date: Mon, 04 Aug 2014 11:27:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 04 Aug 2014 12:58:58 -0400" References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> To: John C Klensin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aNbe-fS41cn706Rgh8QL76yHQcg Cc: dcrocker@bbiw.net, apps-discuss@ietf.org, app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 18:34:27 -0000 FWIW, I didn't even notice that RFC 1846 was experimental. I agree with John's assessment that this has been PS or better for years. Ned From nobody Mon Aug 4 11:34:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB731A00D7 for ; Mon, 4 Aug 2014 11:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBP2rTZV9X9V for ; Mon, 4 Aug 2014 11:34:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30981A00DA for ; Mon, 4 Aug 2014 11:34:26 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEN5N-000GZb-Pr; Mon, 04 Aug 2014 14:34:17 -0400 Date: Mon, 04 Aug 2014 14:34:12 -0400 From: John C Klensin To: dcrocker@bbiw.net, John Levine , apps-discuss@ietf.org Message-ID: In-Reply-To: <53DFC719.8010004@dcrocker.net> References: <20140804172444.2524.qmail@joyce.lan> <53DFC719.8010004@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Vjs9I9iScZcN7IAugfPCwsys1EY Cc: iesg@ieft.org Subject: [apps-discuss] (Last Call: ) Re: Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 18:34:29 -0000 This seems directly relevant to the Last Call, so I have added the appropriate string back to the Subject line and copied the IESG. --On Monday, August 04, 2014 10:47 -0700 Dave Crocker wrote: > On 8/4/2014 10:24 AM, John Levine wrote: >> The suggestion is to change section 4.1 so mail sent to a >> nullmx'ed domain gets a 521 rather than 550 rejection (e.g. >> at submission time.) That seems reasonable to me. >> >> As I understand it, if Barry can change RFC 1846 to standards >> track, I can refer to it without a downref issue. > > > This leads to a decision-three question: > > Is use of the code by the current draft worth making the > /possible and eventual/ change in status of RFC 1846 worth the > indeterminate delay for the current draft? Is it that > important? For whatever my opinion is worth: (2) Yes, it is that important. (2a) I haven't heard anything said so far that points to "interminable delay" if that comment was meant to reflect some very long time of indefinite extent. (2b) It is worth remembering that, if the nullMX draft is simply documenting and ratifying an existing practice that has been around for many years (repeatedly given as the main reason that reviews of some of the associated technical and operational issues and possible alternate strategies are not in order), then another several weeks or months should make no difference. (1) I don't see a necessary downref issue even if nothing is done. As discussed in an earlier note, the list of codes in 5321 has never been exhaustive. Noting my earlier review of that text (on the apps-discuss list) it would be, IMO, completely consistent with even a very restrictive interpretation of the language in 5321 for the present ("nullmx") draft to explicitly update 5321 by adding the code, using it, and making an informative reference to 1846 for a more general discussion of the code and the reasoning behind it. Personally, I think moving 1846 onto the standards track is more sanitary but, if there is really more urgency about approval of "nullmx" than I've seen argued (see above) that giving 1846 a new status can tolerate, than that would be an alternate approach that accomplishes the same purpose and would not, in principle, cost additional time. john From nobody Mon Aug 4 11:49:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9881A010A for ; Mon, 4 Aug 2014 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT5ZpPkxOH7m for ; Mon, 4 Aug 2014 11:49:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7751A00F9 for ; Mon, 4 Aug 2014 11:49:31 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway1.nyi.internal (Postfix) with ESMTP id 29BF922187 for ; Mon, 4 Aug 2014 14:49:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 04 Aug 2014 14:49:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=m+WPux11UuaKWwLJfuioORi+J9c=; b=3nQyKKRHK9eWFrAjTAD8Y2Df0zsx NdB0Ncddcv9i0aLstRk0iNH9ELyGh0CTrHnIc7WtxY+UNEWur0LLKtrEwuz9LtTS /MlA+52V+h7cedzabz3OXxHOrCEvABwx6sSKvjbQezMwQzTDkeHzy3sc2ptVDvLu ag9RZ/dTnNVf67A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=m+WPux11UuaKWwLJfuioOR i+J9c=; b=NzcO9trMNWxDSCyv1ssTV0LGhp3u5zqKGI0bSR1zL8tH32cYgtDYwD zI3uinn5AXFaCuUZ5kxnih22uBEaO89J4rHkiA4YTj7OIF3rUfSJEkuJxf/LqAkK slVBGVh7CO2MgOWljgBw6gbOd+TOWfTigc6AicvzDF62T5NfM0mzo= X-Sasl-enc: rBU7p2IOA1yNrfy6+E5YR5k5W0dFVfL1eBAg030zPYfC 1407178168 Received: from [171.68.20.166] (unknown [171.68.20.166]) by mail.messagingengine.com (Postfix) with ESMTPA id 34E2DC007AF; Mon, 4 Aug 2014 14:49:25 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Mon, 04 Aug 2014 11:49:29 -0700 From: Alissa Cooper To: Barry Leiba Message-ID: Thread-Topic: Alissa Cooper's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) References: <20140804175709.16230.21454.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eqbl3JPDdoe6XPhBuOvGV7UK32o Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Alissa Cooper's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 18:49:33 -0000 On 8/4/14, 11:11 AM, "Barry Leiba" wrote: >> "A server that supports this extension includes "MULTISEARCH" in its >>IMAP >> capability string." >> >> This jumped out at me as I would have expected a statement like this to >> be a normative requirement, rather than a statement of fact. > >Why is that not a normative requirement? It tells how the protocol >works. If you don't do that, you're not doing this protocol. > >Maybe Pete and I should have a chat with you in Honolulu.... >:-) No need, Murray explained your general position on this to me offline (which I did not understand from your message above). Alissa > >Barry From nobody Mon Aug 4 12:26:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D191A01E7 for ; Mon, 4 Aug 2014 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhlwSiOueN5Z for ; Mon, 4 Aug 2014 12:26:47 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE021A01C8 for ; Mon, 4 Aug 2014 12:26:46 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so11845826vcb.24 for ; Mon, 04 Aug 2014 12:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QCKYIpKqTArGVkPIBvNA38NwgqMLqB4Pz3s1j2Ti1dg=; b=hZaTT+ZsJH2RnFKI1Jyx6OW0QG4rPK72Qc4zJOzCMx/D4kXrAOutwBcmFTOE5T4XnN kw3u5NcHv/uGYP2kDMdX3KRYLf+KmH7wUgyD3TcSFd7Or176q3ESHWdEsJ71pDOuZs0W 1E6vH8rKXW3Wm81H36USiHD45oIN4jyHvSgssdHlpPfUkiacC1dE/llho9nJaugAoqyv 3MMj5s/F3OXEqd888kmlpoN1UFJ5E50bQpD8zdn029Zj0E1omsdjlaLwx7oKdRXpIRyP A7B+SLUj0IHp2/HRRpdGP3u98Ft1sTEA627/RzCI+XRJbIxvw3WzaBMGc899RoqPsPr0 ICZA== MIME-Version: 1.0 X-Received: by 10.220.144.147 with SMTP id z19mr25840351vcu.26.1407180406131; Mon, 04 Aug 2014 12:26:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Mon, 4 Aug 2014 12:26:46 -0700 (PDT) In-Reply-To: <53DFC719.8010004@dcrocker.net> References: <20140804172444.2524.qmail@joyce.lan> <53DFC719.8010004@dcrocker.net> Date: Mon, 4 Aug 2014 15:26:46 -0400 X-Google-Sender-Auth: gpGZ4RpS58yWX2KSaO5REqZ-KBI Message-ID: From: Barry Leiba To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BTjpbmys5oHJzMIMMpBOk46dZ7k Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 19:26:48 -0000 >> The suggestion is to change section 4.1 so mail sent to a nullmx'ed >> domain gets a 521 rather than 550 rejection (e.g. at submission time.) >> That seems reasonable to me. >> >> As I understand it, if Barry can change RFC 1846 to standards track, >> I can refer to it without a downref issue. > > This leads to a decision-three question: > > Is use of the code by the current draft worth making the /possible > and eventual/ change in status of RFC 1846 worth the indeterminate delay > for the current draft? Is it that important? The delay will be short; we don't have to wait for the status change. If you add the downref, we just do a pro forma second last call on the document, asking for comments on the downref. We never get any. It delays the document's entry into the RFC Editor queue by no more than two weeks. Barry From nobody Mon Aug 4 12:29:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE881A02B9 for ; Mon, 4 Aug 2014 12:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsrONGB7NsTb for ; Mon, 4 Aug 2014 12:29:31 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F8A1A02A3 for ; Mon, 4 Aug 2014 12:29:31 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so11800584vcb.40 for ; Mon, 04 Aug 2014 12:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FGh/tSx8ULIQiOlfHydMdfpiuXwf7PeW/TfA0IOGWr0=; b=XvbfsIG4mTsw0FzX/7yc/lPjfRcck4273MUkBOzh5Hp7VqcS6rvOgvPLqUuwqAikk7 qGgjwG3eBKpbQMnb1oLbWPWArx2i6V3qUMPFfVT4ygij9GI73sCD/XfN3OYl6I0l9aOo vT7p2O5xQpg7An9KHOFuhQdsxxtov14pgnvdV0o6BJcME/OxBdywQJVFMU7rpOMReJZ6 uy1VyNa96btEXlXEQV101Kuj5ugEbGPc5a6tbgbpO6rEPhPhvNgw4aEXLxcX+pSXrDBL 0/7TmTm9+S3oEzVpjRayhm53zo6M8XIYErYmpGXZQTxL8xVdlByCiYcuxDtisnuTZOkC F2eA== MIME-Version: 1.0 X-Received: by 10.220.130.131 with SMTP id t3mr4099747vcs.30.1407180570228; Mon, 04 Aug 2014 12:29:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Mon, 4 Aug 2014 12:29:30 -0700 (PDT) In-Reply-To: <01PAZBX664E20000SM@mauve.mrochek.com> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> Date: Mon, 4 Aug 2014 15:29:30 -0400 X-Google-Sender-Auth: pouIDOLMzHsTZvHSx_Ims_ZHvOM Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gaYa0ZUJFOrVghv0Ivg_rMeE6BY Cc: Ned Freed Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 19:29:32 -0000 Ned says... > FWIW, I didn't even notice that RFC 1846 was experimental. > I agree with John's assessment that this has been PS or better for years. Excellent. So, let me ask it this way: Does anyone object to: 1. Moving RFC 1846 from Experimental to Proposed Standard? 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? If you do, please say why. If no one objects in the next couple of days, I'll create the status-change document and start a four-week last call on it, which will give plenty more time for any objections to surface, should there be any. Barry From nobody Mon Aug 4 13:31:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0921A0201 for ; Mon, 4 Aug 2014 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-S_6CRYq_n6 for ; Mon, 4 Aug 2014 13:31:37 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D37E21A02AC for ; Mon, 4 Aug 2014 13:31:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1217; t=1407184287; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=VOVs3i2 DXQyOj1eNkqHBFCpneIY=; b=p/decu7SaFNCafjNZYQCtlwgyXt+7E3XWVXFaar 5cFJ8jd5bNhqGArnQWVbEVZB+b8jvNfqxnAWmUaDlIgtGhWksGrSpSqMoOB90Jmw qhEddP+qwAgLzOvoKMV0kVw3/j5rj/tv4yxToHdTIrf3L6U2kTdwQab4GT1El+Y5 AA7A= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 04 Aug 2014 16:31:27 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2369387927.7809.1752; Mon, 04 Aug 2014 16:31:26 -0400 References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 4 Aug 2014 16:31:21 -0400 To: Barry Leiba Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6w_LKt6y29k5FLRNGjUTaKbBSuE Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 20:31:41 -0000 I really don't appreciate, at all, this super fast tracking and rubber stamp= ing without the appropriate industry wide (not just who happens to be here) i= nput and interop reports. And how is this related to the null mx or no mail s= ervice?=20 -- Hector Santos http://www.santronics.com > On Aug 4, 2014, at 3:29 PM, Barry Leiba wrote: >=20 > Ned says... >> FWIW, I didn't even notice that RFC 1846 was experimental. >> I agree with John's assessment that this has been PS or better for years.= >=20 > Excellent. So, let me ask it this way: >=20 > Does anyone object to: >=20 > 1. Moving RFC 1846 from Experimental to Proposed Standard? >=20 > 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? >=20 > If you do, please say why. >=20 > If no one objects in the next couple of days, I'll create the > status-change document and start a four-week last call on it, which > will give plenty more time for any objections to surface, should there > be any. >=20 > Barry >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From nobody Mon Aug 4 13:44:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83971A0313 for ; Mon, 4 Aug 2014 13:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyQbDNZW3cv5 for ; Mon, 4 Aug 2014 13:44:29 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98CF1A02F4 for ; Mon, 4 Aug 2014 13:44:28 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 22AFBD04388; Mon, 4 Aug 2014 16:44:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1407185068; bh=1KLglkgLtLKam8lSgFFCKpbbHvUUl7EKnsBorwLX8oI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=2XzrvAeoYPDvWGWgPqrRtF1odjcEhMYC4FfCugOFz5oeA41swOi0C6p/SjU8RB7Id /7yCurm/x3MqwcwGg90zJKsJtQkrhCn7JRUPJy9wd+GsAAPAPYz35FAUO7zQ7BWERZ 2mFB7PtkSpdQ9Y24NO2QJX7wZxOlpRkzCFWXvoXI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DFF5FD041B9; Mon, 4 Aug 2014 16:44:27 -0400 (EDT) From: Scott Kitterman To: "apps-discuss@ietf.org" Date: Mon, 04 Aug 2014 16:44:26 -0400 Message-ID: <1556568.y7Ptlyhsst@scott-latitude-e6320> User-Agent: KMail/4.13.2 (Linux/3.13.0-32-generic; KDE/4.13.2; x86_64; ; ) In-Reply-To: <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fgjYa1duhYp-_Xdmpiz7A8fYjeU Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 20:44:31 -0000 It's just about a year shy of it's 20th birthday. Do you have a real concern about interoperability or are you just playing process police? In any case, IETF standards are made by the people who show up, so people who happen to be here are who you get. Scott K On Monday, August 04, 2014 16:31:21 Hector Santos wrote: > I really don't appreciate, at all, this super fast tracking and rubber > stamping without the appropriate industry wide (not just who happens to be > here) input and interop reports. And how is this related to the null mx or > no mail service? > > -- > Hector Santos > http://www.santronics.com > > > On Aug 4, 2014, at 3:29 PM, Barry Leiba wrote: > > > > Ned says... > > > >> FWIW, I didn't even notice that RFC 1846 was experimental. > >> I agree with John's assessment that this has been PS or better for years. > > > > Excellent. So, let me ask it this way: > > > > Does anyone object to: > > > > 1. Moving RFC 1846 from Experimental to Proposed Standard? > > > > 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? > > > > If you do, please say why. > > > > If no one objects in the next couple of days, I'll create the > > status-change document and start a four-week last call on it, which > > will give plenty more time for any objections to surface, should there > > be any. > > > > Barry From nobody Mon Aug 4 14:01:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289C91A030D for ; Mon, 4 Aug 2014 14:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_TBNAGFNqHW for ; Mon, 4 Aug 2014 14:01:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130F61A00F5 for ; Mon, 4 Aug 2014 14:01:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 60473F8C001; Mon, 4 Aug 2014 21:01:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1407186060-3336-3335/12/13; Mon, 4 Aug 2014 21:01:00 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 4 Aug 2014 23:01:00 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> In-Reply-To: <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4NlqmvHtqlo7RQ4FK891Sa6UDi4 Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 21:01:06 -0000 On Monday, August 4, 2014 10:31:21 PM CEST, Hector Santos wrote: > I really don't appreciate, at all, this super fast tracking and > rubber stamping without the appropriate industry wide (not just > who happens to be here) input and interop reports. Make a suggestion, then. How should an RFC be treated it it's been experimental for a decade and a lot? > And how is this related to the null mx or no mail service? The nullmx document is to mention 521, which is defined by 1846. Arnt From nobody Mon Aug 4 14:15:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882AC1A0058 for ; Mon, 4 Aug 2014 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEVHLP1tYT2o for ; Mon, 4 Aug 2014 14:15:15 -0700 (PDT) Received: from pop3.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 517C51A032F for ; Mon, 4 Aug 2014 14:15:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2589; t=1407186912; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=Itv1Pfq LtBLzZdrOYGqFMzzijoE=; b=h3VuQPbEuxoLLt2NEEHpI+v14T7es38DoqpaKOg KyLwd1XvDf5UNFhX+jU+NZqSMEkviITsFKsFpzBbUigMQT/Vgler4oty1buBGy+G yGHh5/p/L+6kXlyl+UEoBdAmgp28c80ThOW7Dg1mQgS5bIhBXEypXP03pS1+19Yr iEVw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 04 Aug 2014 17:15:12 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2372013237.7809.3504; Mon, 04 Aug 2014 17:15:11 -0400 References: <20140718160344.52645.qmail@joyce.lan> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <1556568.y7Ptlyhsst@scott-latitude-e6320> Mime-Version: 1.0 (1.0) In-Reply-To: <1556568.y7Ptlyhsst@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 4 Aug 2014 17:15:07 -0400 To: Scott Kitterman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kBvndovsI2tT5kc-zTR9j_kHAt0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 21:15:17 -0000 What r u talking about? Do u have a SMTP product in the market place? You do= n't? Well I do for a few decades now. U have no freaking clue what this mean= and if you only deal with only whom "shows up" well, we have a serious prob= lem. =20 This "experiment" is unknown. It's not in any SMTP RFC. 521 is not document= ed in SMTP. It's not part of state machine response tables. It's all possib= le, but see the spec and understand what it means. Rfc5321 is what's known= . Not this other one and just have the 20 years in the archives doesn't mean= it's place. See if it is first. You don't have any idea what can happen i= f 521 is issued out there. U need to get reports, at least ask the SMTP vend= ors out there and the four week rubber stamping is way too short. -- Hector Santos http://www.santronics.com > On Aug 4, 2014, at 4:44 PM, Scott Kitterman wrote: >=20 > It's just about a year shy of it's 20th birthday. Do you have a real conc= ern=20 > about interoperability or are you just playing process police? >=20 > In any case, IETF standards are made by the people who show up, so people w= ho=20 > happen to be here are who you get. >=20 > Scott K >=20 >> On Monday, August 04, 2014 16:31:21 Hector Santos wrote: >> I really don't appreciate, at all, this super fast tracking and rubber >> stamping without the appropriate industry wide (not just who happens to b= e >> here) input and interop reports. And how is this related to the null mx o= r >> no mail service? >>=20 >> -- >> Hector Santos >> http://www.santronics.com >>=20 >>> On Aug 4, 2014, at 3:29 PM, Barry Leiba wrote:= >>>=20 >>> Ned says... >>>=20 >>>> FWIW, I didn't even notice that RFC 1846 was experimental. >>>> I agree with John's assessment that this has been PS or better for year= s. >>>=20 >>> Excellent. So, let me ask it this way: >>>=20 >>> Does anyone object to: >>>=20 >>> 1. Moving RFC 1846 from Experimental to Proposed Standard? >>>=20 >>> 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? >>>=20 >>> If you do, please say why. >>>=20 >>> If no one objects in the next couple of days, I'll create the >>> status-change document and start a four-week last call on it, which >>> will give plenty more time for any objections to surface, should there >>> be any. >>>=20 >>> Barry >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From nobody Mon Aug 4 14:16:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D0F1A033A for ; Mon, 4 Aug 2014 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5ZMccr1ZLCn for ; Mon, 4 Aug 2014 14:16:45 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD001A0339 for ; Mon, 4 Aug 2014 14:16:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=991; t=1407186999; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=PvGzDXI gGLR8upNo3fGqcOrCHgA=; b=D64G6hE7cg3vs3G+Bx09+bV2KoECM3j80uu2cEj fZyzZOO4SLE6AEfZow3X2LzlWjn0MfpMUmLyw2+RTN73OLXoCyTEfcW9N7ft1Kus 71D2xRantBkMgnVMdaxB3aG+FAH6dnaPRswFlov5iczKjFrkoW63P8Wh6ZiMEhds Xu0o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 04 Aug 2014 17:16:39 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2372099771.7809.3520; Mon, 04 Aug 2014 17:16:38 -0400 References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> Mime-Version: 1.0 (1.0) In-Reply-To: <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <30145317-8042-4FAB-B785-66A4EE993721@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 4 Aug 2014 17:16:33 -0400 To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N7E1SJ9-CTpmG_fuwFm-84X9Ua4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 21:16:46 -0000 By rolling up your sleeves and researching if it's been implemented in a sig= nificant across the board way. Just can't use time as the criteria. -- Hector Santos http://www.santronics.com > On Aug 4, 2014, at 5:01 PM, Arnt Gulbrandsen wr= ote: >=20 >> On Monday, August 4, 2014 10:31:21 PM CEST, Hector Santos wrote: >> I really don't appreciate, at all, this super fast tracking and rubber st= amping without the appropriate industry wide (not just who happens to be her= e) input and interop reports. >=20 > Make a suggestion, then. How should an RFC be treated it it's been experim= ental for a decade and a lot? >=20 >> And how is this related to the null mx or no mail service? >=20 > The nullmx document is to mention 521, which is defined by 1846. >=20 > Arnt >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From nobody Mon Aug 4 14:49:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3C1A0343 for ; Mon, 4 Aug 2014 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBB_c176iRi3 for ; Mon, 4 Aug 2014 14:49:47 -0700 (PDT) Received: from secure.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E61731A0342 for ; Mon, 4 Aug 2014 14:49:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1403; t=1407188983; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=tPRrDpi q0I8jG5xP+5c5Tu/T3tw=; b=tjPAcupEX1NNs8VxEMDi+UeOywiQz1XYJNF//SO 1JUJp08X6lSInfb4F3yEzThgUg1DOTln6g6WWR4J9Fna/sS9mBH83VgTOipxV1nk u2RYY7wxoD+73dF0oSJWsJBVAk39BVcbDoSzupNc5/i2HcLxj+FkaOnZnPsQuirL iOzs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 04 Aug 2014 17:49:43 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2374083370.7809.1404; Mon, 04 Aug 2014 17:49:41 -0400 References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> Mime-Version: 1.0 (1.0) In-Reply-To: <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <22AC4A32-CE97-4424-83E5-5943319CE945@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Mon, 4 Aug 2014 17:49:38 -0400 To: Arnt Gulbrandsen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1O_JCN6wEqP340EcwOkK7T1eIu4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 21:49:49 -0000 > On Aug 4, 2014, at 5:01 PM, Arnt Gulbrandsen wr= ote: >=20 >> And how is this related to the null mx or no mail service? >=20 > The nullmx document is to mention 521, which is defined by 1846. >=20 As mentioned a few times already, the closest empirical field practice to a n= ull mx concept at the receiver level is most likely those systems that have i= mplemented CBV operations. They do a small footprint SMTP callback. They ex= ist. Don't underestimate it.=20 As one of those implementer for 11 years, interoperating with others who als= o implemented it, 521 IS NOT was is used -- 55z is. I'll be happy to expl= ore it for fine tuning specific reply codes for our package, but I can't te= ll you if will cause a client problem or if others will barf on it.=20 We all know it should not, but we don't know, do we? We do know 55x or any o= f the other listed state machine reply codes should be supported for SMTP co= mpliance. But we just don't know how generically it is handled in a state m= achine, i.e. 5yz for all permanent transaction failures. It could be fine in= package X but we don't know how other packages will handle it. It could be= looking for just those codes listed in rfc5321. Four weeks is too short and an appropriate experiment report should be compl= eted.=20 -- Hector Santos http://www.santronics.com= From nobody Mon Aug 4 15:07:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFD51A035A; Mon, 4 Aug 2014 15:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-6OwfR7mJHi; Mon, 4 Aug 2014 15:07:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02AA51A0354; Mon, 4 Aug 2014 15:07:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAZJD7L2O0000C0G@mauve.mrochek.com>; Mon, 4 Aug 2014 15:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407189744; bh=zJp0BAhPbX4cQhcmKhBxPJISlL75NGDFpYbs12MswLA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=K96+BN9nX3hKokQ0Qvz9kuKdvSBCY9pPbb4Zj4IL684U0hT/h2goKqZMhlhjUDnY/ 6yJsGG6Q2rJj2EI4W5HyS/AMNL8ShwL30IrqXr4qMbQUEgzNkFMPHeM/eWXRXMiA1L pHOw5Lhmq0u+fjmhACd1vtyTfY7yZyht4OYCEtD4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAXSNMGRHC0000SM@mauve.mrochek.com>; Mon, 04 Aug 2014 15:02:12 -0700 (PDT) Message-id: <01PAZJD52G4O0000SM@mauve.mrochek.com> Date: Mon, 04 Aug 2014 15:01:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 04 Aug 2014 08:06:56 -0700" <20140804150656.22944.73223.idtracker@ietfa.amsl.com> References: <20140804150656.22944.73223.idtracker@ietfa.amsl.com> To: Adrian Farrel Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/C70ZERAqdNrOWV8jr97atKKdwMs Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:07:23 -0000 Thinking about it, retaining this paragraph seems like a good idea to me. Understanding the history is a Good Thing. Ned > Adrian Farrel has entered the following ballot position for > draft-ietf-appsawg-multimailbox-search-03: No Objection > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I have no objection to the publication of this document, but please > consider my one suggestion below. (Also a homily for the delectation of > future generations.) > --- > In section 1 > This extension was previously published as experimental. There is > now implementation experience, giving confidence in the protocol, so > this document puts the extension on the Standards Track, with some > minor updates that were informed by the implementation experience. > [[RFC Editor: Please remove this paragraph at publication.]] > To the contrary, I think you should retain this paragraph and use it to > record how/why this document obsoletes 6327 with the inclusion of a > forward-pointer to section 8. > --- > I appreciate your use of RFC 6982 (because I get commission), but the > information you included is not overwhelming or very detailed. Nothing > to be done at this stage, but next time... > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 15:17:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC321A0368 for ; Mon, 4 Aug 2014 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEnoHGaBQPX4 for ; Mon, 4 Aug 2014 15:17:22 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B4A1A0350 for ; Mon, 4 Aug 2014 15:17:22 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 15FD1D046BF; Mon, 4 Aug 2014 18:17:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1407190641; bh=Dsxyv11HvON0sQ9IMUWP4on+VKrlRro9T+HAPC2KFhw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jptfmXZfD2uyTvjff9F6pE3K6gsFhG8yGgqVvT4hfbdU7gyl1pH8QSDtGqciWE/ip v2K8nAOnF4VUJGR/HZI2R5knUtsA+iSAPp4lYzteDuUGQsqEfirDET5Z8rvEUlhAx2 sEtoKruH+FyMUSOc/nB7aTZe+neJQ61o55b+Y1Xg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D7394D0442D; Mon, 4 Aug 2014 18:17:20 -0400 (EDT) From: Scott Kitterman To: "apps-discuss@ietf.org" Date: Mon, 04 Aug 2014 18:17:19 -0400 Message-ID: <6641075.rPBfV94Dmf@scott-latitude-e6320> User-Agent: KMail/4.13.2 (Linux/3.13.0-32-generic; KDE/4.13.2; x86_64; ; ) In-Reply-To: <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <1556568.y7Ptlyhsst@scott-latitude-e6320> <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SJOyyZLESwVD2jgNoN5bv_g0DqM Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:17:25 -0000 I think that sort of argument from authority is out of place on an IETF list. Will your product have a problem with this? Give us a yes or no. My MTA of choice (postfix) has implemented 521 replies since version 2.6 (released in 2009). I'm unaware of any issues associated with its use. One of its primary developers is active on the IETF general list, so I'm sure if there's any concerns from that end, they'll be expressed during last call. The IETF doesn't have a magic vendor list to consult. People who have technical concerns should speak up. I don't think wanting reports written qualifies as a technical concern. Scott K On Monday, August 04, 2014 17:15:07 Hector Santos wrote: > What r u talking about? Do u have a SMTP product in the market place? You > don't? Well I do for a few decades now. U have no freaking clue what this > mean and if you only deal with only whom "shows up" well, we have a serious > problem. > > This "experiment" is unknown. It's not in any SMTP RFC. 521 is not > documented in SMTP. It's not part of state machine response tables. It's > all possible, but see the spec and understand what it means. Rfc5321 is > what's known. Not this other one and just have the 20 years in the archives > doesn't mean it's place. See if it is first. You don't have any idea what > can happen if 521 is issued out there. U need to get reports, at least ask > the SMTP vendors out there and the four week rubber stamping is way too > short. > > -- > Hector Santos > http://www.santronics.com > > > On Aug 4, 2014, at 4:44 PM, Scott Kitterman wrote: > > > > It's just about a year shy of it's 20th birthday. Do you have a real > > concern about interoperability or are you just playing process police? > > > > In any case, IETF standards are made by the people who show up, so people > > who happen to be here are who you get. > > > > Scott K > > > >> On Monday, August 04, 2014 16:31:21 Hector Santos wrote: > >> I really don't appreciate, at all, this super fast tracking and rubber > >> stamping without the appropriate industry wide (not just who happens to > >> be > >> here) input and interop reports. And how is this related to the null mx > >> or > >> no mail service? > >> > >> -- > >> Hector Santos > >> http://www.santronics.com > >> > >>> On Aug 4, 2014, at 3:29 PM, Barry Leiba wrote: > >>> > >>> Ned says... > >>> > >>>> FWIW, I didn't even notice that RFC 1846 was experimental. > >>>> I agree with John's assessment that this has been PS or better for > >>>> years. > >>> > >>> Excellent. So, let me ask it this way: > >>> > >>> Does anyone object to: > >>> > >>> 1. Moving RFC 1846 from Experimental to Proposed Standard? > >>> > >>> 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? > >>> > >>> If you do, please say why. > >>> > >>> If no one objects in the next couple of days, I'll create the > >>> status-change document and start a four-week last call on it, which > >>> will give plenty more time for any objections to surface, should there > >>> be any. > >>> > >>> Barry > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 15:18:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D491A0367 for ; Mon, 4 Aug 2014 15:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebiLV87gZcV5 for ; Mon, 4 Aug 2014 15:18:07 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316B51A037C for ; Mon, 4 Aug 2014 15:18:07 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id ABE7CFA00D5; Mon, 4 Aug 2014 22:18:04 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1407190683-3336-3335/12/14; Mon, 4 Aug 2014 22:18:03 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 5 Aug 2014 00:18:03 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <37fab76e-f0e7-48a0-8180-2cc4daf47213@gulbrandsen.priv.no> In-Reply-To: <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <1556568.y7Ptlyhsst@scott-latitude-e6320> <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qLWEnU-f7rKPW45cNUi6wOVuwCM Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:18:12 -0000 On Monday, August 4, 2014 11:15:07 PM CEST, Hector Santos wrote: > This "experiment" is unknown. I found five implementations in one minute of grepping, including Postfix, so not entirely unknown. Arnt From nobody Mon Aug 4 15:45:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8221A038D for ; Mon, 4 Aug 2014 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHvNH2T8eyPB for ; Mon, 4 Aug 2014 15:44:57 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E5E1A0395 for ; Mon, 4 Aug 2014 15:44:54 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so5949945wib.16 for ; Mon, 04 Aug 2014 15:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGs43eGjp5dNPr2CBsQK8zcuEIpQ5yQVevJfHzdUDFE=; b=G+ppj/T6AXG2cCR77ldpPgHAM2zJ5tWUX8pSVJevLxjiHVpvkfjoYf9MNg8Znu3QDi gFKTmi5bWSxUWZZcog7HdcRD/CsH+5GQWR8rH0iuAxvG4FUwd2A7gehPgqGxwQoXuJ81 vSyGjrYpfV4dAdXCSKZlUBtcRIzY4EwcmHXj5OxEjaW1kC1tvtjye69iQdU26gQj7nRt 4Hr6gEJBOqe0TvlDgjDJXbbvLqluMnQypzXPHorHlSQh34AOFtZSvza1qR3zE9cpdZV8 /CUBdiSJ4x69Ar+5tHIpuRVeANGsTanPI/1dEutmSSwikEs4HffZDR4aFwZjX5nnYvq5 mN+A== MIME-Version: 1.0 X-Received: by 10.194.184.230 with SMTP id ex6mr35196339wjc.83.1407192293576; Mon, 04 Aug 2014 15:44:53 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 15:44:53 -0700 (PDT) In-Reply-To: <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <1556568.y7Ptlyhsst@scott-latitude-e6320> <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> Date: Mon, 4 Aug 2014 15:44:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7bb708a8ca189404ffd57cff Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mOeXml-hrBnF6wtiDLaxPqSZ6N8 Cc: Scott Kitterman , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Aug 2014 22:44:59 -0000 --047d7bb708a8ca189404ffd57cff Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 2:15 PM, Hector Santos wrote: > What r u talking about? Do u have a SMTP product in the market place? You > don't? Well I do for a few decades now. U have no freaking clue what this > mean and if you only deal with only whom "shows up" well, we have a serious > problem. > I don't accept the premise that one has to have a product released to have a valid opinion here. In any case, the tone of this reply is not appropriate. Please take it down a notch. This "experiment" is unknown. It's not in any SMTP RFC. 521 is not > documented in SMTP. It's not part of state machine response tables. It's > all possible, but see the spec and understand what it means. Rfc5321 is > what's known. Not this other one and just have the 20 years in the archives > doesn't mean it's place. See if it is first. You don't have any idea what > can happen if 521 is issued out there. U need to get reports, at least ask > the SMTP vendors out there and the four week rubber stamping is way too > short. > Section 4.2 of RFC5321 describes how SMTP clients handle codes in general, even if it's not one of the explicitly listed codes (see, especially, Section 4.2.1). If a client breaks upon seeing 521, it seems to me that it's missed the guidance of that section. So by my read, even if 521 has Experimental status, its use by SMTP servers shouldn't break anything that's been built according to the advice of the Draft Standard. I believe that, at best, your question becomes "How many already-broken clients out there will trip on this if adoption is increased?" I think that's a perfectly fine thing to discuss in a four-week Last Call. -MSK, APPSAWG co-chair --047d7bb708a8ca189404ffd57cff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2014 at 2:15 PM, Hector Santos <hsantos@isd= g.net> wrote:
What r u talking about? Do u have a SMTP pro= duct in the market place? You don't? Well I do for a few decades now. U= have no freaking clue what this mean and if you only deal with only whom &= quot;shows up" well, we have a serious problem.

I don't accept the premise that one ha= s to have a product released to have a valid opinion here.=C2=A0 In any cas= e, the tone of this reply is not appropriate.=C2=A0 Please take it down a n= otch.

This "experiment" is unknown. =C2=A0It's not in any SMTP RFC.= 521 is not documented in SMTP. =C2=A0It's not part of state machine re= sponse tables. It's all possible, but see the spec and understand what = it means. =C2=A0 Rfc5321 is what's known. Not this other one and just h= ave the 20 years in the archives doesn't mean it's place. =C2=A0See= if it is first. =C2=A0You don't have any idea what can happen if 521 i= s issued out there. U need to get reports, at least ask the SMTP vendors ou= t there and the four week rubber stamping is way too short.

Section 4.2 of RFC5321 describes how SMTP = clients handle codes in general, even if it's not one of the explicitly= listed codes (see, especially, Section 4.2.1).=C2=A0 If a client breaks up= on seeing 521, it seems to me that it's missed the guidance of that sec= tion.

So by my read, even if 521 has Experimental status, its use = by SMTP servers shouldn't break anything that's been built accordin= g to the advice of the Draft Standard.

I believe that, at best, your= question becomes "How many already-broken clients out there will trip= on this if adoption is increased?"=C2=A0 I think that's a perfect= ly fine thing to discuss in a four-week Last Call.

-MSK, APPSAWG co-chair
--047d7bb708a8ca189404ffd57cff-- From nobody Mon Aug 4 18:35:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13E1A0AD9; Mon, 4 Aug 2014 18:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brN3sHhZSJVu; Mon, 4 Aug 2014 18:35:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886B51A0ACE; Mon, 4 Aug 2014 18:35:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 18:35:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3DYgI7WySEJYiR9TYf3-C1ByZys Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 01:35:11 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-email-auth-codes-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- We might be able to clear this up with an explanation rather than a change of the text, but I wanted to make sure: I was comparing the descriptions in section 3.1 to the descriptions in RFC 7001 section 2.6.1 and I'm left a bit confused. - When is X.7.20 expected to be returned? Would you use it for "none", "fail", "neutral", "temperror", "permerror", or more than one of those? The way it is worded, you could read it as saying this is only for the "neutral" case (i.e., the signature is there but not valid), but I could also see sending it back for "none". What was the intention? - X.7.21 says it's for the author not matching case, but I would think that this should be generalized for *any* of the RFC 7001 "policy" cases. Do you really intend it only to be used for the particular policy case of no author match? If so, are we going to need other error codes later for other policy cases? Perhaps this could be cleared up with some specific discussion of the 2.6.1 cases in regard to the use of these codes. But as-is, I'm not sure they are going to be used interoperably without further explanation. From nobody Mon Aug 4 19:16:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8ED1A0B00 for ; Mon, 4 Aug 2014 19:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRAOu0MR2qem for ; Mon, 4 Aug 2014 19:15:53 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF7B1A8BB3 for ; Mon, 4 Aug 2014 19:15:53 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so333434ieb.21 for ; Mon, 04 Aug 2014 19:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=2UjGpVaz4WxsC4tNDOPyqv/Mu6m5N740VsQy6vkY5xI=; b=gmbbufP+E6CPXYBEA/CFKtv7lA7zrVId9joEk4d5uoiY4FuK0FZIKjbrprLHwZX9OV OSYKx9016kXoPRalcPjbhsh51pUPsdxIw6/NdoNx0hLXv+NSCTVsX6Y6BAkv8bVyn5iP x4affyl0iBI4oD4bSCsW4FqUeOn01whc1NovCCThyMh0BChUeE57lV7ZgUh1vCKX0VBT BNgPrpFeSTC3JRoo0nGIDX9ENFXCI5q54fm3wbph7nTHs8iney9Z/UxP13qnCZCCg4Ty 2aVC3/rjDLNPSB77lNIqjtCWlbT4Dm26IQz2W9m4W1JnlPqxnSpz2cbyJPofzWlb10xn 3c1w== MIME-Version: 1.0 X-Received: by 10.50.33.100 with SMTP id q4mr2141344igi.8.1407204952939; Mon, 04 Aug 2014 19:15:52 -0700 (PDT) Received: by 10.42.46.18 with HTTP; Mon, 4 Aug 2014 19:15:52 -0700 (PDT) In-Reply-To: <865647D6-F491-4B71-8559-FCC41143B3A2@vpnc.org> References: <53DE7DA1.6060806@isode.com> <865647D6-F491-4B71-8559-FCC41143B3A2@vpnc.org> Date: Mon, 4 Aug 2014 22:15:52 -0400 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SHRr7kMCeRIqFmt-QmmgxcWmq1g Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 02:16:02 -0000 I have built a parser[1] for the Microsoft .net platform for this specification. I have used the format on a number of internal APIs with success. I definitely believe there is value in APPSAWG moving forward with this. Darrel [1] https://github.com/tavis-software/Tavis.Problem On Mon, Aug 4, 2014 at 1:18 PM, Paul Hoffman wrote: > On Aug 3, 2014, at 11:21 AM, Alexey Melnikov wrote: > >> There was very little support for this document so far. Are people interested in working on this document in the APPSAWG? > > Sorry for the late reply. This seems like a fine, easy document for the WG. I'm happy to review it. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 19:54:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDA1B278C; Mon, 4 Aug 2014 19:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy9dktoy-N7E; Mon, 4 Aug 2014 19:54:42 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE051ADDC7; Mon, 4 Aug 2014 19:54:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so6102335wib.8 for ; Mon, 04 Aug 2014 19:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=opfhyta8fiNOVWMHYxyk5mOR+FLeSpt24eXoUdkAZ+Q=; b=EugwmIWDfLk4Vn7Y1V4GaS9s+FoIeTHOmdRoDZzql1OMucaD9Uz8d4kk5VLxeLIv6t HroX3NeldX7AOmxjAmoB0mQUb5/A/NepdiOmWMvvk/cQ1avg/wYE6ymExsLKyMAvWX+e N+rNb+HZq7gZTLDw+tm2kxDTB/OjeVjNENANMpn9wQoffMGG7tbm5reBPY8xQP17sq98 DyJqGHE1Gf8hNKSIyiDYshC8Eqvd8ZfEl6ljXkW8c3qRGbrYfYJ0jn4MtMdMkzUB69SC JBFNoE7ZrrWu2S/RvSnza/XUAEFlFI+f7KoA/CiTxM2fpY6KCX/d9dVjFsLKGDzbjvyu H9Aw== MIME-Version: 1.0 X-Received: by 10.180.38.39 with SMTP id d7mr2376442wik.24.1407207279966; Mon, 04 Aug 2014 19:54:39 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 19:54:39 -0700 (PDT) In-Reply-To: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> Date: Mon, 4 Aug 2014 19:54:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=e89a8f646fcf0c40eb04ffd8fa00 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/I6YYVaj0mOObjFjyzYQzpTjI-D8 Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 02:54:43 -0000 --e89a8f646fcf0c40eb04ffd8fa00 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 6:35 PM, Pete Resnick wrote: > > I was comparing the descriptions in section 3.1 to the descriptions in > RFC 7001 section 2.6.1 and I'm left a bit confused. > > - When is X.7.20 expected to be returned? Would you use it for "none", > "fail", "neutral", "temperror", "permerror", or more than one of those? > The way it is worded, you could read it as saying this is only for the > "neutral" case (i.e., the signature is there but not valid), but I could > also see sending it back for "none". What was the intention? > x.7.20 is for the situation where the message contained no valid signature at all. In terms of RFC 7001, it could be used for "none" (the message wasn't signed), "fail" (there was a valid signature but it failed to verify), "policy" (there was a valid signature but, for example, it didn't cover some header field the verifier requires to be covered per local policy; for example, there's at least one verifier implementation that considers Subject mandatory), "neutral" (there was a signature, but it was syntactically invalid), or "permerror" (there was a signature, but the public key to which it referred was malformed, or it didn't cover the From field as required by RFC 6376). - X.7.21 says it's for the author not matching case, but I would think > that this should be generalized for *any* of the RFC 7001 "policy" cases. > Do you really intend it only to be used for the particular policy case of > no author match? If so, are we going to need other error codes later for > other policy cases? > x.7.21 is intended to reflect the vaguely more specific and common case that there was no valid signature for which the "d=" tag (signing domain) matched the From field domain(s). Put another way, you would see this if it the message was signed only by some third party, or where the verifier actually wants to reveal that this is a specific local policy requirement. Ever since early DKIM implementations, some operators have chosen to make this a requirement, so it's called out specifically here. For any other policy case, the intent is to use x.7.20. > Perhaps this could be cleared up with some specific discussion of the > 2.6.1 cases in regard to the use of these codes. But as-is, I'm not sure > they are going to be used interoperably without further explanation. > How's that? :-) -MSK --e89a8f646fcf0c40eb04ffd8fa00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2014 at 6:35 PM, Pete Resnick <pre= snick@qti.qualcomm.com> wrote:
=

I was comparing the descriptions in section 3.1 to the descriptions in
RFC 7001 section 2.6.1 and I'm left a bit confused.

- When is X.7.20 expected to be returned? Would you use it for "none&q= uot;,
"fail", "neutral", "temperror", "permerr= or", or more than one of those?
The way it is worded, you could read it as saying this is only for the
"neutral" case (i.e., the signature is there but not valid), but = I could
also see sending it back for "none". What was the intention?
<= /blockquote>

x.7.20 is for the situation where the messa= ge contained no valid signature at all.=C2=A0 In terms of RFC 7001, it coul= d be used for "none" (the message wasn't signed), "fail&= quot; (there was a valid signature but it failed to verify), "policy&q= uot; (there was a valid signature but, for example, it didn't cover som= e header field the verifier requires to be covered per local policy; for ex= ample, there's at least one verifier implementation that considers Subj= ect mandatory), "neutral" (there was a signature, but it was synt= actically invalid), or "permerror" (there was a signature, but th= e public key to which it referred was malformed, or it didn't cover the= From field as required by RFC 6376).

- X.7.21 says it's for the author not matching case, but I would think<= br> that this should be generalized for *any* of the RFC 7001 "policy"= ; cases.
Do you really intend it only to be used for the particular policy case of no author match? If so, are we going to need other error codes later for other policy cases?

x.7.21 is intended = to reflect the vaguely more specific and common case that there was no vali= d signature for which the "d=3D" tag (signing domain) matched the= From field domain(s).=C2=A0 Put another way, you would see this if it the = message was signed only by some third party, or where the verifier actually= wants to reveal that this is a specific local policy requirement.=C2=A0 Ev= er since early DKIM implementations, some operators have chosen to make thi= s a requirement, so it's called out specifically here.=C2=A0 For any ot= her policy case, the intent is to use x.7.20.
=C2=A0
Perhaps this could be cleared up with some specific discussion of the
2.6.1 cases in regard to the use of these codes. But as-is, I'm not sur= e
they are going to be used interoperably without further explanation.

How's that?=C2=A0 :-)

-= MSK
--e89a8f646fcf0c40eb04ffd8fa00-- From nobody Mon Aug 4 20:11:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC001B27B6 for ; Mon, 4 Aug 2014 20:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWsAiUyr3WKr for ; Mon, 4 Aug 2014 20:11:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id B79E81B278F for ; Mon, 4 Aug 2014 20:11:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAZONAHBFK000CAO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 4 Aug 2014 17:33:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PAXSNMGRHC0000SM@mauve.mrochek.com>; Mon, 04 Aug 2014 17:33:08 -0700 (PDT) Message-id: <01PAZON906JO0000SM@mauve.mrochek.com> Date: Mon, 04 Aug 2014 17:15:08 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 04 Aug 2014 18:17:19 -0400" <6641075.rPBfV94Dmf@scott-latitude-e6320> References: <20140718160344.52645.qmail@joyce.lan> <1556568.y7Ptlyhsst@scott-latitude-e6320> <667F00D9-8AC5-48D6-BC0E-8E7A98F2B62A@isdg.net> <6641075.rPBfV94Dmf@scott-latitude-e6320> To: Scott Kitterman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VFVi63fe09RsRYN8WyTWNL5TKXQ Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 03:11:49 -0000 > I think that sort of argument from authority is out of place on an IETF list. > Will your product have a problem with this? Give us a yes or no. > My MTA of choice (postfix) has implemented 521 replies since version 2.6 > (released in 2009). I'm unaware of any issues associated with its use. One > of its primary developers is active on the IETF general list, so I'm sure if > there's any concerns from that end, they'll be expressed during last call. FWIW, both Sun/Oracle MTA and PMDF before that have had code in place to handle a 521 greeting (actually any 5yz code) since at least 1994, if not earlier. I don't have earlier sources handy right now so I can't say when the support was added. It's entirely possible it's been there since the SMTP support was first coded. The only change I note in the past 20 years was in the handling of MX hosts returning 521. RFC 1846 clearly states that such hosts MUST NOT return a 521, which leaves open how to handle this bogosity should it occur. We used to bounce the message immediately on receipt of such a response, irrespective of whether or not it was an MX, but around 2000 we changed the code to try additional MXes should any exist. I'm afraid I don't recall the circumstances that led to the change, but IMO the RFC is right to leave open how implementations should handle this condition. Ned From nobody Mon Aug 4 20:33:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5143F1B27F7 for ; Mon, 4 Aug 2014 20:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NS4Bjlif-Q4 for ; Mon, 4 Aug 2014 20:32:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832191B27F2 for ; Mon, 4 Aug 2014 20:32:53 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEVUT-000HBX-4W; Mon, 04 Aug 2014 23:32:45 -0400 Date: Mon, 04 Aug 2014 23:32:40 -0400 From: John C Klensin To: Hector Santos , Arnt Gulbrandsen Message-ID: <3EDC98D0874AA384D1E40681@JcK-HP8200.jck.com> In-Reply-To: <22AC4A32-CE97-4424-83E5-5943319CE945@isdg.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> <22AC4A32-CE97-4424-83E5-5943319CE945@isdg.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zenp-h0fnsHVjcMh9GcP3q4L_30 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 03:33:00 -0000 --On Monday, August 04, 2014 17:49 -0400 Hector Santos wrote: >> The nullmx document is to mention 521, which is defined by >> 1846. > > As mentioned a few times already, the closest empirical field > practice to a null mx concept at the receiver level is most > likely those systems that have implemented CBV operations. > They do a small footprint SMTP callback. They exist. Don't > underestimate it. > > As one of those implementer for 11 years, interoperating with > others who also implemented it, 521 IS NOT was is used -- 55z > is. I'll be happy to explore it for fine tuning specific > reply codes for our package, but I can't tell you if will > cause a client problem or if others will barf on it. > > We all know it should not, but we don't know, do we? We do > know 55x or any of the other listed state machine reply codes > should be supported for SMTP compliance. But we just don't > know how generically it is handled in a state machine, i.e. > 5yz for all permanent transaction failures. It could be fine > in package X but we don't know how other packages will handle > it. It could be looking for just those codes listed in > rfc5321. Hector and others, As Murray suggested, I think the tone of this needs to be taken down a notch. I hope this note can help. First, the practice of setting up a fake SMTP server that responds to any connection attempt with a 5yz code with the intention of saying "go away and don't bother me (permanently)" goes back to the 80s, long predating nullmx and several long-dead conventions including the DNS WKS record that was formally deprecated in RFC 1123 (and, I think, dead in practice before that). In an odd way, none of this has much to do with nullmx -- if that convention is used by the DNS administrator associated with a particular host and understood by clients, no attempt will ever be made to make an SMTP connection so whether there is a stub SMTP server on that host is pretty much irrelevant. So is what such a server might do if a connection is opened to it by a client that doesn't follow the nullmx convention (or if a client that does follow it doesn't get such a record. Maybe that is the point Dave Crocker was trying to make but it seems to me that the nullmx spec opens itself to some of this discussion by giving any advice at all about what a server associated with such a record should do if contacted anyway. One thing I didn't remember until you pointed it out in one of your earlier notes was that RFC 5321 (and 2821) contain explicit text recommending 554 for (quoting 2821; 5321 uses slightly different language) "formally reject[ing] a transaction while still allowing the initial connection". I don't remember whether DRUMS discussed 521 and preferred 554 or whether it really wasn't discussed. But I'm fairly confident that one can find implementations out there that use 554 and 521 (different servers, of course). I am quire certain that I've seen early uses of 502, 503, and 550 and even was slightly involved with an implementation that used 550 30-odd years ago. There is clearly some logic in the latter since RFC 821's description of it includes "no access" in the 550 description (even though its "Command-Reply Sequences" table lists only 220 and 421 for connection establishment). That history is long enough that I don't think your arguments about needing more experimental trials holds up. More important, it has been very clear since at least RFC 1123 that SMTP clients must be prepared to accept, and act plausibly on, _any_ reply code that begins with the digits 2, 4, or 5 (and, after DATA, 3). That rule was made even more explicit in 2821. An SMTP cli8ent implementation that gets into trouble with an unknown code in the appropriate range is so far out of compliance with SMTP as to not be appropriate to worry about. With regard to 1846, I think there are only two realistic choices (of course "don't deal with it for another decade" is a possibility, but I can't really recommend it. One is to face the reality that it is practiced and maybe even that an explicit code that exists for the sole purpose of saying "no SMTP traffic accepted here", differentiating that from the 554 cases that include "not accepting SMTP connections from an address in your range" is desirable for the reasons 1846 outlines. If one believes that, it should be standardized and I/we will face a slightly tricky wording problem when 5321bis is posted and considered. The other is to try to denounce the use of 521, declare the 1846 experiment a failure, and deprecate that spec. I don't think the latter is sensible; YMMD. Finally, remember where this leaves us. Assuming 521 is adopted as a code reserved for a "no SMTP service or SMTP traffic accepted here", a client that knows about it will be able to report more precisely to the user (or originating MUA) what is going on than one that gets a 554, which, in turn, conveys more information than 550. Any of those three convey more information -- and are less misleading-- than using 500, 502, 503, or 504. But, other than better problem reporting, the client response to any of those codes is exactly the same. That is to treat the situation as a fatal error (given the first digit of "5") and dispose of the message without issuing further commands (other than QUIT or RSET) or putting it back in the queue for later retries. best, john From nobody Mon Aug 4 21:10:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9441B2807 for ; Mon, 4 Aug 2014 21:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY4kowNgGAsA for ; Mon, 4 Aug 2014 21:09:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31EA1B2805 for ; Mon, 4 Aug 2014 21:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407211794; x=1438747794; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YLeWzaN6lJhAekle80D0PrQ+JypgyCYtB9tNq/3nVF8=; b=AKORmAU447S2WN1hT0ekRMkWw6IsvFJYlBCqFKQ23VSo/99zM+JLH1cD cIEAWpyazcwkn8z3CwN9DTlnCQ3nLWBp34oLUdwceo/LPf3x/ghmwvS3L 5Mxcepf8slmaRAgsu+mHZ9RsuNWWkJNIju50OXU4CujxMcmuyybQ4KGNC s=; X-IronPort-AV: E=McAfee;i="5600,1067,7520"; a="147472435" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 04 Aug 2014 21:09:53 -0700 X-IronPort-AV: E=Sophos;i="5.01,802,1400050800"; d="scan'208";a="30964930" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2014 21:09:52 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 4 Aug 2014 21:09:52 -0700 Message-ID: <53E0590E.8060204@qti.qualcomm.com> Date: Mon, 4 Aug 2014 23:09:50 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_nvM_Pt7iI1dN1PeLDukFodRaIs Cc: Ned Freed , "apps-discuss@ietf.org" , app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:09:56 -0000 On 8/4/14 9:16 AM, Barry Leiba wrote: > Murray says: > >> > As I understand it, we can't just reclassify it in-place but would instead >> > need to publish a new version as a Proposed Standard and then promote it in >> > the usual way. The main reason I think that is that this should officially >> > update RFC 5321. Is that correct? >> > 2a. If it does "update" 5321, that's just metadata, and that can be > changed at the same time. If there are no substantive updates to the > document, there's no reason to publish a revision. > > 2b. The reason it would "update" 5321, in the RFC-metadata meaning, > would be if it said that all new implementations of SMTP MUST do this. > If it's still an option, it doesn't update 5321. > > All that said, we have to decide whether we want to change the > boilerplate, which currently says this: > > This memo defines an Experimental Protocol for the Internet > community. This memo does not specify an Internet standard of any > kind. > > We might decide that it's weird to have an Internet Standard with that > boilerplate in it. > I think you will find that, even if we don't think it weird, the RFC Editor will think it terribly weird. I believe they will require a new document with a new boilerplate; I seem to remember trying this before and them not wanting to advance the document in place. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Aug 4 21:14:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74191B2807 for ; Mon, 4 Aug 2014 21:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42QB7uSQFdZZ for ; Mon, 4 Aug 2014 21:14:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF62F1B280C for ; Mon, 4 Aug 2014 21:14:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s754DwMu002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 21:14:01 -0700 Message-ID: <53E05984.9090109@dcrocker.net> Date: Mon, 04 Aug 2014 21:11:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <2E2F3B21-6F07-4F47-8197-FD1F70AB0067@isdg.net> <71591a64-a506-422a-80e2-f83678839d5b@gulbrandsen.priv.no> <22AC4A32-CE97-4424-83E5-5943319CE945@isdg.net> <3EDC98D0874AA384D1E40681@JcK-HP8200.jck.com> In-Reply-To: <3EDC98D0874AA384D1E40681@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 04 Aug 2014 21:14:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QnNJxWwpqM13v3-6faIEeJVyPYU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 04:14:04 -0000 On 8/4/2014 8:32 PM, John C Klensin wrote: > So is what such a server might do if a connection > is opened to it by a client that doesn't follow the nullmx > convention (or if a client that does follow it doesn't get such > a record. Maybe that is the point Dave Crocker was trying to > make but it seems to me that the nullmx spec opens itself to > some of this discussion by giving any advice at all about what a > server associated with such a record should do if contacted > anyway. What text in the draft are you referring to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 4 21:20:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8CA1B280F; Mon, 4 Aug 2014 21:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUw8QlzJl3f7; Mon, 4 Aug 2014 21:20:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAD21A0AE6; Mon, 4 Aug 2014 21:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407212433; x=1438748433; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=AF6vDRAatFi0HZes3IfluzahWrNBkufEIqR7+CmB68w=; b=fTxBGtvK11gOm/OczQhVVq6m6/PDQxStIrgAKbpXX9lkh/8Tk1XMionZ Pz8yuvAT8tRCSGcGwh3C0OuDIaePKA4dATePjiZthsjFsTLijudKTofnS bCTtVNQLim+yeQ4vo81BvnTCH1xzh8LjsUe9GWLxG8ZaKUOBNV5uGazX5 I=; X-IronPort-AV: E=McAfee;i="5600,1067,7520"; a="56013130" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 04 Aug 2014 21:20:28 -0700 X-IronPort-AV: E=Sophos;i="5.01,802,1400050800"; d="scan'208,217";a="725810922" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2014 21:20:14 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 4 Aug 2014 21:20:11 -0700 Message-ID: <53E05B7A.5060308@qti.qualcomm.com> Date: Mon, 4 Aug 2014 23:20:10 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070409010201070400040303" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/71_76T2eQLzAmmh_FpzCRrLGy-o Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:20:36 -0000 --------------070409010201070400040303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/4/14 9:54 PM, Murray S. Kucherawy wrote: > On Mon, Aug 4, 2014 at 6:35 PM, Pete Resnick > > wrote: > > > I was comparing the descriptions in section 3.1 to the descriptions in > RFC 7001 section 2.6.1 and I'm left a bit confused. > > - When is X.7.20 expected to be returned? Would you use it for "none", > "fail", "neutral", "temperror", "permerror", or more than one of > those? > The way it is worded, you could read it as saying this is only for the > "neutral" case (i.e., the signature is there but not valid), but I > could > also see sending it back for "none". What was the intention? > > > x.7.20 is for the situation where the message contained no valid > signature at all. In terms of RFC 7001, it could be used for "none" > (the message wasn't signed), "fail" (there was a valid signature but > it failed to verify), "policy" (there was a valid signature but, for > example, it didn't cover some header field the verifier requires to be > covered per local policy; for example, there's at least one verifier > implementation that considers Subject mandatory), "neutral" (there was > a signature, but it was syntactically invalid), or "permerror" (there > was a signature, but the public key to which it referred was > malformed, or it didn't cover the From field as required by RFC 6376). > > - X.7.21 says it's for the author not matching case, but I would think > that this should be generalized for *any* of the RFC 7001 "policy" > cases. > Do you really intend it only to be used for the particular policy > case of > no author match? If so, are we going to need other error codes > later for > other policy cases? > > > x.7.21 is intended to reflect the vaguely more specific and common > case that there was no valid signature for which the "d=" tag (signing > domain) matched the From field domain(s). Put another way, you would > see this if it the message was signed only by some third party, or > where the verifier actually wants to reveal that this is a specific > local policy requirement. Ever since early DKIM implementations, some > operators have chosen to make this a requirement, so it's called out > specifically here. For any other policy case, the intent is to use > x.7.20. > > Perhaps this could be cleared up with some specific discussion of the > 2.6.1 cases in regard to the use of these codes. But as-is, I'm > not sure > they are going to be used interoperably without further explanation. > > > How's that? :-) Aha. That wasn't clear to me from the current text. I took "valid" to only be referring to passing the basic DKIM verification algorithms. I didn't realize that not passing local policies was a reason to send back X.7.20. Perhaps you could clarify the text? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070409010201070400040303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/4/14 9:54 PM, Murray S. Kucherawy wrote:
On Mon, Aug 4, 2014 at 6:35 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

I was comparing the descriptions in section 3.1 to the descriptions in
RFC 7001 section 2.6.1 and I'm left a bit confused.

- When is X.7.20 expected to be returned? Would you use it for "none",
"fail", "neutral", "temperror", "permerror", or more than one of those?
The way it is worded, you could read it as saying this is only for the
"neutral" case (i.e., the signature is there but not valid), but I could
also see sending it back for "none". What was the intention?

x.7.20 is for the situation where the message contained no valid signature at all.  In terms of RFC 7001, it could be used for "none" (the message wasn't signed), "fail" (there was a valid signature but it failed to verify), "policy" (there was a valid signature but, for example, it didn't cover some header field the verifier requires to be covered per local policy; for example, there's at least one verifier implementation that considers Subject mandatory), "neutral" (there was a signature, but it was syntactically invalid), or "permerror" (there was a signature, but the public key to which it referred was malformed, or it didn't cover the From field as required by RFC 6376).

- X.7.21 says it's for the author not matching case, but I would think
that this should be generalized for *any* of the RFC 7001 "policy" cases.
Do you really intend it only to be used for the particular policy case of
no author match? If so, are we going to need other error codes later for
other policy cases?

x.7.21 is intended to reflect the vaguely more specific and common case that there was no valid signature for which the "d=" tag (signing domain) matched the From field domain(s).  Put another way, you would see this if it the message was signed only by some third party, or where the verifier actually wants to reveal that this is a specific local policy requirement.  Ever since early DKIM implementations, some operators have chosen to make this a requirement, so it's called out specifically here.  For any other policy case, the intent is to use x.7.20.
 
Perhaps this could be cleared up with some specific discussion of the
2.6.1 cases in regard to the use of these codes. But as-is, I'm not sure
they are going to be used interoperably without further explanation.

How's that?  :-)

Aha. That wasn't clear to me from the current text. I took "valid" to only be referring to passing the basic DKIM verification algorithms. I didn't realize that not passing local policies was a reason to send back X.7.20. Perhaps you could clarify the text?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------070409010201070400040303-- From nobody Mon Aug 4 21:22:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF381B2831; Mon, 4 Aug 2014 21:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzWME6fGpK-N; Mon, 4 Aug 2014 21:22:16 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052AF1B280F; Mon, 4 Aug 2014 21:22:15 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so347804wes.28 for ; Mon, 04 Aug 2014 21:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iT8zGjhaiNvhRpSstBAdHcv1YC7Ia60TYAWLJGZhkVM=; b=dj14rCWhs3Q+6qcmqU4S1d14l6GWx/Wdot7Q1UX5uRfIIN/23AgdgLOclS8zRnqjot b9Nx3BnrVPNMyPi5XeXj4xxzf4RyBBnaInjlENhszcm+WraGcKXZjssNRGCOmgbb7CzH 4MvxjodMq7Kz7GahNEjFKcuxZq9CCy6EXPKH7Za4cGjJP1bpiksWru7zz1iOCkAYXEdt EiHLRFbEC/k+z63V1r8FtLuIvxGkPmUV17AMP9W9oUY1dMTKhgp9KAqZqCVXLwGIg4BJ 0elPAyboWDYYzCEW7VE/t48BcrDqTHw55CTFXaqYexZg2P8qkzEcXitBX4EJ6Bc+cy0y udUw== MIME-Version: 1.0 X-Received: by 10.180.10.166 with SMTP id j6mr36600847wib.73.1407212534597; Mon, 04 Aug 2014 21:22:14 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 21:22:14 -0700 (PDT) In-Reply-To: <53E05B7A.5060308@qti.qualcomm.com> References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> Date: Mon, 4 Aug 2014 21:22:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c244123f8f2304ffda33ca Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5GBYFsZ02OfXHEfWR2N8EnzPXGo Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:22:20 -0000 --001a11c244123f8f2304ffda33ca Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick wrote: > > Aha. That wasn't clear to me from the current text. I took "valid" to only > be referring to passing the basic DKIM verification algorithms. I didn't > realize that not passing local policies was a reason to send back X.7.20. > Perhaps you could clarify the text? > > How's this for a new Section 3.1?: 3.1. DKIM Failure Codes In the code point definitions below, the term "acceptable" means both of the following: a. The signature passed the basic DKIM verification algorithm as defined in [RFC6376]; and b. The signature satisfied any local policy requirements in addition to the basic algorithm (e.g., certain header fields included in the signed content, no partial signatures, etc.). Code: X.7.20 Sample Text: No valid DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message did not contain any acceptable DKIM signatures. (Note that this violates the advice of Section 6.1 of RFC6376.) Reference: [this document]; RFC6376 Submitter: M. Kucherawy Change controller: IESG Code: X.7.21 Sample Text: No valid author-matched DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message did not contain any acceptable DKIM signatures whose identifier(s) match the author address(es) found in the From header field. (Note that this violates the advice of Section 6.1 of RFC6376.) This is a special case of the X.7.20 status code. Reference: [this document]; RFC6376 Submitter: M. Kucherawy Change controller: IESG --001a11c244123f8f2304ffda33ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+T24gTW9uLCBBdWcgNCwgMjAxNCBhdCA5OjIwIFBNLCBQZXRlIFJlc25p Y2sgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86cHJlc25pY2tAcXRpLnF1YWxj b21tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByZXNuaWNrQHF0aS5xdWFsY29tbS5jb208L2E+Jmd0 Ozwvc3Bhbj4gd3JvdGU6PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIw NCk7cGFkZGluZy1sZWZ0OjFleCI+PHU+PC91Pg0KDQoNCiAgDQoNCjxkaXYgYmdjb2xvcj0iI2Zm ZmZmZiIgdGV4dD0iIzAwMDAwMCI+PGRpdj48ZGl2IGNsYXNzPSJoNSI+DQo8YnI+PC9kaXY+PC9k aXY+DQpBaGEuIFRoYXQgd2FzbiYjMzk7dCBjbGVhciB0byBtZSBmcm9tIHRoZSBjdXJyZW50IHRl eHQuIEkgdG9vayAmcXVvdDt2YWxpZCZxdW90OyB0bw0Kb25seSBiZSByZWZlcnJpbmcgdG8gcGFz c2luZyB0aGUgYmFzaWMgREtJTSB2ZXJpZmljYXRpb24gYWxnb3JpdGhtcy4gSQ0KZGlkbiYjMzk7 dCByZWFsaXplIHRoYXQgbm90IHBhc3NpbmcgbG9jYWwgcG9saWNpZXMgd2FzIGEgcmVhc29uIHRv IHNlbmQNCmJhY2sgWC43LjIwLiBQZXJoYXBzIHlvdSBjb3VsZCBjbGFyaWZ5IHRoZSB0ZXh0Pzxz cGFuIGNsYXNzPSIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+DQo8YnI+PC9mb250Pjwvc3Bh bj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5Ib3cmIzM5O3MgdGhpcyBm b3IgYSBuZXcgU2VjdGlvbiAzLjE/Ojxicj48YnI+My4xLsKgIERLSU0gRmFpbHVyZSBDb2Rlczxi cj48YnI+wqDCoCBJbiB0aGUgY29kZSBwb2ludCBkZWZpbml0aW9ucyBiZWxvdywgdGhlIHRlcm0g JnF1b3Q7YWNjZXB0YWJsZSZxdW90OyBtZWFucyBib3RoPGJyPg0KwqDCoCBvZiB0aGUgZm9sbG93 aW5nOjxicj48YnI+wqDCoCBhLsKgIFRoZSBzaWduYXR1cmUgcGFzc2VkIHRoZSBiYXNpYyBES0lN IHZlcmlmaWNhdGlvbiBhbGdvcml0aG0gYXM8YnI+wqDCoMKgwqDCoMKgIGRlZmluZWQgaW4gW1JG QzYzNzZdOyBhbmQ8YnI+PGJyPsKgwqAgYi7CoCBUaGUgc2lnbmF0dXJlIHNhdGlzZmllZCBhbnkg bG9jYWwgcG9saWN5IHJlcXVpcmVtZW50cyBpbiBhZGRpdGlvbjxicj7CoMKgwqDCoMKgwqAgdG8g dGhlIGJhc2ljIGFsZ29yaXRobSAoZS5nLiwgY2VydGFpbiBoZWFkZXIgZmllbGRzIGluY2x1ZGVk IGluPGJyPg0KwqDCoMKgwqDCoMKgIHRoZSBzaWduZWQgY29udGVudCwgbm8gcGFydGlhbCBzaWdu YXR1cmVzLCBldGMuKS48YnI+PGJyPsKgwqDCoMKgwqAgQ29kZTrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFguNy4yMDxicj7CoMKgwqDCoMKgIFNhbXBsZSBUZXh0OsKgwqDCoMKgwqDCoMKg IE5vIHZhbGlkIERLSU0gc2lnbmF0dXJlIGZvdW5kPGJyPsKgwqDCoMKgwqAgQXNzb2NpYXRlZCBi YXNpYyBzdGF0dXMgY29kZTrCoCA1NTA8YnI+wqDCoMKgwqDCoCBEZXNjcmlwdGlvbjrCoMKgwqDC oMKgwqDCoCBUaGlzIHN0YXR1cyBjb2RlIGlzIHJldHVybmVkIHdoZW4gYSBtZXNzYWdlPGJyPg0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZGlkIG5v dCBjb250YWluIGFueSBhY2NlcHRhYmxlIERLSU08YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2lnbmF0dXJlcy7CoCAoTm90ZSB0aGF0IHRoaXMg dmlvbGF0ZXMgdGhlPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIGFkdmljZSBvZiBTZWN0aW9uIDYuMSBvZiBSRkM2Mzc2Lik8YnI+wqDCoMKgwqDC oCBSZWZlcmVuY2U6wqDCoMKgwqDCoMKgwqDCoMKgIFt0aGlzIGRvY3VtZW50XTsgUkZDNjM3Njxi cj4NCsKgwqDCoMKgwqAgU3VibWl0dGVyOsKgwqDCoMKgwqDCoMKgwqDCoCBNLiBLdWNoZXJhd3k8 YnI+wqDCoMKgwqDCoCBDaGFuZ2UgY29udHJvbGxlcjrCoCBJRVNHPGJyPjxicj48YnI+wqDCoMKg wqDCoCBDb2RlOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgWC43LjIxPGJyPsKgwqDCoMKg wqAgU2FtcGxlIFRleHQ6wqDCoMKgwqDCoMKgwqAgTm8gdmFsaWQgYXV0aG9yLW1hdGNoZWQgREtJ TSBzaWduYXR1cmUgZm91bmQ8YnI+wqDCoMKgwqDCoCBBc3NvY2lhdGVkIGJhc2ljIHN0YXR1cyBj b2RlOsKgIDU1MDxicj4NCsKgwqDCoMKgwqAgRGVzY3JpcHRpb246wqDCoMKgwqDCoMKgwqAgVGhp cyBzdGF0dXMgY29kZSBpcyByZXR1cm5lZCB3aGVuIGEgbWVzc2FnZTxicj7CoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkaWQgbm90IGNvbnRhaW4gYW55 IGFjY2VwdGFibGUgREtJTTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBzaWduYXR1cmVzIHdob3NlIGlkZW50aWZpZXIocykgbWF0Y2ggdGhlPGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGF1dGhv ciBhZGRyZXNzKGVzKSBmb3VuZCBpbiB0aGUgRnJvbSBoZWFkZXI8YnI+DQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBmaWVsZC7CoCAoTm90ZSB0aGF0 IHRoaXMgdmlvbGF0ZXMgdGhlIGFkdmljZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvZiBTZWN0aW9uIDYuMSBvZiBSRkM2Mzc2LinCoCBUaGlz IGlzIGE8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgc3BlY2lhbCBjYXNlIG9mIHRoZSBYLjcuMjAgc3RhdHVzIGNvZGUuPGJyPsKgwqDCoMKgwqAg UmVmZXJlbmNlOsKgwqDCoMKgwqDCoMKgwqDCoCBbdGhpcyBkb2N1bWVudF07IFJGQzYzNzY8YnI+ DQrCoMKgwqDCoMKgIFN1Ym1pdHRlcjrCoMKgwqDCoMKgwqDCoMKgwqAgTS4gS3VjaGVyYXd5PGJy PsKgwqDCoMKgwqAgQ2hhbmdlIGNvbnRyb2xsZXI6wqAgSUVTRzxicj48YnI+PC9kaXY+PC9kaXY+ PGJyPjwvZGl2PjwvZGl2Pg0K --001a11c244123f8f2304ffda33ca-- From nobody Mon Aug 4 21:26:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36D1B284A; Mon, 4 Aug 2014 21:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HaJs3rUDoLK; Mon, 4 Aug 2014 21:26:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1659F1B2824; Mon, 4 Aug 2014 21:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407212788; x=1438748788; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=u7F4veQdAHTJ+WN9wvf1LBw2hilJPkKn35p5+3ZFCns=; b=DXtbHABLQqcuJJDahQqMwvnxTa7oRQ5EWae62zxXHZ4iEGt/KQ8XwtNo BSZZedj+/IoaDtskH4IovrdHLFSkpbIE4hqLJJDl0jocyWRZARDuhEkyw ojelCNNYp3OIwvM/IaT1CqikcJSAiIwaOIQiMSt6OxtaswO0diAPZMxEP U=; X-IronPort-AV: E=McAfee;i="5600,1067,7520"; a="56014030" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 04 Aug 2014 21:26:27 -0700 X-IronPort-AV: E=Sophos;i="5.01,802,1400050800"; d="scan'208,217";a="725812118" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Aug 2014 21:26:27 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 4 Aug 2014 21:26:26 -0700 Message-ID: <53E05CF1.9000102@qti.qualcomm.com> Date: Mon, 4 Aug 2014 23:26:25 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020400010309010508030103" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5Y-3qe5XFGwQ36g0FRkhaeBfjMU Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:26:30 -0000 --------------020400010309010508030103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/4/14 11:22 PM, Murray S. Kucherawy wrote: > On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick > > wrote: > > > Aha. That wasn't clear to me from the current text. I took "valid" > to only be referring to passing the basic DKIM verification > algorithms. I didn't realize that not passing local policies was a > reason to send back X.7.20. Perhaps you could clarify the text? > > > How's this for a new Section 3.1? Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me to leave it for housekeeping purposes; I'll assume that you all can decide on the specifics. Thanks for DISCUSSing it. pr > 3.1. DKIM Failure Codes > > In the code point definitions below, the term "acceptable" means both > of the following: > > a. The signature passed the basic DKIM verification algorithm as > defined in [RFC6376]; and > > b. The signature satisfied any local policy requirements in addition > to the basic algorithm (e.g., certain header fields included in > the signed content, no partial signatures, etc.). > > Code: X.7.20 > Sample Text: No valid DKIM signature found > Associated basic status code: 550 > Description: This status code is returned when a message > did not contain any acceptable DKIM > signatures. (Note that this violates the > advice of Section 6.1 of RFC6376.) > Reference: [this document]; RFC6376 > Submitter: M. Kucherawy > Change controller: IESG > > > Code: X.7.21 > Sample Text: No valid author-matched DKIM signature found > Associated basic status code: 550 > Description: This status code is returned when a message > did not contain any acceptable DKIM > signatures whose identifier(s) match the > author address(es) found in the From header > field. (Note that this violates the advice > of Section 6.1 of RFC6376.) This is a > special case of the X.7.20 status code. > Reference: [this document]; RFC6376 > Submitter: M. Kucherawy > Change controller: IESG > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------020400010309010508030103 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/4/14 11:22 PM, Murray S. Kucherawy wrote:
On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

Aha. That wasn't clear to me from the current text. I took "valid" to only be referring to passing the basic DKIM verification algorithms. I didn't realize that not passing local policies was a reason to send back X.7.20. Perhaps you could clarify the text?


How's this for a new Section 3.1?

Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me to leave it for housekeeping purposes; I'll assume that you all can decide on the specifics. Thanks for DISCUSSing it.

pr

3.1.  DKIM Failure Codes

   In the code point definitions below, the term "acceptable" means both
   of the following:

   a.  The signature passed the basic DKIM verification algorithm as
       defined in [RFC6376]; and

   b.  The signature satisfied any local policy requirements in addition
       to the basic algorithm (e.g., certain header fields included in
       the signed content, no partial signatures, etc.).

      Code:               X.7.20
      Sample Text:        No valid DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          did not contain any acceptable DKIM
                          signatures.  (Note that this violates the
                          advice of Section 6.1 of RFC6376.)
      Reference:          [this document]; RFC6376
      Submitter:          M. Kucherawy
      Change controller:  IESG


      Code:               X.7.21
      Sample Text:        No valid author-matched DKIM signature found
      Associated basic status code:  550
      Description:        This status code is returned when a message
                          did not contain any acceptable DKIM
                          signatures whose identifier(s) match the
                          author address(es) found in the From header
                          field.  (Note that this violates the advice
                          of Section 6.1 of RFC6376.)  This is a
                          special case of the X.7.20 status code.
      Reference:          [this document]; RFC6376
      Submitter:          M. Kucherawy
      Change controller:  IESG



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

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------020400010309010508030103-- From nobody Mon Aug 4 21:28:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242E41B284A; Mon, 4 Aug 2014 21:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yACZsSbkL0FG; Mon, 4 Aug 2014 21:28:49 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3213D1B280F; Mon, 4 Aug 2014 21:28:49 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so344112wgh.6 for ; Mon, 04 Aug 2014 21:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xw9I9oP3UkJWvPaij2SIeGvQMr3LrohJqdWMgwpdqhk=; b=bAqp+BbEEeh5ONLudPn7P7wxKDYL2O3nbSFQVpdFmXIT5n12woKnTv0stYCWneHDX5 Ga7PDvUWBGG5IbPngkM8sn6fQcpZo+bFO9sIdJcNXFbavurCqP0tODiJtGPyLw1g1p36 WaddJ9WUlbjEQqmBfalapyVeuhSCMPonLdpZ1vi2KYOsd5Mxf5Kxm4jxQcfglzXJXHwm /R+J4UaOA/U7uwybIx/ddzaCNZG7XtUiT2QL0TCiEaumutGSs4p17cYLcXKOkgRN0S3Y jxd7WPFZj/r58mjXoH/dmiaFftwqiNKxEkRqTN/7KjKPQkPm6zTzu/JyiEyxm/M0kXl/ snVQ== MIME-Version: 1.0 X-Received: by 10.180.38.39 with SMTP id d7mr2892142wik.24.1407212927429; Mon, 04 Aug 2014 21:28:47 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 4 Aug 2014 21:28:47 -0700 (PDT) In-Reply-To: <53E05CF1.9000102@qti.qualcomm.com> References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> <53E05CF1.9000102@qti.qualcomm.com> Date: Mon, 4 Aug 2014 21:28:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=e89a8f646fcfa9b18d04ffda4abf Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JXfQtVEcJu7KgcHPXXuzM9QQP3g Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-email-auth-codes@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 04:28:51 -0000 --e89a8f646fcfa9b18d04ffda4abf Content-Type: text/plain; charset=UTF-8 On Mon, Aug 4, 2014 at 9:26 PM, Pete Resnick wrote: > > Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me > to leave it for housekeeping purposes; I'll assume that you all can decide > on the specifics. Thanks for DISCUSSing it. > > Likewise, I'm happy to post the update to the tracker now or wait until after the telechat. I'll assume the latter unless directed otherwise. -MSK --e89a8f646fcfa9b18d04ffda4abf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 4, 2014 at 9:26 PM, Pete Resnick <pre= snick@qti.qualcomm.com> wrote:
=
=20

Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me to leave it for housekeeping purposes; I'll assume that you all can decide on the specifics. Thanks for DISCUSSing it.


Likewise, I'm happy to post = the update to the tracker now or wait until after the telechat.=C2=A0 I'= ;ll assume the latter unless directed otherwise.

-MSK
--e89a8f646fcfa9b18d04ffda4abf-- From nobody Mon Aug 4 22:11:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B381A0117; Mon, 4 Aug 2014 22:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMXTS20LGW9l; Mon, 4 Aug 2014 22:11:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A341B2842; Mon, 4 Aug 2014 22:10:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805051057.12794.90818.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 22:10:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Nb1DK5Fq3CalItSh5-LgFHH6zeM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 05:11:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A "Null MX" No Service Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-07.txt Pages : 7 Date : 2014-08-04 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The no service MX RR, informally called null MX, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 4 22:11:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3B1B2840 for ; Mon, 4 Aug 2014 22:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKBmw9HMpZyf; Mon, 4 Aug 2014 22:11:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9881B2847; Mon, 4 Aug 2014 22:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805051058.12794.68690.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 22:10:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ljh8bzNqGqvrb8DDbwLFBTLuWIE Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-nullmx-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 05:11:09 -0000 A new version (-07) has been submitted for draft-ietf-appsawg-nullmx: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-nullmx-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Aug 4 22:14:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7161B28D4 for ; Mon, 4 Aug 2014 22:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icT7NcqResgI for ; Mon, 4 Aug 2014 22:14:54 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0C11A0117 for ; Mon, 4 Aug 2014 22:14:54 -0700 (PDT) Received: from [192.168.1.58] (70.249.200.77.rev.sfr.net [77.200.249.70]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0LpRkv-1WlGoQ3AZB-00fD61; Tue, 05 Aug 2014 07:14:52 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Jan Algermissen In-Reply-To: Date: Tue, 5 Aug 2014 07:14:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53DE7DA1.6060806@isode.com> <865647D6-F491-4B71-8559-FCC41143B3A2@vpnc.org> To: darrel@tavis.ca X-Mailer: Apple Mail (2.1878.2) X-Provags-ID: V02:K0:hotDYlercHp/1SGYBtFrTkqHdUeYf7SHGotpmrqu+Kv ufYCup5J0N7Ro9Wbd/voWnd9oqzLSycuJKten8zZbGaXhswsQa HNXFT0dhlJKXmBsKq8xViHoNKatW0vIeRcA2z6Mo/iRyZ6C+F3 azJRPuFa5ugdIajXFyx+3w8Ergloc7QrbOtADLCMRSCu1l8ICZ n3CCYCdyGY6XLiM8weausJfk4O/AnWyEeEEB7tr8RSsol84NA0 3DBBPWZD2A+ERBuNIj2Pg0g2J2L+LDsgA9Iq7dfYionXYwkUPa F9JAn4h41pRZwp5qN/WfGeEG2QZ+3vac/dDJeZRMPazhk09AUF SZ5WvT8sFRnXrvJUQ5bqjvKBWMOjhbZ/3sF/vPIZ7kqYcjXM5y ySwnCAXEQFCMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SlPAO9qjPaisHiMJa5fjKf5VFVc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 05:14:56 -0000 On 05 Aug 2014, at 04:15, Darrel Miller wrote: > I have built a parser[1] for the Microsoft .net platform for this > specification. I have used the format on a number of internal APIs > with success. >=20 > I definitely believe there is value in APPSAWG moving forward with = this. +1 It has proven very useful in API design in several projects. Jan >=20 > Darrel >=20 > [1] https://github.com/tavis-software/Tavis.Problem >=20 > On Mon, Aug 4, 2014 at 1:18 PM, Paul Hoffman = wrote: >> On Aug 3, 2014, at 11:21 AM, Alexey Melnikov = wrote: >>=20 >>> There was very little support for this document so far. Are people = interested in working on this document in the APPSAWG? >>=20 >> Sorry for the late reply. This seems like a fine, easy document for = the WG. I'm happy to review it. >>=20 >> --Paul Hoffman >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 4 22:20:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153761B2847 for ; Mon, 4 Aug 2014 22:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKsOSnF9Trpo for ; Mon, 4 Aug 2014 22:20:54 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D931A011B for ; Mon, 4 Aug 2014 22:20:54 -0700 (PDT) Received: (qmail 49719 invoked from network); 5 Aug 2014 05:20:52 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Aug 2014 05:20:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10a3.53e069b4.k1408; i=johnl@user.iecc.com; bh=RkD15o9cIkEeMtCBHBfdyLk55yupsPg4XHRZH1Zs1bQ=; b=rR29ekswEeADZ3wmY9iDxaC58vHr8/fXgAVGdOtJcw0f6CSniV6CIQuAAAMnaKszSz7d0f9J1SCFdN/X5FNsu45PImDvgBrs7/btn3V2F4dTZLD70xve3xspbPnZzy4BHi/5qS10v0x+o8vw4Rcxkk8FnoLLac42P5NAZpAEMRrjAagG2n8UkXBqBsIfULQ+UwLkLNRw0zvV9skMxxa+xDo9yk/dx+PJPZ7OboACWv+oIJunhSuutwP/GTDHLySu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10a3.53e069b4.k1408; olt=johnl@user.iecc.com; bh=RkD15o9cIkEeMtCBHBfdyLk55yupsPg4XHRZH1Zs1bQ=; b=30rSba0YZ10JdzDxJuIqXNy+hqAf4fxayOXkBfPwrDjKN3qkS2svdrWJC7eiRdNvyBjdaNs7wdkENB9ykHXNOiqfypFyRhoJ6RH07XpOmXYGdhR6ChJXE6x9ZiSv/0vPS7EM1DyHLj2DbkNW+6z8ITTJLbNPnUrrVCm4y76LbFTO4WMY1j3pQoxL3goboGJBoWBDoeaLCkg1iZq4KZDROsMAVGQrhjyGDYvVub0A3sg5I5QCRWGpyC4Zr8pdrLDf Date: 5 Aug 2014 05:20:29 -0000 Message-ID: <20140805052029.4258.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20140805051058.12794.68690.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NK2GItMd1uue25RsV_VPOSnANIs Subject: Re: [apps-discuss] New Version Notification - draft-ietf-appsawg-nullmx-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 05:20:56 -0000 This version updates the SMTP return codes and adds the enhanced return codes that Arndt and Ned have suggested. Since those codes are new, the IANA section registers them. It now refers to RFC 1846 on the assumption that it's either an allowable downref, or 1846 will be moved to the standards track soon. I also made a few editorial changes that are intended to clarify what it already says. >A new version (-07) has been submitted for draft-ietf-appsawg-nullmx: >http://www.ietf.org/internet-drafts/draft-ietf-appsawg-nullmx-07.txt > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > >Diff from previous version: >http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-07 From nobody Tue Aug 5 06:30:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B71B27BB; Tue, 5 Aug 2014 06:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6kL6U_BzQe2; Tue, 5 Aug 2014 06:30:52 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523D11B27B0; Tue, 5 Aug 2014 06:30:48 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so709162lab.8 for ; Tue, 05 Aug 2014 06:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oDnUhfItwwlGXsf6bRM4S1jPstWfQ+MUXcsHYE59u6s=; b=a3O18nJFbyJwH6JaiuyhjaRAqJv9UYNuKbVW9B0akcW90xYSwiHn1pFoV6apmi3DiK 69KPiBFmGYA97AIpBWjACBmQia/dRqmdoyot2Vq/xixkpK+vZxf28LSzy62X6VAsqREh BZmns8j0vZ5okNWjyNNxsekxwAmHpoBhhUMDwpVdj7y1eE6d7BBc/K6deDSZ7LREcQ2n 9o00JRHK1+1XCoB8N+c02hW20/4OLPH4nT2oZkiNm0fkLT/SdbeOm7PfGFLpsq10qi8I Dr9FrY3ESe2ieefenr872O/1NcOh3ehIqZXdbWZSGHWzzTX6LkYmgwEl/o8kP+n0EYRp 3Kfw== MIME-Version: 1.0 X-Received: by 10.112.181.74 with SMTP id du10mr4044948lbc.40.1407245446502; Tue, 05 Aug 2014 06:30:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 5 Aug 2014 06:30:46 -0700 (PDT) In-Reply-To: References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> <53E05CF1.9000102@qti.qualcomm.com> Date: Tue, 5 Aug 2014 09:30:46 -0400 X-Google-Sender-Auth: cXTRkDAmwiU7YDz9b7YtIXpYEQo Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c36fe4f35f3804ffe1dce1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/R9-fo5eJ9C74UW87vbc8HDphzcM Cc: Pete Resnick , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , IETF Apps Discuss , The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 13:30:54 -0000 --001a11c36fe4f35f3804ffe1dce1 Content-Type: text/plain; charset=ISO-8859-1 Go ahead and post: we're big girls and boys, and can deal with I-D versions. Barry On Tuesday, August 5, 2014, Murray S. Kucherawy wrote: > On Mon, Aug 4, 2014 at 9:26 PM, Pete Resnick > wrote: > >> >> Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants >> me to leave it for housekeeping purposes; I'll assume that you all can >> decide on the specifics. Thanks for DISCUSSing it. >> >> > Likewise, I'm happy to post the update to the tracker now or wait until > after the telechat. I'll assume the latter unless directed otherwise. > > -MSK > --001a11c36fe4f35f3804ffe1dce1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Go ahead and post: we're big girls and boys, and can deal with I-D vers= ions.

Barry

On Tuesday, August 5, 2014, Murray S.= Kucherawy <superuser@gmail.com> wrote:
On Mon, Aug 4, 2014 at 9:26= PM, Pete Resnick <presni= ck@qti.qualcomm.com> wrote:
=20

Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me to leave it for housekeeping purposes; I'll assume that you all can decide on the specifics. Thanks for DISCUSSing it.


Likewise, I'm happy to post = the update to the tracker now or wait until after the telechat.=A0 I'll= assume the latter unless directed otherwise.

-MSK
--001a11c36fe4f35f3804ffe1dce1-- From nobody Tue Aug 5 06:51:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F381B27B3; Tue, 5 Aug 2014 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iPvpVMnmg5A; Tue, 5 Aug 2014 06:51:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03BB1B27C9; Tue, 5 Aug 2014 06:51:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805135142.9469.91236.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 06:51:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oi57CqTcXjtpbcdnaDB_LX5QYCY Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:51:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-06.txt Pages : 7 Date : 2014-08-05 Abstract: This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates [RFC7208] since some of the code points registered replace the ones recommended for use in that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 5 06:51:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AAA1B27C1 for ; Tue, 5 Aug 2014 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9rtVMyFEYeC; Tue, 5 Aug 2014 06:51:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CC81B27D3; Tue, 5 Aug 2014 06:51:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805135142.9469.3923.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 06:51:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/x1JsLERurdjPGFv-oVRgnptNIiY Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-email-auth-codes-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:51:50 -0000 A new version (-06) has been submitted for draft-ietf-appsawg-email-auth-codes: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-email-auth-codes-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Aug 5 07:01:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CBC1B27EA for ; Tue, 5 Aug 2014 07:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUKuoG05kgfU; Tue, 5 Aug 2014 07:01:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC29B1B280D; Tue, 5 Aug 2014 07:00:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805140053.10968.1519.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 07:00:53 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bZBC5l5LbThu3ZQvn28AIMtr9vE Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 14:01:11 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Tue Aug 5 08:27:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3461B296F; Tue, 5 Aug 2014 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUHKBTfkD42B; Tue, 5 Aug 2014 08:27:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51C1B28DA; Tue, 5 Aug 2014 08:27:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805152705.29148.59423.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 08:27:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Eczd9ICy1v0ZuO9I7eVdQ6nc0WE Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Brian Haberman's Yes on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:27:06 -0000 Brian Haberman has entered the following ballot position for draft-ietf-appsawg-nullmx-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4.1 uses the acronym "DSN" without any expansion. I assume this expands to Delivery Status Notification, which is used later in the section. From nobody Tue Aug 5 09:35:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824371A0030; Tue, 5 Aug 2014 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evBWsB94wbZd; Tue, 5 Aug 2014 09:35:45 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7EB1A0364; Tue, 5 Aug 2014 09:35:45 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.1015.2; Tue, 5 Aug 2014 16:35:42 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.93]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.93]) with mapi id 15.00.1015.001; Tue, 5 Aug 2014 16:35:41 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) Thread-Index: AQHPsE2DCDw8SU69OUKUwt2HkK0ZPpvBUJeAgAAX5ACAAACUAIAAASuAgADKfJA= Date: Tue, 5 Aug 2014 16:35:41 +0000 Message-ID: <456751dd3cce4deca23c50210f4eb72c@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> <53E05CF1.9000102@qti.qualcomm.com> In-Reply-To: <53E05CF1.9000102@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [131.107.192.108] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(479174003)(199002)(189002)(52044002)(52604005)(50944004)(24454002)(76482001)(106116001)(1411001)(105586002)(50986999)(54356999)(76176999)(66066001)(46102001)(80022001)(106356001)(16236675004)(21056001)(93886004)(85306004)(74662001)(85852003)(74502001)(31966008)(83322001)(83072002)(19580405001)(19580395003)(92566001)(19625215002)(19300405004)(99396002)(77982001)(15202345003)(87936001)(79102001)(101416001)(15975445006)(2656002)(4396001)(33646002)(81542001)(107046002)(19617315012)(64706001)(110136001)(20776003)(81342001)(24736002)(108616003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_456751dd3cce4deca23c50210f4eb72cBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SnYsIMjYRDKKm-U38OVWmBWQXak Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 16:35:49 -0000 --_000_456751dd3cce4deca23c50210f4eb72cBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a style nitpick and you can feel free to ignore. I have one complai= nt/suggestion regarding this text: Description: This status code is returned when a message did not contain any acceptable DKIM signatures. (Note that this violates the advice of Section 6.1 of RFC6376.) Description: This status code is returned when a message did not contain any acceptable DKIM signatures whose identifier(s) match the author address(es) found in the From header field. (Note that this violates the advice of Section 6.1 of RFC6376.) This is a special case of the X.7.20 status code. The first two words of the phrases "Note that this violates the advice..." = is redundant and superfluous [1]. In writing, if you have something to note= , then note it; don't say "Note that..." In other words, I propose the shor= ter text "This violates the advice...". -- Terry [1] Note that the words "and superfluous" is redundant in that sentence. From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Pete= Resnick Sent: Monday, August 4, 2014 9:26 PM To: Murray S. Kucherawy Cc: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-email-auth-codes@tool= s.ietf.org; The IESG; IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-em= ail-auth-codes-05: (with DISCUSS) On 8/4/14 11:22 PM, Murray S. Kucherawy wrote: On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick > wrote: Aha. That wasn't clear to me from the current text. I took "valid" to only = be referring to passing the basic DKIM verification algorithms. I didn't re= alize that not passing local policies was a reason to send back X.7.20. Per= haps you could clarify the text? How's this for a new Section 3.1? Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me = to leave it for housekeeping purposes; I'll assume that you all can decide = on the specifics. Thanks for DISCUSSing it. pr 3.1. DKIM Failure Codes In the code point definitions below, the term "acceptable" means both of the following: a. The signature passed the basic DKIM verification algorithm as defined in [RFC6376]; and b. The signature satisfied any local policy requirements in addition to the basic algorithm (e.g., certain header fields included in the signed content, no partial signatures, etc.). Code: X.7.20 Sample Text: No valid DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message did not contain any acceptable DKIM signatures. (Note that this violates the advice of Section 6.1 of RFC6376.) Reference: [this document]; RFC6376 Submitter: M. Kucherawy Change controller: IESG Code: X.7.21 Sample Text: No valid author-matched DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message did not contain any acceptable DKIM signatures whose identifier(s) match the author address(es) found in the From header field. (Note that this violates the advice of Section 6.1 of RFC6376.) This is a special case of the X.7.20 status code. Reference: [this document]; RFC6376 Submitter: M. Kucherawy Change controller: IESG _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_456751dd3cce4deca23c50210f4eb72cBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a style nitpick and you can feel free to ignore. I have one compla= int/suggestion regarding this text:

 

Description:       Thi= s status code is returned when a message
            &nb= sp;            = did not contain any acceptable DKIM
            &nb= sp;            = signatures.  (Note that this violates the
            &nb= sp;            = advice of Section 6.1 of RFC6376.)

Description:       Thi= s status code is returned when a message
            &nb= sp;            = did not contain any acceptable DKIM
            &nb= sp;            = signatures whose identifier(s) match the
            &nb= sp;            = author address(es) found in the From header
            &nb= sp;            = field.  (Note that this violates the advice
            &nb= sp;            = of Section 6.1 of RFC6376.)  This is a
            &nb= sp;            = special case of the X.7.20 status code.

The first two words of the = phrases “Note that this violates the advice…” is redundan= t and superfluous [1]. In writing, if you have something to note, then note it; don’t say “Note that…” In other words, I propo= se the shorter text “This violates the advice…”.

 

-- Terry<= /p>

 

[1] Note that the words = 220;and superfluous” is redundant in that sentence.=

 

 

From: apps-discuss [mailto:apps-discuss-bounces@ietf.= org] On Behalf Of Pete Resnick
Sent: Monday, August 4, 2014 9:26 PM
To: Murray S. Kucherawy
Cc: appsawg-chairs@tools.ietf.org; draft-ietf-appsawg-email-auth-cod= es@tools.ietf.org; The IESG; IETF Apps Discuss
Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-app= sawg-email-auth-codes-05: (with DISCUSS)

 

On 8/4/14 11:22 PM, Murray S. Kucherawy wrote: =

On Mon, Aug 4, 2014 at 9:20 PM, Pete Resnick <presnick@qti.qu= alcomm.com> wrote:

 

Aha. That wasn't clea= r to me from the current text. I took "valid" to only be referrin= g to passing the basic DKIM verification algorithms. I didn't realize that = not passing local policies was a reason to send back X.7.20. Perhaps you could clarify the text?

 

How's this for a new Section 3.1?


Much clearer. I'll remove my DISCUSS in the morning, unless Barry wants me = to leave it for housekeeping purposes; I'll assume that you all can decide = on the specifics. Thanks for DISCUSSing it.

pr


3.1.  DKIM Failu= re Codes

   In the code point definitions below, the term "acceptable= " means both
   of the following:

   a.  The signature passed the basic DKIM verification algo= rithm as
       defined in [RFC6376]; and

   b.  The signature satisfied any local policy requirements= in addition
       to the basic algorithm (e.g., certain = header fields included in
       the signed content, no partial signatu= res, etc.).

      Code:      &nb= sp;        X.7.20
      Sample Text:     &n= bsp;  No valid DKIM signature found
      Associated basic status code:  550
      Description:     &n= bsp;  This status code is returned when a message
            &nb= sp;            = did not contain any acceptable DKIM
            &nb= sp;            = signatures.  (Note that this violates the
            &nb= sp;            = advice of Section 6.1 of RFC6376.)
      Reference:     &nbs= p;    [this document]; RFC6376
      Submitter:     &nbs= p;    M. Kucherawy
      Change controller:  IESG


      Code:      &nb= sp;        X.7.21
      Sample Text:     &n= bsp;  No valid author-matched DKIM signature found
      Associated basic status code:  550
      Description:     &n= bsp;  This status code is returned when a message
            &nb= sp;            = did not contain any acceptable DKIM
            &nb= sp;            = signatures whose identifier(s) match the
            &nb= sp;            = author address(es) found in the From header
            &nb= sp;            = field.  (Note that this violates the advice
            &nb= sp;            = of Section 6.1 of RFC6376.)  This is a
            &nb= sp;            = special case of the X.7.20 status code.
      Reference:     &nbs= p;    [this document]; RFC6376
      Submitter:     &nbs= p;    M. Kucherawy
      Change controller:  IESG

 

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



-- 
Pete Resnick <http:/=
/www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--_000_456751dd3cce4deca23c50210f4eb72cBL2SR01MB605namsdf01sdf_-- From nobody Tue Aug 5 10:08:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACA61A039F for ; Tue, 5 Aug 2014 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abblgwysEwyw for ; Tue, 5 Aug 2014 10:08:10 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5101A0376 for ; Tue, 5 Aug 2014 10:08:09 -0700 (PDT) Received: from pc6 (86.144.255.226) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 5 Aug 2014 17:08:07 +0000 Message-ID: <011101cfb0cf$3b90d4e0$4001a8c0@gateway.2wire.net> From: t.petch To: Pete Resnick , Barry Leiba References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53E0590E.8060204@qti.qualcomm.com> Date: Tue, 5 Aug 2014 18:03:45 +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-Originating-IP: [86.144.255.226] X-ClientProxiedBy: DB4PR03CA0011.eurprd03.prod.outlook.com (25.160.39.149) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02945962BD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(51704005)(479174003)(189002)(199002)(24454002)(88136002)(23756003)(83322001)(81542001)(77156001)(44736004)(44716002)(81342001)(84392001)(99396002)(77982001)(93886004)(87976001)(85306004)(14496001)(76176999)(80022001)(4396001)(81686999)(106356001)(92726001)(81816999)(107046002)(79102001)(92566001)(95666004)(15975445006)(83072002)(19580395003)(85852003)(42186005)(77096002)(20776003)(21056001)(50466002)(87286001)(61296003)(50226001)(64706001)(76482001)(102836001)(101416001)(50986999)(33646002)(62236002)(74502001)(66066001)(74662001)(46102001)(19580405001)(31966008)(89996001)(47776003)(62966002)(15202345003)(105586002)(104166001)(86362001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VHPaR-p6v1XnZCvg2jJm71GhVBY Cc: apps-discuss , app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 17:08:13 -0000 ----- Original Message ----- From: "Pete Resnick" To: "Barry Leiba" Cc: "Ned Freed" ; ; Sent: Tuesday, August 05, 2014 5:09 AM > On 8/4/14 9:16 AM, Barry Leiba wrote: > > Murray says: > > > > All that said, we have to decide whether we want to change the > > boilerplate, which currently says this: > > > > This memo defines an Experimental Protocol for the Internet > > community. This memo does not specify an Internet standard of any > > kind. > > > > We might decide that it's weird to have an Internet Standard with that > > boilerplate in it. > > > > I think you will find that, even if we don't think it weird, the RFC > Editor will think it terribly weird. I believe they will require a new > document with a new boilerplate; I seem to remember trying this before > and them not wanting to advance the document in place. RFC1846 is a fine document for its time but the IETF has changed what is expected of a Standard RFC somewhat since then and, reading RFC1846, there is an awful lot more boilerplate that I think may have to be changed (but I think that we should still do it). For example, References, Copyright (for older material), Security, the personal details of the editors, RFC2119 etc; and then there are calls for IPR claims, contacting the editors, verifying that all the options listed have interoperable implementations etc It is a bit like trying to upgrade Windows 95 to Windows 7 - easier just to buy an iPhone:-) Tom Petch > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Aug 5 10:28:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A01A1A046A for ; Tue, 5 Aug 2014 10:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z7JVOTpFPRr for ; Tue, 5 Aug 2014 10:27:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438C51A045B for ; Tue, 5 Aug 2014 10:27:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEiWW-000IJ9-RW; Tue, 05 Aug 2014 13:27:44 -0400 Date: Tue, 05 Aug 2014 13:27:39 -0400 From: John C Klensin To: "t.petch" , Pete Resnick , Barry Leiba Message-ID: <4E6803044B68F2584F639848@JcK-HP8200.jck.com> In-Reply-To: <011101cfb0cf$3b90d4e0$4001a8c0@gateway.2wire.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53E0590E.8060204@qti.qualcomm.com> <011101cfb0cf$3b90d4e0$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X2Y6_u2saD2XLoK2MoD9GJmKt0E Cc: apps-discuss , app-ads@tools.ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 17:28:00 -0000 Tom (and others), Having reviewed the document and sensed the way the wind is blowing, I've generated an XML-based version of the document with updated references, boilerplate, and some general cleanup. I've also written the authors or 1846, with a copy to Pete and Barry, asking how they would like to proceed and will now wait a reasonable amount of time to hear from them. The revision-generating process took about a half-hour, far less time that it would take to debate whether or not it was _really_ necessary on this list. :-( As a preview, the draft "Differences from RFC 1846" section now reads, approximately, o Updated boilerplate and editorial material for a standards track document. As part of this, added new Section 1 ("Introduction") and Section 7 ("Context and other Approaches"). o Removed "experimental" material o Updated references and improved ties to RFC 5321. o Mentioned the "nullMX" relationship. Of course, if the 1846 authors take the document over, they may discard some or all of that material. john --On Tuesday, August 05, 2014 18:03 +0100 "t.petch" wrote: > ----- Original Message ----- > From: "Pete Resnick" > To: "Barry Leiba" > Cc: "Ned Freed" ; > ; > Sent: Tuesday, August 05, 2014 5:09 AM >> On 8/4/14 9:16 AM, Barry Leiba wrote: >> > Murray says: >> > > >> > All that said, we have to decide whether we want to change >> > the boilerplate, which currently says this: >> > >> > This memo defines an Experimental Protocol for the >> > Internet community. This memo does not specify an >> > Internet standard of > any >> > kind. >> > >> > We might decide that it's weird to have an Internet >> > Standard with > that >> > boilerplate in it. >> > >> >> I think you will find that, even if we don't think it weird, >> the RFC Editor will think it terribly weird. I believe they >> will require a new document with a new boilerplate; I seem to >> remember trying this before and them not wanting to advance >> the document in place. > > RFC1846 is a fine document for its time but the IETF has > changed what is expected of a Standard RFC somewhat since then > and, reading RFC1846, there is an awful lot more boilerplate > that I think may have to be changed (but I think that we > should still do it). > > For example, References, Copyright (for older material), > Security, the personal details of the editors, RFC2119 etc; > and then there are calls for IPR claims, contacting the > editors, verifying that all the options listed have > interoperable implementations etc It is a bit like trying to > upgrade Windows 95 to Windows 7 - easier just to buy an > iPhone:-) > > Tom Petch > >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Tue Aug 5 11:15:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62681A0080; Tue, 5 Aug 2014 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiAv0pn0YpyT; Tue, 5 Aug 2014 11:15:23 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C481A0067; Tue, 5 Aug 2014 11:15:21 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so1400576wes.35 for ; Tue, 05 Aug 2014 11:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=phqOOG6WZdaTIYPsVfvDnGncIkQiV+XduQDlQG58n4o=; b=V6gQJ4dxGDd73DyZ6TgxggUxkyfO7s55GSKzLHsnw8h0ToZsIUT1ixDqn4j4j92ebe jWmE8uB1izt2ThJK92JBuu0afpYA9AoFt8Cs4H3u+2mAaHriCjpK8IRotE8B3DlGkrFL WdOzNMNTYLEyZn/kfvCRQRW46dzmrexkleBkx17F+m11mrN+iFhVjb7PNnLhXzTPrDj2 X2E16qnRSMcx5EUuLY0khyj2aw+5eDoGTq077207PTdu0BhRHasbLIT3iDrBmEoh9FFe DFEqjvjyTKovDtaeGfg4kQcH0I4zauFpQdwF5iSdj8K6xPJTTaod4ae7DLrgFRwiY1Qn 6eJQ== MIME-Version: 1.0 X-Received: by 10.194.62.67 with SMTP id w3mr8372327wjr.32.1407262518170; Tue, 05 Aug 2014 11:15:18 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Tue, 5 Aug 2014 11:15:18 -0700 (PDT) In-Reply-To: <456751dd3cce4deca23c50210f4eb72c@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> <53E05B7A.5060308@qti.qualcomm.com> <53E05CF1.9000102@qti.qualcomm.com> <456751dd3cce4deca23c50210f4eb72c@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Tue, 5 Aug 2014 11:15:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7b872e9a805fe304ffe5d611 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dRfvhs1dnWCRbRSuUotGek-G5nQ Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 18:15:26 -0000 --047d7b872e9a805fe304ffe5d611 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 5, 2014 at 9:35 AM, Terry Zink wrote: > This is a style nitpick and you can feel free to ignore. I have one > complaint/suggestion regarding this text: > > > > Description: This status code is returned when a message > did not contain any acceptable DKIM > signatures. (Note that this violates the > advice of Section 6.1 of RFC6376.) > > Description: This status code is returned when a message > did not contain any acceptable DKIM > signatures whose identifier(s) match the > author address(es) found in the From header > field. (Note that this violates the advice > of Section 6.1 of RFC6376.) This is a > special case of the X.7.20 status code. > > The first two words of the phrases =E2=80=9CNote that this violates the = advice=E2=80=A6=E2=80=9D > is redundant and superfluous [1]. In writing, if you have something to > note, then note it; don=E2=80=99t say =E2=80=9CNote that=E2=80=A6=E2=80= =9D In other words, I propose the > shorter text =E2=80=9CThis violates the advice=E2=80=A6=E2=80=9D. > Thanks for the suggestion. If there's another version of the draft, I'll remove it. There's adequate discussion of what's going on in the following section anyway. If there's no new version, Barry can have the RFC Editor make that adjustment if he's so inclined. -MSK --047d7b872e9a805fe304ffe5d611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 5, 2014 at 9:35 AM, Terry Zink <tz= ink@exchange.microsoft.com> wrote:

This is a style nitpick and you can feel free to ignore. = I have one complaint/suggestion regarding this text:

=C2=A0=

Description:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thi= s status code is returned when a message
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= did not contain any acceptable DKIM
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= signatures.=C2=A0 (Note that this violates the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= advice of Section 6.1 of RFC6376.)

Description:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 This status code is returned when a message
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= did not contain any acceptable DKIM
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= signatures whose identifier(s) match the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= author address(es) found in the From header
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= field.=C2=A0 (Note that this violates the advice
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= of Section 6.1 of RFC6376.)=C2=A0 This is a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= special case of the X.7.20 status code.

The first two words o= f the phrases =E2=80=9CNote that this violates the advice=E2=80=A6=E2=80=9D= is redundant and superfluous [1]. In writing, if you have something to not= e, then note it; don=E2=80=99t say =E2=80=9CNote that=E2=80=A6=E2=80=9D In other words,= I propose the shorter text =E2=80=9CThis violates the advice=E2=80=A6=E2= =80=9D.


--047d7b872e9a805fe304ffe5d611-- From nobody Tue Aug 5 12:06:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB11B2B0E for ; Tue, 5 Aug 2014 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXOGWonJLuFU; Tue, 5 Aug 2014 12:06:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B5B1B2AFF; Tue, 5 Aug 2014 12:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805190647.25861.13140.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 12:06:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dRg4njYnhJbZTcN9jNWCyuM2fjw Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:06:50 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Tue Aug 5 13:37:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DBE1B2B8B; Tue, 5 Aug 2014 13:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fnoIE7W6tqJ; Tue, 5 Aug 2014 13:37:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C41A0302; Tue, 5 Aug 2014 13:37:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805203745.7333.47126.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 13:37:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/53H3blXCwbfJknheWvv3Ey7kXbc Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Adrian Farrel's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:37:47 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-appsawg-nullmx-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objection to the publication of this document and you'll probably call me picky when I point to the last line in Section 3. A domain MUST NOT advertise multiple MX RRs including a null MX. That says one of two things: 1. You must not advertise multiple MX RR if any one of them is a null MX. 2. You must not advertise more than one null MX, but may advertise one null MX along with other MX RRs. I think you mean the former in which case... A domain that advertises a null MX MUST NOT advertise any other MX RR. But, if you meant the latter that could also be clarified. From nobody Tue Aug 5 15:02:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D81B2C00 for ; Tue, 5 Aug 2014 15:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trLuTgBJCoL9 for ; Tue, 5 Aug 2014 15:01:57 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E95D1B2BFA for ; Tue, 5 Aug 2014 15:01:56 -0700 (PDT) Received: (qmail 99865 invoked from network); 5 Aug 2014 22:01:55 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Aug 2014 22:01:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=123b5.53e15451.k1408; i=johnl@user.iecc.com; bh=wnCy7R+Kc4JZBen02dym/5acp4NUgHtRrzl63lnts60=; b=mfNryioTw66Ej/SSbj84FW1CsYlDacFtd3mv3AE4CLxYVbnpOyxjY0tIJ9FKLsGJNcp5IHzRJzCgFp5MpGa9SeSR6LIwt2aRlqgfYZ22Lgo1JjEr/ZwrbTWVYYt9FzJP4x79ANr2ErvmCxH57154NMGQOpj+OiAobiyTI6DTw7tDBZUq8OefG0ykKcjovnaF3FWJcjomAWMZzoV285HCW7l5oq7CfLAg71RA6j+yPAnGKBvkaVMCMqmvop3Pz5Zo DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=123b5.53e15451.k1408; olt=johnl@user.iecc.com; bh=wnCy7R+Kc4JZBen02dym/5acp4NUgHtRrzl63lnts60=; b=ZcEDTnKxjiFf0ps/AKPjjGIGsoowEPLohTgli2GctP3LezVayggFZBdxTVw2wTC+bvBg0pT8RhT98Coce3jlxbtSDwNkHzRFmlEcEl5Fze6f4T3OfUdCVUec6gGpMEdCQ2vjWRepFzSoLYafWJi3m7gus/pA0OPQz9K8UAjjf+noRQ10EhPPXix6IROYLbVdbjMe1RArPv8CpAZU+8XxWU6qRmvj51c/83in+MYsVND4Vd+s5dtK3zTURWDqMiZ3 Date: 5 Aug 2014 22:01:31 -0000 Message-ID: <20140805220131.74676.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <011101cfb0cf$3b90d4e0$4001a8c0@gateway.2wire.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iFzSQC63ebstqQwEiDiACLreh2E Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 22:01:58 -0000 >RFC1846 is a fine document for its time but the IETF has changed >what is expected of a Standard RFC somewhat since then ... That's true, but we also have a lot of standards from 1995 and earlier that we use every day. Unless you think there's something in 1846 that is wrong and needs to be changed, what interop problem would be be solving by recycling and adding all the modern goop? The copyright and other admin problems are water under the bridge, it's published, nothing's going to change about it. R's, John PS: On the third hand, I have some sympathy for Klensin's concern that doing the goop could be faster than deciding not to do it. From nobody Tue Aug 5 15:44:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46331B2C11; Tue, 5 Aug 2014 15:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl8AdvpvKFD0; Tue, 5 Aug 2014 15:44:12 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD841B2854; Tue, 5 Aug 2014 15:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407278651; d=isode.com; s=selector; i=@isode.com; bh=B/AuPK8CJQhq/Xmy7kFgiJSPziwBhR+Bi6U5uiaHKxM=; 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=oiiCOgVreHc9TTrvs1RayXeR3U6gxi7Wmpz5HGqw6cdTnPjnc3W+0Tb7OqfjoOQ8DDBe/k Dp/orflZLXAyiSqW9knayXRB4eIB+QrNdCxLTVjBNOBAHTkTa6pie+5Ge9CJ4vQAWMVqYX pbMr8wsiAYb8djj0pNG8MaL50+Vck6o=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 5 Aug 2014 23:44:11 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11D201) In-Reply-To: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> Date: Tue, 5 Aug 2014 23:54:07 +0100 Message-Id: <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> To: Kathleen Moriarty MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nCkODsAajXql-DEeYJQ1XK7RG2s Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 22:44:14 -0000 Hi Kathleen, > On 5 Aug 2014, at 22:59, "Kathleen Moriarty" wrote: >=20 > The draft is well written and this should be easy to clear, but I thought > it was important to discuss to see if a change might be needed. >=20 > In the security considerations section, the following sentence says, > "Mailboxes matching the source options for which the logged-in user > lacks sufficient rights MUST be ignored by the ESEARCH command > processing (see the paragraph about this in Section 2.2). " >=20 > It is good that access is not permitted, but shouldn't this be logged as > a possible access attempt violation? There was no intent to prevent logging, but the general approach of access c= ontrol to mailboxes in IMAP is "treat mailboxes you don't have access to as n= on existent". So logging all mailboxes that the user has no access too is no= t necessarily productive and might generate lots of noise. The point of the sentence was to remind implementors that access control per= missions are still to be checked. Best Regards, Alexey From nobody Tue Aug 5 15:51:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5D71A03CA for ; Tue, 5 Aug 2014 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QthGKVbK-tXh for ; Tue, 5 Aug 2014 15:51:44 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326D91B2814 for ; Tue, 5 Aug 2014 15:51:42 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XEna0-000Iis-Ek; Tue, 05 Aug 2014 18:51:40 -0400 Date: Tue, 05 Aug 2014 18:51:35 -0400 From: John C Klensin To: John Levine , apps-discuss@ietf.org Message-ID: In-Reply-To: <20140805220131.74676.qmail@joyce.lan> References: <20140805220131.74676.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 X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7I4bF1lMqXtpiSEDy0m3x_gc-cY Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Aug 2014 22:51:46 -0000 --On Tuesday, August 05, 2014 22:01 +0000 John Levine wrote: >> RFC1846 is a fine document for its time but the IETF has >> changed what is expected of a Standard RFC somewhat since >> then ... > > That's true, but we also have a lot of standards from 1995 and > earlier that we use every day. > > Unless you think there's something in 1846 that is wrong and > needs to be changed, what interop problem would be be solving > by recycling and adding all the modern goop? The copyright > and other admin problems are water under the bridge, it's > published, nothing's going to change about it. There is, in fairness, a little bit of text there about experiments (e.g., telling the authors how things worked out) as well as the traditional "...does not specify an Internet standard of any kind" status statement. Like (I assume) you and Barry, I think that stuff can be blown off by a procedural reclassification if anything can. But... > PS: On the third hand, I have some sympathy for Klensin's > concern that doing the goop could be faster than deciding not > to do it. Based on recent history, I can easily imagine our spending days and days debating just what conditions an Experimental spec needs to meet to be moved onto the standards track without a new document and then days more debating whether this one qualifies. I can also imagine days or weeks of amateur lawyering about apparently-contradictory statements, etc. A 30 minute investment in a draft that, with signoff from the original authors, could be ready to go into a four week Last Call late this week or early next seemed more efficient and less frustrating and, of course, it would immediately satisfy those who believe it is really necessary. I'm not sure I like what it says about the IETF if that extra ritual is the best answer, but I think the pragmatic approach is to just do it and debate the rest later. The tone of the comment to which you responded just reinforces that view. john From nobody Tue Aug 5 19:54:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FD01A0AFB; Tue, 5 Aug 2014 19:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkTpVTgOiyIl; Tue, 5 Aug 2014 19:53:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7605B1A0B09; Tue, 5 Aug 2014 19:53:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806025357.32613.75967.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 19:53:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SnoaR5UJfFpiWkxZUnn_2cNWS0M Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-nottingham-safe-hint-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 02:54:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The "safe" HTTP Preference Author : Mark Nottingham Filename : draft-nottingham-safe-hint-03.txt Pages : 8 Date : 2014-08-05 Abstract: This specification defines a "safe" preference for HTTP requests, expressing a desire to avoid "objectionable" content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-nottingham-safe-hint-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-nottingham-safe-hint-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 6 06:33:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4251B2A0A; Wed, 6 Aug 2014 06:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MysQEKyqbxu; Wed, 6 Aug 2014 06:33:24 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328391B2A06; Wed, 6 Aug 2014 06:33:24 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so1975562lam.14 for ; Wed, 06 Aug 2014 06:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ktT/9+E183lp53t3FRqnRyc1MfE5mSIcDgxXVdyXGlM=; b=JG+awY8du3rzBwYHitXq6Sco7GGn4lxtkh1cjKzo8OTMoDReSF3XWaT4ZDd+NNZZvy PDDwl+LxxQrC0Jgf5nnvXioKT5q0fJhi+2dNseUN9POs7C957ytFRbsM8stpq6U8TkL7 2mTXsNtv2JdhrB2zG93TuQaz97NtMHuOHkAjt6iAaqv513rJTsP78cait2qhPYpT76wE gXLNbLuFOEBpyLPbztAaVU0rY/GoPxK4IdWomoz1dslPsopKV4hxncKaW611FoBLfXec 95tS/eylWg2nsWxIDRk54DeXnQ8yrtm2ngieqY+9VV44mVRzQdiajNm7yjYvsgbq7O1N zVpg== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr10657044lbc.16.1407332002411; Wed, 06 Aug 2014 06:33:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Wed, 6 Aug 2014 06:33:22 -0700 (PDT) In-Reply-To: <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> Date: Wed, 6 Aug 2014 09:33:22 -0400 X-Google-Sender-Auth: t9IKjPGe6gsXhpBJiRwXShSNwes Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c2448215bbc504fff604f3 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Pd1t5W_JgvXs5GmhDOf4yI93a5Y Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , Kathleen Moriarty , "appsawg-chairs@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 13:33:26 -0000 --001a11c2448215bbc504fff604f3 Content-Type: text/plain; charset=ISO-8859-1 What Alexey said. To add to that: 1. Subtree searches and the like are quite likely to match mailboxes that the user does not have access to, and logging such things would not be useful. 2. In general, IMAP says nothing at all about logging. It defines the protocol. Logging (along with what to log) is an implementation choice. This document shouldn't be saying any more about it than RFC 3501, or other IMAP specs. Barry On Tuesday, August 5, 2014, Alexey Melnikov > wrote: > Hi Kathleen, > > > On 5 Aug 2014, at 22:59, "Kathleen Moriarty" < > Kathleen.Moriarty.ietf@gmail.com> wrote: > > > > The draft is well written and this should be easy to clear, but I thought > > it was important to discuss to see if a change might be needed. > > > > In the security considerations section, the following sentence says, > > "Mailboxes matching the source options for which the logged-in user > > lacks sufficient rights MUST be ignored by the ESEARCH command > > processing (see the paragraph about this in Section 2.2). " > > > > It is good that access is not permitted, but shouldn't this be logged as > > a possible access attempt violation? > > There was no intent to prevent logging, but the general approach of access > control to mailboxes in IMAP is "treat mailboxes you don't have access to > as non existent". So logging all mailboxes that the user has no access too > is not necessarily productive and might generate lots of noise. > > The point of the sentence was to remind implementors that access control > permissions are still to be checked. > > Best Regards, > Alexey > > > --001a11c2448215bbc504fff604f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What Alexey said.

To add to that:
1.=A0Subtree= searches and the like are quite likely to match mailboxes that the user do= es not have access to, and logging such things would not be useful.


Barry

On Tuesday, August 5, 2014, Alexey Melniko= v <alexey.melnikov@isode.com> wrote:=
Hi Kathleen,

> On 5 Aug 2014, at 22:59, "Kathleen Moriarty" <Kathleen= .Moriarty.ietf@gmail.com> wrote:
>
> The draft is well written and this should be easy to clear, but I thou= ght
> it was important to discuss to see if a change might be needed.
>
> In the security considerations section, the following sentence says, > "Mailboxes matching the source options for which the logged-in us= er
> =A0 lacks sufficient rights MUST be ignored by the ESEARCH command
> =A0 processing (see the paragraph about this in Section 2.2). " >
> It is good that access is not permitted, but shouldn't this be log= ged as
> a possible access attempt violation?

There was no intent to prevent logging, but the general approach of access = control to mailboxes in IMAP is "treat mailboxes you don't have ac= cess to as non existent". So logging all mailboxes that the user has n= o access too is not necessarily productive and might generate lots of noise= .

The point of the sentence was to remind implementors that access control pe= rmissions are still to be checked.

Best Regards,
Alexey


--001a11c2448215bbc504fff604f3-- From nobody Wed Aug 6 06:45:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C71B2D37 for ; Wed, 6 Aug 2014 06:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IedV_7bVohxq for ; Wed, 6 Aug 2014 06:44:54 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFC21B2A0A for ; Wed, 6 Aug 2014 06:44:53 -0700 (PDT) Received: from pc6 (86.144.255.226) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Wed, 6 Aug 2014 13:44:51 +0000 Message-ID: <00d701cfb17c$00a35940$4001a8c0@gateway.2wire.net> From: t.petch To: John Levine , References: <20140805220131.74676.qmail@joyce.lan> Date: Wed, 6 Aug 2014 14:39:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.144.255.226] X-ClientProxiedBy: DB4PR02CA0025.eurprd02.prod.outlook.com (10.242.174.153) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 02951C14DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(199002)(51704005)(377454003)(21056001)(89996001)(23676002)(14496001)(80022001)(64706001)(66066001)(20776003)(44716002)(79102001)(47776003)(88136002)(77156001)(87286001)(62236002)(87976001)(62966002)(92726001)(81542001)(46102001)(93916002)(4396001)(86362001)(92566001)(50226001)(83072002)(85852003)(77982001)(76482001)(44736004)(19580395003)(19580405001)(84392001)(83322001)(74662001)(74502001)(31966008)(81342001)(50466002)(102836001)(105586002)(104166001)(95666004)(106356001)(61296003)(77096002)(42186005)(99396002)(50986999)(81816999)(33646002)(76176999)(81686999)(107886001)(107046002)(85306004)(101416001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RjfWCTV2fQ7giOMZlDA4invG3rw Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 13:44:57 -0000 ----- Original Message ----- From: "John Levine" To: Cc: Sent: Tuesday, August 05, 2014 11:01 PM > >RFC1846 is a fine document for its time but the IETF has changed > >what is expected of a Standard RFC somewhat since then ... > > That's true, but we also have a lot of standards from 1995 and earlier > that we use every day. > > Unless you think there's something in 1846 that is wrong and needs to > be changed, what interop problem would be be solving by recycling and > adding all the modern goop? The copyright and other admin problems > are water under the bridge, it's published, nothing's going to change > about it. John I have been amazed in recent times at the hostility shown at IETF Last Call to an I-D that has been extensively reviewed and well regarded in a WG. So putting RFC1846 out with its present wording as an exemplar of an IETF full Standard in 2014 .. mmm it might sneak out unnoticed by any other Area or WG but I think it more likely we would generate a DoS attack on Appsawg. So, nothing to do with interop or anything technical, just politics. Simpler to take the technical content and recast it in modern form; I reckoned it would take me half a day and thought I might do it on Friday but no matter, the job has been done better, with a much better chance of success, than I would have done it. Tom Petch > R's, > John > > PS: On the third hand, I have some sympathy for Klensin's concern that > doing the goop could be faster than deciding not to do it. From nobody Wed Aug 6 07:19:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFAD1B2B1B for ; Wed, 6 Aug 2014 07:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drUTOiNxmkom for ; Wed, 6 Aug 2014 07:19:48 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0076.outbound.protection.outlook.com [213.199.154.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4701B2D4F for ; Wed, 6 Aug 2014 07:19:47 -0700 (PDT) Received: from pc6 (86.144.255.226) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 14:19:44 +0000 Message-ID: <011c01cfb180$e0949d80$4001a8c0@gateway.2wire.net> From: t.petch To: Barry Leiba , References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> Date: Wed, 6 Aug 2014 15:05:05 +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-Originating-IP: [86.144.255.226] X-ClientProxiedBy: DB4PR02CA0047.eurprd02.prod.outlook.com (10.242.174.175) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02951C14DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(51704005)(189002)(199002)(77096002)(62236002)(44716002)(66066001)(42186005)(46102001)(105586002)(23756003)(61296003)(87286001)(107046002)(33646002)(79102001)(77982001)(87976001)(80022001)(20776003)(15975445006)(50466002)(47776003)(93886004)(85306004)(95666004)(64706001)(106356001)(81542001)(81342001)(77156001)(76482001)(84392001)(101416001)(21056001)(83322001)(19580405001)(19580395003)(74662001)(99396002)(74502001)(85852003)(31966008)(83072002)(104166001)(86362001)(92726001)(92566001)(102836001)(62966002)(93916002)(81816999)(76176999)(81686999)(50226001)(4396001)(44736004)(88136002)(14496001)(50986999)(89996001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aUZxoagP7BK9uKA9MveWSpZFMSE Cc: Ned Freed Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 14:19:50 -0000 ----- Original Message ----- From: "Barry Leiba" To: Cc: "Ned Freed" Sent: Monday, August 04, 2014 8:29 PM > Ned says... > > FWIW, I didn't even notice that RFC 1846 was experimental. > > I agree with John's assessment that this has been PS or better for years. > > Excellent. So, let me ask it this way: > > Does anyone object to: > > 1. Moving RFC 1846 from Experimental to Proposed Standard? > > 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? > > If you do, please say why. Barry A reservation. Internet Standard requires that all the described features have been implemented and while '521' is clearly implemented in plenty of places, are there two implementations of each and every feature (which is what I have seen called out in other such proposals?) I would parse RFC1846 into about five separate features, and it is not clear to me that the implementations all do everything (well, they don't, but I am uncertain which they do do:-( Or is RFC6410 (3) There are no unused features in the specification that greatly increase implementation complexity. woolly enough for us to say that there is nothing of complexity involved? Tom Petch > If no one objects in the next couple of days, I'll create the > status-change document and start a four-week last call on it, which > will give plenty more time for any objections to surface, should there > be any. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Aug 6 07:25:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45461B27CF for ; Wed, 6 Aug 2014 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pzYfe1_lIE4 for ; Wed, 6 Aug 2014 07:25:06 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEA81B27C9 for ; Wed, 6 Aug 2014 07:25:05 -0700 (PDT) Received: from pc6 (86.144.255.226) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 14:25:03 +0000 Message-ID: <014201cfb181$9e54f860$4001a8c0@gateway.2wire.net> From: t.petch To: , , apps-discuss References: <20140805190647.25861.13140.idtracker@ietfa.amsl.com> Date: Wed, 6 Aug 2014 15:20:41 +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-Originating-IP: [86.144.255.226] X-ClientProxiedBy: DB4PR02CA0049.eurprd02.prod.outlook.com (10.242.174.177) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02951C14DC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(377454003)(13464003)(51704005)(199002)(189002)(81816999)(50986999)(74662001)(77096002)(15202345003)(81686999)(99396002)(31966008)(66066001)(95666004)(14496001)(74502001)(76176999)(105586002)(89996001)(21056001)(85852003)(87286001)(101416001)(92566001)(61296003)(50226001)(104166001)(62236002)(87976001)(84392001)(50466002)(83322001)(62966002)(4396001)(20776003)(76482001)(19580395003)(42186005)(44736004)(107886001)(15975445006)(85306004)(64706001)(83072002)(107046002)(81542001)(44716002)(47776003)(86362001)(80022001)(33646002)(88136002)(46102001)(77982001)(81342001)(19580405001)(92726001)(106356001)(93916002)(77156001)(102836001)(23756003)(79102001)(74416001)(7726001)(162123002); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FjveexREKHtwc-4gghITnvRVed8 Subject: Re: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 14:25:09 -0000 I see no explanation from IANA as to their objections to this I-D - if they are in the tracker, then finding them has defeated me - but wonder if it is because the I-D does not mention that this is an update to the Enumerated Status Codes (obvious as that might be to us). Tom Petch ----- Original Message ----- From: "IETF Secretariat" To: ; ; ; Sent: Tuesday, August 05, 2014 8:06 PM > IANA review state changed to IANA - Not OK > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Aug 6 07:28:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B7B1B27D3 for ; Wed, 6 Aug 2014 07:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CeW5tL4F0Ai for ; Wed, 6 Aug 2014 07:28:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9871B27CF for ; Wed, 6 Aug 2014 07:28:42 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s76ESZB8026317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Aug 2014 07:28:38 -0700 Message-ID: <53E23B0F.5060709@dcrocker.net> Date: Wed, 06 Aug 2014 07:26:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "t.petch" , appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, apps-discuss References: <20140805190647.25861.13140.idtracker@ietfa.amsl.com> <014201cfb181$9e54f860$4001a8c0@gateway.2wire.net> In-Reply-To: <014201cfb181$9e54f860$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 06 Aug 2014 07:28:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/C3cDsmZdHElGkAL6cStqYo8LGh4 Subject: Re: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:28:44 -0000 On 8/6/2014 7:20 AM, t.petch wrote: > I see no explanation from IANA as to their objections to this I-D - if > they are in the tracker, then finding them has defeated me - but > wonder if it is because the I-D does not mention that this is an update > to the Enumerated Status Codes (obvious as that might be to us). http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/history/ The entry below the system-generated IANA Review state can be expanded and shows extended comments from Pearl Liang. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 6 08:46:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3412E1B2BBF; Tue, 5 Aug 2014 14:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFfW_1HMiDJ2; Tue, 5 Aug 2014 14:59:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE33F1A0317; Tue, 5 Aug 2014 14:59:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> Date: Tue, 05 Aug 2014 14:59:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5G6BLQNs8wKKnUcgIKQFtzc0Tg8 X-Mailman-Approved-At: Wed, 06 Aug 2014 08:46:35 -0700 Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:59:02 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The draft is well written and this should be easy to clear, but I thought it was important to discuss to see if a change might be needed. In the security considerations section, the following sentence says, "Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing (see the paragraph about this in Section 2.2). " It is good that access is not permitted, but shouldn't this be logged as a possible access attempt violation? From nobody Wed Aug 6 09:10:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA51A0AE6; Wed, 6 Aug 2014 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRQkpG2nZ9ee; Wed, 6 Aug 2014 09:09:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0361A045D; Wed, 6 Aug 2014 09:09:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 09:09:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6c358KDAHYF1VIcAjA3ut5q1mb8 Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 16:10:00 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-nullmx-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just curious - do we know or are we guessing that this won't be an issue for DNSSEC (implementations)? I've no info either way, so its purely curiosity, really:-) From nobody Wed Aug 6 09:29:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20E1A0AED; Wed, 6 Aug 2014 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfffdBDiv_ic; Wed, 6 Aug 2014 09:29:45 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE67C1A0AEA; Wed, 6 Aug 2014 09:29:42 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gf5so2383573lab.9 for ; Wed, 06 Aug 2014 09:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h0iCBaNC07ts4JuvVZSV68JJyurZzXXvaZFkQfzpirM=; b=RZmnYNvvm3B4dRZXifXvAFlm/gAG2IzLbtHeN46RYMwkXZyfdaoHd5Y+Zxni70Jq8X 92im95z91AZxvo4jafn75n7jM5J40tEQrb/qTP+qLVuVN+ny+JH+zAuzQdjnPYDYi2BO NskSyuLavcgQxHHyp9f4y/7UA5Hy3pmXLk97LSK5hlJKCOFVCDjZBC+TeOStQ8l/5EC0 Ga/WeVhir3GAjOOVt4q8YTQcxzJh2cMHpRKvElKPNhldNc/jjSszxV+FvA6WjnIxBLNA L+hQA9zCqhApwkgj0asPK5ZuDDhrwrQo9BirrTJLgfegJMdK7PmoINWF1Md432KxYQDA xPIA== MIME-Version: 1.0 X-Received: by 10.112.161.201 with SMTP id xu9mr11414553lbb.59.1407342581178; Wed, 06 Aug 2014 09:29:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Wed, 6 Aug 2014 09:29:41 -0700 (PDT) In-Reply-To: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> Date: Wed, 6 Aug 2014 12:29:41 -0400 X-Google-Sender-Auth: 5Dli9ooMGtNBrszUu3fSZ7s2cLw Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JnNkx5o_C6B_UzofmY8fn-wuOAA Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 16:29:46 -0000 > Just curious - do we know or are we guessing that > this won't be an issue for DNSSEC (implementations)? > I've no info either way, so its purely curiosity, > really:-) I don't understand what might be an issue for DNSSEC (implementations). What are you thinking? Barry From nobody Wed Aug 6 09:58:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2B1A0AE6; Wed, 6 Aug 2014 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66zV6-sIecmU; Wed, 6 Aug 2014 09:57:52 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6471A03F9; Wed, 6 Aug 2014 09:57:52 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B791B8A031; Wed, 6 Aug 2014 16:57:51 +0000 (UTC) Date: Wed, 6 Aug 2014 12:57:50 -0400 From: Andrew Sullivan To: Stephen Farrell Message-ID: <20140806165750.GB37544@mx1.yitter.info> References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EhX0_8X7Lkyyn7HL3-zl4w9RYBE Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 16:57:54 -0000 On Wed, Aug 06, 2014 at 09:09:58AM -0700, Stephen Farrell wrote: > > Just curious - do we know or are we guessing that > this won't be an issue for DNSSEC (implementations)? > I've no info either way, so its purely curiosity, > really:-) If it is, they're utterly broken. I doubt anyone has tested, but it would be wrong for an implementation to spit up on the RDATA like that. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Aug 6 12:13:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619361B27AE; Wed, 6 Aug 2014 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW6FWPINrSlW; Wed, 6 Aug 2014 12:13:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7705F1A003A; Wed, 6 Aug 2014 12:13:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806191310.7603.58212.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 12:13:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GXNw-J2_pn98SksoKh1ra_JW38Q Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Richard Barnes' Yes on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 19:13:12 -0000 Richard Barnes has entered the following ballot position for draft-ietf-appsawg-nullmx-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems like it would be worth documenting the fact that this is likely to result in increased bogus traffic to the DNS root. Just because "." is technically not valid doesn't mean that some DNS libraries won't accept it. For example, `dig . A` will happily send a query. But the root is already used to dealing with noise, and in exchange for increasing that noise floor a little, we get to potentially reduce mail noise by a lot. So the trade-off is worth making, but it would be nice to document it. From nobody Wed Aug 6 12:41:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD771A0102; Wed, 6 Aug 2014 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svePNSwmB7G2; Wed, 6 Aug 2014 12:41:30 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683EC1A0101; Wed, 6 Aug 2014 12:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407354090; x=1438890090; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OfctPaUZ431SjuFPRwN3yHVzc4+4YKKqFZf4SF8bvlA=; b=kZeaAGMzlyuT7DX3IEJ2zKVkY56zXRBb89bUzvAkgRfItb+gBoixIYNw DGFEOQ79zZQNC9Y/ddZ7BUN/jh5Q6mrbp3Seh62lfqc3bkQ8EDbO1Ppps VJ4MlCV/2Bq7vVt0XhYx+Oah1ZPh3K5S3ox0r6fOp3VU8vJ2zPryhzdZJ c=; X-IronPort-AV: E=McAfee;i="5600,1067,7522"; a="72455279" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 06 Aug 2014 12:41:30 -0700 X-IronPort-AV: E=Sophos;i="5.01,813,1400050800"; d="scan'208,217";a="687122620" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Aug 2014 12:41:28 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Aug 2014 12:41:27 -0700 Message-ID: <53E284E5.4000304@qti.qualcomm.com> Date: Wed, 6 Aug 2014 14:41:25 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kathleen Moriarty References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030404030209020906010007" X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V9cs71xutlDeRkRcKFgRRNuzCec Cc: "apps-discuss@ietf.org" , "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 19:41:33 -0000 --------------030404030209020906010007 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/6/14 1:51 PM, Kathleen Moriarty wrote: > The part I am having a little trouble with is the server side since a > new capability to search multiple accounts is enabled through this draft. No, that's not true, or at least misstated: There is nothing you can search with this mechanism that you can't search by multiple SELECT/SEARCH pairs. > In Barry's response, I didn't think #1 was possible as I thought from > reading the draft that read access was required for the user to search > any subtree. Why would this allow searches outside of the user's > access rights? I must have missed something and would appreciate an > explanation of why this would be allowed. If the server supports the Access Control List (ACL) [RFC4314] extension, then the logged-in user is required to have the "r" right for each mailbox she wants to search. In addition, any mailboxes that are not explicitly named (accessed through "personal" or "subtree", for example) are required to have the "l" right. You could have "l" access to the parent and "r" access to the child. > Implementations/deployments could wind up with access permission > issues that enable access to an account in which a user should not > have access. I've seen this happen in other applications and it's not > pretty when one user can see another users data (or one company can > see data about another company). You could get into privacy concerns > very quickly since we are talking about email or at the service > provider level corporate data leakage. Being able to catch > configuration mistakes through log analysis can be very helpful > (seeing failed access attempts). The other issue could be where an > attacker tries to get access outside of their normal set of accounts, > exploiting this new feature and possible implementation or > provisioning flaws (again, failed access attempt logs are helpful). On this, I agree with Barry's point #2: This is an implementation detail and is not part of the protocol. I could implement logging by logging errors for SELECT, or ESEARCH, or any other IMAP command that impinges on ACLs. Or I could log all SELECTs and ESEARCHs (successful and unsuccessful) and that would give me a much better log analysis of when users have improper access to certain parts of the tree. I don't think this needs to be pointed out in this protocol document. > Alexey's explanation was helpful, could something along those lines be > added? I think 4314 already has a good discussion of this. Do you think something more is needed? > How about adding a recommendation for developers to implement logging > of failed access attempts and the implementer can decide whether or > not to enable it or to use it when debugging/testing to ensure access > is limited as expected? Again, I'm not convinced this belongs in a protocol document. I can see loads of interesting reasons to implement all different sorts of logging facilities, some for security, some for all sorts of other purposes. But that seems to me solely a local implementation issue, not an issue for the protocol. pr > On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba > wrote: > > What Alexey said. > > To add to that: > 1. Subtree searches and the like are quite likely to match > mailboxes that the user does not have access to, and logging such > things would not be useful. > > 2. In general, IMAP says nothing at all about logging. It defines > the protocol. Logging (along with what to log) is an > implementation choice. This document shouldn't be saying any more > about it than RFC 3501, or other IMAP specs. > > Barry > > > On Tuesday, August 5, 2014, Alexey Melnikov > wrote: > > Hi Kathleen, > > > On 5 Aug 2014, at 22:59, "Kathleen Moriarty" > wrote: > > > > The draft is well written and this should be easy to clear, > but I thought > > it was important to discuss to see if a change might be needed. > > > > In the security considerations section, the following > sentence says, > > "Mailboxes matching the source options for which the > logged-in user > > lacks sufficient rights MUST be ignored by the ESEARCH command > > processing (see the paragraph about this in Section 2.2). " > > > > It is good that access is not permitted, but shouldn't this > be logged as > > a possible access attempt violation? > > There was no intent to prevent logging, but the general > approach of access control to mailboxes in IMAP is "treat > mailboxes you don't have access to as non existent". So > logging all mailboxes that the user has no access too is not > necessarily productive and might generate lots of noise. > > The point of the sentence was to remind implementors that > access control permissions are still to be checked. > > Best Regards, > Alexey > > > > > > -- > > Best regards, > Kathleen -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------030404030209020906010007 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/6/14 1:51 PM, Kathleen Moriarty wrote:

The part I am having a little trouble with is the server side since a new capability to search multiple accounts is enabled through this draft.

No, that's not true, or at least misstated: There is nothing you can search with this mechanism that you can't search by multiple SELECT/SEARCH pairs.

In Barry's response, I didn't think #1 was possible as I thought from reading the draft that read access was required for the user to search any subtree.  Why would this allow searches outside of the user's access rights?  I must have missed something and would appreciate an explanation of why this would be allowed.

   If the server supports the Access Control List (ACL) [RFC4314]
   extension, then the logged-in user is required to have the "r" right
   for each mailbox she wants to search.  In addition, any mailboxes
   that are not explicitly named (accessed through "personal" or
   "subtree", for example) are required to have the "l" right.

You could have "l" access to the parent and "r" access to the child.

Implementations/deployments could wind up with access permission issues that enable access to an account in which a user should not have access.  I've seen this happen in other applications and it's not pretty when one user can see another users data (or one company can see data about another company).  You could get into privacy concerns very quickly since we are talking about email or at the service provider level corporate data leakage.  Being able to catch configuration mistakes through log analysis can be very helpful (seeing failed access attempts).  The other issue could be where an attacker tries to get access outside of their normal set of accounts, exploiting this new feature and possible implementation or provisioning flaws (again, failed access attempt logs are helpful).

On this, I agree with Barry's point #2: This is an implementation detail and is not part of the protocol. I could implement logging by logging errors for SELECT, or ESEARCH, or any other IMAP command that impinges on ACLs. Or I could log all SELECTs and ESEARCHs (successful and unsuccessful) and that would give me a much better log analysis of when users have improper access to certain parts of the tree. I don't think this needs to be pointed out in this protocol document.

Alexey's explanation was helpful, could something along those lines be added?

I think 4314 already has a good discussion of this. Do you think something more is needed?

How about adding a recommendation for developers to implement logging of failed access attempts and the implementer can decide whether or not to enable it or to use it when debugging/testing to ensure access is limited as expected?

Again, I'm not convinced this belongs in a protocol document. I can see loads of interesting reasons to implement all different sorts of logging facilities, some for security, some for all sorts of other purposes. But that seems to me solely a local implementation issue, not an issue for the protocol.

pr

On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba <barryleiba@computer.org> wrote:
What Alexey said.

To add to that:
1. Subtree searches and the like are quite likely to match mailboxes that the user does not have access to, and logging such things would not be useful.

2. In general, IMAP says nothing at all about logging.  It defines the protocol.  Logging (along with what to log) is an implementation choice.  This document shouldn't be saying any more about it than RFC 3501, or other IMAP specs.
Barry


On Tuesday, August 5, 2014, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi Kathleen,

> On 5 Aug 2014, at 22:59, "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> wrote:
>
> The draft is well written and this should be easy to clear, but I thought
> it was important to discuss to see if a change might be needed.
>
> In the security considerations section, the following sentence says,
> "Mailboxes matching the source options for which the logged-in user
>   lacks sufficient rights MUST be ignored by the ESEARCH command
>   processing (see the paragraph about this in Section 2.2). "
>
> It is good that access is not permitted, but shouldn't this be logged as
> a possible access attempt violation?

There was no intent to prevent logging, but the general approach of access control to mailboxes in IMAP is "treat mailboxes you don't have access to as non existent". So logging all mailboxes that the user has no access too is not necessarily productive and might generate lots of noise.

The point of the sentence was to remind implementors that access control permissions are still to be checked.

Best Regards,
Alexey





--

Best regards,
Kathleen

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------030404030209020906010007-- From nobody Wed Aug 6 12:53:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790A91B27FD; Wed, 6 Aug 2014 12:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Eu9--abafM; Wed, 6 Aug 2014 12:53:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C7E141B27FC; Wed, 6 Aug 2014 12:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C616DBE7D; Wed, 6 Aug 2014 20:53:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B_Kado2inJG; Wed, 6 Aug 2014 20:53:50 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.51.147]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98F4BBE83; Wed, 6 Aug 2014 20:53:50 +0100 (IST) Message-ID: <53E287CE.4040604@cs.tcd.ie> Date: Wed, 06 Aug 2014 20:53:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Barry Leiba References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mWaFhYVWTht3DvaDIdnHnGjJweE Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 19:53:54 -0000 On 06/08/14 17:29, Barry Leiba wrote: >> Just curious - do we know or are we guessing that >> this won't be an issue for DNSSEC (implementations)? >> I've no info either way, so its purely curiosity, >> really:-) > > I don't understand what might be an issue for DNSSEC > (implementations). What are you thinking? I've seen code break when assumptions that to-be-signed (sub)fields are non-zero length get changed. This'd be a possible case like that. I fully agree that its quite unlikely that much code would break like that and I assume overwhelmingly unlikely there's a protocol issue and I hope nobody goes to trouble checking it out. S. > > Barry > From nobody Wed Aug 6 13:34:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B31A016C; Wed, 6 Aug 2014 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFtpAUvuzxWb; Wed, 6 Aug 2014 13:34:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 405F71A0162; Wed, 6 Aug 2014 13:34:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806203427.1065.52814.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 13:34:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9FZBbjfc3tkw3XQ-O76bFvuIG8o Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:34:29 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question, at most a nit. In the Abstract This extension also uses MAILBOX and TAG fields in ESEARCH responses, ^^^^^^^ ^^^ allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. but in 1. Introduction o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a ^^^^^^^ ^^^^^^^^^^^ ^^^ client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466]. I'm only pattern matching, but should these lists of fields match? Or am I not understanding (which is likely)? From nobody Wed Aug 6 13:41:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD2B1A0162; Wed, 6 Aug 2014 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKtK_CCkzdSU; Wed, 6 Aug 2014 13:41:13 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672AF1A00FA; Wed, 6 Aug 2014 13:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407357674; x=1438893674; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wQriHUcnhzSRnnBE8D3SC2JQC9KdpowOsCeV6HQQcEM=; b=w2QkhwqcNlSejCX6yp0ZH4LPqQUfa8w9BNUgWVRmMC7mKc8OLJCI5NAO FRmN7x/oBvTODRo0hZ0mhnPDX0Do5tvPCLdEb+QDc18Y/GGDA1KySXyIU bLnhWvrhsal9zWLUitZ/TQ5FpnWTERtLTekSG17mrZ9W5Z0Z7vcSYQ6JX I=; X-IronPort-AV: E=McAfee;i="5600,1067,7522"; a="72457960" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 06 Aug 2014 13:41:13 -0700 X-IronPort-AV: E=Sophos;i="5.01,813,1400050800"; d="scan'208";a="31023475" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Aug 2014 13:41:12 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Aug 2014 13:41:11 -0700 Message-ID: <53E292E5.1070706@qti.qualcomm.com> Date: Wed, 6 Aug 2014 15:41:09 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kathleen Moriarty References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> <53E284E5.4000304@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OeyoW7JE2Il3l-RsVelFnLNLMsQ Cc: "apps-discuss@ietf.org" , "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 20:41:15 -0000 On 8/6/14 3:01 PM, Kathleen Moriarty wrote: > OK, I'll remove the discuss and appreciate the discussion/explanation. Thanks Kathleen. If you do find something that is not clear from 4314 that we need to say in here, we can always take a look back before final publication. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Aug 6 13:53:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90571A01C6; Wed, 6 Aug 2014 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfgjjXUrcCy2; Wed, 6 Aug 2014 13:53:17 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F021A0271; Wed, 6 Aug 2014 13:53:17 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so3496000igb.17 for ; Wed, 06 Aug 2014 13:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1kNittV+058RJlJR2m+mDZG8TFsrGM1KU4T8O3UkSWQ=; b=U+DvbcsLOtNwKUORHvtH2xr8USGe83MTHKVck+nHvDVyQO3Hai68epdLUdEfO6sLZ2 LBTOWeaWH5NaYOZTZRh/4gcdO0qJliu+JoIpNwAQR4csMgR+zim83zxGOEoJ49oCgS7R AddyFVxan8uv1Xry7OgZco2zrzQQoEw25VEMSAfWLPL9wdXTX7gE/JfCDqLTYjXlTq1X AlbUyOs95ruuIpUFwXo5WYoeVjpDnSJ3OPumsxwCU7c0xRJrxS0Gxm8zY+O23i4mPdQb /4RXTlqu5t6Tg7dAnCTbs7A8wgaC0SeDLI/P6u+w1tloNQBPH03fKCEIwFe138bJ/TX8 LW6Q== X-Received: by 10.43.154.145 with SMTP id le17mr18843426icc.20.1407358396981; Wed, 06 Aug 2014 13:53:16 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id vl4sm11815713igb.3.2014.08.06.13.53.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 13:53:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <53E287CE.4040604@cs.tcd.ie> Date: Wed, 6 Aug 2014 13:53:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DDABB6C-5C58-42F4-A2FC-53F5175C727B@gmail.com> References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> <53E287CE.4040604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0W8WW52QjU1mhznV3eyfdbX1Bow Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, Apps Discuss , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 20:53:20 -0000 On Aug 6, 2014, at 12:53 PM, Stephen Farrell = wrote: > On 06/08/14 17:29, Barry Leiba wrote: >>> Just curious - do we know or are we guessing that >>> this won't be an issue for DNSSEC (implementations)? >>> I've no info either way, so its purely curiosity, >>> really:-) >>=20 >> I don't understand what might be an issue for DNSSEC >> (implementations). What are you thinking? >=20 > I've seen code break when assumptions that to-be-signed > (sub)fields are non-zero length get changed. This'd be a > possible case like that. >=20 > I fully agree that its quite unlikely that much code > would break like that and I assume overwhelmingly unlikely > there's a protocol issue and I hope nobody goes to trouble > checking it out. Dear Stephen, John Klensin has already noted the possible confusion caused by the = resource name. The value is not null, but rather represents a pointer = to root "." John Levine argued changing its name after many years of = unofficial references would be counter productive. Regards, Douglas Otis From nobody Wed Aug 6 14:33:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6541A02D0; Wed, 6 Aug 2014 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgbV0wnN7rkR; Wed, 6 Aug 2014 14:32:54 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEF41A0242; Wed, 6 Aug 2014 14:32:54 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so2035471lbd.36 for ; Wed, 06 Aug 2014 14:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HHwO40iIPhGl1LdnynudEZ5o647nA0iVnYxSjNZKvqg=; b=kSlZyj6jODVxo+qrNQG0r47kzn60EupqDeje3SBVwhzJQ2aBoKqqDNRy/hPMgO2pdq e0MHCmXRKu5/6pu86XlxzVOYn2NX0jIDvl7iGGRfoApRAZJJn1OPMGy3gidpGp01yKcz jWcRldD9cG7KRO92c9smi2ZAPnZksd+iR+rLamugsvw2CCmCXZZHzm6cdQ1G63pigx6Q CmMxGHeaxFLMQ7PViYe8P2wIk/uwzIKPyA1HDH9PUE7MaQUdRAS7P9URIC1Wt7Fv3Ut0 Z3uMP2kMd+tSRQ9vBGCgTC4db/YMs4ZKMzQE2L5hYmlBATT+DCopXnCCdKNMQgaFOP// ynLA== MIME-Version: 1.0 X-Received: by 10.152.3.199 with SMTP id e7mr13353844lae.35.1407360772564; Wed, 06 Aug 2014 14:32:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Wed, 6 Aug 2014 14:32:52 -0700 (PDT) In-Reply-To: <20140806203427.1065.52814.idtracker@ietfa.amsl.com> References: <20140806203427.1065.52814.idtracker@ietfa.amsl.com> Date: Wed, 6 Aug 2014 17:32:52 -0400 X-Google-Sender-Auth: VXMAnGXp8hRSTykR1g7sE4TDfdY Message-ID: From: Barry Leiba To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7iZ46TvWYF8nfyQpHK0zrlmox64 Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 21:32:55 -0000 > This > extension also uses MAILBOX and TAG fields in ESEARCH responses, > ^^^^^^^ ^^^ > allowing a client to pipeline the searches if it chooses. This > document updates RFC 4466 and obsoletes RFC 6237. > > but in 1. Introduction > > o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a > ^^^^^^^ ^^^^^^^^^^^ ^^^ > client to distinguish which responses go with which search (and > which mailbox). A client can safely pipeline these search > commands without danger of confusion. The addition of the MAILBOX > and UIDVALIDITY fields updates the search-correlator item defined > in [RFC4466]. > > I'm only pattern matching, but should these lists of fields match? I think it really doesn't matter. But there's no harm, and some consistency, in having "UIDVALIDITY" in the abstract as well, so I'll add it. Barry From nobody Wed Aug 6 14:33:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48431B287F; Wed, 6 Aug 2014 14:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NviWB5RMiMIO; Wed, 6 Aug 2014 14:33:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 369141A031F; Wed, 6 Aug 2014 14:33:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 931F6BE9C; Wed, 6 Aug 2014 22:33:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auYwLQfYUmSQ; Wed, 6 Aug 2014 22:33:44 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.51.147]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5EA52BE98; Wed, 6 Aug 2014 22:33:44 +0100 (IST) Message-ID: <53E29F37.8080309@cs.tcd.ie> Date: Wed, 06 Aug 2014 22:33:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Douglas Otis References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> <53E287CE.4040604@cs.tcd.ie> <5DDABB6C-5C58-42F4-A2FC-53F5175C727B@gmail.com> In-Reply-To: <5DDABB6C-5C58-42F4-A2FC-53F5175C727B@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4ADlPuP6ZEYhKPIJc1N7SeyZeXU Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , Barry Leiba , The IESG , Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 21:33:48 -0000 Doug, On 06/08/14 21:53, Douglas Otis wrote: > > On Aug 6, 2014, at 12:53 PM, Stephen Farrell > wrote: >> On 06/08/14 17:29, Barry Leiba wrote: >>>> Just curious - do we know or are we guessing that this won't be >>>> an issue for DNSSEC (implementations)? I've no info either way, >>>> so its purely curiosity, really:-) >>> >>> I don't understand what might be an issue for DNSSEC >>> (implementations). What are you thinking? >> >> I've seen code break when assumptions that to-be-signed (sub)fields >> are non-zero length get changed. This'd be a possible case like >> that. >> >> I fully agree that its quite unlikely that much code would break >> like that and I assume overwhelmingly unlikely there's a protocol >> issue and I hope nobody goes to trouble checking it out. > > Dear Stephen, > > John Klensin has already noted the possible confusion caused by the > resource name. The value is not null, but rather represents a > pointer to root "." John Levine argued changing its name after many > years of unofficial references would be counter productive. Mine is a different non-issue. I'm fine with the name. S. > > Regards, Douglas Otis > > > > > From nobody Wed Aug 6 14:50:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F531B289C; Wed, 6 Aug 2014 14:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wMxOBVydbtD; Wed, 6 Aug 2014 14:50:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7331A02A0; Wed, 6 Aug 2014 14:50:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 14:50:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MS7bJ4xoSi0OAlo3nl-8lVgpPIg Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 21:50:38 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-email-auth-codes-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Since only one code is returned and since the client has to assume that other failures may have happened in parallel, and since the X.7.20 code covers two different things (i.e. (a) and (b) from 3.1), did the wg consider splitting out 3.1's (a) and (b) into different codes? That way the 3.1.a code would conform to 6376 and the 3.1.b code would be "failed my local DKIM specifics." Seems to me that splitting those out might be better but I'm fine if this was considered and rejected (i.e. no need to re-do the reason for rejecting, just tell me it happened and that'll be fine). - The intro could make the X.7.nn notation clearer, but it becomes blatently obvious if one reads 5248 so its ok unless you want to be extra-nice to the reader. From nobody Wed Aug 6 16:55:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75F91A0358; Wed, 6 Aug 2014 16:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnt9hMeudhfs; Wed, 6 Aug 2014 16:55:11 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86BF1A0350; Wed, 6 Aug 2014 16:55:08 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so4076327wib.2 for ; Wed, 06 Aug 2014 16:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r4jqdGcHt9oPvbns+yKT5+XRHNh0M840eBrI3pInat8=; b=i5Jw9IV5Qr8ZTFRzF78oJccL953GHU5kd848DMa8+Mj6Px6RfIbZSzeuLJp45xCMpt ElHyIwI28ix3QqT9XgITHO2YLU3Wo4mxd/ajGtHPK9Bzifczm29s0JDJmsW4IXQe7k67 J4q78YA10vcpeR/rVgFP8BK1By2RxOm2b+GBOCGZlINIhSDeukEEmt8QeiY4DzP95UND gdRjllc/MZMQf5WHcYea4TgzVlIkJGWLH8EKVg9eCIsc/LHRvO5HEKN2N+tdo4oYtb03 5lPOjRlTznDCd1Sq/j/f4Cdp5xfAFytx7wyFVJNWZxWs9U/SjDEGIDSGWTrn412Filjb zTvQ== MIME-Version: 1.0 X-Received: by 10.180.81.234 with SMTP id d10mr20138034wiy.79.1407369306939; Wed, 06 Aug 2014 16:55:06 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Wed, 6 Aug 2014 16:55:06 -0700 (PDT) In-Reply-To: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> Date: Wed, 6 Aug 2014 16:55:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d044281349ba95004fffeb3e7 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fGvEDMdbHkum0L-MVjV8OJvVS2E Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 23:55:13 -0000 --f46d044281349ba95004fffeb3e7 Content-Type: text/plain; charset=UTF-8 Hi Stephen, On Wed, Aug 6, 2014 at 2:50 PM, Stephen Farrell wrote: > - Since only one code is returned and since the client has to > assume that other failures may have happened in parallel, and > since the X.7.20 code covers two different things (i.e. (a) and > (b) from 3.1), did the wg consider splitting out 3.1's (a) and > (b) into different codes? That way the 3.1.a code would > conform to 6376 and the 3.1.b code would be "failed my local > DKIM specifics." Seems to me that splitting those out might be > better but I'm fine if this was considered and rejected (i.e. > no need to re-do the reason for rejecting, just tell me it > happened and that'll be fine). > There haven't to my knowledge been any instances of wanting or needing to report 3.1.a separately from 3.1.b, which is why they're rolled into the same status code. To date the only distinction of interest is between what's covered by x.7.20 and x.7.21, namely the domain name alignment. In that sense all we're documenting here is a set of codes that match what the industry has been doing since DKIM started achieving serious deployment. -MSK --f46d044281349ba95004fffeb3e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Wed, Aug 6, 2014 at 2:50 PM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:
- Since only one = code is returned and since the client has to
assume that other failures may have happened in parallel, and
since the X.7.20 code covers two different things (i.e. (a) and
(b) from 3.1), did the wg consider splitting out 3.1's (a) and
(b) into different codes? =C2=A0That way the 3.1.a code would
conform to 6376 and the 3.1.b code would be "failed my local
DKIM specifics." Seems to me that splitting those out might be
better but I'm fine if this was considered and rejected (i.e.
no need to re-do the reason for rejecting, just tell me it
happened and that'll be fine).

Ther= e haven't to my knowledge been any instances of wanting or needing to r= eport 3.1.a separately from 3.1.b, which is why they're rolled into the= same status code.=C2=A0 To date the only distinction of interest is betwee= n what's covered by x.7.20 and x.7.21, namely the domain name alignment= .=C2=A0 In that sense all we're documenting here is a set of codes that= match what the industry has been doing since DKIM started achieving seriou= s deployment.

-MSK

=C2=A0
--f46d044281349ba95004fffeb3e7-- From nobody Wed Aug 6 17:13:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4B11A02E0; Wed, 6 Aug 2014 17:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9xFqU5xKBH1; Wed, 6 Aug 2014 17:13:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C3F921A02D2; Wed, 6 Aug 2014 17:13:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EB40BE08; Thu, 7 Aug 2014 01:13:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTmXTrVJrRpP; Thu, 7 Aug 2014 01:12:59 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.51.147]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7B16BE07; Thu, 7 Aug 2014 01:12:59 +0100 (IST) Message-ID: <53E2C48A.6060804@cs.tcd.ie> Date: Thu, 07 Aug 2014 01:12:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VBAoShbmwJGuseXxoJ2MCnQpFD0 Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 00:13:03 -0000 On 07/08/14 00:55, Murray S. Kucherawy wrote: > Hi Stephen, > > On Wed, Aug 6, 2014 at 2:50 PM, Stephen Farrell > wrote: > >> - Since only one code is returned and since the client has to >> assume that other failures may have happened in parallel, and >> since the X.7.20 code covers two different things (i.e. (a) and >> (b) from 3.1), did the wg consider splitting out 3.1's (a) and >> (b) into different codes? That way the 3.1.a code would >> conform to 6376 and the 3.1.b code would be "failed my local >> DKIM specifics." Seems to me that splitting those out might be >> better but I'm fine if this was considered and rejected (i.e. >> no need to re-do the reason for rejecting, just tell me it >> happened and that'll be fine). >> > > There haven't to my knowledge been any instances of wanting or needing to > report 3.1.a separately from 3.1.b, which is why they're rolled into the > same status code. To date the only distinction of interest is between > what's covered by x.7.20 and x.7.21, namely the domain name alignment. In > that sense all we're documenting here is a set of codes that match what the > industry has been doing since DKIM started achieving serious deployment. Sure, I get that. If separating 3.1.a and 3.1.b doesn't resonate with folks, that's fine, we should just move on. However, if it did, then that'd I think get rid of some of the odd language about the DKIM spec. But its a minor point, not worth more mail unless people want to take that route. Cheers, S. > > -MSK > From nobody Wed Aug 6 17:19:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06F1A0340; Wed, 6 Aug 2014 17:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oG6OTiw07cT; Wed, 6 Aug 2014 17:19:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 779CD1B2890; Wed, 6 Aug 2014 17:19:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s770JPUZ028307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 17:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407370779; x=1407457179; bh=YhSQhPJKJjqD4AR5/UuGr1FzCpXN3vj1heQSI3L+kQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BbYPrccQgc2Fgj8zLJyxrX5vdfPGKouYHUco1jAYrIizo/rtnrsbwYebCfjZq+QOJ O0Uo4HdB9FBmHvLuAAK7pUXMfbN7/Fod7I73O1+aKRWH5hAbBNAZjovFzsLtpolXq8 P2r0L2iRLirm5mi8T/ujpE7n3WJr4ZKjSGiFp6jY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407370779; x=1407457179; i=@elandsys.com; bh=YhSQhPJKJjqD4AR5/UuGr1FzCpXN3vj1heQSI3L+kQM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ePTRRhVA47m0ZHv0g3/NFmzuY+SO3FvkRAH24ZTqaoVStatUt04Wg09asYcKAy6hk g0xhuEEUVYGSzqHV25dWUyxy1HebXRVXUdVsKKo9muBl4SyjcuztbwGnFet2fGo+bu 4bQPexCJ6rdML1xdmMNcEfmt1HDTuiroEM7iwjNo= Message-Id: <6.2.5.6.2.20140806170614.0c70d8b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Aug 2014 17:18:53 -0700 To: "Stephen Farrell" , iesg@ietf.org From: S Moonesamy In-Reply-To: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aGh0lROv1cX7gn2r30deQA5NMWU Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 00:19:48 -0000 Hi Stephen, At 14:50 06-08-2014, Stephen Farrell wrote: >COMMENT: >---------------------------------------------------------------------- > > >- Since only one code is returned and since the client has to >assume that other failures may have happened in parallel, and >since the X.7.20 code covers two different things (i.e. (a) and >(b) from 3.1), did the wg consider splitting out 3.1's (a) and >(b) into different codes? That way the 3.1.a code would >conform to 6376 and the 3.1.b code would be "failed my local >DKIM specifics." Seems to me that splitting those out might be >better but I'm fine if this was considered and rejected (i.e. >no need to re-do the reason for rejecting, just tell me it >happened and that'll be fine). There was a DISCUSS from Pete ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12731.html ). Murray suggested some text for Section 3.1, i.e. the (a) and the (b) ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12732.html ). The question of whether 3.1 (a) and (b) should be split into two different codes did not arise during the working group discussions. Regards, S. Moonesamy (as document shepherd) From nobody Wed Aug 6 17:52:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5E81A02D6 for ; Wed, 6 Aug 2014 17:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sz9Vgymm0FD for ; Wed, 6 Aug 2014 17:52:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E6C1A0298 for ; Wed, 6 Aug 2014 17:52:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s770pnQi015007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 17:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407372721; x=1407459121; bh=iktiqX2i0qlnkPCToU6YDIOtuR7KiwvBjVxMKXXshKA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NArTSJoGz4X0PK5PNkmzei/9N+m1iFICUcTFiQpI4L3AbQQIxhRUGmxUjJaup3o4b Rulf54QeP8wPPE/Ggl+N94vFdLZpxv2oNCJgv6LhxDDBJBsCty0Ge0U6R91O0Srtul bCRYMHgcTc30JaZtizIn2txcIpfT1LaK2uuGQL2g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407372721; x=1407459121; i=@elandsys.com; bh=iktiqX2i0qlnkPCToU6YDIOtuR7KiwvBjVxMKXXshKA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T8zk5U8cNTEC7z+lCEQmuLoipUTq+LHBByltYVyooVTbnXPCpSvvpMb3L8zF75ODc Nb/+hMz7tBZy9GDAYrBLBCwgRp+Rsga7Ydj1gMuSbBeqwzeNoJsV005veQ06ku5H4p iak8znvOCxj2TSUiglFV6bBsfpbcjnTRm2OOrZUI= Message-Id: <6.2.5.6.2.20140806172920.0c82ada8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Aug 2014 17:51:08 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <20140805013510.3778.62099.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o2JQFOb_XmyGKXqvmBw5UsUtGMw Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-email-auth-codes-05: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 00:52:12 -0000 Hi Murray, At 19:54 04-08-2014, Murray S. Kucherawy wrote: >x.7.20 is for the situation where the message contained no valid >signature at all. In terms of RFC 7001, it could be used for "none" >(the message wasn't signed), "fail" (there was a valid signature but >it failed to verify), "policy" (there was a valid signature but, for >example, it didn't cover some header field the verifier requires to >be covered per local policy; for example, there's at least one >verifier implementation that considers Subject mandatory), "neutral" >(there was a signature, but it was syntactically invalid), or >"permerror" (there was a signature, but the public key to which it >referred was malformed, or it didn't cover the From field as >required by RFC 6376). This is an individual comment. I read Section 3.1 of draft-ietf-appsawg-email-auth-codes-06 again and I found it a little confusing. The sample text says: "No valid DKIM signature found". This is where I read Section 6.1 of RFC 6376 to find out what is valid. Note that there is only one DKIM verification algorithm. The change between -05 and -06 is the emphasis on the term "acceptable" and introduces "basic DKIM verification algorithm". The definitions (a) and (b) defines "acceptable" and the code says "anything that is not that". My quick suggestion would be to change "valid" to "acceptable" in the "Sample Text" and avoid introducing "basic algorithm" in (a) and (b). Regards, S. Moonesamy From nobody Wed Aug 6 18:12:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02B01A031B for ; Wed, 6 Aug 2014 18:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUGJVvYsGWj7 for ; Wed, 6 Aug 2014 18:12:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9FB1A029D for ; Wed, 6 Aug 2014 18:12:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB2IFHE0FK000ILB@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 6 Aug 2014 18:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407373657; bh=fJq4BiHS+QUwJRSPlMgScN+a3pRgZnIjfgNpfTNs2FE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=PtpVA+WN8nOELWw2qI/gbjfyZy5g+hJp0/NtjIjMfcy3BzvosE8L1iB9ppCDthApR N9mSxEAF56QPLAhm3U2eYYrJDX+OCE1Fggm9DOQI6uOav/Tq4gLa9PL4EZoz305aVW ev7qBcTHQX8FIQ03lPuLsGCw69Aynx7mulnhwkbk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB1WDAOHGG0000SM@mauve.mrochek.com>; Wed, 06 Aug 2014 18:07:24 -0700 (PDT) Message-id: <01PB2IFF93FA0000SM@mauve.mrochek.com> Date: Wed, 06 Aug 2014 11:31:53 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 06 Aug 2014 15:05:05 +0100" <011c01cfb180$e0949d80$4001a8c0@gateway.2wire.net> References: <20140718160344.52645.qmail@joyce.lan> <53DCEB4E.3040304@dcrocker.net> <01PAY7SXC9G80000XX@mauve.mrochek.com> <0E33C5441DF523932AC8C978@JcK-HP8200.jck.com> <53DFABE6.8070004@dcrocker.net> <01PAZBX664E20000SM@mauve.mrochek.com> <011c01cfb180$e0949d80$4001a8c0@gateway.2wire.net> To: "t.petch" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8gCUnl0sMcGnlqRJqyXoR5M8U8A Cc: Barry Leiba , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Request to reclassify RFC 1846 to standard track X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 01:12:31 -0000 > ----- Original Message ----- > From: "Barry Leiba" > To: > Cc: "Ned Freed" > Sent: Monday, August 04, 2014 8:29 PM > > Ned says... > > > FWIW, I didn't even notice that RFC 1846 was experimental. > > > I agree with John's assessment that this has been PS or better for > years. > > > > Excellent. So, let me ask it this way: > > > > Does anyone object to: > > > > 1. Moving RFC 1846 from Experimental to Proposed Standard? > > > > 2. Moving RFC 1846 to Internet Standard (see RFC 6410, Section 2.2)? > > > > If you do, please say why. > Barry > A reservation. Internet Standard requires that all the described > features have been implemented and while '521' is clearly implemented in > plenty of places, are there two implementations of each and every > feature (which is what I have seen called out in other such proposals?) > I would parse RFC1846 into about five separate features, and it is not > clear to me that the implementations all do everything (well, they > don't, but I am uncertain which they do do:-( > Or is RFC6410 > (3) There are no unused features in the specification that greatly > increase implementation complexity. > woolly enough for us to say that there is nothing of complexity > involved? Rather than speculate, why not take a look at the RFC? It's only 4 pages, not counting the boilerplate, less than 3. There are two parts to this, the client part and the server part. Server first. Writing a stub server that writes a line to a connection and then closes the connection is not what we call rocket science. We shipped one of these for years; I think it was around 20 lines of code. The alternate "read a line, and if it's not QUIT send a line, if it is QUIT send a different line and close the conenction" is only slightly more difficult. I really hope there's consensus that the state of network programming is sufficiently advanced that we don't have to check and evaluate stub server implementations. If so, that's enough about that. The rest of this deals with actual SMTP servers and clients. The other server option is to have an MX that points to a regular SMTP server that returns a 521, as oppose to some other error, when a sees an address using a "does not accept mail" domain. Of course every standards compliant SMTP server in existence is capable of returning a 5YX error in response to an invalid address. RFC 5321 requires it, among other things. As for the client, all you have to do is handle 5YZ errors properly by bouncing the message. The only even marginally "new" part of this is the possibility of a 5YZ response to the server greeting, which isn't explicitly called out in RFC 5321 or its predecessors. But any implementor with half a brain will have figured out this is a possibility even if they never saw this RFC. Indeed, in most implementations this handling is going to fall out of the generic handler for SMTP responses. It certainly did so in ours. There is one optional bit of business the client can do, which is in the event of misconfiguration where an MX points to a server that returns 521, it may make more sense to try other MXes than fail the message immediately. Our server does this, and again, this is trivial because the existing logic for 4YZ greetings has to do the same thing. Now, I suppose if you really want to be formal, and assuming you're dealing with SMTP clients and servers that comply with RFC 5321, the checklist for this document consists of exactly one item: (1) Do you handle 5YZ greeting responses either by trying the next MX if there is one or by bouncing the message as undeliverable? And since we've already had at least two implementors say their implementations support this, I think we're done. Ned From nobody Wed Aug 6 18:33:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112141A03D0; Wed, 6 Aug 2014 18:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIuo8rcPh_Cc; Wed, 6 Aug 2014 18:33:49 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 48C781A03B7; Wed, 6 Aug 2014 18:33:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9BE252CC48; Thu, 7 Aug 2014 04:33:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgel9hRD9Yfz; Thu, 7 Aug 2014 04:33:40 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id DAF6E2CC64; Thu, 7 Aug 2014 04:33:34 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_3EE50A43-BE4D-41F2-8DA2-A778062EED8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077860DD21@MX15A.corp.emc.com> Date: Thu, 7 Aug 2014 13:32:10 +1200 Message-Id: <4E175BF1-E335-4737-B5C4-EECC6556AC43@piuha.net> References: <8D3D17ACE214DC429325B2B98F3AE712077860DD21@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/W7aBeXalIIhTEf1BTH9ouYIRJsk Cc: "mx0dot@yahoo.com" , "standards@taugh.com" , "ops-dir@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 01:33:51 -0000 --Apple-Mail=_3EE50A43-BE4D-41F2-8DA2-A778062EED8C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Thank you very much for your reviews of this document, David. Jari --Apple-Mail=_3EE50A43-BE4D-41F2-8DA2-A778062EED8C 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT4tcbAAoJEM80gCTQU46qpNwQALPEo/loL4zJ7MyofTcaOd5o 2eydbNG6JkVHPQ0+XlZ4Gml6htd3wN/hfI5Ox2oxHQndNDsBKAfa6mzqE3B3R6KG LjZ+iYYqgjPqVOrALIQwNgWGH5fkhwL3vJBNeMYQPEHKvEFQP2LVeE9BFHgCbBqM ioAOkKmfMdJrZ8NlWzKB+xS2iQChArmPdmNqAkgWV6nXbuwzM9VUo32v9/+y3Oz9 2sApROJWjL+DA7sHJMdF2qDeawcE3n0a8dSK/YeW6SAbquNwITOCflkFhJ7yx9df 5xvQZFMjzD4NdgL3m09Xmu2i05TN8xovHJArIBTK41QNo+TMQKfvfHUoQsFLXX3O GGfHi4ArzBV1wkPg3u66h8VmOjt8F8VaRX9M1bfXKbX5HdIsDplkJ7IbOQPjCzU3 7UbAayOM6cxq10MOzazW2vOOQRSz7qNXo+4Lbt+6+pMX6Xpn6mxjmhgujARBbX/Q LWPutNSIun2p7KCujI35Hml0XpU/2OP+I8gpOdcccqyOWdvF4a7JotpjDHfywdzK kKUSXV9HV/i8uR7J8bZrjaoQPCPiB7YQl6WJVbSo9sPeS6odQG9cjGBvwRRbk/kx TKvpwU11Nz3+fp2k6WrHGcT8UnPG3wDzJ5jQyc+rtE8sl6sOPMWc5fdsZyTmQRah UBBOW8D4eX6qo4UNMMin =l9Wg -----END PGP SIGNATURE----- --Apple-Mail=_3EE50A43-BE4D-41F2-8DA2-A778062EED8C-- From nobody Wed Aug 6 19:24:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0118E1A0880; Wed, 6 Aug 2014 19:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXOlzCrxNKH4; Wed, 6 Aug 2014 19:24:44 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3ED71A0643; Wed, 6 Aug 2014 19:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407378283; x=1438914283; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LSPcmh/i//lkyaHjWRhjCf+0EE6DrZxwDNuft2VTADY=; b=xFimw/bhv2LQASbQqd4FkkwkFJyTxOGq6ZrWYatQMmGR/WvOf9S9T1Ci jSkk6Tt9Jp4clJhRuaiA6jBu2J+c9Wm80YFsnaDNO23eLlwNaEln/OgB6 5GSMBM7yoXZZ5NyUjyOv5tS4laNMUp1z5SmlIs4VgVP54v8bua1oByVKC k=; X-IronPort-AV: E=McAfee;i="5600,1067,7522"; a="72472969" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 06 Aug 2014 19:24:43 -0700 X-IronPort-AV: E=Sophos;i="5.01,815,1400050800"; d="scan'208";a="687305615" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Aug 2014 19:24:42 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 6 Aug 2014 19:24:42 -0700 Message-ID: <53E2E367.2060703@qti.qualcomm.com> Date: Wed, 6 Aug 2014 21:24:39 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140806170614.0c70d8b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20140806170614.0c70d8b0@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/biL8NFVelXOn7SYWlOxltA24gUc Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 02:24:47 -0000 On 8/6/14 7:18 PM, S Moonesamy wrote: > Hi Stephen, > At 14:50 06-08-2014, Stephen Farrell wrote: >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - Since only one code is returned and since the client has to >> assume that other failures may have happened in parallel, and >> since the X.7.20 code covers two different things (i.e. (a) and >> (b) from 3.1), did the wg consider splitting out 3.1's (a) and >> (b) into different codes? That way the 3.1.a code would >> conform to 6376 and the 3.1.b code would be "failed my local >> DKIM specifics." Seems to me that splitting those out might be >> better but I'm fine if this was considered and rejected (i.e. >> no need to re-do the reason for rejecting, just tell me it >> happened and that'll be fine). > > There was a DISCUSS from Pete ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12731.html ). > Murray suggested some text for Section 3.1, i.e. the (a) and the (b) ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12732.html ). > > > The question of whether 3.1 (a) and (b) should be split into two > different codes did not arise during the working group discussions. And to be clear, my DISCUSS was because I thought the text was not clear that 3.1.a and 3.1.b were being combined in X.7.20. Now the text is clear that they are, which is why I moved off of my DISCUSS, but that's not to say that I think it's good that they're combined. Murray has argued that there has been no need to split them and therefore there is no likely future need to do so either. The WG should probably decide if that's true, because once you put X.7.20 in to mean the combination of 3.1.a and 3.1.b, there's no going back; if you decide later that they ought to be split, you'll be deprecating X.7.20 and making two new codes. I'd rather see them split now, but it's not a showstopper, and if the WG considers it and decides it's not necessary, like Stephen I will be fine with it. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Aug 6 20:26:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A6D1A0A86 for ; Wed, 6 Aug 2014 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw-w85lltQC8 for ; Wed, 6 Aug 2014 20:26:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7E1A08F8 for ; Wed, 6 Aug 2014 20:26:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.128.135]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s773Q1Rn019182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2014 20:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407381976; x=1407468376; bh=iDkD0us7EqEn5DAdtchn4A49bmMksYeLXjPrnCf7ga0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lo79pELlb7+Si6ylNWFVS1TztuT5SHfbrKd6Tqb69hKpmug75V1IrkFgQtlzD3Xub UcOATWkXmKeBxw6kklkDmFSc4lNeOhGYfV7ukHxLgYqgF3AiOPJyHFeljfNFVYv+rR HMAqy3ZqifPbUvthpUTjI4qirMt7xCzu0RTV57XI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407381976; x=1407468376; i=@elandsys.com; bh=iDkD0us7EqEn5DAdtchn4A49bmMksYeLXjPrnCf7ga0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kmqy4U8mv7EeLIdavgcMW39q8h2YkxMOQRmNbU+cN9sUWC5iVvk3PjvRB4rIsRcX2 J4h1ucbuEBJFja6waejVhCCkEpA4bz+5TkVuxHvvLV+Y9464GMZsKoI9yz7qTh5kbd olj1D8WuWAjbHXL30Z/zVT4pPoPXb5ft7XgVfXkM= Message-Id: <6.2.5.6.2.20140806195819.0c3e2f40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Aug 2014 20:14:28 -0700 To: Pete Resnick , apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <53E2E367.2060703@qti.qualcomm.com> References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140806170614.0c70d8b0@elandnews.com> <53E2E367.2060703@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AzMIvIAXKOEAnYtQcZXmtGpTckI Cc: appsawg-chairs@tools.ietf.org, Barry Leiba , draft-ietf-appsawg-email-auth-codes@tools.ietf.org Subject: [apps-discuss] Section 3.1 of draft-ietf-appsawg-email-auth-codes-06 (was: Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 03:26:29 -0000 Hi Pete, [removed iesg@ from the working group discussion] At 19:24 06-08-2014, Pete Resnick wrote: >And to be clear, my DISCUSS was because I thought the text was not >clear that 3.1.a and 3.1.b were being combined in X.7.20. Now the >text is clear that they are, which is why I moved off of my DISCUSS, >but that's not to say that I think it's good that they're combined. >Murray has argued that there has been no need to split them and >therefore there is no likely future need to do so either. The WG >should probably decide if that's true, because once you put X.7.20 >in to mean the combination of 3.1.a and 3.1.b, there's no going >back; if you decide later that they ought to be split, you'll be >deprecating X.7.20 and making two new codes. I'd rather see them >split now, but it's not a showstopper, and if the WG considers it >and decides it's not necessary, like Stephen I will be fine with it. I suggest that the working group considers the above points. I'll wait for comments until end of Friday (this week). Regards, S. Moonesamy (as document shepherd) From nobody Wed Aug 6 22:05:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FA1A0ABD; Wed, 6 Aug 2014 22:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f91Qt_H5shxK; Wed, 6 Aug 2014 22:05:10 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA811A0ABB; Wed, 6 Aug 2014 22:05:09 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9927558wiv.13 for ; Wed, 06 Aug 2014 22:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LR74knei+vywwflNWp63ZOYjXEDCkKm7Q0RlK3b5KXs=; b=HKeND36LfzcjBaoG/GkEawJxVmqmKXMA8DGcUPBpy5Qj15aDtcyimZMF+zwzfrI1aa brPJERGwCI6YYSDYV3FFPyoS+txrr7WFBRTNhk7rinMMShfhIh1UTi/sGCNu42lziV2+ Fox3FtiN3OdO6kFEDthS2S1gCVZm6g+738vgxqPtXTmnu9Zkx4RhEtWf4yjykUYrKWG6 AEYVX8tdPYBTdBSh0X1UXkoHpLmLbkZ7Kc/nBdzaJwcB+7dFiAs5rkWoq6vbZbtsWWkk 5qIP5ytd99bs74RyZzglkL9RoIez1FsBd4exSS6cEi/MabEg5uMwTG5+ArgW8IAtL3Nx 3/fA== MIME-Version: 1.0 X-Received: by 10.194.62.67 with SMTP id w3mr21174034wjr.32.1407387907827; Wed, 06 Aug 2014 22:05:07 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Wed, 6 Aug 2014 22:05:07 -0700 (PDT) In-Reply-To: <53E2E367.2060703@qti.qualcomm.com> References: <20140806215037.13299.94321.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140806170614.0c70d8b0@elandnews.com> <53E2E367.2060703@qti.qualcomm.com> Date: Wed, 6 Aug 2014 22:05:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b872e9a4eae520500030836 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qHJBXCFy5KIVopXkJd1aowZry1Y Cc: IETF Apps Discuss , "draft-ietf-appsawg-email-auth-codes@tools.ietf.org" , S Moonesamy , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 05:05:13 -0000 --047d7b872e9a4eae520500030836 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 6, 2014 at 7:24 PM, Pete Resnick wrote: > > And to be clear, my DISCUSS was because I thought the text was not clear > that 3.1.a and 3.1.b were being combined in X.7.20. Now the text is clear > that they are, which is why I moved off of my DISCUSS, but that's not to > say that I think it's good that they're combined. Murray has argued that > there has been no need to split them and therefore there is no likely > future need to do so either. The WG should probably decide if that's true, > because once you put X.7.20 in to mean the combination of 3.1.a and 3.1.b, > there's no going back; if you decide later that they ought to be split, > you'll be deprecating X.7.20 and making two new codes. I'd rather see them > split now, but it's not a showstopper, and if the WG considers it and > decides it's not necessary, like Stephen I will be fine with it. > I'll add it if the WG thinks it's needed or is a good idea. I just haven't seen any call for separating the two cases in practice so far. -MSK --047d7b872e9a4eae520500030836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 6, 2014 at 7:24 PM, Pete Resnick <pre= snick@qti.qualcomm.com> wrote:
=

=
And to be clear, my DISCUSS was because I thought the text was not clear th= at 3.1.a and 3.1.b were being combined in X.7.20. Now the text is clear tha= t they are, which is why I moved off of my DISCUSS, but that's not to s= ay that I think it's good that they're combined. Murray has argued = that there has been no need to split them and therefore there is no likely = future need to do so either. The WG should probably decide if that's tr= ue, because once you put X.7.20 in to mean the combination of 3.1.a and 3.1= .b, there's no going back; if you decide later that they ought to be sp= lit, you'll be deprecating X.7.20 and making two new codes. I'd rat= her see them split now, but it's not a showstopper, and if the WG consi= ders it and decides it's not necessary, like Stephen I will be fine wit= h it.

I'll add it if the WG th= inks it's needed or is a good idea.=C2=A0 I just haven't seen any c= all for separating the two cases in practice so far.

-MSK=
--047d7b872e9a4eae520500030836-- From nobody Thu Aug 7 03:38:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43611B2A4D; Thu, 7 Aug 2014 03:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-ZGb2OXJ_W9; Thu, 7 Aug 2014 03:38:48 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02921B2A48; Thu, 7 Aug 2014 03:38:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43952) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1XFL5i-0000NW-mJ (Exim 4.82_3-c0e5623) (return-path ); Thu, 07 Aug 2014 11:38:39 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XFL5i-0001O8-SM (Exim 4.72) (return-path ); Thu, 07 Aug 2014 11:38:38 +0100 Date: Thu, 7 Aug 2014 11:38:38 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Stephen Farrell In-Reply-To: <53E287CE.4040604@cs.tcd.ie> Message-ID: References: <20140806160958.7475.43515.idtracker@ietfa.amsl.com> <53E287CE.4040604@cs.tcd.ie> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NhQ_clf71xirEy_bCrbb-RcNRcQ Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , Barry Leiba , The IESG , Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 10:38:49 -0000 Stephen Farrell wrote: > On 06/08/14 17:29, Barry Leiba wrote: > > > > I don't understand what might be an issue for DNSSEC > > (implementations). What are you thinking? > > I've seen code break when assumptions that to-be-signed > (sub)fields are non-zero length get changed. This'd be a > possible case like that. In the null MX case the target field is one octet, not zero octets. From the point of view of a DNSSEC signer the relevant field is the entire RDATA which is priority+target i.e. 3 octets. If you want to try a DNSSEC signer with a zero octet RDATA field, put an empty TXT record in your zone. There are no DNSSEC implications to the null MX draft. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: West or northwest becoming variable, 3 or 4, then becoming cyclonic 4 or 5, occasionally 6 later. Slight or moderate. Occasional rain. Moderate or good. From nobody Thu Aug 7 05:42:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210391B2791; Thu, 7 Aug 2014 05:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJdaf0rAk9Qv; Thu, 7 Aug 2014 05:42:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 375111A0169; Thu, 7 Aug 2014 05:42:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807124213.6757.83087.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 05:42:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BM5zcv_M3AsSTrBPS4xV2s9UE9E Cc: draft-ietf-appsawg-nullmx@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:42:22 -0000 Ted Lemon has entered the following ballot position for draft-ietf-appsawg-nullmx-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Senders of abusive mail often use forged undeliverable return addresses. Null MX allows DSNs and other attempted responses to such mail to be disposed of efficiently. What's a DSN? Please define in the terminology section, or add a reference saying that the reader should read (X), or just expand on first use: not all readers will have the SMTP RFCs memorized. :) Also, it's not clear to me how this is a win unless the forged undeliverable return address has a null MX. Is that the envisioned scenario? If so, an additional sentence or two explaining why this is likely would help to justify the existence of this paragraph; otherwise I recommend just deleting it--it's not necessary, and on the face of it it seems implausible, but I'm not a spam expert, so maybe there's a reason of which I am not aware that the spammer would set this up, or use a fake domain for which a null MX exists. From nobody Thu Aug 7 05:58:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F101B2AD8; Thu, 7 Aug 2014 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpRztaaLY9y1; Thu, 7 Aug 2014 05:58:47 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B37C1B2ACD; Thu, 7 Aug 2014 05:58:46 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b17so2395024lan.39 for ; Thu, 07 Aug 2014 05:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hWhucw0cg5CAuqtl1tMHadIRmeAg505a4o9awzcTfUc=; b=ePxytuIekdvJJrmAT5gi1Piy0l9s/Yw8A654R+FTGy4/P32fFrFc1WC9BB+PbTTS+A EsDrNbWLB+9gBX3J55bzYAZp6i6lGLjENnRYxfndHWZ5oo4Q3ZLfP1ce0CkARrFI8BLX OvVB6lMIGo6MC9eUPz8eSCjWmkSOKdmul05mRfFQClRwBubfqrrhHofQ5abZFEHLfct2 pJui4pT4rt0aPhZTmlHcD32cMeFqQL60JJ23lfXF8rJEGimC9K1u2waHDf1ah80FJRAx usJZLWVNh48SsuW/UiIKj5b3LG72ECMhJmEbo0Bdg03bvL8LGBDAjgkhdmw8Yg0OkDn+ tbEw== MIME-Version: 1.0 X-Received: by 10.112.161.201 with SMTP id xu9mr15829445lbb.59.1407416324791; Thu, 07 Aug 2014 05:58:44 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 7 Aug 2014 05:58:44 -0700 (PDT) In-Reply-To: <20140807124213.6757.83087.idtracker@ietfa.amsl.com> References: <20140807124213.6757.83087.idtracker@ietfa.amsl.com> Date: Thu, 7 Aug 2014 08:58:44 -0400 X-Google-Sender-Auth: 1wNJYy6IPuvT_qVrW3qk0682CzY Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c31d3c1724ad050009a665 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6ZLkKgp98OUzTobNbq3TISq-YE4 Cc: "draft-ietf-appsawg-nullmx@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 12:58:49 -0000 --001a11c31d3c1724ad050009a665 Content-Type: text/plain; charset=ISO-8859-1 You're right that a spammer using randomly generated fake domain names is not likely to pick a real one with a null mx. But a lot of spam is sent using domain names harvested from the Internet, sometimes picking ones that seem related to one or more of the recipients, in order to make the mail seem legitimate. It's those that are actually reasonably likely to pick domain names that aren't used to send email. It's those that the paragraph in question is addressing. Barry On Thursday, August 7, 2014, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-ietf-appsawg-nullmx-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Senders of abusive mail often use forged undeliverable return > addresses. Null MX allows DSNs and other attempted responses to such > mail to be disposed of efficiently. > > What's a DSN? Please define in the terminology section, or add a > reference saying that the reader should read (X), or just expand on first > use: not all readers will have the SMTP RFCs memorized. :) > > Also, it's not clear to me how this is a win unless the forged > undeliverable return address has a null MX. Is that the envisioned > scenario? If so, an additional sentence or two explaining why this is > likely would help to justify the existence of this paragraph; otherwise I > recommend just deleting it--it's not necessary, and on the face of it it > seems implausible, but I'm not a spam expert, so maybe there's a reason > of which I am not aware that the spammer would set this up, or use a fake > domain for which a null MX exists. > > > --001a11c31d3c1724ad050009a665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You're right that a spammer using randomly generated fake domain names = is not likely to pick a real one with a null mx. =A0But a lot of spam is se= nt using domain names harvested from the Internet, sometimes picking ones t= hat seem related to one or more of the recipients, in order to make the mai= l seem legitimate. =A0It's those that are actually reasonably likely to= pick domain names that aren't used to send email. =A0It's those th= at the paragraph in question is addressing.

Barry

On Thursday, August 7, 2014, Ted Lemon <ted.lemon@nominum.com> wrote:
Ted Lemon has entered the following ballot position for
draft-ietf-appsawg-nullmx-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=A0 =A0Senders of abusive mail often use forged undeliverable return
=A0 =A0addresses. =A0Null MX allows DSNs and other attempted responses to s= uch
=A0 =A0mail to be disposed of efficiently.

What's a DSN? =A0 Please define in the terminology section, or add a reference saying that the reader should read (X), or just expand on first use: not all readers will have the SMTP RFCs memorized. :)

Also, it's not clear to me how this is a win unless the forged
undeliverable return address has a null MX. =A0 Is that the envisioned
scenario? =A0 If so, an additional sentence or two explaining why this is likely would help to justify the existence of this paragraph; otherwise I recommend just deleting it--it's not necessary, and on the face of it i= t
seems implausible, but I'm not a spam expert, so maybe there's a re= ason
of which I am not aware that the spammer would set this up, or use a fake domain for which a null MX exists.


--001a11c31d3c1724ad050009a665-- From nobody Thu Aug 7 06:04:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA061B29D3; Thu, 7 Aug 2014 06:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjA359mSu3YQ; Thu, 7 Aug 2014 06:04:32 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D601B29C5; Thu, 7 Aug 2014 06:04:32 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 387A21B83AB; Thu, 7 Aug 2014 06:04:32 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2302919004B; Thu, 7 Aug 2014 06:04:32 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 06:04:31 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 7 Aug 2014 09:04:09 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7C99231C-478C-4A28-A9FA-CB192723A5ED@nominum.com> References: <20140807124213.6757.83087.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H2zChBsqiHwe_elUN7-wf9QiMHo Cc: "draft-ietf-appsawg-nullmx@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 13:04:38 -0000 On Aug 7, 2014, at 8:58 AM, Barry Leiba wrote: > You're right that a spammer using randomly generated fake domain names = is not likely to pick a real one with a null mx. But a lot of spam is = sent using domain names harvested from the Internet, sometimes picking = ones that seem related to one or more of the recipients, in order to = make the mail seem legitimate. It's those that are actually reasonably = likely to pick domain names that aren't used to send email. It's those = that the paragraph in question is addressing. I suspected it was something like this. I think it would be beneficial = to add a sentence or two explaining this scenario for the reader, = although obviously it's not strictly necessary. From nobody Thu Aug 7 06:27:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A811B2B04; Thu, 7 Aug 2014 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6siD5EEfM47; Thu, 7 Aug 2014 06:27:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7241B2AFE; Thu, 7 Aug 2014 06:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807132741.24902.62963.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 06:27:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mJDDp7a5r1i6X6Ri81pTGvdcND4 Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 13:27:43 -0000 Ted Lemon has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] The list of implementations is apparently one, which is not in widespread use. I mention this not to argue against reclassification. But: The client SHOULD NOT provide source options that resolve to including the same mailbox more than once. A server can, of course, remove the duplicates before processing, but the server MAY return "BAD" to an ESEARCH command with duplicate source mailboxes. This sounds a little tenuous to me, and I wonder if it's not the result of some implementors making an engineering decision and then deciding to mention it in the RFC as advice. ISTM that it's actually not unreasonable to expect two mail box terms to identify an overlapping set of mailboxes, and in such a case it would be very desirable for the server to eliminate the duplicate rather than rejecting the command: that is, it is easier for the server to know that such a duplication exists than for the client to know, and therefore requiring the client to prevent this error is more onerous than requiring the server to prevent the error. ISTM that the right advice here is "the server should notice and eliminate duplicates when searching, and MUST NOT return BAD." However I assume there was vigorous discussion on the working group mailing list that reached the conclusion presented in the current text, and eagerly await explanation as to why I am wrong about this. :) From nobody Thu Aug 7 06:49:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261B21B2B35; Thu, 7 Aug 2014 06:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d8_1cZ58jNy; Thu, 7 Aug 2014 06:49:38 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDE31B2B32; Thu, 7 Aug 2014 06:49:37 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so3486680lab.7 for ; Thu, 07 Aug 2014 06:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rsZf5tBvnbVx+AHbUkuioMwq/OUL1Bd2ucCBn7FY4FY=; b=o1cGtYqgqLzcVJ1IDBTUSc2+n0aq+YMKewVB0SlOFrL2Ee7VFNG77ixg8LBrkrCVed YX1K8C6SepAZmaPyiNUacaokpiITmejpN80e7wOZhkugZmnUxPWYkWX6CjDRkvHiCS6a DyFV8CZIxEycNnyA2Is6/fsMHpVuLrGvXFJiirwb59rYGRb7v69XjUS9C6DWZz9p/IkD DvlAV7XItB86LFAtPqfwyKNc5M6tR0+St9E5AjqpEVLYP5bdtBSP8/o5ZVMb3tH8lQ4G MtmmDIJdh8q+ZwjWxcg4+XljSTNpR0gW+4RsT9j8GX3xXUjVVFktEVgV2DSiudM41lX3 N2Vg== MIME-Version: 1.0 X-Received: by 10.152.36.195 with SMTP id s3mr8946836laj.28.1407419376379; Thu, 07 Aug 2014 06:49:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 7 Aug 2014 06:49:36 -0700 (PDT) In-Reply-To: <20140807132741.24902.62963.idtracker@ietfa.amsl.com> References: <20140807132741.24902.62963.idtracker@ietfa.amsl.com> Date: Thu, 7 Aug 2014 09:49:36 -0400 X-Google-Sender-Auth: IYibyQ4Uw2usO8eShRsBGuZOeW8 Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8vOuhTJh1u8_EqaESi8cAhVniso Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 13:49:41 -0000 > This extension was previously published as experimental. There is > now implementation experience, giving confidence in the protocol, so > this document puts the extension on the Standards Track, with some > minor updates that were informed by the implementation experience. > [[RFC Editor: Please remove this paragraph at publication.]] > > The list of implementations is apparently one, which is not in widespread > use. Right; forgive me for erroneously saying "widespread" in that paragraph (which, by the way, at Adrian's suggestion will no longer be removed at publication). > The client SHOULD NOT provide source options that resolve to > including the same mailbox more than once. A server can, of course, > remove the duplicates before processing, but the server MAY return > "BAD" to an ESEARCH command with duplicate source mailboxes. > > This sounds a little tenuous to me, and I wonder if it's not the result > of some implementors making an engineering decision and then deciding to > mention it in the RFC as advice. ISTM that it's actually not > unreasonable to expect two mail box terms to identify an overlapping set > of mailboxes, and in such a case it would be very desirable for the > server to eliminate the duplicate rather than rejecting the command: that > is, it is easier for the server to know that such a duplication exists > than for the client to know, and therefore requiring the client to > prevent this error is more onerous than requiring the server to prevent > the error. ISTM that the right advice here is "the server should notice > and eliminate duplicates when searching, and MUST NOT return BAD." > However I assume there was vigorous discussion on the working group > mailing list that reached the conclusion presented in the current text, > and eagerly await explanation as to why I am wrong about this. :) Indeed, it was debated for, quite literally, many minutes before being settled on. This *was* reviewed by the primary implementors of email servers, and I'm confident that they think what's there is reasonable protocol ("MAY return 'BAD'). Perhaps it would be better to reverse its sense: rather than saying that the server MAY consider it a protocol error to include duplicates, say that it's a protocol error but the server MAY accept and process it anyway. The point, though, is that actual clients do not have a need for mixing the non-specific mailbox specifiers ("selected", "personal", "inboxes", "subscribed", and "subtree"). An ESEARCH that searches, say, "subscribed" and "subtree" at the same time is just not going to happen. And because the "mailboxes" specifier takes only an explicit list of mailboxes, with no wildcard matching, there's really no problem for clients to make sure there's no overlap. It's possible that a client might want to search << mailboxes "f1" subscribed >>, where f1 is subscribed, but, again, that's the sort of think a properly written client should be able to sort out (it ought to know which mailboxes are subscribed). The most likely user interface for this is a mailbox list with check-boxes, which, by its nature, will de-dup things. I suspect that a change from "BAD" to "NO" would be acceptable, but we (the IMAP community) really don't see what's there as a problem for implementations (&deity knows, there are enough other traps in implementing IMAP, and this isn't one of them). Barry From nobody Thu Aug 7 07:05:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98A1B2B60; Thu, 7 Aug 2014 07:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUqaX93IwfyZ; Thu, 7 Aug 2014 07:05:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484C11B2B56; Thu, 7 Aug 2014 07:05:42 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1C44C1B83AD; Thu, 7 Aug 2014 07:05:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E762919004B; Thu, 7 Aug 2014 07:05:41 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 07:05:36 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 7 Aug 2014 10:05:12 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <50F0BDB4-31D8-409A-A2AA-CB1EB6183B2D@nominum.com> References: <20140807132741.24902.62963.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vsJOPKs9Zi0JLwi3uBlHKflOihA Cc: "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 14:05:50 -0000 On Aug 7, 2014, at 9:49 AM, Barry Leiba wrote: > It's possible that a client might want to search << mailboxes "f1" > subscribed >>, where f1 is subscribed, but, again, that's the sort of > think a properly written client should be able to sort out (it ought > to know which mailboxes are subscribed). This is in fact the scenario I was considering. If the WG thought = about this and doesn't care, I don't care. From nobody Thu Aug 7 08:08:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362C51B2799; Wed, 6 Aug 2014 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYA_3qVH5Vj4; Wed, 6 Aug 2014 11:51:03 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D735B1A009C; Wed, 6 Aug 2014 11:51:02 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id hz20so2682038lab.27 for ; Wed, 06 Aug 2014 11:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8HuYFZtZzJ7eD57PNxY2JpwgpGWtuCVu5QEHvZUke/g=; b=wTdk+oaG+T7TqPkfFw4bM+zKTOQO4EHuDKtODxOMz8DFrkANimomRzjyiuyHoTgtV6 9KX2Kh4f8l2MnyHph/SCRB46NrTYgCgt4Q0dEz95rCxMP1DcfmOmCQHGgitX3lCfQVoH Qwh4ZRzzBv6Jwlyu0SOztZ9DYcmu4ZDQQU8T6keHDrNXkjBE8UQzGg0QvBbqkUMAZXzI PpZu9gSVBZr3adzF77ZGen0sO8CppJx/EWQd5GxWZw9rTzoIa65a7ivWeC8dsCRwYkll S7GK2gjblCsciJtKIvwbIvf/IKh7MIM2Kj7/6LLEIVVniJMbW3/OMN15gYUz+gjmUe8E okeg== MIME-Version: 1.0 X-Received: by 10.112.155.226 with SMTP id vz2mr2992865lbb.23.1407351060988; Wed, 06 Aug 2014 11:51:00 -0700 (PDT) Received: by 10.112.147.168 with HTTP; Wed, 6 Aug 2014 11:51:00 -0700 (PDT) In-Reply-To: References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> Date: Wed, 6 Aug 2014 14:51:00 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0118281c10877a04fffa74a8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/d7ltbTZAj65yj3PTVO0z9JaPgKY X-Mailman-Approved-At: Thu, 07 Aug 2014 08:07:46 -0700 Cc: "appsawg-chairs@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" , "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 18:51:06 -0000 X-List-Received-Date: Wed, 06 Aug 2014 18:51:06 -0000 --089e0118281c10877a04fffa74a8 Content-Type: text/plain; charset=UTF-8 Thanks for the quick responses! On the client side, I agree with the approach taken in that they should not be notified if a mailbox exists. That will prevent reconnaissance. The part I am having a little trouble with is the server side since a new capability to search multiple accounts is enabled through this draft. In Barry's response, I didn't think #1 was possible as I thought from reading the draft that read access was required for the user to search any subtree. Why would this allow searches outside of the user's access rights? I must have missed something and would appreciate an explanation of why this would be allowed. It's probably obvious why I would ask about logging, but in case it is not clear, here are the scenarios I am thinking about: Implementations/deployments could wind up with access permission issues that enable access to an account in which a user should not have access. I've seen this happen in other applications and it's not pretty when one user can see another users data (or one company can see data about another company). You could get into privacy concerns very quickly since we are talking about email or at the service provider level corporate data leakage. Being able to catch configuration mistakes through log analysis can be very helpful (seeing failed access attempts). The other issue could be where an attacker tries to get access outside of their normal set of accounts, exploiting this new feature and possible implementation or provisioning flaws (again, failed access attempt logs are helpful). Alexey's explanation was helpful, could something along those lines be added? From your responses, the search seems to go across a range of accounts whether or not there is read access. Where are the access controls checked and is it before the search is performed or after results are determined? I had assumed it was prior to the search, but am not sure from your responses. How about adding a recommendation for developers to implement logging of failed access attempts and the implementer can decide whether or not to enable it or to use it when debugging/testing to ensure access is limited as expected? Thanks for your help understanding this new feature better. I'd just like to make sure we are not missing an access control issue. On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba wrote: > What Alexey said. > > To add to that: > 1. Subtree searches and the like are quite likely to match mailboxes that > the user does not have access to, and logging such things would not be > useful. > > 2. In general, IMAP says nothing at all about logging. It defines the > protocol. Logging (along with what to log) is an implementation choice. > This document shouldn't be saying any more about it than RFC 3501, or > other IMAP specs. > > Barry > > > On Tuesday, August 5, 2014, Alexey Melnikov > wrote: > >> Hi Kathleen, >> >> > On 5 Aug 2014, at 22:59, "Kathleen Moriarty" < >> Kathleen.Moriarty.ietf@gmail.com> wrote: >> > >> > The draft is well written and this should be easy to clear, but I >> thought >> > it was important to discuss to see if a change might be needed. >> > >> > In the security considerations section, the following sentence says, >> > "Mailboxes matching the source options for which the logged-in user >> > lacks sufficient rights MUST be ignored by the ESEARCH command >> > processing (see the paragraph about this in Section 2.2). " >> > >> > It is good that access is not permitted, but shouldn't this be logged as >> > a possible access attempt violation? >> >> There was no intent to prevent logging, but the general approach of >> access control to mailboxes in IMAP is "treat mailboxes you don't have >> access to as non existent". So logging all mailboxes that the user has no >> access too is not necessarily productive and might generate lots of noise. >> >> The point of the sentence was to remind implementors that access control >> permissions are still to be checked. >> >> Best Regards, >> Alexey >> >> >> -- Best regards, Kathleen --089e0118281c10877a04fffa74a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the quick responses!

On the = client side, I agree with the approach taken in that they should not be not= ified if a mailbox exists. =C2=A0That will prevent reconnaissance. =C2=A0Th= e part I am having a little trouble with is the server side since a new cap= ability to search multiple accounts is enabled through this draft.=C2=A0

In Barry's response, I didn't think #1 was poss= ible as I thought from reading the draft that read access was required for = the user to search any subtree. =C2=A0Why would this allow searches outside= of the user's access rights? =C2=A0I must have missed something and wo= uld appreciate an explanation of why this would be allowed.

It's probably obvious why I would ask about logging= , but in case it is not clear, here are the scenarios I am thinking about:<= /div>

Implementations/deployments could wind up with acc= ess permission issues that enable access to an account in which a user shou= ld not have access. =C2=A0I've seen this happen in other applications a= nd it's not pretty when one user can see another users data (or one com= pany can see data about another company). =C2=A0You could get into privacy = concerns very quickly since we are talking about email or at the service pr= ovider level corporate data leakage. =C2=A0Being able to catch configuratio= n mistakes through log analysis can be very helpful (seeing failed access a= ttempts). =C2=A0The other issue could be where an attacker tries to get acc= ess outside of their normal set of accounts, exploiting this new feature an= d possible implementation or provisioning flaws (again, failed access attem= pt logs are helpful). =C2=A0

Alexey's explanation was helpful, could something a= long those lines be added? =C2=A0 From your responses, the search seems to = go across a range of accounts whether or not there is read access. =C2=A0Wh= ere are the access controls checked and is it before the search is performe= d or after results are determined? =C2=A0I had assumed it was prior to the = search, but am not sure from your responses.

How about adding a recommendation for developers to imp= lement logging of failed access attempts and the implementer can decide whe= ther or not to enable it or to use it when debugging/testing to ensure acce= ss is limited as expected? =C2=A0

Thanks for your help understanding this new feature bet= ter. I'd just like to make sure we are not missing an access control is= sue.




On Wed, Aug 6, 2014 at 9:33 AM, Barry Le= iba <barryleiba@computer.org> wrote:
What Alexey said.

To add to that:
1.=C2=A0Subt= ree searches and the like are quite likely to match mailboxes that the user= does not have access to, and logging such things would not be useful.

2. In general, IMAP says nothing at all about logging. =C2= =A0It defines the protocol. =C2=A0Logging (along with what to log)=C2=A0is = an implementation choice. =C2=A0This document shouldn't be saying any m= ore about it than RFC 3501, or other IMAP specs.

Barry


On Tuesday, August = 5, 2014, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi Kathleen,

> On 5 Aug 2014, at 22:59, "Kathleen Moriarty" <Kathleen= .Moriarty.ietf@gmail.com> wrote:
>
> The draft is well written and this should be easy to clear, but I thou= ght
> it was important to discuss to see if a change might be needed.
>
> In the security considerations section, the following sentence says, > "Mailboxes matching the source options for which the logged-in us= er
> =C2=A0 lacks sufficient rights MUST be ignored by the ESEARCH command<= br> > =C2=A0 processing (see the paragraph about this in Section 2.2). "= ;
>
> It is good that access is not permitted, but shouldn't this be log= ged as
> a possible access attempt violation?

There was no intent to prevent logging, but the general approach of access = control to mailboxes in IMAP is "treat mailboxes you don't have ac= cess to as non existent". So logging all mailboxes that the user has n= o access too is not necessarily productive and might generate lots of noise= .

The point of the sentence was to remind implementors that access control pe= rmissions are still to be checked.

Best Regards,
Alexey





--

Best regards,
Kathleen
--089e0118281c10877a04fffa74a8-- From nobody Thu Aug 7 08:08:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637681B2831; Wed, 6 Aug 2014 13:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtYi9JFIoIFW; Wed, 6 Aug 2014 13:01:48 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F281A0218; Wed, 6 Aug 2014 13:01:47 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id b8so2754949lan.19 for ; Wed, 06 Aug 2014 13:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j93FPs/K70Vk6gm4bdc8rr49NCGwpOjJZ8kEASQW/5o=; b=g2dK2Hqlr/oPl0KPVUVKM9cS9KOTmYhi8AnjbqJBbxb2N9y0mgA177k3Liqcvh7z86 8L0t99YWQ9rBbfcK/oI4FTR0r2L/mmAHyO5nS9by9bonda703JpM++01tYbGAIQRfSaI 2cBQUFgXNxvGOw7c65p686/jUmEthCQDBfOyhgkdJoGWAnAtYtWOqUPa9QHMwJCMgDWm efeD21Yo2zVXukTJCAKIBJlvWPvw89nHaAgPZ1hCL8WDYrWVEfWy37Ib0i2OQDr9qdkq mfG/ukq6IFHQFqLsgUFr/wsbESni0ZqxRvHYxnT54101isynJ7fAO4Re6oSbAkh2zgpJ VWbg== MIME-Version: 1.0 X-Received: by 10.152.45.101 with SMTP id l5mr13406356lam.20.1407355306273; Wed, 06 Aug 2014 13:01:46 -0700 (PDT) Received: by 10.112.147.168 with HTTP; Wed, 6 Aug 2014 13:01:46 -0700 (PDT) In-Reply-To: <53E284E5.4000304@qti.qualcomm.com> References: <20140805215900.12037.16876.idtracker@ietfa.amsl.com> <0AE5710B-B2DB-486B-88E5-033603F7A167@isode.com> <53E284E5.4000304@qti.qualcomm.com> Date: Wed, 6 Aug 2014 16:01:46 -0400 Message-ID: From: Kathleen Moriarty To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c288f21a71f404fffb7153 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/X-9t7ezo6NAHeYvvqEoPDrRspTU X-Mailman-Approved-At: Thu, 07 Aug 2014 08:07:46 -0700 Cc: "apps-discuss@ietf.org" , "draft-ietf-appsawg-multimailbox-search@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , Barry Leiba Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-multimailbox-search-03: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Aug 2014 20:01:52 -0000 --001a11c288f21a71f404fffb7153 Content-Type: text/plain; charset=UTF-8 Thanks, Pete, Barry & Alexey. I chatted with Barry and went back through the draft again... On Wed, Aug 6, 2014 at 3:41 PM, Pete Resnick wrote: > On 8/6/14 1:51 PM, Kathleen Moriarty wrote: > > The part I am having a little trouble with is the server side since a > new capability to search multiple accounts is enabled through this draft. > > > No, that's not true, or at least misstated: There is nothing you can > search with this mechanism that you can't search by multiple SELECT/SEARCH > pairs. > > OK, that's helpful, thank you. I wasn't sure if this was clear enough (access controls managed on the server side) and the last paragraph of 2.2 covers it. > > In Barry's response, I didn't think #1 was possible as I thought from > reading the draft that read access was required for the user to search any > subtree. Why would this allow searches outside of the user's access > rights? I must have missed something and would appreciate an explanation > of why this would be allowed. > > > If the server supports the Access Control List (ACL) [RFC4314] > extension, then the logged-in user is required to have the "r" right > for each mailbox she wants to search. In addition, any mailboxes > that are not explicitly named (accessed through "personal" or > "subtree", for example) are required to have the "l" right. > > You could have "l" access to the parent and "r" access to the child. > > OK, thanks. > > Implementations/deployments could wind up with access permission issues > that enable access to an account in which a user should not have access. > I've seen this happen in other applications and it's not pretty when one > user can see another users data (or one company can see data about another > company). You could get into privacy concerns very quickly since we are > talking about email or at the service provider level corporate data > leakage. Being able to catch configuration mistakes through log analysis > can be very helpful (seeing failed access attempts). The other issue could > be where an attacker tries to get access outside of their normal set of > accounts, exploiting this new feature and possible implementation or > provisioning flaws (again, failed access attempt logs are helpful). > > > On this, I agree with Barry's point #2: This is an implementation detail > and is not part of the protocol. I could implement logging by logging > errors for SELECT, or ESEARCH, or any other IMAP command that impinges on > ACLs. Or I could log all SELECTs and ESEARCHs (successful and unsuccessful) > and that would give me a much better log analysis of when users have > improper access to certain parts of the tree. I don't think this needs to > be pointed out in this protocol document. > OK, I wanted to check as it was a gap that popped out at me from operational and incident response experience. I'd try to exploit it ;-) > > Alexey's explanation was helpful, could something along those lines be > added? > > > I think 4314 already has a good discussion of this. Do you think something > more is needed? > I looked through some of the RFC, but not all and this should be good. I'll try to get through the rest, but have a bunch more reading to get through for tomorrow still :-) > > > How about adding a recommendation for developers to implement logging of > failed access attempts and the implementer can decide whether or not to > enable it or to use it when debugging/testing to ensure access is limited > as expected? > > > Again, I'm not convinced this belongs in a protocol document. I can see > loads of interesting reasons to implement all different sorts of logging > facilities, some for security, some for all sorts of other purposes. But > that seems to me solely a local implementation issue, not an issue for the > protocol. > OK, I'll remove the discuss and appreciate the discussion/explanation. Thanks, Kathleen > > pr > > > On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba > wrote: > >> What Alexey said. >> >> To add to that: >> 1. Subtree searches and the like are quite likely to match mailboxes that >> the user does not have access to, and logging such things would not be >> useful. >> >> 2. In general, IMAP says nothing at all about logging. It defines the >> protocol. Logging (along with what to log) is an implementation choice. >> This document shouldn't be saying any more about it than RFC 3501, or >> other IMAP specs. >> >> Barry >> >> >> On Tuesday, August 5, 2014, Alexey Melnikov >> wrote: >> >>> Hi Kathleen, >>> >>> > On 5 Aug 2014, at 22:59, "Kathleen Moriarty" < >>> Kathleen.Moriarty.ietf@gmail.com> wrote: >>> > >>> > The draft is well written and this should be easy to clear, but I >>> thought >>> > it was important to discuss to see if a change might be needed. >>> > >>> > In the security considerations section, the following sentence says, >>> > "Mailboxes matching the source options for which the logged-in user >>> > lacks sufficient rights MUST be ignored by the ESEARCH command >>> > processing (see the paragraph about this in Section 2.2). " >>> > >>> > It is good that access is not permitted, but shouldn't this be logged >>> as >>> > a possible access attempt violation? >>> >>> There was no intent to prevent logging, but the general approach of >>> access control to mailboxes in IMAP is "treat mailboxes you don't have >>> access to as non existent". So logging all mailboxes that the user has no >>> access too is not necessarily productive and might generate lots of noise. >>> >>> The point of the sentence was to remind implementors that access control >>> permissions are still to be checked. >>> >>> Best Regards, >>> Alexey >>> >>> >>> > > > -- > > Best regards, > Kathleen > > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- Best regards, Kathleen --001a11c288f21a71f404fffb7153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Pete, Barry & Alexey.

I cha= tted with Barry and went back through the draft again...


On Wed, Aug 6, 2014 at 3:41 = PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:<= br>
=20
On 8/6/14 1:51 PM, Kathleen Moriarty wrote:

The part I am having a little trouble with is the server side since a new capability to search multiple accounts is enabled through this draft.

No, that's not true, or at least misstated: There is nothing you can search with this mechanism that you can't search by multiple SELECT/SEARCH pairs.

OK, t= hat's helpful, thank you. =C2=A0I wasn't sure if this was clear eno= ugh (access controls managed on the server side) and the last paragraph of = 2.2 covers it.=C2=A0

In Barry's response, I didn't think #1 was possible as I tho= ught from reading the draft that read access was required for the user to search any subtree. =C2=A0Why would this allow searches outside of the user's access rights? =C2=A0I must have missed something and would appreciate an explanation of why this would be allowed.

=C2=A0=C2=A0 If the server supports the Access Control List (ACL) [RFC4314]=
=C2=A0=C2=A0 extension, then the logged-in user is required to have the &qu= ot;r" right
=C2=A0=C2=A0 for each mailbox she wants to search.=C2=A0 In addition, any m= ailboxes
=C2=A0=C2=A0 that are not explicitly named (accessed through "personal= " or
=C2=A0=C2=A0 "subtree", for example) are required to have the &qu= ot;l" right.

You could have "l" access to the parent and "r" access = to the child.

OK, thanks.= =C2=A0

Implementations/deployments could wind up with access permission issues that enable access to an account in which a user should not have access. =C2=A0I've seen this happen in other applicatio= ns and it's not pretty when one user can see another users data (or one company can see data about another company). =C2=A0You could get into privacy concerns very quickly since we are talking about email or at the service provider level corporate data leakage. =C2=A0Being able to catc= h configuration mistakes through log analysis can be very helpful (seeing failed access attempts). =C2=A0The other issue could be where an attacker tries to get access outside of their normal set of accounts, exploiting this new feature and possible implementation or provisioning flaws (again, failed access attempt logs are helpful).

On this, I agree with Barry's point #2: This is an implementation detail and is not part of the protocol. I could implement logging by logging errors for SELECT, or ESEARCH, or any other IMAP command that impinges on ACLs. Or I could log all SELECTs and ESEARCHs (successful and unsuccessful) and that would give me a much better log analysis of when users have improper access to certain parts of the tree. I don't think this needs to be pointed out in this protocol document.

OK, I wanted to check as it was a gap that popped = out at me from operational and incident response experience. =C2=A0I'd = try to exploit it ;-)



Alexey's explanation was helpful, could something along those lines be added?

I think 4314 already has a good discussion of this. Do you think something more is needed?

I looked th= rough some of the RFC, but not all and this should be good. =C2=A0I'll = try to get through the rest, but have a bunch more reading to get through f= or tomorrow still :-)
=C2=A0


How about adding a recommendation for developers to implement logging of failed access attempts and the implementer can decide whether or not to enable it or to use it when debugging/testing to ensure access is limited as expected?

Again, I'm not convinced this belongs in a protocol document. I can see loads of interesting reasons to implement all different sorts of logging facilities, some for security, some for all sorts of other purposes. But that seems to me solely a local implementation issue, not an issue for the protocol.

OK, I&= #39;ll remove the discuss and appreciate the discussion/explanation.
<= div>
Thanks,
Kathleen=C2=A0

pr


On Wed, Aug 6, 2014 at 9:33 AM, Barry Leiba <barryleiba@computer.org> wrote:
What Alexey said.

To add to that:
1.=C2=A0Subtree searches and the like are quite likely to match mailboxes that the user does not have access to, and logging such things would not be useful.

2. In general, IMAP says nothing at all about logging. =C2=A0It defines the protocol. =C2=A0Logging (along with what to log)=C2=A0is an implementation choice. =C2=A0This document shouldn't be saying any more about it than RFC 3501, or other IMAP specs.
Barry


On Tuesday, August 5, 2014, Alexey Melnikov <alexey.melnikov@isode.co= m> wrote:
Hi Kathleen,

> On 5 Aug 2014, at 22:59, "Kathleen Moriarty" <Kathleen= .Moriarty.ietf@gmail.com> wrote:
>
> The draft is well written and this should be easy to clear, but I thought
> it was important to discuss to see if a change might be needed.
>
> In the security considerations section, the following sentence says,
> "Mailboxes matching the source options for which the logged-in us= er
> =C2=A0 lacks sufficient rights MUST be ignored by the ESEARCH command<= br> > =C2=A0 processing (see the paragraph about this in Section 2.2). "= ;
>
> It is good that access is not permitted, but shouldn't this be logged as
> a possible access attempt violation?

There was no intent to prevent logging, but the general approach of access control to mailboxes in IMAP is "treat mailboxes you don't = have access to as non existent". So logging all mailboxes that the user has no access too is not necessarily productive and might generate lots of noise.

The point of the sentence was to remind implementors that access control permissions are still to be checked.

Best Regards,
Alexey





--

Best regards,
Kathleen

--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478



--

Best regards,
Kathleen
--001a11c288f21a71f404fffb7153-- From nobody Thu Aug 7 08:08:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037EF1B2871; Wed, 6 Aug 2014 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPT5TR8VXiVf; Wed, 6 Aug 2014 13:04:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 417281B284A; Wed, 6 Aug 2014 13:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806200439.20927.38857.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 13:04:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0fLXRasLOttmIPdJJWmUdjv3gRw X-Mailman-Approved-At: Thu, 07 Aug 2014 08:07:47 -0700 Cc: draft-ietf-appsawg-multimailbox-search@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-multimailbox-search-03: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 20:04:49 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-multimailbox-search-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for discussing my concerns around logging. I'm okay with that being left as an implementation choice (not mentioned in the draft), but do think it would be helpful to have it for testing access controls as well as detection of unapproved access attempts. From nobody Thu Aug 7 08:58:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9925B1B2D16; Thu, 7 Aug 2014 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRFU7nTu7CiL; Thu, 7 Aug 2014 08:58:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5293A1B2DAA; Thu, 7 Aug 2014 08:57:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807155738.6104.13835.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 08:57:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y6SzvizRXCTD4BlYuvpjdZ_6gP0 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multimailbox-search-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : IMAP4 Multimailbox SEARCH Extension Authors : Barry Leiba Alexey Melnikov Filename : draft-ietf-appsawg-multimailbox-search-04.txt Pages : 11 Date : 2014-08-07 Abstract: The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multimailbox-search-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multimailbox-search-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 7 08:58:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF31B2DC0 for ; Thu, 7 Aug 2014 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyW5wvSCPHYm; Thu, 7 Aug 2014 08:58:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE53A1B2D95; Thu, 7 Aug 2014 08:57:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org, apps-discuss@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807155738.6104.60138.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 08:57:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tV5jFTp2f-hZog5qSMdH5Q5s5kI Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multimailbox-search-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:58:21 -0000 A new version (-04) has been submitted for draft-ietf-appsawg-multimailbox-search: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multimailbox-search-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multimailbox-search-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Aug 7 10:10:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248C91A0009 for ; Thu, 7 Aug 2014 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omS0aZAN_zRt; Thu, 7 Aug 2014 10:10:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCCE1A0AE8; Thu, 7 Aug 2014 10:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807171029.3573.46786.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 10:10:29 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4Nnmv7mDbf4W8UoxKA9V-CJIu4M Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:10:32 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ From nobody Thu Aug 7 10:11:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A839C1A0AF1 for ; Thu, 7 Aug 2014 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJfKt0zVfUCq; Thu, 7 Aug 2014 10:11:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886851A0AFD; Thu, 7 Aug 2014 10:11:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807171140.13183.18967.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 10:11:40 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YqxIs3zS6Csn7lVqvUnGSmw2mJ4 Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:11:43 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Thu Aug 7 10:12:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBA1B2E78 for ; Thu, 7 Aug 2014 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-RGekgWtO5f; Thu, 7 Aug 2014 10:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF39E1B2E7A; Thu, 7 Aug 2014 10:12:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807171242.964.19003.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 10:12:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zsK98EVbYze8KSvf1133JBb1rtI Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:12:45 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ From nobody Thu Aug 7 13:57:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA31A00EB for ; Thu, 7 Aug 2014 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRts5d2vk6Te for ; Thu, 7 Aug 2014 13:57:23 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFB01A01E5 for ; Thu, 7 Aug 2014 13:57:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3112; t=1407445037; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oNkopEGqpT4Cb54lQyuche7Q8VA=; b=l1AlvjqlMBPnmAyfiiX+ 4oGxWYqukr6/gfMC+9N9/Je1adbW6QENf1sIKz+ctmdGwhGMTXzYwdbUjOX47lx5 HsEa9EqzTwyCcKKVxUAR4azdrBqI0MTdLlZI7fMjNWYVs36J9vGq65fTid8OipjF 6ZlhqhMVv5gXwRx+vABll2I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 07 Aug 2014 16:57:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2630134145.1846.1444; Thu, 07 Aug 2014 16:57:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3112; t=1407444763; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yf+Ai7y 6FKD14aFW3RmmA2q5b+vj0yRbU5ixfAHrlxo=; b=MgZy4AcKQDBa0ZL/3YUrmgs bBj5UB7b4uN2FPWQWHrmwn8sYSH75x0bdeOGCqNYdW8IlfXJbnJxUQ/KIR2uNenw X/3IEOKdhqNUmDDysxjyiK9cj56Ws5cVHyi1CY0MnlWsMESgEpXNKZi70UaxOYEC fwWD1DmC3VfF/UZa0+5k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 07 Aug 2014 16:52:43 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1222609515.9.5180; Thu, 07 Aug 2014 16:52:41 -0400 Message-ID: <53E3E829.3060201@isdg.net> Date: Thu, 07 Aug 2014 16:57:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba , Ted Lemon References: <20140807124213.6757.83087.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9s3Pa0_X5qYyRJdY09R3lALMLgg Cc: "draft-ietf-appsawg-nullmx@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-nullmx-07: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Aug 2014 20:57:24 -0000 I believe it will be generically applied to all anonymous transactions. IOW, it will be used as an across the board 5321.Mail From check for any non-whitelisted return-address. I can provide 11 years of CBV statistics to determine which percentage are real No MX versus NULLMX based. We currently use a 550 when the return-address CBV fails, so that isn't going to change. Code wise, one line can be added to implement this check to help preempt the actual CBV call: if mx.count == 1 and mx.exchange[0] == "." then return FALSE return CBV(MX) -- HLS On 8/7/2014 8:58 AM, Barry Leiba wrote: > You're right that a spammer using randomly generated fake domain names is > not likely to pick a real one with a null mx. But a lot of spam is sent > using domain names harvested from the Internet, sometimes picking ones that > seem related to one or more of the recipients, in order to make the mail > seem legitimate. It's those that are actually reasonably likely to pick > domain names that aren't used to send email. It's those that the paragraph > in question is addressing. > > Barry > > On Thursday, August 7, 2014, Ted Lemon wrote: > >> Ted Lemon has entered the following ballot position for >> draft-ietf-appsawg-nullmx-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Senders of abusive mail often use forged undeliverable return >> addresses. Null MX allows DSNs and other attempted responses to such >> mail to be disposed of efficiently. >> >> What's a DSN? Please define in the terminology section, or add a >> reference saying that the reader should read (X), or just expand on first >> use: not all readers will have the SMTP RFCs memorized. :) >> >> Also, it's not clear to me how this is a win unless the forged >> undeliverable return address has a null MX. Is that the envisioned >> scenario? If so, an additional sentence or two explaining why this is >> likely would help to justify the existence of this paragraph; otherwise I >> recommend just deleting it--it's not necessary, and on the face of it it >> seems implausible, but I'm not a spam expert, so maybe there's a reason >> of which I am not aware that the spammer would set this up, or use a fake >> domain for which a null MX exists. >> >> >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Aug 8 00:09:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2968A1A0428; Fri, 8 Aug 2014 00:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEudAAHltLoH; Fri, 8 Aug 2014 00:09:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C73961A0418; Fri, 8 Aug 2014 00:08:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808070859.30176.53976.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 00:08:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hNVVJOUXZjncXFZhRKuvu_HTIA0 Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:09:13 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Aug 8 11:18:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52791A0008 for ; Fri, 8 Aug 2014 11:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue7kk0k2wub1; Fri, 8 Aug 2014 11:18:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0901A001B; Fri, 8 Aug 2014 11:18:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808181848.4461.49665.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 11:18:48 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3WTmrYPGXd-RJ0jFbQFqLihBcXc Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:18:50 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Fri Aug 8 11:29:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17E61A0008; Fri, 8 Aug 2014 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LTcwcTZ6dFR; Fri, 8 Aug 2014 11:29:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 205D91A001E; Fri, 8 Aug 2014 11:29:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808182911.4546.81469.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 11:29:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KPB3MkrpH2F8jliLNeB97-TZ1VY Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-email-auth-codes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:29:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Email Authentication Status Codes Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-email-auth-codes-07.txt Pages : 8 Date : 2014-08-08 Abstract: This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures. This document updates [RFC7208] since some of the code points registered replace the ones recommended for use in that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-email-auth-codes-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 8 11:29:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B591A001B for ; Fri, 8 Aug 2014 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twjqABQ51ebO; Fri, 8 Aug 2014 11:29:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 359B01A0028; Fri, 8 Aug 2014 11:29:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808182911.4546.25798.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 11:29:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LYAM98Drh--CdoAKsw1RvDe4uf4 Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-email-auth-codes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:29:17 -0000 A new version (-07) has been submitted for draft-ietf-appsawg-email-auth-codes: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-email-auth-codes-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-email-auth-codes-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Aug 8 11:32:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23111A0009 for ; Fri, 8 Aug 2014 11:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4Jt0oxbFPJw; Fri, 8 Aug 2014 11:32:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 399371A000B; Fri, 8 Aug 2014 11:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808183206.19112.8071.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 11:32:06 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wREJHRCZpHz19_HisUJrFOpL4vk Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:32:09 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ From nobody Fri Aug 8 19:16:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09DA1A0A74; Fri, 8 Aug 2014 19:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxPSr6LywZml; Fri, 8 Aug 2014 19:16:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A94451A0A92; Fri, 8 Aug 2014 19:16:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140809021641.2407.62592.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 19:16:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vnc9x67B6WFzVDPti3bNSrE5Tn4 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 02:16:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A "Null MX" No Service Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-08.txt Pages : 7 Date : 2014-08-08 Abstract: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The no service MX RR, informally called null MX, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server, which permits significant operational efficiencies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 8 19:16:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC801A0A8F for ; Fri, 8 Aug 2014 19:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yZLJmzukyFO; Fri, 8 Aug 2014 19:16:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D14231A0A9D; Fri, 8 Aug 2014 19:16:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140809021641.2407.23518.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 19:16:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nt4B31xhrHHByEhaUop0aXONQBQ Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-nullmx-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 02:16:46 -0000 A new version (-08) has been submitted for draft-ietf-appsawg-nullmx: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-nullmx-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-nullmx-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Aug 8 19:46:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD421A0383 for ; Fri, 8 Aug 2014 19:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bToIS-W1k33q for ; Fri, 8 Aug 2014 19:46:02 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0181A0367 for ; Fri, 8 Aug 2014 19:46:01 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so1856902wib.2 for ; Fri, 08 Aug 2014 19:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lQ3ilooK1oLpuwATTaHHnC6htlGzpoXhDAFAddVkFws=; b=Zoaez7sI1kUPQfKrLzcLyJJOU7vnoyHGb6aXmWEdaY+Rp62unkGLhp5pDSFKQ71GQB CA1gJx5EIrBa8FvM9dRu2bTOH/nyY+UO8sVO5PKm267ZixAii/yO+qPS5nJ/+Rui8beJ VKF8Gg3a7n3BfT+Rm2OlXAC2SCW1RVkC/NeTuq4Fu4tEMKD4SZljPl47bWT5dhyxBSwt +lsB81wbx6lNpNmpuFAGBQd2B8mvV9135KkuZ6UpN+nu29ewfLH4tJj9imMQoGzfWfjZ WFzh/4F/nHod6yBErgr5XIb7CE/2a7oC4WBocJexBcYoLiFYvdYB40FmE2klFm7kTkD1 Wemw== MIME-Version: 1.0 X-Received: by 10.180.75.14 with SMTP id y14mr2539280wiv.79.1407552360377; Fri, 08 Aug 2014 19:46:00 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Fri, 8 Aug 2014 19:46:00 -0700 (PDT) Date: Fri, 8 Aug 2014 19:46:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d043c82007175d005002952f9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tS3xR43buCqgzFUZQtxTfzWVqDk Subject: [apps-discuss] APPSAWG Calls for Adoption X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Aug 2014 02:46:04 -0000 --f46d043c82007175d005002952f9 Content-Type: text/plain; charset=UTF-8 Colleagues, The following five documents entered Call For Adoption state after discussion at the Toronto meeting in July, and those Calls have now completed: draft-hansen-mdn-3798bis draft-kucherawy-authres-ptypes-registry draft-nottingham-http-problem draft-nottingham-safe-hint draft-seantek-text-markdown-media-type The particularly interesting case is draft-nottingham-safe-hint. Given the positions presented by various participants, the co-chairs think that APPSAWG is not the right way to proceed with this document. We are sending it back to the responsible Area Director, who will decide what to do with it from there. The remaining four documents appear to have enough support, fit within our charter, and have encountered no opposition to being processed as APPSAWG documents. They are therefore adopted as working group items, and the authors are thus invited to resubmit their documents with appropriate working group names, starting with "draft-ietf-appsawg-". Along with submitting your drafts, please compose a mini-charter, including a brief description of what the document seeks to accomplish, what's in scope and what's not in scope, the month in which you anticipate having the document ready for the IESG, and the names of people who will commit to providing ongoing and timely feedback as the document evolves. Also, since we have been regularly assigning non-chair document shepherds in APPSAWG for some time now, please let the co-chairs know If any of those are interested in acting as document shepherds. Examples of past and current mini-charters can be found here: http://tools.ietf.org/wg/appsawg/trac/wiki (Please don't use "list pending" for your supporter submissions.) Once we have the mini-charters in hand, we'll accept your renamed document submissions into the working group. Alexey & Murray, APPSAWG co-chairs --f46d043c82007175d005002952f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The following five documents entered Call For Adoption state after=20 discussion at the Toronto meeting in July, and those Calls have now=20 completed:

draft-hansen-mdn-3798bis
draft-kucherawy-authres-ptypes-registry
= draft-nottingham-http-problem
draft-nottingham-safe-hint
draft-seante= k-text-markdown-media-type

The particul= arly interesting case is draft-nottingham-safe-hint.=C2=A0 Given the positi= ons presented by various participants, the co-chairs think that APPSAWG is = not the right way to proceed with this document.=C2=A0 We are sending it ba= ck to the responsible Area Director, who will decide what to do with it fro= m there.

The remaining four documents appear to have enough support,=20 fit within our charter, and have encountered no opposition to being=20 processed as APPSAWG documents.=C2=A0 They are therefore adopted as working= =20 group items, and the authors are thus invited to resubmit their=20 documents with appropriate working group names, starting with=20 "draft-ietf-appsawg-".

Along with submitting your drafts, please compose a=20 mini-charter, including a brief description of what the document seeks=20 to accomplish, what's in scope and what's not in scope, the month i= n=20 which you anticipate having the document ready for the IESG, and the=20 names of people who will commit to providing ongoing and timely feedback as the document evolves.=C2=A0 Also, since we have been regularly assignin= g=20 non-chair document shepherds in APPSAWG for some time now, please let=20 the co-chairs know If any of those are interested in acting as document=20 shepherds.=C2=A0 Examples of past and current mini-charters can be found=20 here:

http://tools.ietf.org/wg/appsawg/trac/wiki

(Please don't u= se "list pending" for your supporter submissions.)

On= ce we have the mini-charters in hand, we'll accept your renamed documen= t submissions into the working group.

Alexey & Murray, APPSAWG co-chairs
--f46d043c82007175d005002952f9-- From nobody Fri Aug 8 21:07:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679791A0646 for ; Fri, 8 Aug 2014 21:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4_Yn7HmiHX9; Fri, 8 Aug 2014 21:07:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8C1A0A8B; Fri, 8 Aug 2014 21:07:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140809040713.8622.3923.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 21:07:13 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zvV3z62WoJRjWb0_P6M9MPRZJ8o Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 04:07:15 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Fri Aug 8 21:38:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79EE1A0AA4 for ; Fri, 8 Aug 2014 21:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdDhUqRZslkf; Fri, 8 Aug 2014 21:38:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EBF1A0AAD; Fri, 8 Aug 2014 21:38:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140809043838.25301.1887.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 21:38:38 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TTu3ADv9U_YTzBm75bj7vCkWaWg Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 04:38:41 -0000 IESG state changed to Last Call Requested from Approved-announcement to be sent Second last call is being requested for the downref to RFC 1846. The last call text has been regenerated and then significantly changed. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Sat Aug 9 05:14:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9A1B27D4 for ; Sat, 9 Aug 2014 05:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yupp6Wn8Zn9D for ; Sat, 9 Aug 2014 05:14:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B254F1B27D3 for ; Sat, 9 Aug 2014 05:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD9FDBE98; Sat, 9 Aug 2014 13:14:35 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ-0BmlHuzDZ; Sat, 9 Aug 2014 13:14:34 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.24.171]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26595BE35; Sat, 9 Aug 2014 13:14:34 +0100 (IST) Message-ID: <53E610A9.8090107@cs.tcd.ie> Date: Sat, 09 Aug 2014 13:14:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Barry Leiba References: <53D01455.6090504@cisco.com> <53D1115C.2010903@dcrocker.net> <53D526A1.5030505@cs.tcd.ie> <53D61B84.5080504@cs.tcd.ie> <53D6985E.2040500@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lSbbT-SfeQLs8dlKXRtHI0md6r0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Aug 2014 12:14:41 -0000 Hiya, Belatedly catching up on this. I suspect this is getting repetitive so probably no need to follow up and whoever's calling consensus on this can just take this into account. On 29/07/14 15:55, Barry Leiba wrote: >>>> Yes, the specific new concern that I raised there relates to >>>> equating this signal emitted from a browser with the "safe" >>>> concept of networking in general that seems to be espoused >>>> by for example the Chinese govt, where "safe" is apparently >>>> interpreted to mean quite a few things with significant >>>> impact on networking in general. A server-side or a n/w that >>>> did that could badly impact on interop. >> >> The fact that the signal term suggested clashes with that used >> (in a translation) to describe general network controls such >> as used in e.g. China is a concern. That has two aspects: 1) the >> colliding but undefined term indicates a specific actual problem >> that could otherwise be considered only a potential issue and >> 2) the signal emitted could well be (mins?)interpreted as being >> much more broad than http or than this request/response pair and >> I don't see how to rule that out without assigning at least some >> semantics to the signal and thereby invalidating the stated goal >> of the proponents that this signal does not have defined >> semantics. (If one tried to tie "safe" to one http request/response >> then presumably a page-load could result in not-"safe" content >> being seen. If one broadens it out then, how much, for how long >> etc? Both seem problematic.) > > Stephen, I think this is a real stretch. I can see how reasonable folks could differ on that. > The document doesn't just throw out "safe" with no explanation at all, > and more explanation of what's intended could easily be added to make > it yet clearer. I thought avoiding that rathole was part of the proposal myself. > But if we're trying to make it so that nothing we do > could be misinterpreted and abused by parties inclined to abuse it, > we're going to fail, and we'll do nothing. That last, IMO, *is* the correct outcome for "we" == IETF. Some earlier suggested this as an ISE thing, which would make sense perhaps. >>>> I also think the similarity with DNT is worrying. We were >>>> absolutely correct to not take that one on, as its troubled >>>> history within W3C I think shows. > > There's very little similarity with DNT. DNT said, "I know you want > to track the user, but the user doesn't want that. Please don't." > Safe-hint says, "You have a 'safe' setting that you offer the user. > The user is hereby opting into that." The above is not quite accurate IMO. There's a missing "If" since the UA doesn't know what the site does or does not do when emitting the value. And the "user" opting in to an undefined "that" is quite an odd proposition since the user presumably set the safe checkbox six months previous to ever visiting this site which may have changed its definition in that period. And of course this is liable to be the kind of thing that some govt might mandate be turned on by the UA, causing yet another mess and definitely taking out any user choice. The whole thing is ill-defined and a likely source of future trouble IMO. > They vastly different things, > with the only similarity being that they're both using HTTP headers to > request a feature. No. They are both similar in a) not being required for interop, b) being deliberately ill-defined at the protocol level and c) having no enforcement or checking mechanism at all. And while some of the incentives may be better aligned compared to DNT, not all are, e.g. those of users and governments perhaps. >>>> And I think this topic ought be considered by the IETF as >>>> a whole and not only on appsawg, before the work is adopted. >>>> Looking at appsawg's charter I think its fair to say that >>>> this is not a "small-scale addition" to HTTP - while it may >>>> appear so in terms of bits on the wire, the impact of that >>>> one new bit in a request is arguably large-scale. > > I think this is a stretch also. Again we disagree about that. IMO area WGs should not adopt work that is likely to be significantly controversial. The reason being that if that work is adopted and developed within an area WG then that effort and history distorts consideration by the IETF as a whole during an eventual 2-week LC. For controversial things forming a WG or AD sponsoring seem to me to be much better as that allows broader IETF consideration at the appropriate time, at the start of the (collective) work. I think the HTTP Forwarded header demonstrates that this is not at all a stretch. Someone else mentioned WebFinger as another. I do agree it can be hard to determine whether or not a bit of work is sufficiently controversial that it ought not be an area WG item. > In any case, I'll point out that what > little objection there is, is from a vocal minority; Vocal is purely pejorative though, right? And minority implies vote counting. I'd also point out that most of at least my mail has been in response to questions asked. > that this *is* a > small-scale addition with one person (you) trying to argue that it's > more than that; I interpret some of the other arguments against doing this as possibly being in agreement with me on this point. While that's not definitive, I don't think you can say that I am the only one who thinks this controversial and someone else at least has also suggested the ISE route. > that appsawg has quite broad participation; True. However, again I think HTTP Forwarded showed that there are limits there in terms of there being interests that are not well represented in this or any area WG. > and that > the IETF community outside appsawg will be able to comment during last > call, which is likely to happen very quickly. See above. Cheers, S. > > Barry > From nobody Sat Aug 9 05:30:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9469F1B27F2 for ; Sat, 9 Aug 2014 05:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmOOv6MiE-Nw for ; Sat, 9 Aug 2014 05:30:09 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1746F1B27D4 for ; Sat, 9 Aug 2014 05:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:Content-Transfer-Encoding:To:Date:Message-Id:In-Reply-To:Content-Type:From:References:Subject; bh=0WEJerapCBE+O9XfdYc/iVOrmwO0OS6GK/5uZsRe07o=; b=t5NNwZU47Xz4mp5xKe4x0InfKenaJUokMW1ThDYodErilZohb1jsQ2vl3at3Z1eWeTmDbTluJO7B29IMjAVJsKsXoBKoCQXQvHdVrk47b8BMRdxRqn1LsF1fAIklTE+CIVzFN8cZYgCtL+XghIDV64ukIBxKZE7rni5BW81JRUE=; Received: from stjhnbsu0ww-156034155194.pppoe-dynamic.high-speed.nb.bellaliant.net ([156.34.155.194]:62576 helo=[192.168.2.12]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XG5m0-0004Fl-2z for apps-discuss@ietf.org; Sat, 09 Aug 2014 05:29:30 -0700 References: <53D01455.6090504@cisco.com> <53D1115C.2010903@dcrocker.net> <53D526A1.5030505@cs.tcd.ie> <53D61B84.5080504@cs.tcd.ie> <53D6985E.2040500@cs.tcd.ie> <53E610A9.8090107@cs.tcd.ie> From: Eric Burger Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11D257) In-Reply-To: <53E610A9.8090107@cs.tcd.ie> Message-Id: Date: Sat, 9 Aug 2014 09:29:22 -0300 To: apps-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/knSbpfrzTQrz0QZEn3cTzUpmpXc Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Aug 2014 12:30:11 -0000 How about this to get us out of the rabbit hole? Instead of calling this the= "safe-hint" header, let us call it the "pink-hint" header. When a server re= ceives a request with the pink-hint header, it [fill in the current proposed= behavior of safe-hint]. That gets us out of the layer 8 and 9 issues that a= ttempt (at layer 5) to answer the question of "what is 'safe'?" -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF= LEMONADE for mobile email! See > On Aug 9, 2014, at 9:14 AM, Stephen Farrell wr= ote: >=20 >=20 > Hiya, >=20 > Belatedly catching up on this. I suspect this is getting > repetitive so probably no need to follow up and whoever's > calling consensus on this can just take this into account. >=20 > On 29/07/14 15:55, Barry Leiba wrote: >>>>> Yes, the specific new concern that I raised there relates to >>>>> equating this signal emitted from a browser with the "safe" >>>>> concept of networking in general that seems to be espoused >>>>> by for example the Chinese govt, where "safe" is apparently >>>>> interpreted to mean quite a few things with significant >>>>> impact on networking in general. A server-side or a n/w that >>>>> did that could badly impact on interop. >>>=20 >>> The fact that the signal term suggested clashes with that used >>> (in a translation) to describe general network controls such >>> as used in e.g. China is a concern. That has two aspects: 1) the >>> colliding but undefined term indicates a specific actual problem >>> that could otherwise be considered only a potential issue and >>> 2) the signal emitted could well be (mins?)interpreted as being >>> much more broad than http or than this request/response pair and >>> I don't see how to rule that out without assigning at least some >>> semantics to the signal and thereby invalidating the stated goal >>> of the proponents that this signal does not have defined >>> semantics. (If one tried to tie "safe" to one http request/response >>> then presumably a page-load could result in not-"safe" content >>> being seen. If one broadens it out then, how much, for how long >>> etc? Both seem problematic.) >>=20 >> Stephen, I think this is a real stretch. >=20 > I can see how reasonable folks could differ on that. >=20 >> The document doesn't just throw out "safe" with no explanation at all, >> and more explanation of what's intended could easily be added to make >> it yet clearer. =20 >=20 > I thought avoiding that rathole was part of the proposal > myself. >=20 >> But if we're trying to make it so that nothing we do >> could be misinterpreted and abused by parties inclined to abuse it, >> we're going to fail, and we'll do nothing. >=20 > That last, IMO, *is* the correct outcome for "we" =3D=3D IETF. > Some earlier suggested this as an ISE thing, which would > make sense perhaps. >=20 >>>>> I also think the similarity with DNT is worrying. We were >>>>> absolutely correct to not take that one on, as its troubled >>>>> history within W3C I think shows. >>=20 >> There's very little similarity with DNT. DNT said, "I know you want >> to track the user, but the user doesn't want that. Please don't." >> Safe-hint says, "You have a 'safe' setting that you offer the user. >> The user is hereby opting into that." =20 >=20 > The above is not quite accurate IMO. There's a missing "If" > since the UA doesn't know what the site does or does not do > when emitting the value. And the "user" opting in to an > undefined "that" is quite an odd proposition since the user > presumably set the safe checkbox six months previous to ever > visiting this site which may have changed its definition > in that period. And of course this is liable to be the kind > of thing that some govt might mandate be turned on by the > UA, causing yet another mess and definitely taking out any > user choice. >=20 > The whole thing is ill-defined and a likely source of future > trouble IMO. >=20 >> They vastly different things, >> with the only similarity being that they're both using HTTP headers to >> request a feature. >=20 > No. They are both similar in a) not being required for interop, > b) being deliberately ill-defined at the protocol level and c) > having no enforcement or checking mechanism at all. >=20 > And while some of the incentives may be better aligned compared > to DNT, not all are, e.g. those of users and governments perhaps. >=20 >>>>> And I think this topic ought be considered by the IETF as >>>>> a whole and not only on appsawg, before the work is adopted. >>>>> Looking at appsawg's charter I think its fair to say that >>>>> this is not a "small-scale addition" to HTTP - while it may >>>>> appear so in terms of bits on the wire, the impact of that >>>>> one new bit in a request is arguably large-scale. >>=20 >> I think this is a stretch also. =20 >=20 > Again we disagree about that. IMO area WGs should not adopt > work that is likely to be significantly controversial. The > reason being that if that work is adopted and developed within > an area WG then that effort and history distorts consideration > by the IETF as a whole during an eventual 2-week LC. For > controversial things forming a WG or AD sponsoring seem to me > to be much better as that allows broader IETF consideration > at the appropriate time, at the start of the (collective) work. > I think the HTTP Forwarded header demonstrates that this is > not at all a stretch. Someone else mentioned WebFinger as > another. >=20 > I do agree it can be hard to determine whether or not a bit > of work is sufficiently controversial that it ought not be an > area WG item. >=20 >> In any case, I'll point out that what >> little objection there is, is from a vocal minority; >=20 > Vocal is purely pejorative though, right? And minority implies > vote counting. I'd also point out that most of at least my mail > has been in response to questions asked. >=20 >> that this *is* a >> small-scale addition with one person (you) trying to argue that it's >> more than that; >=20 > I interpret some of the other arguments against doing this as > possibly being in agreement with me on this point. While that's > not definitive, I don't think you can say that I am the only > one who thinks this controversial and someone else at least has > also suggested the ISE route. >=20 >> that appsawg has quite broad participation; >=20 > True. However, again I think HTTP Forwarded showed that there > are limits there in terms of there being interests that are > not well represented in this or any area WG. >=20 >> and that >> the IETF community outside appsawg will be able to comment during last >> call, which is likely to happen very quickly. >=20 > See above. >=20 > Cheers, > S. >=20 >=20 >>=20 >> Barry >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Sat Aug 9 16:38:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77E1A03AD for ; Sat, 9 Aug 2014 16:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7NAaoA2_1zD for ; Sat, 9 Aug 2014 16:38:45 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3EA1A0185 for ; Sat, 9 Aug 2014 16:38:44 -0700 (PDT) Received: (qmail 42212 invoked from network); 9 Aug 2014 23:38:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Aug 2014 23:38:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1368a.53e6b0fa.k1408; i=johnl@user.iecc.com; bh=iv/8rzpHVcXABOzhcybN45lYeck6+36VCEgoPdrRmC0=; b=Z8vWM83fm+xPxI+s7oJOOUKyfjlmyljGVKm6hv656brzr31qrPLzt4Pq6dwTr7Xqkd+TZ76Ne7ZR4Eu4QX0Wutw8+Ye4ydBJfZI9X0XcD6A4murZzhx8HQWCKTvoU0rEZvN95SugOrq6yTQfBX4F+q2F9SdEGhwBFrDhcapQkHh4sj5Cft7CQXtoZezBOYL++01zlR3nygcJUfiXzOPDH1rTOyIlK8dhqzSvIX6KmqJfbNJmN/Ls0dR6n2uEOE/d DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1368a.53e6b0fa.k1408; olt=johnl@user.iecc.com; bh=iv/8rzpHVcXABOzhcybN45lYeck6+36VCEgoPdrRmC0=; b=RjmpIB/qDFimKuGZ0sFI1NQb0Loq9GY/QcWgfY0RVCxFRSo8gJ9L50LIvyyHE+s6D4cUzCtJUC/9s2dCAFNFSoKR2x2S1Lynzxgl+0UVA0gUdpyZ1nS3I1a7BrM4rVIIsdwDRoOORNZ0hzCF+/X0Xb6Azl9WMN+X2NXN91xma2hJzhCo9LzI6tYNnnYCATA6Ih9rA1vhpyOQaSVJ3IZigqU4xapQQvzm/odk0xM1D+sczrLSZhbg8U7OFyXpf/77 Date: 9 Aug 2014 23:38:11 -0000 Message-ID: <20140809233811.79497.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/U3hROeDL9iP4A8yBIqLxJE-UkiY Subject: Re: [apps-discuss] Call For Adoption: draft-nottingham-safe-hint X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Aug 2014 23:38:46 -0000 In article you write: >How about this to get us out of the rabbit hole? Instead of calling this the "safe-hint" >header, let us call it the "pink-hint" header. No such luck. We seem to have a fairly deep disagreement between the faction that wants to write up this tiny hack as is since it's already implemented in two of the most widely used browsers, and the faction that insists we can't do that, we have to do something more complicated and probably different. I find the latter position baffling, but there are clearly people who feel strongly about it, so if we're going to do this, one side needs to wear the other down and that's more messiness than we can do in appsarea. R's, John From nobody Sun Aug 10 08:43:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE21A0430 for ; Sun, 10 Aug 2014 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZtWuAh8bZdd for ; Sun, 10 Aug 2014 08:43:50 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6BD1A0222 for ; Sun, 10 Aug 2014 08:43:50 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id v10so7064233qac.19 for ; Sun, 10 Aug 2014 08:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=MDgegtiAnM8QXckwnO3+K5l5IZ1xSTqcNsK0RTvc6QQ=; b=k1Kn6WpATbLnLaopzyTar85LDfoU/X3EL3OxlgnHm/WEK/PwMcVKed3cXZzhoJ08F5 HnsFujdXOOfFYbRLf0O3tm49tSHCV2T/YxA2dHAaPhpedRCroZp3pvhBPhrK0Zt4QeFV 1oF8/vFlq3aoysEB54bIyaU8qY8OjcwzfOZScm0qAno2EfF9RDIZPGoqXaMwoDlQ7Beq kn4CT/HMuRfws/D6L5o6hnA1L6iA49++kpxkdl3UbXGg2co1HW6307C9xNg6VrI3lGD7 WWWbDGP0FCXYYBU5J0f1MFv8HQ8uBk3eyQAyhqU82s0ylfhTiPQyJs5qi2tZ2xJLVNmG NvpQ== X-Received: by 10.140.20.17 with SMTP id 17mr39643431qgi.85.1407685429717; Sun, 10 Aug 2014 08:43:49 -0700 (PDT) Received: from PeterPC (c-76-118-25-250.hsd1.ma.comcast.net. [76.118.25.250]) by mx.google.com with ESMTPSA id w15sm16555800qay.34.2014.08.10.08.43.48 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Aug 2014 08:43:49 -0700 (PDT) Message-ID: <1DA3C3D25F644B498433A52FA89B8603@PeterPC> From: "Peter Occil" To: "Sean Leonard" References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> <53DF979D.8040500@seantek.com> In-Reply-To: <53DF979D.8040500@seantek.com> Date: Sun, 10 Aug 2014 11:43:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MIMEOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140810-0, 08/10/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/N5yDnPZPEEW_TdmPdGKCzTxJZFI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Aug 2014 15:43:51 -0000 For your information. I became interested in defining Markdown and made an attempt at a Markdown standard, or at least a less ambiguous syntax specification than the original. The document is found at: Note that it's currently incomplete, but it should be enough for you to comment on it. The project page is . You can raise issues there (or if you prefer, on this mailing list). --Peter -----Original Message----- From: Sean Leonard Sent: Monday, August 04, 2014 10:24 AM To: Murray S. Kucherawy Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type On 8/3/2014 11:12 PM, Murray S. Kucherawy wrote: > On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard > wrote: > > Just wanted to add some observations that I made at the APPSAWG > presentation: > > > While reviewing our open calls for adoption, I just noticed that this > document currently requests Informational status. Why not Proposed > Standard? > I am okay with Proposed Standard/Standards-Track status. However, I am also okay with Informational status. Section 3.1 of RFC 6838 effectively says that the registration proposal for a standards-tree registration (i.e., text/markdown) MUST be published as an RFC, which can be Standards Track or Informational (or BCP or Experimental). Informational is a somewhat lower bar than Standards-Track, and I would rather have a registration than have the doc mired in techno-politics and bikeshedding. :) Ned Freed (and others) made several good points about the nebulous-ness of the Markdown format. There is no canonical Markdown format that everybody agrees upon and looks to; the original Gruber specification leaves much ambiguous. But this proposal avoids adopting work on the Markdown format. If another person or organization can herd the cats, good for them. This proposal is primarily about getting the media type (and parameters) standardized, which would be useful to the community. If that fits in Standards-Track, then great. Otherwise, Informational will do just fine. Cheers, Sean _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 11 02:52:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136801A03AB; Mon, 11 Aug 2014 02:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITomYpTJyR7a; Mon, 11 Aug 2014 02:51:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 104DA1A03A0; Mon, 11 Aug 2014 02:51:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 02:51:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6oE9Guvq6pkBK0_cP5T7tN7hvoM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 09:51:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A Property Types Registry for the Authentication-Results Header Field Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-authres-ptypes-registry-00.txt Pages : 5 Date : 2014-08-10 Abstract: [RFC7001] describes a header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can add or use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. One portion of the definition in that document limits the types of authentication properties about a message to a small, fixed set. This document updates the specification to allow new property types to be declared and used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-authres-ptypes-registry-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 11 06:24:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779141A01AA; Mon, 11 Aug 2014 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_IERShQmSqt; Mon, 11 Aug 2014 06:24:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5111A006A; Mon, 11 Aug 2014 06:24:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140811132445.6567.62539.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 06:24:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/83VTvF_yVxJmALHkD9BoKM7V3sU Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (A "Null MX" No Service Resource Record for Domains that Accept No Mail) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:24:46 -0000 The IESG has tentatively approved the following document: - 'A "Null MX" No Service Resource Record for Domains that Accept No Mail' as Proposed Standard Changes to the document late in the review process have resulted in the addition of a downward reference to RFC 1846, which is an Experimental document. This extra Last Call is specifically to ask for comments on whether that downward reference is appropriate. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately this means that the A/ AAAA record is taken to be mail server address even when that address does not accept mail. The no service MX RR, informally called null MX, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server, which permits significant operational efficiencies. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Aug 11 06:24:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8E1A0345 for ; Mon, 11 Aug 2014 06:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMIT0LMHgcMf; Mon, 11 Aug 2014 06:24:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167AA1A0113; Mon, 11 Aug 2014 06:24:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811132447.6567.11376.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 06:24:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8oAVcBiNLSekdNF0kxdA-qqs1Wc Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:24:50 -0000 Last call has been made for draft-ietf-appsawg-nullmx and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Mon Aug 11 10:31:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34F71A0037 for ; Mon, 11 Aug 2014 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtfHWeDUamrD for ; Mon, 11 Aug 2014 10:31:03 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DAF1A0027 for ; Mon, 11 Aug 2014 10:31:03 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s7BHV2NZ022221 for ; Mon, 11 Aug 2014 10:31:02 -0700 Received: from ds135-91-110-222.dhcps.ugn.att.com ([135.91.110.222]) by maillennium.att.com (mailgw1) with ESMTP id <20140811173100gw100j0cqve>; Mon, 11 Aug 2014 17:31:01 +0000 X-Originating-IP: [135.91.110.222] Message-ID: <53E8FDF7.4060203@att.com> Date: Mon, 11 Aug 2014 13:31:35 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: IETF Apps Discuss References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070808070105000207050703" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vsfVnOM1tMYB1nFwCwRdrim3TdI Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Aug 2014 17:31:04 -0000 This is a multi-part message in MIME format. --------------070808070105000207050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/4/14, 2:12 AM, Murray S. Kucherawy wrote: > On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard > wrote: > > Just wanted to add some observations that I made at the APPSAWG > presentation: > > > While reviewing our open calls for adoption, I just noticed that this > document currently requests Informational status. Why not Proposed > Standard? For registering the media type, Informational status should be sufficient. It's not standardizing the format; just registering the media type. Tony Hansen --------------070808070105000207050703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/4/14, 2:12 AM, Murray S. Kucherawy wrote:
On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
Just wanted to add some observations that I made at the APPSAWG presentation:

While reviewing our open calls for adoption, I just noticed that this document currently requests Informational status.  Why not Proposed Standard?

For registering the media type, Informational status should be sufficient. It's not standardizing the format; just registering the media type.

    Tony Hansen
--------------070808070105000207050703-- From nobody Mon Aug 11 11:20:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111F41A0746 for ; Mon, 11 Aug 2014 11:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ9XWakVAdej; Mon, 11 Aug 2014 11:20:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 696DD1A06F6; Mon, 11 Aug 2014 11:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-email-auth-codes@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811182031.28783.50962.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:20:31 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bCg-GqbL9BBdg_4t4wT7ghQRths Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:20:46 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ From nobody Mon Aug 11 11:26:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6299B1A0066 for ; Mon, 11 Aug 2014 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg6826-0lQYG; Mon, 11 Aug 2014 11:26:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3CC1A0747; Mon, 11 Aug 2014 11:26:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811182629.31164.81933.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:26:29 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VFORPcC5TtSP1J0Udfk0Pm4dQxM Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:26:33 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ From nobody Mon Aug 11 15:50:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF451A06D9 for ; Mon, 11 Aug 2014 15:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmXlvq_Ks6o0 for ; Mon, 11 Aug 2014 15:50:36 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C771A06A3 for ; Mon, 11 Aug 2014 15:50:35 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B13CA956006; Mon, 11 Aug 2014 18:50:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1407797434; bh=f8EhYoUxXTYVVh9pSLeAgCgXb4AzjIjC230tFXQEypM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=s0TCmjuzDvyhitJ7zvfCS8bPPtExSMHtdRGlpQrzOf+HWFeLAQn8HFxIRWnI4pq65 JEnvEQxacrw3XkVDPmxVtZ8D9j2GKoXLPeONe5lFjdFOQUBUlkHDenGo6/Gbo91fTE XGr9pPmFn/JetUuw99MH3UCchdlydMkQ17FOiarw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 797EA956001; Mon, 11 Aug 2014 18:50:34 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 11 Aug 2014 18:50:33 -0400 Message-ID: <1805872.I6BDV7KmAB@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-32-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> References: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jWSUUYZxqrqbocw__1tEkDgbvnw Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Aug 2014 22:50:39 -0000 On Monday, August 11, 2014 02:51:58 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 : A Property Types Registry for the > Authentication-Results Header Field Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-authres-ptypes-registry-00.txt > Pages : 5 > Date : 2014-08-10 > > Abstract: > [RFC7001] describes a header field called Authentication-Results for > use with electronic mail messages to indicate the results of message > authentication efforts. Any receiver-side software, such as mail > filters or Mail User Agents (MUAs), can add or use this header field > to relay that information in a convenient and meaningful way to > users, or make sorting and filtering decisions. > > One portion of the definition in that document limits the types of > authentication properties about a message to a small, fixed set. > This document updates the specification to allow new property types > to be declared and used. I've reviewed the document and support the concept. I'm not sure about the backward compatibility approach though. A-R parsing code based on a strict interpretation of the existing standard, RFC 7001, would raise an error with a new ptype. There's nothing in 7001 or its predecessors to indicate unknown ptypes are anything other than an error condition. As an alternative solution, I would suggest that this draft state that any A-R field that uses a new ptype must use version 2. For backward compatibility systems adding version 2 A-R fields can also add a version 1 field that omits the new ptype if that is a useful thing to do. Processing software that has been updated to consume version 2 records should ignore duplicate version 1 records. Scott K From nobody Mon Aug 11 16:06:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456411A0720 for ; Mon, 11 Aug 2014 16:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnzC1uQ8FLEd for ; Mon, 11 Aug 2014 16:06:10 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F761A01EF for ; Mon, 11 Aug 2014 16:06:09 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so4962987wiv.3 for ; Mon, 11 Aug 2014 16:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3JIOymrbnUvrfjmaW3GLdbR9SEkyuCcc1QWOaVVwSO0=; b=xBLHd8E+LGfl5jlEO52tJKpBHKjlGEM27yB5HgRQ4GVtFNh+FWTODGpga9zOrxeIdV ynO5bTWwkzMCWWxygXURady+Gu/vThjg7JcAdoAoDikIDhae58c2ZpdI3gvyjfEzaOn4 Ua+kOS/bL//vY2lM68BU7pvK0eTZ1H0vX8ljLCChyvrjTzze9B8/sFO5AvjSMd59Ib/O k9UnAgVssACpPYVd64jpKjZo1I2i7RsFDj4HP8Ccwfh4XcvGok9vgHXz0FgpAR5KbjNu q7EvYkoLcQI6oeolb0B2m4VY7yeYLvnDPzOlNB7He0/udkVXYSk1ApzTiNke/JpP/rs/ Rrlw== MIME-Version: 1.0 X-Received: by 10.180.75.14 with SMTP id y14mr23508381wiv.79.1407798368347; Mon, 11 Aug 2014 16:06:08 -0700 (PDT) Received: by 10.180.10.99 with HTTP; Mon, 11 Aug 2014 16:06:08 -0700 (PDT) In-Reply-To: <1805872.I6BDV7KmAB@scott-latitude-e6320> References: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> <1805872.I6BDV7KmAB@scott-latitude-e6320> Date: Mon, 11 Aug 2014 16:06:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c8200a92f19050062994e Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lJTCsj1G0a5iFKpgKm7d0DJ5tfE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Aug 2014 23:06:11 -0000 --f46d043c8200a92f19050062994e Content-Type: text/plain; charset=UTF-8 On Mon, Aug 11, 2014 at 3:50 PM, Scott Kitterman wrote: > I've reviewed the document and support the concept. I'm not sure about the > backward compatibility approach though. > > A-R parsing code based on a strict interpretation of the existing standard, > RFC 7001, would raise an error with a new ptype. There's nothing in 7001 > or > its predecessors to indicate unknown ptypes are anything other than an > error > condition. > Section 4.1 of 7001 says: MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the corresponding registry for such values as defined in Section 6 . Moreover, such agents MUST ignore a result indicated for any "method" they do not specifically support. Doesn't that cover it? -MSK --f46d043c8200a92f19050062994e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 11, 2014 at 3:50 PM, Scott Kitterman <scott= @kitterman.com> wrote:
I've reviewed the doc= ument and support the concept. =C2=A0I'm not sure about the
backward compatibility approach though.

A-R parsing code based on a strict interpretation of the existing standard,=
RFC 7001, would raise an error with a new ptype. =C2=A0There's nothing = in 7001 or
its predecessors to indicate unknown ptypes are anything other than an erro= r
condition.

Section 4.1 of 7001 says:
   MUAs and downstream filters MUST ignore any result =
reported using a
   "result" not specified in the IANA "Result Code" reg=
istry or a
   "ptype" not listed in the corresponding registry for such valu=
es as
   defined in Sect=
ion 6.  Moreover, such agents MUST ignore a result
   indicated for any "method" they do not specifically support.
Doesn't that cover it?

-MSK
--f46d043c8200a92f19050062994e-- From nobody Mon Aug 11 16:20:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5552D1A072D for ; Mon, 11 Aug 2014 16:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.197 X-Spam-Level: ** X-Spam-Status: No, score=2.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDdlXhQK7c7E for ; Mon, 11 Aug 2014 16:20:02 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4711A0728 for ; Mon, 11 Aug 2014 16:20:02 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 19E2AD046A4; Mon, 11 Aug 2014 19:20:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1407799201; bh=XplUZcveSqWY1t0CjKB6DuH55ZXpKpVI/fyAACh7vb4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z9ijI4GLNfABj00K0Hg4CZY5tYUiz6VFYkCLxLsXGu1Kt50Z2tmk/MmtREzPdQHKe kOP0SvSxGEzO9GMmozHrVTrpGWK/3PEJ0ghiUdr7VA748kwRMyPyuUVW8aB8kucFKz kAKyzFNd+sukNNWEo+/BZaECt30LZiMsBgAajw7s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DBC2FD0463B; Mon, 11 Aug 2014 19:20:00 -0400 (EDT) From: Scott Kitterman To: IETF Apps Discuss Date: Mon, 11 Aug 2014 19:20 -0400 Message-ID: <1792132.XtOk7aQIyf@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-32-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> <1805872.I6BDV7KmAB@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tvsBm2Yn2zceRkPr4PanEeh1hSg Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Aug 2014 23:20:05 -0000 On Monday, August 11, 2014 16:06:08 Murray S. Kucherawy wrote: > On Mon, Aug 11, 2014 at 3:50 PM, Scott Kitterman > > wrote: > > I've reviewed the document and support the concept. I'm not sure about > > the > > backward compatibility approach though. > > > > A-R parsing code based on a strict interpretation of the existing > > standard, > > RFC 7001, would raise an error with a new ptype. There's nothing in 7001 > > or > > its predecessors to indicate unknown ptypes are anything other than an > > error > > condition. > > Section 4.1 of 7001 says: > > MUAs and downstream filters MUST ignore any result reported using a > "result" not specified in the IANA "Result Code" registry or a > "ptype" not listed in the corresponding registry for such values as > defined in Section 6 > . Moreover, such agents > MUST ignore a result > indicated for any "method" they do not specifically support. > > Doesn't that cover it? Actually, I think it does. Never mind, I'm happy. Scott K From nobody Mon Aug 11 20:00:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BAA1A0264 for ; Mon, 11 Aug 2014 20:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTiLrkc2NqOo for ; Mon, 11 Aug 2014 19:59:59 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3A1A0263 for ; Mon, 11 Aug 2014 19:59:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB9LMIF44W00138P@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 11 Aug 2014 19:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407812099; bh=TNm2T6+FlXOUzF4Gg0D+QIFGNxZzt5xmEn9gCBLbOuI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Yv+Lkg9oiQvLxZhmbHoSDx2krSCBBtNWU6y4Ypg9Bq+/NnkFhIZA6MRwe/MqL4rpR 30wsPNLPuq4v8z/BhISkl3tgOdLqA/4EFSnHnlDrcmqLCr+NNk/BWPLt5F+3lBhlKg MV4YMxZAX0LWTUqSOK6+nXnOHuBr16+ONNCeHs7E= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB2RFWCBO00000SM@mauve.mrochek.com>; Mon, 11 Aug 2014 19:54:55 -0700 (PDT) Message-id: <01PB9LMH5SXU0000SM@mauve.mrochek.com> Date: Mon, 11 Aug 2014 19:53:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 11 Aug 2014 13:31:35 -0400" <53E8FDF7.4060203@att.com> References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> <53E8FDF7.4060203@att.com> To: Tony Hansen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZTsxHQGNyNXDOkp1CpZlJZLnU3I Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 03:00:00 -0000 > On 8/4/14, 2:12 AM, Murray S. Kucherawy wrote: > > On Tue, Jul 22, 2014 at 2:07 PM, Sean Leonard > > wrote: > > > > Just wanted to add some observations that I made at the APPSAWG > > presentation: > > > > > > While reviewing our open calls for adoption, I just noticed that this > > document currently requests Informational status. Why not Proposed > > Standard? > For registering the media type, Informational status should be > sufficient. It's not standardizing the format; just registering the > media type. Agreed. If, however, the document ends up expanding to include some sort of shared base syntax (I'm not saying it should or will, but let's suppose), then there's a case to be made for proposed. Ned From nobody Mon Aug 11 20:22:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1CE1A0780 for ; Mon, 11 Aug 2014 20:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdhGT3Irq0Yk for ; Mon, 11 Aug 2014 20:22:21 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C1E1A0271 for ; Mon, 11 Aug 2014 20:22:21 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s7C3MKTX023329 for ; Mon, 11 Aug 2014 20:22:21 -0700 Received: from vpn-135-70-101-18.vpn.swst.att.com ([135.70.101.18]) by maillennium.att.com (mailgw1) with ESMTP id <20140812032220gw100j0cr9e>; Tue, 12 Aug 2014 03:22:20 +0000 X-Originating-IP: [135.70.101.18] Message-ID: <53E9888F.9090906@att.com> Date: Mon, 11 Aug 2014 23:22:55 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: IETF Apps Discuss References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> <53E8FDF7.4060203@att.com> <01PB9LMH5SXU0000SM@mauve.mrochek.com> In-Reply-To: <01PB9LMH5SXU0000SM@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PE_IFuR1T4YtiJUYN3cGvp0rPps Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 03:22:22 -0000 On 8/11/14, 10:53 PM, Ned Freed wrote: > >> For registering the media type, Informational status should be >> sufficient. It's not standardizing the format; just registering the >> media type. > > Agreed. If, however, the document ends up expanding to include some > sort of > shared base syntax (I'm not saying it should or will, but let's > suppose), then > there's a case to be made for proposed. I would write that as "If >>and only if<< ..." :-) Tony Hansen From nobody Mon Aug 11 20:34:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2676C1A01A8 for ; Mon, 11 Aug 2014 20:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWOmb_36otDI for ; Mon, 11 Aug 2014 20:33:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4051A019B for ; Mon, 11 Aug 2014 20:33:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB9MTJEZ74000J00@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 11 Aug 2014 20:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1407814133; bh=weCcow//Dcoig4kAN8WawM5vwLnroQMUFqQ/PdE3pLI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=UWbQX2NTcXJpA3Q7bX+YIUQY1uWy6OkiYhdSAqai5B7FEUe+A62cLSHFEbrgZnheM CA71UakyxJyr7eNFvWtDGMmA72eQaa/6o1aLcGNr6iwdOQp07zJsj7bleQtumLOuqY 43vs+BRA4iqIeNJY+TJnu7R31EhVPWlLqFBhDe7w= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PB2RFWCBO00000SM@mauve.mrochek.com>; Mon, 11 Aug 2014 20:28:50 -0700 (PDT) Message-id: <01PB9MTIBG2C0000SM@mauve.mrochek.com> Date: Mon, 11 Aug 2014 20:28:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 11 Aug 2014 23:22:55 -0400" <53E9888F.9090906@att.com> References: <64A70A8D-E82B-4269-B243-6A5DA98AEB56@standardstrack.com> <20140721195032.7791.qmail@joyce.lan> <01PAFXOJO2QQ007ZXF@mauve.mrochek.com> <20140722170739.174919sctur0hbwg@webmail.tuffmail.net> <53E8FDF7.4060203@att.com> <01PB9LMH5SXU0000SM@mauve.mrochek.com> <53E9888F.9090906@att.com> To: Tony Hansen Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/P_3LxOjk468eCigZkK-QemXsjcI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-seantek-text-markdown-media-type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 03:33:59 -0000 > On 8/11/14, 10:53 PM, Ned Freed wrote: > > > >> For registering the media type, Informational status should be > >> sufficient. It's not standardizing the format; just registering the > >> media type. > > > > Agreed. If, however, the document ends up expanding to include some > > sort of > > shared base syntax (I'm not saying it should or will, but let's > > suppose), then > > there's a case to be made for proposed. > I would write that as "If >>and only if<< ..." :-) Fair point ;-) Ned From nobody Tue Aug 12 12:06:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAAD1A0738 for ; Tue, 12 Aug 2014 12:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfKEVViigtxf; Tue, 12 Aug 2014 12:06:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CB1A0742; Tue, 12 Aug 2014 12:06:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812190642.32569.52643.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 12:06:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/W8xE6t4T4MoEu6azidJqdCbJnXQ Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:06:47 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Tue Aug 12 14:20:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519CE1A0718 for ; Tue, 12 Aug 2014 14:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ig_5XOQEMZ for ; Tue, 12 Aug 2014 14:20:33 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1864E1A066B for ; Tue, 12 Aug 2014 14:20:32 -0700 (PDT) Received: from [192.168.2.120] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 5C73FCB46 for ; Tue, 12 Aug 2014 17:20:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 17:20:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D6CD8A3-D8F0-4DE7-985A-DFEAF1420510@eudaemon.net> References: <20140811095158.16173.99141.idtracker@ietfa.amsl.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/k-uO6uxYBU5voDHK9YborMaEEDY Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 21:20:34 -0000 On Aug 11, 2014, at 5:51 AM, Internet-Drafts@ietf.org wrote: > Title : A Property Types Registry for the = Authentication-Results Header Field > Filename : = draft-ietf-appsawg-authres-ptypes-registry-00.txt > Date : 2014-08-10 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registr= y/ I've reviewed this, and support its movement onward & upward. If = ongoing review is needed, feel free to include me. =3D- Tim From nobody Wed Aug 13 12:54:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD61F1A0110; Tue, 12 Aug 2014 13:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ7qFWHlO55f; Tue, 12 Aug 2014 13:30:32 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F581A0104; Tue, 12 Aug 2014 13:30:28 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7CKUNAq012158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2014 16:30:27 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7CKUNAq012158 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407875427; bh=0iOqwexQrwHrnclPc6i44cRl9+o=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nH6WVbPQGhOvv8AMeJpJAQ8DfZQIX2V+y2P5HL06SP0mUZoYPmDsolYpYdGfBFf6H 1Cc8W1rnfqE+fFogN82v0q6gMpz6e4SjcR6HpM85fgP35pLOMkE4I1XiOlqUTiDmrD TiZ7AMoDSPB4zQmBggVsTv/BlZBwvf0evI7vcO6g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7CKUNAq012158 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 12 Aug 2014 16:30:10 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7CKQvOQ008471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 16:30:10 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 12 Aug 2014 16:29:38 -0400 From: "Black, David" To: "standards@taugh.com" , "mx0dot@yahoo.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Date: Tue, 12 Aug 2014 16:29:37 -0400 Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08 Thread-Index: Ac+2bBxDyTCd8vjpQQ2sYrKDYqkWYQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B951D2A@MX15A.corp.emc.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 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: GIS Solicitation, DLM_1, public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JWv00h102EkAGjh73YhcpdxRWHY X-Mailman-Approved-At: Wed, 13 Aug 2014 12:54:43 -0700 Cc: "Black, David" , "ietf@ietf.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Aug 2014 20:30:39 -0000 This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follows ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: . Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-appsawg-nullmx-08 Reviewer: David L. Black Review Date: August 12, 2014 IETF LC End Date: August 25, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft is a short specification of a NULL MX resource record whose publication in the DNS indicates that a domain does not accept email. Good news: The one remaining nit from the Gen-ART review of the -05 version has been corrected in the -08 version. Bad news: idnits 2.13.00 noted the added downref to RFC 1846, for which the draft is now in a second IETF Last Call. A draft has just been submitted to replace RFC 1846 (Experimental) with a Standards Track RFC: https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/ The IESG should decide whether to proceed with the downref to RFC 1846bis vs. publish the 1846bis draft as a standards track RFC and reference it. That decision is the open issue in this review of the nullmx draft. >From an operational perspective, the added SMTP status codes for null MX errors (one of which is the cause of the downref) are an improvement, in that they enable more precise reporting of the reason for email not being delivered. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, July 25, 2014 10:46 AM > To: standards@taugh.com; mx0dot@yahoo.com; General Area Review Team (gen- > art@ietf.org); ops-dir@ietf.org > Cc: apps-discuss@ietf.org; ietf@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-06 >=20 > The -06 version of this draft addresses the topics raised in the Gen-ART > review of the -05 version, except that Section 1 is still missing from > the Table of Contents (possible xml2rfc problem?). >=20 > Summary: Ready with nits. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Black, David > > Sent: Thursday, July 17, 2014 12:39 AM > > To: standards@taugh.com; mx0dot@yahoo.com; General Area Review Team (ge= n- > > art@ietf.org); ops-dir@ietf.org > > Cc: apps-discuss@ietf.org; ietf@ietf.org; Black, David > > Subject: Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-05 > > > > This is a combined Gen-ART and OPS-DIR review. > > Boilerplate for both follows ... > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at: > > > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > I have reviewed this document as part of the Operational directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments > > were written primarily for the benefit of the operational area director= s. > > Document editors and WG chairs should treat these comments just like an= y > other > > last call comments. > > > > Document: draft-ietf-appsawg-nullmx-05 > > Reviewer: David L. Black > > Review Date: July 16, 2014 > > IETF LC End Date: July 17, 2014 > > IESG Telechat Date: August 7, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft is a short specification of a NULL MX resource record whose > > publication in the DNS indicates that a domain does not accept email. > > > > I found one relatively minor issue. > > > > Minor Issues: > > > > Something is wrong with this paragraph in the Security Considerations > section: > > > > In the unlikely event that a domain legitimately sends email but doe= s > > not want to receive email, SMTP servers that reject mail from domain= s > > that advertise a NULL MX risk losing email from those domains. The > > normal way to send mail for which a sender wants no responses remain= s > > unchanged, by using an empty RFC5321.MailFrom address. > > > > Why is that treated as a security consideration? In light of the first > > paragraph in Section 4.3 stating that it's acceptable for SMTP clients = to > > not send email to domains that publish NULL MX records, this text ought= to > > be recommending that such a domain (legitimately sends email but does n= ot > > want to receive email) SHOULD NOT publish a NULL MX record and SHOULD > provide > > an SMTP server that promptly rejects all email delivery attempt. It ca= n > > then further explain that not following the "SHOULD NOT" causes lost em= ail > > as described in the quoted text, and not following the "SHOULD" causes = long > > delivery timeouts as described in Section 2. I'd also suggest moving t= his > > discussion to Section 4.3 so that it follows the first paragraph there. > > > > Nits: > > > > Section 1 is missing from Table of Contents. > > > > First paragraph in Section 4.1: > > "address is not deliverable" -> "the email is not deliverable" > > > > Second paragraph in Section 4.1 assumes that all or most domains that > > do not accept email also publish NULL MX records. That assumption shou= ld > > be stated as part of the first sentence of the paragraph, as the immedi= ately > > preceding paragraph is about the benefits of individual domains publish= ing > > NULL MX records. > > > > In Section 4.3, please provide text descriptions of the 550 reply code = and > > 5.1.2 enhanced status code. > > > > OLD > > 550 reply code > > NEW > > 550 reply code (Requested action not taken: mailbox unavailable) > [RFC5321] > > > > OLD > > 5.1.2 enhanced status code > > NEW > > 5.1.2 enhanced status code (Permanent Failure, Bad destination syste= m > > address) > > > > idnits 2.13.01 didn't find anything to complain about. > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > A.1.1 Has deployment been discussed? > > > > Yes, and NULL MX records are already deployed in the DNS. > > > > A.1.5. Has the impact on network operation been discussed? > > > > Yes, in general, NULL MX records have significant operational > > benefits as described in the draft. > > > > A.2. Do you anticipate any manageability issues with the specification= ? > > > > No. This is a minor extension to an existing use of DNS resource > > records. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From nobody Wed Aug 13 13:05:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE721A056D for ; Wed, 13 Aug 2014 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8qJgOGAl5Z9 for ; Wed, 13 Aug 2014 13:05:15 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313CE1A04C2 for ; Wed, 13 Aug 2014 13:05:15 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so211307wgh.23 for ; Wed, 13 Aug 2014 13:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PAAxUaWjw1IXKH0689Ik4U9a9laWxc1/xaToi2qaWHQ=; b=w3hrUlmsXk+CWpooZWuxlzXECxxMnFs9ajGrMsBGsH+Jv1lIwD0e9cVNL39WhA/7dP 4mv1ev7C/Rsz/uush7M1o+SIySPHKnjBfAvC3rYxi9nKmhu0Gr/w2NfjWeFpasDB4uad FOdE1NGyZWKvE7X8dHsta1wGNp1GeYwGPRjl/b9vlVsdashjGeqAUygP1LowfcRP2+ZN eiK/HB1CbZ00dv0B6Wd+lbaMuL7ws8EGE/23peQHjlgspnfoya75KUawdnFrI8EpWVf2 0Ox0zfnvslVnIlmOjajqNyjVFY8QuF6Uodyh6UauJ+qgFaczRes/WgR2SayiQaIi/y9F Pcaw== MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr6152054wju.33.1407960313904; Wed, 13 Aug 2014 13:05:13 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Wed, 13 Aug 2014 13:05:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Aug 2014 22:05:13 +0200 Message-ID: From: Daniel Migault To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0cf645e48cf0500884eb4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MlIA6beSD3GkWnnKRswbxdeJj-k Subject: [apps-discuss] Fwd: Time Zone Distribution Protocol WG Milestones (tzdist) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Aug 2014 20:05:17 -0000 --047d7bf0cf645e48cf0500884eb4 Content-Type: text/plain; charset=UTF-8 My apologies if you already have received this email. I miss pelt the email for the application area. Hi, We are getting under way with the tzdist WG [1]. This IETF working group (WG) goal is to define time zone data distribution protocols. If you want to join please the tzdist WG [2]. These are the milestones we propose. If you have any comments, please feel free to post them before Tuesday August 19 so we can consider them. Milestones: - September 2014 Adopt time zone data distribution protocol draft as WG document - September 2014 Adopt an CalDAV extension draft as WG document - January 2015 Submit time zone data distribution protocol draft for WGLC - March 2015 Submit time zone data distribution protocol draft as Standards Track RFC - March 2015 Submit CalDAV extension draft for WGLC - June 2015 Submit CalDAV extension draft as Standards Track RFC - September 2016 re-charter the WG [1] http://datatracker.ietf.org/wg/tzdist/charter/ [2] https://www.ietf.org/mailman/listinfo/tzdist -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bf0cf645e48cf0500884eb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My apologies if you already have received this email. I mi= ss pelt the email for the application area.
=C2=A0

Hi,
<= div class=3D"gmail_quote">

We are getting under way wit= h the tzdist WG [1]. This IETF working group (WG)=20 goal is to define time zone data distribution protocols. If you want to=20 join please the tzdist WG [2].

These are the milestones we=20 propose. If you have any comments, please feel free to post them before Tue= sday August 19 so we can consider them.

Milestones:
=C2=A0=C2=A0=C2= =A0=C2=A0 - September 2014 Adopt time zone data distribution protocol draft= as WG document
=C2=A0=C2=A0=C2=A0=C2=A0 - September 2014 Adopt an CalDA= V extension draft as WG document
=C2=A0=C2=A0=C2=A0=C2=A0 - January 2015 Submit time zone data distribution = protocol draft for WGLC
=C2=A0=C2=A0=C2=A0=C2=A0 - March 2015 Submit time zone data distribution pr= otocol draft as Standards Track RFC
=C2=A0=C2=A0=C2=A0=C2=A0 - March 201= 5 Submit CalDAV extension draft for WGLC
=C2=A0=C2=A0=C2=A0=C2=A0 - June= 2015 Submit CalDAV extension draft as Standards Track RFC
=C2=A0=C2=A0=C2=A0=C2=A0 - September 2016 re-charter the WG


[1] http://datatracker.ietf.org/wg/tzdist/charter/
[2] https:/= /www.ietf.org/mailman/listinfo/tzdist

--
Daniel Migault
Orange Labs -- Security
+33 6 7= 0 72 69 58



--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--047d7bf0cf645e48cf0500884eb4-- From nobody Fri Aug 15 11:06:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9651A01F1; Fri, 15 Aug 2014 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOrDtFdoId1F; Fri, 15 Aug 2014 11:06:15 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A0E1A01F9; Fri, 15 Aug 2014 11:06:14 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so2657088igb.14 for ; Fri, 15 Aug 2014 11:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3BR4nuNPBKZAcUDsznz42e+oO/wIj3eIGr5XFQqcslw=; b=1IxX565I9EZ5XcAbPjFXChk1Sz+cFDobp11pZcZ0frBfxdpSrfxZMizGqAZVii4xXK r4hDqv/ofPmTn5RhpvnLsnxDAoREysqG4dokMDa7p800daqNkmZkHWpuc4TbtHeiQzbh kRy6fQQkYMyrxd53wjehHi1OsG1jednxuHuxGDiIqiJK3RTvK1fly2KzgZkUNQvUXUxz pFlwPmqI2uVCXLyImRN4B/FAraqhoW6fYhqDeNJI62H9RBoweWXVep4rUszxGw1i6Jcf P9NPlSnPYO+xsqLO7hy6/RtnOvj/hgUVQbLIGmxyU+0mmKn3oCECXPP7SO+IjHME2eNf lCgw== MIME-Version: 1.0 X-Received: by 10.43.164.130 with SMTP id ms2mr23061630icc.9.1408125974093; Fri, 15 Aug 2014 11:06:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.148 with HTTP; Fri, 15 Aug 2014 11:06:14 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B951D2A@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951D2A@MX15A.corp.emc.com> Date: Fri, 15 Aug 2014 14:06:14 -0400 X-Google-Sender-Auth: y6Nl_qW_oxNQG7M93HpMg7hDdQI Message-ID: From: Barry Leiba To: "Black, David" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uIP4KHVwk8jUq0QNL-Tx0cL6UX4 Cc: "ops-dir@ietf.org" , "standards@taugh.com" , "ietf@ietf.org" , "apps-discuss@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "mx0dot@yahoo.com" Subject: Re: [apps-discuss] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Aug 2014 18:06:16 -0000 Thanks, David, for the re-review. > A draft has just been > submitted to replace RFC 1846 (Experimental) with a Standards Track RFC: > > https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/ > > The IESG should decide whether to proceed with the downref to RFC 1846bis > vs. publish the 1846bis draft as a standards track RFC and reference it. > That decision is the open issue in this review of the nullmx draft. Right, and the decision has already been made, which is why the second last-call notice says that the document has been "tentatively approved": The plan is to put the nullmx draft into the RFC Editor queue. If we can do the 1846bis processing quickly, so that when AUTH48 comes for nullmx we see 1846bis as being essentially done, we will hold nullmx, process the two documents together, and change the reference. But if it looks like 1846bis is getting hung up, we will proceed with publication of nullmx with the downref. That plan was discussed on the apps-discuss list a couple of weeks ago. Barry From nobody Mon Aug 18 08:32:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989EF1A063E; Mon, 18 Aug 2014 08:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiQbMPa3Wher; Mon, 18 Aug 2014 08:31:55 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 966E01A0647; Mon, 18 Aug 2014 08:31:52 -0700 (PDT) Received: from [192.168.2.117] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 1EA2ACB46; Mon, 18 Aug 2014 11:31:55 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 18 Aug 2014 11:31:49 -0400 To: Apps Discuss , dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nOVlMQi6mcZ03V-Z5iiUWMjqoTs Subject: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2014 15:31:56 -0000 Hello world of email, The DMARC WG is getting started [1]. This IETF working group's goal is = to address interoperability issues with indirect email flows, to = document operational practices, and to mature the existing DMARC base = specification. If you would like to join please visit the DMARC WG [2]. The WG's Wiki page [3] documents the approach the WG will take to = produce its deliverables. You can find the roadmap/milestones on the = site [4]. For your convenience, the proposed milestones are: - 91st IETF: Document describing interoperability issues with DMARC = and indirect mail flows. - EOY 2014: Deliverable #1 (above document + possible methods to = address). - Feb 2015: draft DMARC Usage Guide - 92nd IETF: Deliverable #2 - Document describing DMARC improvements = to better support indirect mail flows.=20 - May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide If you have comments on the milestones, please provide them by August = 25th. Have fun, =3D- Tim [1] http://datatracker.ietf.org/wg/dmarc/charter/ [2] https://www.ietf.org/mailman/listinfo/dmarc [3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki [4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap From nobody Mon Aug 18 08:50:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA291A066F; Mon, 18 Aug 2014 08:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaAusDFUJ7vb; Mon, 18 Aug 2014 08:50:51 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FBE1A0665; Mon, 18 Aug 2014 08:50:51 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Mon, 18 Aug 2014 11:50:51 -0400 From: "MH Michael Hammer (5304)" To: Tim Draegen , Apps Discuss , "dmarc@ietf.org" Thread-Topic: [apps-discuss] Start of DMARC WG + proposed milestones Thread-Index: AQHPuvmZqmbuddt63E2frkuXv5j9Z5vWggGg Date: Mon, 18 Aug 2014 15:50:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.221] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Fk8apCsrI0Xl8LzA0rST4Vd56aE Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2014 15:50:53 -0000 Is the DMARC Usage Guide the same as the BCP or is it a different document?= If it is a different document, is the BCP going to be one of the milestone= s for the WG or is it off the table? Mike > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Ti= m > Draegen > Sent: Monday, August 18, 2014 11:32 AM > To: Apps Discuss; dmarc@ietf.org > Subject: [apps-discuss] Start of DMARC WG + proposed milestones >=20 > Hello world of email, >=20 > The DMARC WG is getting started [1]. This IETF working group's goal is t= o > address interoperability issues with indirect email flows, to document > operational practices, and to mature the existing DMARC base specificatio= n. > If you would like to join please visit the DMARC WG [2]. >=20 > The WG's Wiki page [3] documents the approach the WG will take to produce > its deliverables. You can find the roadmap/milestones on the site [4]. = For > your convenience, the proposed milestones are: >=20 > - 91st IETF: Document describing interoperability issues with DMARC a= nd > indirect mail flows. > - EOY 2014: Deliverable #1 (above document + possible methods to > address). > - Feb 2015: draft DMARC Usage Guide > - 92nd IETF: Deliverable #2 - Document describing DMARC improvements > to better support indirect mail flows. > - May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide >=20 > If you have comments on the milestones, please provide them by August > 25th. Have fun, >=20 > =3D- Tim >=20 >=20 > [1] http://datatracker.ietf.org/wg/dmarc/charter/ > [2] https://www.ietf.org/mailman/listinfo/dmarc > [3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki > [4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Aug 18 09:09:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7481A0699; Mon, 18 Aug 2014 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQSDKruCtLf8; Mon, 18 Aug 2014 09:09:24 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id BC5C91A0696; Mon, 18 Aug 2014 09:09:24 -0700 (PDT) Received: from [192.168.2.117] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 90CDDCB46; Mon, 18 Aug 2014 12:09:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: Date: Mon, 18 Aug 2014 12:09:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DDEC5AD-9116-4099-B0F0-E37F745AEE15@eudaemon.net> References: To: Mike Hammer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6B2qpVThaNF4GBsFtkNazOFcGxc Cc: "dmarc@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2014 16:09:26 -0000 On Aug 18, 2014, at 11:50 AM, MH Michael Hammer (5304) = wrote: > Is the DMARC Usage Guide the same as the BCP or is it a different = document? If it is a different document, is the BCP going to be one of = the milestones for the WG or is it off the table? They are one and the same. From nobody Mon Aug 18 14:02:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F621A6F7A; Mon, 18 Aug 2014 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jebLah1mrZ8C; Mon, 18 Aug 2014 14:02:32 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66B81A0194; Mon, 18 Aug 2014 14:02:31 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id pi18so5073754lab.23 for ; Mon, 18 Aug 2014 14:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2u6WH9jI8KasR00lmBZxIC/Ji/Dx47ITOuTDfRiLjFw=; b=TcTiQA/SFOwKU2HTlhdQ40u/+DkOlg5F1lcOHcQNefTkSUJE27REpzaaYt8QApdwAn dLk6M24XBg6cJzh5RFOHjGE8k/g6L2qgLCFgChU9UKuEjwomN9a1QUXW3OYOI8d+SyKU j3ZA5fUUEBKYwagZzyFAAjkgtLDXIhycKzGDBwoYtJNytpp95oAbWlzUzdLDRNfiY26H R0b4kTNTbae55xLEOb1GR1Ynd9CvIYptWsLogp9fs3MePejf/t3rbNETS9o7huXgHr5r AWWcQxo+EpfEXvRLYvQCGu1dPsfjXxbhsRqjJvs2apBw7pjIonlvwM9COS4s0+g1XYKy 7vOg== X-Received: by 10.152.3.199 with SMTP id e7mr32142090lae.35.1408395749963; Mon, 18 Aug 2014 14:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.29.166 with HTTP; Mon, 18 Aug 2014 14:02:09 -0700 (PDT) In-Reply-To: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> From: James M Snell Date: Mon, 18 Aug 2014 14:02:09 -0700 Message-ID: To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TCrGlGiwsecfw_zGIS-CmLaNEPQ Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Aug 2014 21:02:34 -0000 In the case of using Merge-Patch with the HTTP Patch method, "validation" would typically occur using the Conditional HTTP Request Mechanisms (ETags and If-Match/If-None-Match). These aren't fool proof, of course, but they provide a Good Enough approximation. If someone needed something more rigorous, they could layer it in. - James On Mon, Aug 18, 2014 at 1:58 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-appsawg-json-merge-patch-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The draft looks very good and the security considerations in RFC5789 > cover most of the bases I would be concerned with. I do have a question > I'd like to discuss to see if it applies or not. > > Normally, in other spaces patches are validated and that might be as > simple as making sure the hash of the patch provided by the source > matches the value you calculated (not corrupted, *should* be from the > source you think it's from). I don't see any mention of this practice, > is there a reason for that or should it be added? Maybe it's not > possible because of how the patch is delivered over HTTP, but I figured > it was worth flagging to discuss quickly. > > > > From nobody Tue Aug 19 21:44:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513251A6F97; Mon, 18 Aug 2014 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9aES8BpbEBl; Mon, 18 Aug 2014 13:58:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E141A070A; Mon, 18 Aug 2014 13:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 13:58:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QcJGsfj9u5OcmvMv6TYjn5z5268 X-Mailman-Approved-At: Tue, 19 Aug 2014 21:44:16 -0700 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:58:14 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-json-merge-patch-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The draft looks very good and the security considerations in RFC5789 cover most of the bases I would be concerned with. I do have a question I'd like to discuss to see if it applies or not. Normally, in other spaces patches are validated and that might be as simple as making sure the hash of the patch provided by the source matches the value you calculated (not corrupted, *should* be from the source you think it's from). I don't see any mention of this practice, is there a reason for that or should it be added? Maybe it's not possible because of how the patch is delivered over HTTP, but I figured it was worth flagging to discuss quickly. From nobody Tue Aug 19 23:04:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA901A87AB for ; Tue, 19 Aug 2014 23:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzYyJPpLnsyM for ; Tue, 19 Aug 2014 23:04:22 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AD61A87AE for ; Tue, 19 Aug 2014 23:04:21 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so6153320wiv.2 for ; Tue, 19 Aug 2014 23:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ervJjj6ZIdZRcIzmJE5o5GYAhZ+WEAB6Ff4hgczwWzQ=; b=HMMMqJtWChio6eWoDjlgKkreG6Hze9X1Y+Q9mI7uwiQDF7NjMIhLo266I0OcaGoFwy szy9AfV8G4F9Ll3S/2f8oKxbgPg07DoXCpbe+LgAhid5G/FzFTdYRuEhB0XH6Aj4urpF dnx3FoQEoO63IRMWVPoaE0V+5+QeV72cIT3L0NABP/nb5B+6ZONRf345gyU3YtTnDvaS ojuBBovR71KNJ/xOZb7if059LuNmHC1uqef5I2YhSYEtaCmx8M6Pvvwx2eZ+EoArEw4Q PnEK6CmJcIvLR9SBkFvxv8PxdZHvA8JVyk7DYU++adPHUeYQGA4ZCS5r2OzlyyM06swx MYLw== MIME-Version: 1.0 X-Received: by 10.181.5.39 with SMTP id cj7mr12458532wid.79.1408514660521; Tue, 19 Aug 2014 23:04:20 -0700 (PDT) Received: by 10.180.35.42 with HTTP; Tue, 19 Aug 2014 23:04:20 -0700 (PDT) Date: Tue, 19 Aug 2014 23:04:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134de48005d070501096060 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vrvhQRJOBbqB3-0fqSjWgwZxmFY Subject: [apps-discuss] Minutes from APPSAWG/APPAREA meeting at IETF 90 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 06:04:23 -0000 --001a1134de48005d070501096060 Content-Type: text/plain; charset=UTF-8 Colleagues, The minutes from our meeting at IETF 90 are now visible here: http://www.ietf.org/proceedings/90/minutes/minutes-90-appsawg Please provide any corrections prior to September 5th. After that they will be a permanent part of the proceedings. -MSK, APPSAWG co-chair --001a1134de48005d070501096060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The minutes from our meeting = at IETF 90 are now visible here:

http://www.ietf.org/proceedings/90/m= inutes/minutes-90-appsawg

Please provide any corrections prior to September 5th.=C2=A0 Afte= r that they will be a permanent part of the proceedings.

-MSK,= APPSAWG co-chair
--001a1134de48005d070501096060-- From nobody Wed Aug 20 09:06:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476F41A6F58 for ; Wed, 20 Aug 2014 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU2HIjHyVSfI for ; Wed, 20 Aug 2014 09:06:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD061A0AF3 for ; Wed, 20 Aug 2014 09:06:09 -0700 (PDT) Received: (qmail 17607 invoked from network); 20 Aug 2014 16:06:07 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Aug 2014 16:06:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16951.53f4c76b.k1408; i=johnl@user.iecc.com; bh=WzMsuGL00bHrYpqNc9Dbcif4QGaoh7rUhAEeVHg+wrA=; b=tjG7XcdUzAOMuGFUBCl6EAPhYjNVbdZfz3i2nqIrAFl1SMYuIzGwinsH5DrLF4GlE6r2WT1wIjDHiDUOmtSAM5AohqRSWQLXugNVnvwXGfxAwvNsbuWL1diNHDwOcQ1S9Lvx6YHgOP4OZeq2YleTCb2UTR55OElsBP3N97wGmhhooRBhRS+9E0p/MwUgzH88vSdqpnf9zl+BjrDr8Rd5PVnuRBVBkB6I/sJgdIMpowNLKyV3owVwEIxZxmxBfeim DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16951.53f4c76b.k1408; olt=johnl@user.iecc.com; bh=WzMsuGL00bHrYpqNc9Dbcif4QGaoh7rUhAEeVHg+wrA=; b=goHoVaV23+3xxZEuqg6ZLChrI48p7Jh5teex0qrzhblKHXqawBUZHbocvrnkzLPymF1aNupnLdAQ018aW/WwLQBCeSkbC7Klx2hj+RZE6CeAuGywd1SZ++P8XGo1P7+iQVJFTu+ZVQ2wmGH8AAq9xX+3j50RRXGxs4fLP0aw63qTLu/vHApmWZkalBRICVydLDNL1S1vGDnepWvpl14zu85+iJLKmCB2M9keu+7Vt/PtVZeQp9BOwsEqBLLY6w6L Date: 20 Aug 2014 16:05:41 -0000 Message-ID: <20140820160541.92496.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nmEokB9pX-6r7CZJvxx84av8150 Subject: Re: [apps-discuss] Minutes from APPSAWG/APPAREA meeting at IETF 90 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 16:06:12 -0000 >Please provide any corrections prior to September 5th. After that they >will be a permanent part of the proceedings. I think I said "refreshingly quaint" rather than "quaint". I only care because I think that makes it clearer that I think safe-hint is a good idea. R's from the fabulous Jersey Shore, John From nobody Wed Aug 20 10:19:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CB91A048F; Wed, 20 Aug 2014 10:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRx76PvJ7I2e; Wed, 20 Aug 2014 10:19:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E74CA1A0029; Wed, 20 Aug 2014 10:19:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 10:19:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Gug1MzU6eGd1W36DdVdbKGTZuMk Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 17:19:05 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-json-merge-patch-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am certainly willing to be talked out of this, but I am concerned about the implementability and would like to DISCUSS it a bit. In section 2: To apply the merge patch document to a target resource, the system realizes the effect of the following function, described in pseudocode. For this description, the function is called MergePatch, and it takes two arguments: the target resource document and the merge patch document. The Target argument can be any JSON value, or undefined. The Patch argument can be any JSON value. It took me repeated reading of the pseudocode (and may I mention that I *hate* languages which rely on indentation ;-) ) to figure out that: - If the Patch if not an object, the result *is* the Patch - The Patch can't act on the internals of an array; it can only replace the whole thing - The Patch cannot replace objects with new objects. Can't we *please* have a textual description of this protocol in addition to a (recursive!) pseudocode function? I am not convinced that an implementer will get their implementation right just from the pseudocode. From nobody Wed Aug 20 13:23:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85BA1A6FB5 for ; Wed, 20 Aug 2014 13:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKrRMv1xXdUr for ; Wed, 20 Aug 2014 13:23:05 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CAC1A0AE9 for ; Wed, 20 Aug 2014 13:23:02 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id wp4so6790225obc.1 for ; Wed, 20 Aug 2014 13:23:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RDHLQzeL7w3MbYmPTgVh17mkBc1FPuvCXkN7Ldv9sBc=; b=B83v5ztzE1JWakrglbAtFesZ3sQKuod72d+5NbolZJIwmv6N46PIHBiQJxhChLgPM0 4T2p2aipEhoMmzQ70Rk+Kk3B/9nUyt9UmOfcXxNNwjjO2/2d+rdphSLwJ9TRwWpSpGtH HhSkR+i9K7NfkxRE6q79iGXLGxLbk/Fal5q00L1Zg5+ZuAemGSIgt2sTnF5kVXp+lQy0 F7m2jtaD/bHcAyj35RhPJHsDNv+nDCicvhV4/3vjD1ul42+V4l1btSSyJGYQLszCiKDg 0UZTD87gpLsr+hiSIJCAP79wrC4HB3JLH+Wmt3BGJBGV4OVLs22yt3KqgwHhgdK6pHmc gU5w== X-Gm-Message-State: ALoCoQmHoKoI4wqlg1gV3BOCWN9XtXWXhNoidOdnMfPBndYijjXwuA/9Fkh68fM1RmMax4Vx33oh MIME-Version: 1.0 X-Received: by 10.60.162.71 with SMTP id xy7mr50776122oeb.33.1408566181556; Wed, 20 Aug 2014 13:23:01 -0700 (PDT) Received: by 10.76.106.207 with HTTP; Wed, 20 Aug 2014 13:23:01 -0700 (PDT) In-Reply-To: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 16:23:01 -0400 Message-ID: From: Richard Barnes To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b33c6eae5f09f0501155e8d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eH_qKd7L_elVj3FlDsmIC7GAAUU Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 20:23:07 -0000 --047d7b33c6eae5f09f0501155e8d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 1:19 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-json-merge-patch-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am certainly willing to be talked out of this, but I am concerned about > the implementability and would like to DISCUSS it a bit. > > In section 2: > > To apply the merge patch document to a target resource, the system > realizes the effect of the following function, described in > pseudocode. For this description, the function is called MergePatch, > and it takes two arguments: the target resource document and the > merge patch document. The Target argument can be any JSON value, or > undefined. The Patch argument can be any JSON value. > > It took me repeated reading of the pseudocode (and may I mention that I > *hate* languages which rely on indentation ;-) ) to figure out that: > > - If the Patch if not an object, the result *is* the Patch > - The Patch can't act on the internals of an array; it can only replace > the whole thing > - The Patch cannot replace objects with new objects. > > Can't we *please* have a textual description of this protocol in addition > to a (recursive!) pseudocode function? I am not convinced that an > implementer will get their implementation right just from the pseudocode I don't really understand the confusion here. This algorithm encodes exactly what I surmised from looking at the example in the introduction, and it was implementable in ~10min in python with only a very difference between code and pseudocode (to deal with the case where Target[Name] is undefined). http://pastebin.mozilla.org/6073129 The textual description would probably be less clear, and would still be recursive! --047d7b33c6eae5f09f0501155e8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 20, 2014 at 1:19 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
Pete Resnick has entered = the following ballot position for
draft-ietf-appsawg-json-merge-patch-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-= json-merge-patch/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am certainly willing to be talked out of this, but I am concerned about the implementability and would like to DISCUSS it a bit.

In section 2:

=C2=A0 =C2=A0To apply the merge patch document to a target resource, the sy= stem
=C2=A0 =C2=A0realizes the effect of the following function, described in =C2=A0 =C2=A0pseudocode.=C2=A0 For this description, the function is called= MergePatch,
=C2=A0 =C2=A0and it takes two arguments: the target resource document and t= he
=C2=A0 =C2=A0merge patch document.=C2=A0 The Target argument can be any JSO= N value, or
=C2=A0 =C2=A0undefined.=C2=A0 The Patch argument can be any JSON value.

It took me repeated reading of the pseudocode (and may I mention that I
*hate* languages which rely on indentation ;-) ) to figure out that:

- If the Patch if not an object, the result *is* the Patch
- The Patch can't act on the internals of an array; it can only replace=
the whole thing
- The Patch cannot replace objects with new objects.

Can't we *please* have a textual description of this protocol in additi= on
to a (recursive!) pseudocode function? I am not convinced that an
implementer will get their implementation right just from the pseudocode

I don't really understand the confusion h= ere.=C2=A0 This algorithm encodes exactly what I surmised from looking at t= he example in the introduction, and it was implementable in ~10min in pytho= n with only a very difference between code and pseudocode (to deal with the= case where Target[Name] is undefined).

http://pastebin.mozilla= .org/6073129

The textual description would probably b= e less clear, and would still be recursive!
--047d7b33c6eae5f09f0501155e8d-- From nobody Wed Aug 20 13:39:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF29A1A0ADE; Wed, 20 Aug 2014 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp4TU1ryRmtC; Wed, 20 Aug 2014 13:39:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4501A06FB; Wed, 20 Aug 2014 13:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408567145; x=1440103145; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s3jEfQfNYPbbeNmMApTFnkWzWf1AiaxO3hbDbGix+3k=; b=VmighQERpK+uAR2Yn5Fa6KBncRg9iDajuZLo7xjISORw3ZJazY5WnOBW 6dbSl1RPn46QSnaps57+3LoLeXo2/1j0cx8LgP3uCGQQB1hTjhGI+E/8A Zn2wBDR17DA2ksZCIUWF9JIDFR1mmC8nIv+y/tSnSh/rbi4PJ5gSalByF 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59384798" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2014 13:39:04 -0700 X-IronPort-AV: E=Sophos;i="5.01,904,1400050800"; d="scan'208";a="720733598" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 13:39:04 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 13:39:04 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 13:39:03 -0700 Message-ID: <53F50765.2080709@qti.qualcomm.com> Date: Wed, 20 Aug 2014 15:39:01 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Richard Barnes References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0ZraqoaxeE5X_7swWktunAHfdjk Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 20:39:06 -0000 On 8/20/14 3:23 PM, Richard Barnes wrote: > I don't really understand the confusion here. This algorithm encodes > exactly what I surmised from looking at the example in the > introduction, and it was implementable in ~10min in python with only a > very difference between code and pseudocode (to deal with the case > where Target[Name] is undefined). > > http://pastebin.mozilla.org/6073129 > > The textual description would probably be less clear, and would still > be recursive! I would have been much more impressed if you had said, "It was implementable in ~10min is C without using recursion at all". I'd also of course love to see some edge case examples (like a Patch being other than an object, or a Patch containing some nulls in an array) that actually debugged as opposed to repeating the obvious example from the document. And of course that's my concern: Because there is no textual description, I can't tell if anything that I might implement that is structured differently from the pseudocode provided would in fact be equivalent except by doing a debug analysis of the psuedocode and my code. That's the difference between doing open source and writing a standard. And I'll repeat, I could be talked out of it. But if I had to implement this in C without recursion, I'd be a grumpy implementer. Of course, I'm old and grumpy to begin with. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Aug 20 13:54:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF301A8768 for ; Wed, 20 Aug 2014 13:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQXI2xOFvnwM for ; Wed, 20 Aug 2014 13:54:11 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C9B1A876D for ; Wed, 20 Aug 2014 13:54:09 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so6084370oif.2 for ; Wed, 20 Aug 2014 13:54:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AduCn/+m/hnHZOSISdtB+g21yEM3jxi3MjnpZ7uos1E=; b=X32+AoePc3tzvQsmjLJYhnRo89vnct0jh6PFyTuwiv+cwhkrx9jRLdPkIlMig3lp8f KtUjuv98xM2/yiJwoYKm0EqAlx++dv1h2Tvkh+EMCQnvjH2RNNKryxSe2muaoIaPyNz7 sR5qRtth+4KKXMDR8XKC+vhgO7kdXJsdso+IOSAs7Q61w5eVonpzBKCvuq9CwrSL+z9G w/DZSQgY2Qx+TdkLblnDt0L5pP2MkrtCqMl1rRJa7rqoI0VYT6ti7dwjZhWikEBDqvm6 KLb7nvABv9wufZ3R7oSuCZeN1hmTmTwYws3sWrBUqNdBsJ+4cyEi2BWMNItwC3MMAOcL zdcw== X-Gm-Message-State: ALoCoQmr/FJ5F2jObAr0T8RlfnnQqcD9njrR+5AkVtYKCD/qiSuXIluJlUc1PlcHGlsxWzAXct6M MIME-Version: 1.0 X-Received: by 10.60.60.167 with SMTP id i7mr52296838oer.41.1408568048728; Wed, 20 Aug 2014 13:54:08 -0700 (PDT) Received: by 10.76.106.207 with HTTP; Wed, 20 Aug 2014 13:54:08 -0700 (PDT) In-Reply-To: <53F50765.2080709@qti.qualcomm.com> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> Date: Wed, 20 Aug 2014 16:54:08 -0400 Message-ID: From: Richard Barnes To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0158bab43053bc050115ce94 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Bq_IQCTEKeg2TNNGf5AcKf_avyE Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 20:54:15 -0000 --089e0158bab43053bc050115ce94 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 4:39 PM, Pete Resnick wrote: > On 8/20/14 3:23 PM, Richard Barnes wrote: > >> I don't really understand the confusion here. This algorithm encodes >> exactly what I surmised from looking at the example in the introduction, >> and it was implementable in ~10min in python with only a very difference >> between code and pseudocode (to deal with the case where Target[Name] is >> undefined). >> >> http://pastebin.mozilla.org/6073129 >> >> The textual description would probably be less clear, and would still be >> recursive! >> > > I would have been much more impressed if you had said, "It was > implementable in ~10min is C without using recursion at all". > As someone whose day job involves writing C, that's a ridiculous standard for anything that doesn't require bit-accuracy. Likewise no recursion -- the state is going to have to get stored somewhere, might as well be the stack. I'd also of course love to see some edge case examples (like a Patch being > other than an object, or a Patch containing some nulls in an array) that > actually debugged as opposed to repeating the obvious example from the > document. > That's a fine suggestion, but not DISCUSS-worthy. > And of course that's my concern: Because there is no textual description, > I can't tell if anything that I might implement that is structured > differently from the pseudocode provided would in fact be equivalent except > by doing a debug analysis of the psuedocode and my code. That's the > difference between doing open source and writing a standard. > Textual descriptions are just algorithms in natural language. > And I'll repeat, I could be talked out of it. But if I had to implement > this in C without recursion, I'd be a grumpy implementer. Of course, I'm > old and grumpy to begin with. > Honestly, if you're using JSON in C, you're probably a grumpy implementor. C is not built to handle dynamic data structures like JSON hands you. --Richard > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --089e0158bab43053bc050115ce94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 20, 2014 at 4:39 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
On 8/20/14 3:23 PM, Richard = Barnes wrote:
I don't really understand the confusion here.=C2=A0 This algorithm enco= des exactly what I surmised from looking at the example in the introduction= , and it was implementable in ~10min in python with only a very difference = between code and pseudocode (to deal with the case where Target[Name] is un= defined).

http://pa= stebin.mozilla.org/6073129

The textual description would probably be less clear, and would still be re= cursive!

I would have been much more impressed if you had said, "It was impleme= ntable in ~10min is C without using recursion at all".

As someone whose day job involves writing C, that'= s a ridiculous standard for anything that doesn't require bit-accuracy.=

Likewise no recursion -- the state is going to have to get stored somew= here, might as well be the stack.
=C2=A0

I'd also of course love to see some edge case examples (like a Patch be= ing other than an object, or a Patch containing some nulls in an array) tha= t actually debugged as opposed to repeating the obvious example from the do= cument.

That's a fine suggestion, but not DISC= USS-worthy.

=C2=A0
And of course that's my concern: Because there is no textual descriptio= n, I can't tell if anything that I might implement that is structured d= ifferently from the pseudocode provided would in fact be equivalent except = by doing a debug analysis of the psuedocode and my code. That's the dif= ference between doing open source and writing a standard.

Textual descriptions are just algorithms i= n natural language.
=C2=A0


Honestly, if you're usin= g JSON in C, you're probably a grumpy implementor.=C2=A0 C is not built= to handle dynamic data structures like JSON hands you.

<= /div>
--Richard

=C2=A0

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


--089e0158bab43053bc050115ce94-- From nobody Wed Aug 20 14:21:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629FD1A2119; Wed, 20 Aug 2014 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9jYBMQqWgxm; Wed, 20 Aug 2014 14:21:08 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C7B1A0B7B; Wed, 20 Aug 2014 14:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408569668; x=1440105668; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZfEnw6yK7zBsXGf4gNtzakmIMeUou+YAkobpq9BXvCg=; b=O/i6bM02NfWiUV/z2KUgECL/+GEAqtSa5y/lJ4kDYsbub0ymYTej8DsE Q3I33w+UthGudXlOB7FlBJdW7GwHgP2kXZqkpVkqthDcu+5aV8JMQS5Nb HHXftW5WeyMpIYAN7DBi9SGr6h0FKaWHzVHIn2LVur2uNrES2RTxr0kTw Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="73207665" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 20 Aug 2014 14:21:08 -0700 X-IronPort-AV: E=Sophos;i="5.01,904,1400050800"; d="scan'208,217";a="720757176" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 14:21:07 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (10.46.56.181) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:21:07 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:21:06 -0700 Message-ID: <53F51141.6070408@qti.qualcomm.com> Date: Wed, 20 Aug 2014 16:21:05 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Richard Barnes References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040501010304060401080900" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nJKck98x91HK4mRYdH8e_1jQr8s Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 21:21:11 -0000 --------------040501010304060401080900 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/20/14 3:54 PM, Richard Barnes wrote: > On Wed, Aug 20, 2014 at 4:39 PM, Pete Resnick > > wrote: > > I would have been much more impressed if you had said, "It was > implementable in ~10min is C without using recursion at all". > > > As someone whose day job involves writing C, that's a ridiculous > standard for anything that doesn't require bit-accuracy. > > Likewise no recursion -- the state is going to have to get stored > somewhere, might as well be the stack. > > I'd also of course love to see some edge case examples (like a > Patch being other than an object, or a Patch containing some nulls > in an array) that actually debugged as opposed to repeating the > obvious example from the document. > > > That's a fine suggestion, but not DISCUSS-worthy. None of the above is part of the DISCUSSion. I was simply saying that a python version that perfectly mirrors the pseudocode is not going to convince me that the pseudocode is sufficient for independent implementations. Even if you had provided some non-recursive C that purportedly did the same thing, I'm not sure that would convince me that a textual description is unnecessary. Like I said, it took me quite a while looking at the pseudocode to figure out what the edge cases were. I'm *pretty sure* I could code it up in C at this point, but I'm not positive, because I'm not sure I've gotten all of the semantics right. > > And of course that's my concern: Because there is no textual > description, I can't tell if anything that I might implement that > is structured differently from the pseudocode provided would in > fact be equivalent except by doing a debug analysis of the > psuedocode and my code. That's the difference between doing open > source and writing a standard. > > > Textual descriptions are just algorithms in natural language. No, they are most certainly not. Textual descriptions provide semantics to the operations. Unlike algorithms, textual descriptions can give you the edge cases, can tell you what happens in all sorts of weird error conditions, etc., and all without having to give you the full algorithm. To take an example from one of the -core documents on this week's call: The sequence number selected for a notification MUST be greater than that of any preceding notification sent to the same client with the same token for the same resource. Yes, that surely implies parts of an algorithm, but it doesn't require that the code, e.g., check for a client identifier or a token and compare it to some table of previously sent notifications. It simply means that, however you code it, you satisfy the requirement. > > And I'll repeat, I could be talked out of it. But if I had to > implement this in C without recursion, I'd be a grumpy > implementer. Of course, I'm old and grumpy to begin with. > > > Honestly, if you're using JSON in C, you're probably a grumpy > implementor. C is not built to handle dynamic data structures like > JSON hands you. Well, that might be true. I can think of all sorts of interesting ways to do a JSON implementation in C. (I've parsed some pretty weird crap in C in my day.) But really, this misses the point of my concern: As an implementer, it seems to me that I'm having to figure out the semantics of the algorithm in order to be sure I've gotten it right. Maybe my brain is soft today because of all of this reading, but it wasn't obvious to me that the pseudocode was so simple that anyone would be able to successfully do that. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040501010304060401080900 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/20/14 3:54 PM, Richard Barnes wrote:
On Wed, Aug 20, 2014 at 4:39 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

I would have been much more impressed if you had said, "It was implementable in ~10min is C without using recursion at all".

As someone whose day job involves writing C, that's a ridiculous standard for anything that doesn't require bit-accuracy.

Likewise no recursion -- the state is going to have to get stored somewhere, might as well be the stack.
 
I'd also of course love to see some edge case examples (like a Patch being other than an object, or a Patch containing some nulls in an array) that actually debugged as opposed to repeating the obvious example from the document.

That's a fine suggestion, but not DISCUSS-worthy.

None of the above is part of the DISCUSSion. I was simply saying that a python version that perfectly mirrors the pseudocode is not going to convince me that the pseudocode is sufficient for independent implementations.

Even if you had provided some non-recursive C that purportedly did the same thing, I'm not sure that would convince me that a textual description is unnecessary. Like I said, it took me quite a while looking at the pseudocode to figure out what the edge cases were. I'm *pretty sure* I could code it up in C at this point, but I'm not positive, because I'm not sure I've gotten all of the semantics right.
 
And of course that's my concern: Because there is no textual description, I can't tell if anything that I might implement that is structured differently from the pseudocode provided would in fact be equivalent except by doing a debug analysis of the psuedocode and my code. That's the difference between doing open source and writing a standard.

Textual descriptions are just algorithms in natural language.

No, they are most certainly not. Textual descriptions provide semantics to the operations. Unlike algorithms, textual descriptions can give you the edge cases, can tell you what happens in all sorts of weird error conditions, etc., and all without having to give you the full algorithm. To take an example from one of the -core documents on this week's call:

   The sequence number selected for a notification MUST be greater than
   that of any preceding notification sent to the same client with the
   same token for the same resource.

Yes, that surely implies parts of an algorithm, but it doesn't require that the code, e.g., check for a client identifier or a token and compare it to some table of previously sent notifications. It simply means that, however you code it, you satisfy the requirement.
 
And I'll repeat, I could be talked out of it. But if I had to implement this in C without recursion, I'd be a grumpy implementer. Of course, I'm old and grumpy to begin with.

Honestly, if you're using JSON in C, you're probably a grumpy implementor.  C is not built to handle dynamic data structures like JSON hands you.

Well, that might be true. I can think of all sorts of interesting ways to do a JSON implementation in C. (I've parsed some pretty weird crap in C in my day.) But really, this misses the point of my concern: As an implementer, it seems to me that I'm having to figure out the semantics of the algorithm in order to be sure I've gotten it right. Maybe my brain is soft today because of all of this reading, but it wasn't obvious to me that the pseudocode was so simple that anyone would be able to successfully do that.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040501010304060401080900-- From nobody Wed Aug 20 14:29:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA45F1A87CD for ; Wed, 20 Aug 2014 14:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5Rt_4sywWUa for ; Wed, 20 Aug 2014 14:29:39 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283DB1A87BC for ; Wed, 20 Aug 2014 14:29:39 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id eb12so6875523oac.3 for ; Wed, 20 Aug 2014 14:29:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rJ7gEt8biW7FsvLcn9ej3Lv9mlsIAAHl2gEvao69WIo=; b=SpXCJMiRomRpxkRDhmpxTUsSrrgqoAecE4hvORQ+Rkmx8nQI7aDeu/Vz6yxU3Hhbld AHNJDHCd6Bqs7nOLemvQZd+K8lYmvxWV2HB38Rv1FFxbhNSjej321qfPVo+yDBeKVROc p6Z6rmJ6qotXDGbw0XrKKiIhrNDOp56R3m7AWkYJhIkt9qPcy+07Mm3nEYQf9fXqYPZV kNfak9NCMCAkm8x2+jxv8jCX+swWsEEN95dilSmh/h/Yv4loG60d5LDkDIoiGfiwgjAZ G+Rs/Jiv3+p3lTs34UtB8RKotwORLznkki7tWDKje8AtkJDM6ievKg4Xk4aUgDS2XUbT q18g== X-Gm-Message-State: ALoCoQllzI9Y1qU/AqvPt2/oJ+Rq94H6tVI5gh+xRBI7Hdo2yNSDgb3TUNHVVBfJIFkbO7uM7Ndr MIME-Version: 1.0 X-Received: by 10.182.240.230 with SMTP id wd6mr2897039obc.87.1408570178494; Wed, 20 Aug 2014 14:29:38 -0700 (PDT) Received: by 10.76.106.207 with HTTP; Wed, 20 Aug 2014 14:29:38 -0700 (PDT) In-Reply-To: <53F51141.6070408@qti.qualcomm.com> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> <53F51141.6070408@qti.qualcomm.com> Date: Wed, 20 Aug 2014 17:29:38 -0400 Message-ID: From: Richard Barnes To: Pete Resnick Content-Type: multipart/alternative; boundary=089e01634d7421b2db0501164dd5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6ND9ktuHhAT4g5HIn2OCT_eXV0o Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 21:29:45 -0000 --089e01634d7421b2db0501164dd5 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 5:21 PM, Pete Resnick wrote: > On 8/20/14 3:54 PM, Richard Barnes wrote: > > On Wed, Aug 20, 2014 at 4:39 PM, Pete Resnick > wrote: > > I would have been much more impressed if you had said, "It was >> implementable in ~10min is C without using recursion at all". >> > > As someone whose day job involves writing C, that's a ridiculous > standard for anything that doesn't require bit-accuracy. > > Likewise no recursion -- the state is going to have to get stored > somewhere, might as well be the stack. > > >> I'd also of course love to see some edge case examples (like a Patch >> being other than an object, or a Patch containing some nulls in an array) >> that actually debugged as opposed to repeating the obvious example from the >> document. >> > > That's a fine suggestion, but not DISCUSS-worthy. > > > None of the above is part of the DISCUSSion. I was simply saying that a > python version that perfectly mirrors the pseudocode is not going to > convince me that the pseudocode is sufficient for independent > implementations. > > Even if you had provided some non-recursive C that purportedly did the > same thing, I'm not sure that would convince me that a textual description > is unnecessary. Like I said, it took me quite a while looking at the > pseudocode to figure out what the edge cases were. I'm *pretty sure* I > could code it up in C at this point, but I'm not positive, because I'm not > sure I've gotten all of the semantics right. > > > > And of course that's my concern: Because there is no textual >> description, I can't tell if anything that I might implement that is >> structured differently from the pseudocode provided would in fact be >> equivalent except by doing a debug analysis of the psuedocode and my code. >> That's the difference between doing open source and writing a standard. >> > > Textual descriptions are just algorithms in natural language. > > > No, they are most certainly not. Textual descriptions provide semantics to > the operations. Unlike algorithms, textual descriptions can give you the > edge cases, can tell you what happens in all sorts of weird error > conditions, etc., and all without having to give you the full algorithm. To > take an example from one of the -core documents on this week's call: > > The sequence number selected for a notification MUST be greater than > that of any preceding notification sent to the same client with the > same token for the same resource. > > Yes, that surely implies parts of an algorithm, but it doesn't require > that the code, e.g., check for a client identifier or a token and compare > it to some table of previously sent notifications. It simply means that, > however you code it, you satisfy the requirement. > It sounds like you're looking for some abstracted, "here's what the algorithm must accomplish" definition. The CORE case is simple enough that that works. In this case, the objective is complex enough that I don't see how you get there without defining an algorithm. (Keep in mind that JSON itself is recursive, so to some degree, if you don't recurse, you're doing it wrong!) Could you suggest text? --Richard > > > > And I'll repeat, I could be talked out of it. But if I had to implement >> this in C without recursion, I'd be a grumpy implementer. Of course, I'm >> old and grumpy to begin with. >> > > Honestly, if you're using JSON in C, you're probably a grumpy > implementor. C is not built to handle dynamic data structures like JSON > hands you. > > > Well, that might be true. I can think of all sorts of interesting ways to > do a JSON implementation in C. (I've parsed some pretty weird crap in C in > my day.) But really, this misses the point of my concern: As an > implementer, it seems to me that I'm having to figure out the semantics of > the algorithm in order to be sure I've gotten it right. Maybe my brain is > soft today because of all of this reading, but it wasn't obvious to me that > the pseudocode was so simple that anyone would be able to successfully do > that. > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --089e01634d7421b2db0501164dd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 20, 2014 at 5:21 PM, Pete Resnick <= ;presnick@qt= i.qualcomm.com> wrote:
=20
On 8/20/14 3:54 PM, Richard Barnes wrote:
On Wed, Aug 20, 2014 at 4:39 PM, Pete Re= snick <presnick@qti.qualcomm.com> wrote:

I would have been much more impressed if you had said, "It was implementable in ~10min is C without using recursion at all".

As someone whose day job involves writing C, that's a ridiculous standard for anything that doesn't require bit-accuracy.

Likewise no recursion -- the state is going to have to get stored somewhere, might as well be the stack.
=C2=A0
I'd also of course love to see some edge case examples (like a Patch being other than an object, or a Patch containing some nulls in an array) that actually debugged as opposed to repeating the obvious example from the document.

That's a fine suggestion, but not DISCUSS-worthy.

None of the above is part of the DISCUSSion. I was simply saying that a python version that perfectly mirrors the pseudocode is not going to convince me that the pseudocode is sufficient for independent implementations.

Even if you had provided some non-recursive C that purportedly did the same thing, I'm not sure that would convince me that a textual description is unnecessary. Like I said, it took me quite a while looking at the pseudocode to figure out what the edge cases were. I'm *pretty sure* I could code it up in C at this point, but I'm not positive, because I'm not sure I've gotten all of the semantics rig= ht.

=C2=A0
And of course that's my concern: Because there is no textual description, I can't tell if anything that I might implement that is structured differently from the pseudocode provided would in fact be equivalent except by doing a debug analysis of the psuedocode and my code. That's the difference between doing open source and writing a standard.

Textual descriptions are just algorithms in natural language.

No, they are most certainly not. Textual descriptions provide semantics to the operations. Unlike algorithms, textual descriptions can give you the edge cases, can tell you what happens in all sorts of weird error conditions, etc., and all without having to give you the full algorithm. To take an example from one of the -core documents on this week's call:

=C2=A0=C2=A0 The sequence number selected for a notification MUST be greate= r than
=C2=A0=C2=A0 that of any preceding notification sent to the same client wit= h the
=C2=A0=C2=A0 same token for the same resource.

Yes, that surely implies parts of an algorithm, but it doesn't require that the code, e.g., check for a client identifier or a token and compare it to some table of previously sent notifications. It simply means that, however you code it, you satisfy the requirement.

It sounds like you're looking= for some abstracted, "here's what the algorithm must accomplish&q= uot; definition.=C2=A0 The CORE case is simple enough that that works.=C2= =A0 In this case, the objective is complex enough that I don't see how = you get there without defining an algorithm.=C2=A0 (Keep in mind that JSON = itself is recursive, so to some degree, if you don't recurse, you'r= e doing it wrong!)

Could you suggest text?=C2=A0
--Richard

=C2=A0

=C2=A0
And I'll repeat, I could be talked out of it. But if I had to implement this in C without recursion, I'd be a grumpy implementer. Of course, I'm old and grumpy to begin with.

Honestly, if you're using JSON in C, you're probably a grump= y implementor.=C2=A0 C is not built to handle dynamic data structures like JSON hands you.

Well, that might be true. I can think of all sorts of interesting ways to do a JSON implementation in C. (I've parsed some pretty weird crap in C in my day.) But really, this misses the point of my concern: As an implementer, it seems to me that I'm having to figure out the semantics of the algorithm in order to be sure I've gotten it right. Maybe my brain is soft today because of all of this reading, but it wasn't obvious to me that the pseudocode was so simple that anyone would be able to successfully do that.


pr
--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--089e01634d7421b2db0501164dd5-- From nobody Wed Aug 20 14:41:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DB11A87E0; Wed, 20 Aug 2014 14:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQKHait2dsup; Wed, 20 Aug 2014 14:41:46 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 831F11A87D1; Wed, 20 Aug 2014 14:41:46 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 340042007F128; Wed, 20 Aug 2014 14:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZVRepNMAX5vP7pVf74bP iNcozEA=; b=GPAOQaydoGoMP19yqk60WEwHcZ3hsKdImEny+6/tVzL+67ZHbUFD EVVQnR6LskyzN+tGbcInQjD+TSOZX6aQYk1QctBKKT/bUyO5gXSbgK1UcaJbUqNA 4VOmPtqMnCwMLf4k0Q/GakfVKbsp5a5pXCjlxcpIXgc9HrNH25AJ530= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id B1C872007F125; Wed, 20 Aug 2014 14:41:45 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so7567833wiw.12 for ; Wed, 20 Aug 2014 14:41:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr51866302wjq.36.1408570904365; Wed, 20 Aug 2014 14:41:44 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 20 Aug 2014 14:41:44 -0700 (PDT) In-Reply-To: <53F50765.2080709@qti.qualcomm.com> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> Date: Wed, 20 Aug 2014 16:41:44 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/h-ubnruXya_iZx0dZqyaqKkDDi0 Cc: Richard Barnes , draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 21:41:47 -0000 FYI, in jq, this can be implemented as follows (assuming $doc is bound to the document to be edited and $patch is bound to the patch): def apply_patch(patch): . as $doc | patch as $patch | $patch | reduce (path(recurse(.[]?; true))?) as $path ($doc; ($patch | getpath($path)) as $value | if $value == null then delpaths([$path]) elif $value | type | . == "number" or . == "string" or . == "boolean" then setpath($path; $value) else . end); This applies the patches output by the `patch` closure to the input. It recurses for traversing paths in the $patch. In English this says "for each path in the patch, if the value at that path in the patch is null then delete the same path from the document, else if the value at that path in the patch is a scalar then set the same path in the document to that scalar, else leave the document as-is". Nico -- Nico -- From nobody Wed Aug 20 15:15:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB21A893A for ; Wed, 20 Aug 2014 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usk_Ga-_5ihp for ; Wed, 20 Aug 2014 15:15:15 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA04F1A8935 for ; Wed, 20 Aug 2014 15:15:15 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 628735405B for ; Wed, 20 Aug 2014 15:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QYEF5TEnhxVrnBsXe2GA x/pMPnE=; b=tIP2+5ZHrHMM5af9ezTcg30YYG3fcUUwRjmjHlFFWN/Y1etJJqST vJxL8btrUKI01E5tZIB02D8QGk1OInjKRTy1nBvCPouJCi7s6bJ96Ci//i/qL/UI rf3nw83H3w3Wzcp+ifTaqjrYFDBYo7OCItmWi3iK7T8KxNWffGuoc9I= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 1231354058 for ; Wed, 20 Aug 2014 15:15:14 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so8412996wgh.14 for ; Wed, 20 Aug 2014 15:15:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr52049389wjq.36.1408572913712; Wed, 20 Aug 2014 15:15:13 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 20 Aug 2014 15:15:13 -0700 (PDT) In-Reply-To: References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> Date: Wed, 20 Aug 2014 17:15:13 -0500 Message-ID: From: Nico Williams To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vM6_Es7ZWnQyLpzInHgylK7kuPg Cc: Pete Resnick , draft-ietf-appsawg-json-merge-patch@tools.ietf.org, Apps Discuss Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 22:15:16 -0000 On Wed, Aug 20, 2014 at 3:54 PM, Richard Barnes wrote: > Honestly, if you're using JSON in C, you're probably a grumpy implementor. > C is not built to handle dynamic data structures like JSON hands you. Well, if you're using libjq, you're probably not too grumpy. It's notionally a copy-on-write API, so one writes code like: obj = jv_object_set(obj, jv_string("foo"), ...); Memory management is easier than with non-COW JSON C libraries I've used. Anyways, I'm making noise... But I hope it helps someone. You can find libjq at https://github.com/stedolan/jq . Nico -- From nobody Wed Aug 20 15:20:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824601A894C; Wed, 20 Aug 2014 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKpV5ebSagmT; Wed, 20 Aug 2014 15:20:40 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 86B181A8A4B; Wed, 20 Aug 2014 15:20:39 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 66005264060; Wed, 20 Aug 2014 15:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0M6PP4iUb/yW5WjRJ7Os FJa3C2g=; b=bMukV+LyyZ/S2S+UP90iVU+Wklfw6O2YdXJhF+H3WKoaqUcBgzGL Ln10jMo0ArB745D7xiMtug9Odwc6PPhIbaP2j8WmMbIyh8kjaKAbk/HN/26X6ucw loWfWkOTNXnhx/XztmDiReKaJ5h9YEu2318CWggS0IDwrjpBVpoew2I= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id E30FA264059; Wed, 20 Aug 2014 15:20:38 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so7302524wiw.3 for ; Wed, 20 Aug 2014 15:20:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.203 with SMTP id e11mr289839wiw.28.1408573237865; Wed, 20 Aug 2014 15:20:37 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 20 Aug 2014 15:20:37 -0700 (PDT) In-Reply-To: References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> <53F51141.6070408@qti.qualcomm.com> Date: Wed, 20 Aug 2014 17:20:37 -0500 Message-ID: From: Nico Williams To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DLhPIqpkHhdS7nTVQ7XExGTqki8 Cc: Apps Discuss , Pete Resnick , draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 22:20:40 -0000 On Wed, Aug 20, 2014 at 4:29 PM, Richard Barnes wrote: > [...]. (Keep in mind that JSON > itself is recursive, so to some degree, if you don't recurse, you're doing > it wrong!) Path traversal in a tree requires a stack, which is really what Pete R. must have meant, since tail-recursion is equivalent to looping, and non-tail-recursion is equivalent to a loop that keeps state in a stack -- it's the stack that must be a sticking point, and if it is it's the need to traverse the tree that is the cause of it. A path-based patch doesn't require a stack. Sometimes a path-based patch is easier to use than this scheme, sometimes it's the reverse. Partly it depends on what you have to work with on the client side. Nico -- From nobody Wed Aug 20 15:40:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB21A006A; Wed, 20 Aug 2014 15:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuvAiH8BrC1c; Wed, 20 Aug 2014 15:40:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1665A1A894B; Wed, 20 Aug 2014 15:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820224003.17644.2418.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 15:40:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HxFqKap6WvBwmb07xr9DTsAPTqE Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-json-merge-patch-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:40:16 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-json-merge-patch-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I didn't get why if Patch is not an object then MergePatch(foo, Patch) returns Patch. From nobody Wed Aug 20 16:08:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE771A005B; Wed, 20 Aug 2014 16:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWSV9xMbFvDj; Wed, 20 Aug 2014 16:08:16 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A321A0055; Wed, 20 Aug 2014 16:08:15 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7849415wib.4 for ; Wed, 20 Aug 2014 16:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B2+vo+w2g+Tlu2UiJ97FjqM3NlCdc1CFdIKkBf3ntNE=; b=xlmoy6Nw+POvdWAzvgpwU1RBspOVjFZT7weKbIcj/0htlETzCP6SOYpRCPuOWqGlk7 KOeRoA+JQDjQLJewPn1Kc2Ar2B1M7l+IEMKkujXq3b6J1XShxEnoK9dRHp3UUPmWX8VC pTOG+yMM5byv8Jar5bwRD5KHCwUj6i10goq4qH8HS0JIontcc9QxO8F3pp0OMYwtpW6P tIxhxrTuL4dA5nrHLXDgsVZHI62dlDHax01vI5q6iEw8n6cuqtkiMJqfEErSS8mh66EC vt00rnKCPTr4yG70t37q3/d4um4VDDiWcK+wGRAnpkPOPwiTyg+8hOj1G1/oqEotoqXd 5c/Q== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr63384817wjb.59.1408576094280; Wed, 20 Aug 2014 16:08:14 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Wed, 20 Aug 2014 16:08:14 -0700 (PDT) In-Reply-To: <20140820224003.17644.2418.idtracker@ietfa.amsl.com> References: <20140820224003.17644.2418.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 16:08:14 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jYErN3RtWdcAPgvnVqmJiVsf3qI Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , Apps Discuss Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-json-merge-patch-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 23:08:17 -0000 On 20 August 2014 15:40, Stephen Farrell wrote: > I didn't get why if Patch is not an object then > MergePatch(foo, Patch) returns Patch. That's for arrays and scalars. From nobody Wed Aug 20 16:32:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D31A01E4; Wed, 20 Aug 2014 16:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCM1INik3Vyh; Wed, 20 Aug 2014 16:31:57 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6191A005D; Wed, 20 Aug 2014 16:31:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,905,1399989600"; d="scan'208";a="219174063" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 21 Aug 2014 09:23:24 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="297797901" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 21 Aug 2014 09:31:56 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 21 Aug 2014 09:31:55 +1000 From: "Manger, James" To: Pete Resnick , Richard Barnes Date: Thu, 21 Aug 2014 09:31:53 +1000 Thread-Topic: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) Thread-Index: Ac+8ts7lJ2cssV+jT9iJGtJ3j6+yBwAFsnHA Message-ID: <255B9BB34FB7D647A506DC292726F6E127C685E02B@WSMSG3153V.srv.dir.telstra.com> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> In-Reply-To: <53F50765.2080709@qti.qualcomm.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gGi95SbCCPN_WczAmNTQd-jtZNw Cc: "draft-ietf-appsawg-json-merge-patch@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Aug 2014 23:31:59 -0000 > I'd also of course love to see some edge case examples > (like a Patch being other than an object, That would be examples 9, 10, 11, and 12 in Appendix A "Example Test Cases"= . > or a Patch containing some nulls in an array) Reasonable suggestion. > that actually debugged as opposed to repeating the obvious example from t= he document. The 15 examples in Appendix A do that. -- James Manger From nobody Wed Aug 20 17:16:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABC01A0649 for ; Wed, 20 Aug 2014 17:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URI_NOVOWEL=0.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWEKFInEasU2 for ; Wed, 20 Aug 2014 17:15:52 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123E81A003A for ; Wed, 20 Aug 2014 17:15:51 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id v1so7545468yhn.37 for ; Wed, 20 Aug 2014 17:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hQociO6Aj4SAH5eh5iDZc9n0WiuvumXBB3eKAbdb+qU=; b=GUMOW96XG+xF3w/60ASEolLfEKwVdRNHO3Y68T3sCgOCBVSMytDlMOGXUkXxwYgUH+ qDLbIhvWDkHRo3gCMLQ/DmnmblQ9oAxfApFyfHDx7uhyFkNnkpj9J90JQ1CZK9ghzCDG TNyqRV/pvAUFsgy8hiTTFBWSp6YjbqgFTrxVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hQociO6Aj4SAH5eh5iDZc9n0WiuvumXBB3eKAbdb+qU=; b=IgXYQYFBynaP12cOFY6WeU8gMIXGBD2bbc75+kwM+6VNbZhMn0WNwSUENXDzmT0/Lu GyKyuor1dcxP38uh+uVTmFWFfAP339+7QzwLoheCXaBGYq6LDUXMoV3TR6aU+YekofrR 0HETvUl6ku+EQfTHV5tqQ812AGijCi/4ogl8AMxIYYjLlEir/p2gkMVNwQ664MbOz4V/ qfxuSld+afVfOMxy9J2YP1DlxAc5ByGyeoxZBexHOKUImvfJRa5kuwoL7p8/6WsvdZf2 s9ys5+WalCuuIk1l+PBsRlrhtZAvIHzjWNINJYfllgxpYwz5mJQ7vjT/NLwjjHhffMq2 3BYg== X-Gm-Message-State: ALoCoQnnbMBi5cMr5lnG+cmaoqXv+OfqtiWJZGDbmL+9qJ4XB5Ir4oM7mX2wvplBzfl21Re4z3af MIME-Version: 1.0 X-Received: by 10.236.101.138 with SMTP id b10mr7034653yhg.91.1408580151274; Wed, 20 Aug 2014 17:15:51 -0700 (PDT) Received: by 10.170.116.206 with HTTP; Wed, 20 Aug 2014 17:15:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Aug 2014 17:15:51 -0700 Message-ID: From: Mike Jones To: Tim Draegen Content-Type: multipart/alternative; boundary=20cf301b606f8e04a90501189fdc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/S7dgxar0ndT13ge6G83xjhqYBlY Cc: "dmarc@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 00:15:54 -0000 --20cf301b606f8e04a90501189fdc Content-Type: text/plain; charset=UTF-8 Hi Tim, The list of milestones and deliverables looks good to me. Having not participated in an IETF working group before, I have process oriented questions. Am I a part of the working group by being a member of the dmarc@ietf.org list? How do I contribute to the working group, will the chairs ask for input at specific times or for volunteers to write specific pieces of documents? How does the working group decide that any given suggestion warrants inclusion in a deliverable or a base spec change or some other action? Thanks, Mike On Mon, Aug 18, 2014 at 8:31 AM, Tim Draegen wrote: > Hello world of email, > > The DMARC WG is getting started [1]. This IETF working group's goal is to > address interoperability issues with indirect email flows, to document > operational practices, and to mature the existing DMARC base > specification. If you would like to join please visit the DMARC WG [2]. > > The WG's Wiki page [3] documents the approach the WG will take to produce > its deliverables. You can find the roadmap/milestones on the site [4]. > For your convenience, the proposed milestones are: > > - 91st IETF: Document describing interoperability issues with DMARC > and indirect mail flows. > - EOY 2014: Deliverable #1 (above document + possible methods to > address). > - Feb 2015: draft DMARC Usage Guide > - 92nd IETF: Deliverable #2 - Document describing DMARC improvements > to better support indirect mail flows. > - May 2015: Deliverable #3 - base spec changes + DMARC Usage Guide > > If you have comments on the milestones, please provide them by August > 25th. Have fun, > > =- Tim > > > [1] http://datatracker.ietf.org/wg/dmarc/charter/ > [2] https://www.ietf.org/mailman/listinfo/dmarc > [3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki > [4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- *Mike Jones, Director of Product Management* *mjones@agari.com l M: 703.728.3978 l www.agari.com Changing Email Security For Good* *l* --20cf301b606f8e04a90501189fdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,=C2=A0

The list of milestones an= d deliverables looks good to me. Having not participated in an IETF working= group before, I have process oriented questions. =C2=A0

Am I a part of the working group by being a member of the dmarc@ietf.org list?=C2=A0
How do I contribute to the working group, will the chairs ask for inpu= t at specific times or for volunteers to write specific pieces of documents= ?=C2=A0
How does the working group decide that any given suggesti= on warrants inclusion in a deliverable or a base spec change or some other = action?=C2=A0

Thanks,
Mike

=C2=A0<= /div>


On= Mon, Aug 18, 2014 at 8:31 AM, Tim Draegen <tim@eudaemon.net>= wrote:
Hello world of email,

The DMARC WG is getting started [1].=C2=A0 This IETF working group's go= al is to address interoperability issues with indirect email flows, to docu= ment operational practices, and to mature the existing DMARC base specifica= tion.=C2=A0 If you would like to join please visit the DMARC WG [2].

The WG's Wiki page [3] documents the approach the WG will take to produ= ce its deliverables.=C2=A0 You can find the roadmap/milestones on the site = [4].=C2=A0 For your convenience, the proposed milestones are:

=C2=A0 =C2=A0 - 91st IETF: Document describing interoperability issues with= DMARC and indirect mail flows.
=C2=A0 =C2=A0 - EOY 2014: Deliverable #1 (above document + possible methods= to address).
=C2=A0 =C2=A0 - Feb 2015: draft DMARC Usage Guide
=C2=A0 =C2=A0 - 92nd IETF: Deliverable #2 - Document describing DMARC impro= vements to better support indirect mail flows.
=C2=A0 =C2=A0 - May 2015: Deliverable #3 - base spec changes + DMARC Usage = Guide

If you have comments on the milestones, please provide them by August 25th.= =C2=A0 Have fun,

=3D- Tim


[1] http://datatracker.ietf.org/wg/dmarc/charter/
[2] https://www.ietf.org/mailman/listinfo/dmarc
[3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki
[4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap

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



--
Mike Jones, Director of Product Management
--20cf301b606f8e04a90501189fdc-- From nobody Wed Aug 20 17:55:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663021A000F; Wed, 20 Aug 2014 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTpJJK6iVks9; Wed, 20 Aug 2014 17:55:36 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87951A6FA3; Wed, 20 Aug 2014 17:55:34 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7L0tVuD030831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 17:55:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 17:55:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A3C0DE1-2593-45EE-8FA9-B6007A728D10@vpnc.org> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GPoQNFMkOqhRm6DQQj93U4HtOGA Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 00:55:37 -0000 On Aug 20, 2014, at 10:19 AM, Pete Resnick = wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I am certainly willing to be talked out of this, but I am concerned = about > the implementability and would like to DISCUSS it a bit. >=20 > In section 2: >=20 > To apply the merge patch document to a target resource, the system > realizes the effect of the following function, described in > pseudocode. For this description, the function is called = MergePatch, > and it takes two arguments: the target resource document and the > merge patch document. The Target argument can be any JSON value, or > undefined. The Patch argument can be any JSON value. >=20 > It took me repeated reading of the pseudocode (and may I mention that = I > *hate* languages which rely on indentation ;-) ) to figure out that: >=20 > - If the Patch if not an object, the result *is* the Patch > - The Patch can't act on the internals of an array; it can only = replace > the whole thing > - The Patch cannot replace objects with new objects. >=20 > Can't we *please* have a textual description of this protocol in = addition > to a (recursive!) pseudocode function? I am not convinced that an > implementer will get their implementation right just from the = pseudocode. As you know, the earlier drafts of this document were textural = descriptions, and the WG kept having problems with the text. When the = pseudocode replacement was suggested, the WG seemed to like that much = better. Also note that the pseudocode in the draft is much more textural = than typical pseudocode. So, no, I don't think we can have a textural description that won't end = up looking a lot like the pseudocode. In particular, I seriously doubt = we can have such text without recursion; we tried earlier and pretty = much failed. Unfortunately, I cannot convince you about your hypothetical implementer = who tries to get their implementation from the pseudocode but ignores = the examples as test cases. We have a pretty complete set of examples = that could shake out any implementation, I believe. Your discussion of C = with Richard confuses me more on this point, since the C programmers I = know would probably strongly prefer to go from pseudocode and examples = than from text. --Paul Hoffman= From nobody Wed Aug 20 18:09:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1501A6F97; Wed, 20 Aug 2014 18:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOX0sTJgx7IM; Wed, 20 Aug 2014 18:08:51 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EC71A0027; Wed, 20 Aug 2014 18:08:50 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7L18idT031705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 18:08:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 18:08:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gx4YxIllf_h1iHdjDNbLTjl2oLM Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 01:09:00 -0000 On Aug 18, 2014, at 1:58 PM, Kathleen Moriarty = wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The draft looks very good and the security considerations in RFC5789 > cover most of the bases I would be concerned with. I do have a = question > I'd like to discuss to see if it applies or not. >=20 > Normally, in other spaces patches are validated and that might be as > simple as making sure the hash of the patch provided by the source > matches the value you calculated (not corrupted, *should* be from the > source you think it's from). I don't see any mention of this = practice, > is there a reason for that or should it be added? Maybe it's not > possible because of how the patch is delivered over HTTP, but I = figured > it was worth flagging to discuss quickly. The patches described in this document can be delivered however the = implementers want. The document explicitly shows how to do this for any = MIME-aware transport. Some of those might come with hashes that the = recipient are expected to check, but most of the common ones today are = not. I don't think that advice about sending hashes, checking hashes, = ignoring patches that don't come with hashes, and so on are any more = applicable here than to any other formats that could cause changes in = system settings. --Paul Hoffman= From nobody Wed Aug 20 18:27:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7B1A004B; Wed, 20 Aug 2014 18:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DjOhrVqxHDr; Wed, 20 Aug 2014 18:26:57 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5781A6F70; Wed, 20 Aug 2014 18:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408584417; x=1440120417; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rdv2mR+rAqA0y6VU4QIPuRNyEutJ/9Itg9/cj+65r/M=; b=SnzSWFvaMB/YpPedwqVhkFkCn7gJ7A6qe9NVBhFwAre+9ZgXyv1ymiTd Kwp98SJ7EGBn4yKs7AedmtRpjDYBgEs4pMGbYsG6ko9trlDuDH4RiHaEW 6MP+bqkNvBmsNUNCUoc1nQu7epgm/1kU/fxEr669bW7rTA+ufjBC7/4kY Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59429651" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2014 18:26:57 -0700 X-IronPort-AV: E=Sophos;i="5.01,905,1400050800"; d="scan'208";a="788788074" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 18:26:57 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 18:26:55 -0700 Message-ID: <53F54ADE.4050706@qti.qualcomm.com> Date: Wed, 20 Aug 2014 20:26:54 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <5A3C0DE1-2593-45EE-8FA9-B6007A728D10@vpnc.org> In-Reply-To: <5A3C0DE1-2593-45EE-8FA9-B6007A728D10@vpnc.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vEEizu76t6g-H8LC4t7lTuyesX8 Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 01:27:00 -0000 On 8/20/14 7:55 PM, Paul Hoffman wrote: > As you know, the earlier drafts of this document were textural descriptions... Actually, I did not know. I haven't been following this particular document on the apps-discuss list. > ...and the WG kept having problems with the text. When the pseudocode replacement was suggested, the WG seemed to like that much better. Also note that the pseudocode in the draft is much more textural than typical pseudocode. > > So, no, I don't think we can have a textural description that won't end up looking a lot like the pseudocode. In particular, I seriously doubt we can have such text without recursion; we tried earlier and pretty much failed. > Well, that may be the end of the DISCUSSion then. If you've already tried and failed to produce this, I'm not inclined to have you re-suffer. I may make some suggestions of text to clarify those things that I had trouble getting through, but those will simply be comments. If you all think they would be helpful to implementers, I think it would be good to add them. I'll work on that when I finish my other document reviews. But unless someone wants to come out of the woodwork and say, "Pete's right. Back to the saltmines!", consider this resolved. I'll update my ballot when I get a chance. > Unfortunately, I cannot convince you about your hypothetical implementer who tries to get their implementation from the pseudocode but ignores the examples as test cases. We have a pretty complete set of examples that could shake out any implementation, I believe. Your discussion of C with Richard confuses me more on this point, since the C programmers I know would probably strongly prefer to go from pseudocode and examples than from text. > It's a style thing. I always hated coding from pseudocode; I could always come up with more efficient algorithms. I'd rather just be told what the interfaces were and what the output was supposed to look like. But to each his own. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Aug 20 18:50:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FD91A6F7F; Wed, 20 Aug 2014 18:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkM9e2scJsPv; Wed, 20 Aug 2014 18:50:48 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB6F1A6F7D; Wed, 20 Aug 2014 18:50:48 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7L1oh4d033053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 18:50:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 20 Aug 2014 18:50:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/khxqTYhDXaFcfMm7trV-dMESpaM Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 01:50:50 -0000 On Aug 20, 2014, at 6:20 PM, Kathleen Moriarty = wrote: > On Wed, Aug 20, 2014 at 9:08 PM, Paul Hoffman = wrote: > On Aug 18, 2014, at 1:58 PM, Kathleen Moriarty = wrote: >=20 > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > The draft looks very good and the security considerations in RFC5789 > > cover most of the bases I would be concerned with. I do have a = question > > I'd like to discuss to see if it applies or not. > > > > Normally, in other spaces patches are validated and that might be as > > simple as making sure the hash of the patch provided by the source > > matches the value you calculated (not corrupted, *should* be from = the > > source you think it's from). I don't see any mention of this = practice, > > is there a reason for that or should it be added? Maybe it's not > > possible because of how the patch is delivered over HTTP, but I = figured > > it was worth flagging to discuss quickly. >=20 > The patches described in this document can be delivered however the = implementers want. The document explicitly shows how to do this for any = MIME-aware transport. Some of those might come with hashes that the = recipient are expected to check, but most of the common ones today are = not. I don't think that advice about sending hashes, checking hashes, = ignoring patches that don't come with hashes, and so on are any more = applicable here than to any other formats that could cause changes in = system settings. >=20 > Sure agreed, but it's common practice to do that sort of thing with = patches, so mentioning the practice would be good since you are saying = it's possible. I think it could be helpful to implementers to = understand that option. Can you add a couple of sentences? I'm not sure I can add those sentences in a useful fashion. With current = delivery mechanisms (HTTP being the most common), MIME objects don't = come with hashes for checking. So giving that advice would cause = developers to look for something that they won't have, namely hashes of = the MIME object they just got. I do hope you're not asking us to change the format to include an = internal hash. That would require inventing JSON canonicalization (which = the JOSE WG has flailed miserably on) and say "canonicalize, pick a hash = function, hash, and add that to the patch object". The recipient would = need to pull the hash out before processing the patch, canonicalize the = result, and check the hash. This is conceptually possible but it seems = onerous, and has not been done in any of the earlier patch formats that = have been standardized in the IETF. --Paul Hoffman= From nobody Wed Aug 20 19:01:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4941A0061; Wed, 20 Aug 2014 19:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkptfhx3QFbb; Wed, 20 Aug 2014 19:00:55 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3642D1A06D8; Wed, 20 Aug 2014 19:00:55 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so3793976iec.5 for ; Wed, 20 Aug 2014 19:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gUIg5bzrMG6m9shXkEmWypf9Z1pWwLN7qnvndSJ4S3s=; b=EDUXcpflq8Nyz+iu4qtvAmriIQXPo/2Fu+tmVH0FHBavzmyZQRBO4YTMBi++qkgktG vaM1pnpPruleMTb4a8Ezf/r1Q17HCUdd88rJvsuhchwBqIUUoNnRAqCn2EmtOcOYECqr O6XUq2sjV6P/Qq08dwe3tJskJqQp4o+djG/TCtR5SQ1ZDqzCq7GqOtVB651kBXQQy0vt XFoaWrby+mQTtr2cyztYDosaclcFJAk1R4PHPMALNVxAeeDw5dI9lRozg5Zy4gJTK+9Z hIQQ8leHWcG+rZZogtk7g+TIMKsO/QDWXG8lbnLtRdwbB1JDBdR4y1w56by3HsaExDhw RcKQ== MIME-Version: 1.0 X-Received: by 10.50.55.68 with SMTP id q4mr16656178igp.44.1408586454578; Wed, 20 Aug 2014 19:00:54 -0700 (PDT) Received: by 10.107.131.134 with HTTP; Wed, 20 Aug 2014 19:00:53 -0700 (PDT) Received: by 10.107.131.134 with HTTP; Wed, 20 Aug 2014 19:00:53 -0700 (PDT) In-Reply-To: <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> Date: Wed, 20 Aug 2014 19:00:53 -0700 Message-ID: From: James M Snell To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b10ce9142bdec05011a1799 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ukHDhfzgnSuB1XnQLa1eJ5ykM9E Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, Kathleen Moriarty , appsawg-chairs@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 02:00:57 -0000 --047d7b10ce9142bdec05011a1799 Content-Type: text/plain; charset=UTF-8 On Aug 20, 2014 6:50 PM, "Paul Hoffman" wrote: > [Snip] > > I'm not sure I can add those sentences in a useful fashion. With current delivery mechanisms (HTTP being the most common), MIME objects don't come with hashes for checking. So giving that advice would cause developers to look for something that they won't have, namely hashes of the MIME object they just got. > +1 > I do hope you're not asking us to change the format to include an internal hash. That would require inventing JSON canonicalization (which the JOSE WG has flailed miserably on) and say "canonicalize, pick a hash function, hash, and add that to the patch object". The recipient would need to pull the hash out before processing the patch, canonicalize the result, and check the hash. This is conceptually possible but it seems onerous, and has not been done in any of the earlier patch formats that have been standardized in the IETF. > +1... Adding an internal hash would not work with this mechanism without taking a major step backwards. I do not see the value. - James > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --047d7b10ce9142bdec05011a1799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 20, 2014 6:50 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
[Snip]
>
> I'm not sure I can add those sentences in a useful fashion. With c= urrent delivery mechanisms (HTTP being the most common), MIME objects don&#= 39;t come with hashes for checking. So giving that advice would cause devel= opers to look for something that they won't have, namely hashes of the = MIME object they just got.
>

+1

> I do hope you're not asking us to change the format= to include an internal hash. That would require inventing JSON canonicaliz= ation (which the JOSE WG has flailed miserably on) and say "canonicali= ze, pick a hash function, hash, and add that to the patch object". The= recipient would need to pull the hash out before processing the patch, can= onicalize the result, and check the hash. This is conceptually possible but= it seems onerous, and has not been done in any of the earlier patch format= s that have been standardized in the IETF.
>

+1... Adding an internal hash would not work with this mecha= nism without taking a major step backwards. I do not see the value.

- James

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

--047d7b10ce9142bdec05011a1799-- From nobody Wed Aug 20 23:19:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A79D1A86E0; Wed, 20 Aug 2014 23:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avxihp969KFs; Wed, 20 Aug 2014 23:19:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2E61A0208; Wed, 20 Aug 2014 23:19:24 -0700 (PDT) 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.5/8.14.5) with ESMTP id s7L6JFbf022113; Thu, 21 Aug 2014 08:19:15 +0200 (CEST) Received: from [10.181.181.114] (92.40.249.0.threembb.co.uk [92.40.249.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2C6F2E5A; Thu, 21 Aug 2014 08:19:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> Date: Thu, 21 Aug 2014 07:19:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <550407F4-8B27-4EE3-852D-42FD0A6082E9@tzi.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> To: Paul Hoffman Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mIHEcV9ZzDcxhJ3mDCreINtZM1w Cc: Apps Discuss , Kathleen Moriarty , "draft-ietf-appsawg-json-merge-patch@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 06:19:26 -0000 > On 21.08.2014, at 02:50, Paul Hoffman wrote: >=20 > inventing JSON canonicalization If that ever happens, it is easy to define another media type for validating= hashes that carries a pair of a patch (e.g. In merge patch format) and a ha= sh. (Or, a MAC...) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 20 23:30:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17DC1A86ED; Wed, 20 Aug 2014 23:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsH9Puu-xQRK; Wed, 20 Aug 2014 23:30:48 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7C1A6FD5; Wed, 20 Aug 2014 23:30:47 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id A5D7E67C06D; Wed, 20 Aug 2014 23:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=knPRJb2RJYHMkwmjkhMv pCmazs0=; b=vgubMWPVsUq2ZJT7dtXF44kVGSsk5A+7y0Sj/TIDf1k/wojtvm6H DiQ9RpVYdfq2PdqewQZGv65/y6KC3uLed9r/izyRts+Y8EuLDBeXrk/uWgCkUZJ4 FpnNlmCgHo10M+89CQ4ktGnobnGfgO6vwtLx0wlMJ4tni4xH9OavsQU= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (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 2EE0067C056; Wed, 20 Aug 2014 23:30:47 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so8957456wes.31 for ; Wed, 20 Aug 2014 23:30:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.203 with SMTP id e11mr2617935wiw.28.1408602645917; Wed, 20 Aug 2014 23:30:45 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 20 Aug 2014 23:30:45 -0700 (PDT) In-Reply-To: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 01:30:45 -0500 Message-ID: From: Nico Williams To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/v_uDw2pOzNaSLXJrcwHoIJHfUvM Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , Apps Discuss Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 06:30:48 -0000 My take is that this patch is not as general as RFC6902, but for some use-cases it is easier to construct a patch of this form, therefore it has utility, and depending on the edits one wishes to make, one of the two patches can be more verbose than the other. (E.g., making changes to various random parts of a large JSON text is likely to produce a smaller patch with RFC6902, but some template-type edits will be easier with the new patch.) Still, if I had to pick just one JSON patch format, I'd pick a path-based one like RFC6902. Nico -- From nobody Wed Aug 20 23:31:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4651A0468; Wed, 20 Aug 2014 23:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKZLF1UYvotj; Wed, 20 Aug 2014 23:31:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CD41A6FCF; Wed, 20 Aug 2014 23:31:50 -0700 (PDT) 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.5/8.14.5) with ESMTP id s7L6VhDs018400; Thu, 21 Aug 2014 08:31:43 +0200 (CEST) Received: from [10.181.181.114] (92.40.249.0.threembb.co.uk [92.40.249.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6BB20E65; Thu, 21 Aug 2014 08:31:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: <53F54ADE.4050706@qti.qualcomm.com> Date: Thu, 21 Aug 2014 07:31:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <5A3C0DE1-2593-45EE-8FA9-B6007A728D10@vpnc.org> <53F54ADE.4050706@qti.qualcomm.com> To: Pete Resnick Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bGFxE92AcNSOG7jyMwUDsApnfiA Cc: "apps-discuss@ietf.org" , "draft-ietf-appsawg-json-merge-patch@tools.ietf.org" , Paul Hoffman , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 06:31:53 -0000 Pete, I'm absolutely with you on the principle. Many of the current "web standards= " are extremely hard to use because they rely completely on complex, undebug= gable pseudo code. We should not repeat this mistake. In this specific case, the pseudo code is simple and indeed works much bette= r than a textual description. (And it has been derived from an implementatio= n, which does pass all the examples.) Sent from my iPad > On 21.08.2014, at 02:26, Pete Resnick wrote: >=20 >> On 8/20/14 7:55 PM, Paul Hoffman wrote: >> As you know, the earlier drafts of this document were textural descriptio= ns... >=20 > Actually, I did not know. I haven't been following this particular documen= t on the apps-discuss list. >=20 >> ...and the WG kept having problems with the text. When the pseudocode rep= lacement was suggested, the WG seemed to like that much better. Also note th= at the pseudocode in the draft is much more textural than typical pseudocode= . >>=20 >> So, no, I don't think we can have a textural description that won't end u= p looking a lot like the pseudocode. In particular, I seriously doubt we can= have such text without recursion; we tried earlier and pretty much failed. >=20 > Well, that may be the end of the DISCUSSion then. If you've already tried a= nd failed to produce this, I'm not inclined to have you re-suffer. I may mak= e some suggestions of text to clarify those things that I had trouble gettin= g through, but those will simply be comments. If you all think they would be= helpful to implementers, I think it would be good to add them. I'll work on= that when I finish my other document reviews. But unless someone wants to c= ome out of the woodwork and say, "Pete's right. Back to the saltmines!", con= sider this resolved. I'll update my ballot when I get a chance. >=20 >> Unfortunately, I cannot convince you about your hypothetical implementer w= ho tries to get their implementation from the pseudocode but ignores the exa= mples as test cases. We have a pretty complete set of examples that could sh= ake out any implementation, I believe. Your discussion of C with Richard con= fuses me more on this point, since the C programmers I know would probably s= trongly prefer to go from pseudocode and examples than from text. >=20 > It's a style thing. I always hated coding from pseudocode; I could always c= ome up with more efficient algorithms. I'd rather just be told what the inte= rfaces were and what the output was supposed to look like. But to each his o= wn. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From nobody Thu Aug 21 01:19:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2711A002D for ; Thu, 21 Aug 2014 01:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xBF9sWeimEX for ; Thu, 21 Aug 2014 01:18:59 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7098A1A000C for ; Thu, 21 Aug 2014 01:18:59 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 5B82C32E55C for ; Thu, 21 Aug 2014 17:18:14 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56cb_b494_5608272b_fe23_4c78_b8db_bb17307b16cb; Thu, 21 Aug 2014 17:18:13 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AFF65BFB5A for ; Thu, 21 Aug 2014 17:18:12 +0900 (JST) Message-ID: <53F5AB35.9080601@it.aoyama.ac.jp> Date: Thu, 21 Aug 2014 17:17:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> In-Reply-To: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ukAMxCinJNK5R57cV2fZ3OHzHCc Subject: [apps-discuss] Fwd: I-D Action: draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 08:19:00 -0000 I thought that 521 was quite old and widely used. So can we change the abstract to not say that it defines a "new" code? Regards, Martin. -------- Original Message -------- Title : SMTP 521 Reply Code Author : John C Klensin Filename : draft-klensin-smtp-521code-00.txt Pages : 4 Date : 2014-08-20 Abstract: This memo defines a new Simple Mail Transfer Protocol (SMTP) reply code, 521. That code may be used to indicate that an Internet host does not accept incoming mail. From nobody Thu Aug 21 01:44:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2071A0091; Thu, 21 Aug 2014 01:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4GBE7RakV4p; Thu, 21 Aug 2014 01:44:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690D71A0086; Thu, 21 Aug 2014 01:44:50 -0700 (PDT) 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.5/8.14.5) with ESMTP id s7L8ikAF006032; Thu, 21 Aug 2014 10:44:46 +0200 (CEST) Received: from [10.181.181.114] (92.40.249.21.threembb.co.uk [92.40.249.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0ED0EFDE; Thu, 21 Aug 2014 10:44:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 21 Aug 2014 09:44:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2613BA4D-4E5D-4B9E-93E3-D5DC46B85C54@tzi.org> References: <20140820171903.1548.80834.idtracker@ietfa.amsl.com> <53F50765.2080709@qti.qualcomm.com> <53F51141.6070408@qti.qualcomm.com> To: Richard Barnes Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/y7PY2q7cBCGZytEzO78062zj84A Cc: "apps-discuss@ietf.org" , Pete Resnick , "draft-ietf-appsawg-json-merge-patch@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 08:44:51 -0000 > On 20.08.2014, at 22:29, Richard Barnes wrote: >=20 > without defining an algorithm. If you squint a bit*), you can see that the pseudo code is just a recursive (= functional) definition, not really a (procedural) algorithm. Anything that h= as to say "go to step 6" fails the smell test. This one doesn't.=20 Gr=C3=BC=C3=9Fe, Carsten *) needed because there are some variables, iirc.= From nobody Thu Aug 21 01:52:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FC71A00A8; Thu, 21 Aug 2014 01:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDWWzSBR2LGZ; Thu, 21 Aug 2014 01:52:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA6B1A0091; Thu, 21 Aug 2014 01:52:38 -0700 (PDT) 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.5/8.14.5) with ESMTP id s7L8qTti021198; Thu, 21 Aug 2014 10:52:29 +0200 (CEST) Received: from [10.181.181.114] (92.40.249.21.threembb.co.uk [92.40.249.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90437FEA; Thu, 21 Aug 2014 10:52:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Thu, 21 Aug 2014 09:52:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <888129E5-1C95-4E4F-B1D1-FFB20379411D@tzi.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> To: Nico Williams Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HXHHyKlwMWVYRrd6WPzaV2nDLoY Cc: Apps Discuss , Kathleen Moriarty , "draft-ietf-appsawg-json-merge-patch@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 08:52:39 -0000 This format has a sweet spot, which is: O replacement points are values of map members, only O null never occurs as a value of a map member to be emplaced or is otherwis= e innocuous O replacement points are not deeply nested RFC 6902 obviously is more general. Merge-patch captures and formalizes wha= t many people already have been doing (often mistakenly using PUT with the o= riginal media type, not PATCH). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 21 06:56:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338D1A02E5 for ; Thu, 21 Aug 2014 06:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gej9EFFZjiWT for ; Thu, 21 Aug 2014 06:55:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2051A02E4 for ; Thu, 21 Aug 2014 06:55:56 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKSqH-0007e4-N8; Thu, 21 Aug 2014 09:55:53 -0400 Date: Thu, 21 Aug 2014 09:55:48 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , apps-discuss@ietf.org Message-ID: In-Reply-To: <53F5AB35.9080601@it.aoyama.ac.jp> References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Q0cYFeK0o4VfibaGlmZ2PFOMmpk Subject: Re: [apps-discuss] Fwd: I-D Action: draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 13:55:58 -0000 --On Thursday, August 21, 2014 17:17 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > I thought that 521 was quite old and widely used. So can we > change the abstract to not say that it defines a "new" code? Yes, certainly. Fixed in -01, which I will issue in the next 24 hours if there are no other comments. regards, john From nobody Thu Aug 21 07:11:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19B1A032A; Thu, 21 Aug 2014 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYvTreK4xDID; Thu, 21 Aug 2014 07:11:43 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FB01A6FEB; Thu, 21 Aug 2014 07:11:22 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7LEBIRE064073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2014 07:11:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Thu, 21 Aug 2014 07:11:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/hMYgVDC7RgGhfivNp2KCPALnJ3M Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-json-merge-patch@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 14:11:48 -0000 Pete Resnick hates it when I just roll over on DISCUSSes that I think = will make the document a bit worse, so I'll do another round on this, = then probably roll over. Your call. On Aug 20, 2014, at 7:14 PM, Kathleen Moriarty = wrote: > Not to worry, I wasn't asking for anything to be added other than text = in the security considerations for when it was possible, keying off of = your first response, "The document explicitly shows how to do this for = any MIME-aware transport. Some of those might come with hashes that the = recipient are expected to check, but most of the common ones today are = not." Obviously, it would not be something required since it doesn't = always get delivered, but I don't see a reason to exclude mention of = this practice when it provides additional integrity checking when it is = available. There is a very good reason not to: it will likely cause false negative = rejections much more often than catching positives. JSON is a text = format, and this merge patch format creates patches small enough to = easily be sent around in email. Email clients tend to add or strip = trailing whitespace and change line ending characters; so does FTP. = Thus, a hash will likely say "this is bad" even when it is perfectly = good. Thus, encouraging the use of hash checking at all is causing more = operational security errors. > I guess I find it odd that this has not been done before, so I'm = guessing there has not been security issues yet that caused an update in = practices? Correct. For JSON or XML, sending a hash and expecting systems to reject = messages because of text conversions is a bad practice. The best = practice of "check the hash on this patch" is quite appropriate for .tgz = .zip tarballs, and that's where you see it in the security community. --Paul Hoffman= From nobody Thu Aug 21 07:33:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3E81A87CA; Thu, 21 Aug 2014 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dQVru4W29ZO; Thu, 21 Aug 2014 07:33:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 042CC1A031A; Thu, 21 Aug 2014 07:33:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821143321.30781.95418.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:33:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9dwze0Ee39jyvRW2ztBzDq2N-ak Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-json-merge-patch-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:33:30 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-json-merge-patch-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My previous DISCUSS asked for some textual description of the pseudocode. It turns out that the WG attempted that and was unable to come up with something clear enough to produce interoperable implementations. That's a bummer, but I am willing to take the WG's word that they tried. I will only suggest adding some text after the pseudocode to assist folks in noticing some of the "interesting" aspects of the patch procedure: Note: This algorithm has some results that might not be immediately obvious to the implementer: - If the Patch is not itself an object, the Patch replaces the entire contents of the Target. - The Patch can only affect the entire value of a member of a Target object. In particular, a Patch cannot change members of an array; it can only replace or delete the entire array. If the WG thinks there are other things worth mentioning, it might help the implementer. As I said previously, it did take me re-reading the pseudocode several times to truly understand the semantics, and if an implementer needs to structure their code differently than the pseudocode, it would be nice to point out some possibly tricky bits. From nobody Thu Aug 21 08:00:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4971A0113; Thu, 21 Aug 2014 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B88mZhNyjcWP; Thu, 21 Aug 2014 08:00:07 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0011A070C; Thu, 21 Aug 2014 08:00:06 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKTqL-0007jJ-VI; Thu, 21 Aug 2014 11:00:01 -0400 Date: Thu, 21 Aug 2014 10:59:56 -0400 From: John C Klensin To: Paul Hoffman , Kathleen Moriarty Message-ID: <53C6517CA3F01EF3E9E35D7B@JcK-HP8200.jck.com> In-Reply-To: References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o4TtZjIHBGx6Ch4tG2koryP-DNo Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 15:00:13 -0000 --On Thursday, August 21, 2014 07:11 -0700 Paul Hoffman wrote: >... > There is a very good reason not to: it will likely cause false > negative rejections much more often than catching positives. > JSON is a text format, and this merge patch format creates > patches small enough to easily be sent around in email. Email > clients tend to add or strip trailing whitespace and change > line ending characters; so does FTP. Thus, a hash will likely > say "this is bad" even when it is perfectly good. Thus, > encouraging the use of hash checking at all is causing more > operational security errors. >... Paul, I agree with your analysis and the conclusion that, Kathleen's suggested change would make the document worse and, unless people were smart enough to ignore it, increase false negatives. That could be fixed by a lot more text, but I don't think that would be worth it. However, a nit and a more general comment: Nit: With email clients, "adjusting" trailing white space and line ending is long-established and normal behavior to adapt textual messages to the local environment. That behavior cannot be in violation of IETF Standards because we have never (IMO, wisely) specified the behavior of MUAs. However, barring local extensions, FTP allows only two transfer encoding types for stream-type data that are still relevant in the contemporary Internet. If "type ascii" is used, a canonical form is specified and an FTP client or server are in violation of the spec if anything else is sent. Of course, one or the other might convert between that form and local conventions -- that was actually the intent and may be what you were referring to. "Type ASCII" is implausible (bad things will happen) for, e.g., ISO 8859 or non-ASCII-repertoire Unicode data. If "type image" is used, whatever exists on the sender side is expected to be delivered, bit-by-bit intact, to the receiver; anything else is a protocol violation. BTW, if anyone cares about an analogy for "type ASCII" for general Unicode data or things that can be mapped into it, I've tried to float a "TYPE U" proposal several times but it has gotten no traction in the past. General comment, more to Kathleen and the IESG than to you: There are many formats that are essentially plain text at the character level, including JSON and XML as well as ordinary email. When hashes (or other types of signatures) are being computed over them, we should try to be a lot more cautious than we have been about the importance of specifying a canonical form and computing the hash over it. FWIW, the problem gets a _lot_ worse when we move past ASCII data and into Unicode and its various canonical and encoding forms. That caution could take the form of warning about a lot of false negatives and not overreacting to them or could actually involve a canonical form specification. But, IMO, we have been somewhat too willing to ignore the problem or pretend it isn't there. john From nobody Thu Aug 21 09:36:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D362F1A050E for ; Thu, 21 Aug 2014 09:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmbw2kIs3jOL; Thu, 21 Aug 2014 09:36:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB351A0673; Thu, 21 Aug 2014 09:36:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821163648.30469.96503.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 09:36:48 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2hjlFpE4ordhPhIKPuJgl2zMjEg Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:36:51 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Thu Aug 21 10:50:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9571A1F16; Thu, 21 Aug 2014 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKIiOcdVJ8M1; Thu, 21 Aug 2014 10:50:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8F1A6F1D; Thu, 21 Aug 2014 10:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821175000.27068.24963.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 10:50:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/otHBS6BRRfGvaPojaQnIOspctuc Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:50:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : JSON Merge Patch Authors : Paul Hoffman James M Snell Filename : draft-ietf-appsawg-json-merge-patch-07.txt Pages : 9 Date : 2014-08-21 Abstract: This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 21 10:50:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4468C1A6EF7 for ; Thu, 21 Aug 2014 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPi7lGjyPVnl; Thu, 21 Aug 2014 10:50:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6C1A6F25; Thu, 21 Aug 2014 10:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821175000.27068.92083.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 10:50:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3QgPS5gt8EYC5ITIujaGDtrDTcs Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-json-merge-patch-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:50:04 -0000 A new version (-07) has been submitted for draft-ietf-appsawg-json-merge-patch: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-merge-patch-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Aug 21 10:53:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6E1A06F0 for ; Thu, 21 Aug 2014 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw9GsvjF0iRu; Thu, 21 Aug 2014 10:53:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD121A0707; Thu, 21 Aug 2014 10:53:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821175302.5220.4207.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 10:53:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aTqEIWC9QHRwwPBuy01mIqguTOg Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:53:04 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Thu Aug 21 16:41:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E91A874A for ; Thu, 21 Aug 2014 16:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8ff5jfFkjwu for ; Thu, 21 Aug 2014 16:41:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A81A1A8741 for ; Thu, 21 Aug 2014 16:41:43 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.123.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AB9922E1F4; Thu, 21 Aug 2014 19:41:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: Date: Fri, 22 Aug 2014 09:41:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WJktbiuyvyJMuNJB7J6RlfjA_bo Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Minutes from APPSAWG/APPAREA meeting at IETF 90 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 23:41:44 -0000 I don't recall the next step for json-home being a call for adoption; = did I remember that wrong? Regards, On 20 Aug 2014, at 4:04 pm, Murray S. Kucherawy = wrote: > Colleagues, >=20 > The minutes from our meeting at IETF 90 are now visible here: >=20 > http://www.ietf.org/proceedings/90/minutes/minutes-90-appsawg >=20 > Please provide any corrections prior to September 5th. After that = they will be a permanent part of the proceedings. >=20 > -MSK, APPSAWG co-chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 21 22:16:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9661A0033 for ; Thu, 21 Aug 2014 22:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuv8mnmPTTSo for ; Thu, 21 Aug 2014 22:16:10 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE60D1A0029 for ; Thu, 21 Aug 2014 22:16:09 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so9537941lab.4 for ; Thu, 21 Aug 2014 22:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HCkhPBt0DLlFmHab4+Eynh3aUCmFNYmfoD+B8lkA984=; b=V2D+PjRIuMdk19Ey9OulYShpSKcEcdt+nefVyJNKKZy3pS7UZO+4UMU0b+KqGVpM/v 8k0w/o3xQpZdXxf5FC5zqh5MR9bpwnyHwTEUqFWprYU5U+w4evnaznrWOC1W+sNvl/b2 Mk1tUSBYPXHMuQls2Qv02CaV7FnJv6HBsFdGC4GzHP/7sMBKRhZ2LZv14v1tNVSURWFb WWCmwlrJPQhISpMyTGZJgDBJuVAAX0cd2zczeU6W2QY128WTho1zGFilZI4t5fF39Y7f t2ULDKTpy33NVPRkpNKLWLYqDQ4/UtNfh7R0k0VAGzPBGRCZJLA3Q+iMVMkpIuRVL6wg db5A== MIME-Version: 1.0 X-Received: by 10.112.78.38 with SMTP id y6mr344293lbw.94.1408684568120; Thu, 21 Aug 2014 22:16:08 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Thu, 21 Aug 2014 22:16:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 22:16:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c3db4248936c050130efee Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zcZMaMgalHmFXcWbZxozwnFtFDA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Minutes from APPSAWG/APPAREA meeting at IETF 90 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 05:16:14 -0000 --001a11c3db4248936c050130efee Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 4:41 PM, Mark Nottingham wrote: > I don't recall the next step for json-home being a call for adoption; did > I remember that wrong? > Probably just a copy-pasta error then. I'll tidy it up. -MSK --001a11c3db4248936c050130efee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 21, 2014 at 4:41 PM, Mark Nottingham <mnot@mnot.n= et> wrote:
I don't recall the next step for json-home being a call for adoption; d= id I remember that wrong?

=C2=A0Probabl= y just a copy-pasta error then.=C2=A0 I'll tidy it up.

-MSK
--001a11c3db4248936c050130efee-- From nobody Fri Aug 22 03:57:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D21A0272 for ; Fri, 22 Aug 2014 03:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NdAt-TR6FhB for ; Fri, 22 Aug 2014 03:57:17 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0084.outbound.protection.outlook.com [213.199.154.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE391A0278 for ; Fri, 22 Aug 2014 03:57:16 -0700 (PDT) Received: from pc6 (109.147.210.26) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 10:57:14 +0000 Message-ID: <024801cfbdf7$b274bb00$4001a8c0@gateway.2wire.net> From: t.petch To: John C Klensin , References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> Date: Fri, 22 Aug 2014 11:56:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR05CA0010.eurprd05.prod.outlook.com (25.160.40.20) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(199003)(377454003)(2473001)(24454002)(51704005)(42186005)(19580405001)(61296003)(31966008)(19580395003)(50226001)(105586002)(23676002)(101416001)(62966002)(230783001)(104166001)(106356001)(95666004)(44736004)(4396001)(50466002)(107886001)(74662001)(107046002)(64706001)(102836001)(74502001)(83322001)(33646002)(21056001)(87976001)(85306004)(88136002)(15975445006)(81542001)(79102001)(89996001)(44716002)(46102001)(62236002)(77096002)(92566001)(76482001)(84392001)(66066001)(77982001)(86362001)(20776003)(85852003)(87286001)(93916002)(116806002)(77156001)(81816999)(99396002)(83072002)(81686999)(76176999)(80022001)(92726001)(47776003)(50986999)(90102001)(81342001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6m1ACFotQCem5iBgFoQwOjK87PQ Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 10:57:19 -0000 John The body of the document has references [RFC5321] and [nullMX]. The list of references goes [1] [2] [1] [2]. (It is amazing what you can do with submission tools:-) Tom Petch ----- Original Message ----- From: "John C Klensin" To: "Martin J. Dürst" ; Sent: Thursday, August 21, 2014 2:55 PM > --On Thursday, August 21, 2014 17:17 +0900 "\"Martin J. > Dürst\"" wrote: > > > I thought that 521 was quite old and widely used. So can we > > change the abstract to not say that it defines a "new" code? > > Yes, certainly. Fixed in -01, which I will issue in the next > 24 hours if there are no other comments. > > regards, > john > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Aug 22 05:43:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D951A01E7 for ; Fri, 22 Aug 2014 05:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLyD0GiqsOAB for ; Fri, 22 Aug 2014 05:43:35 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF841A01E8 for ; Fri, 22 Aug 2014 05:43:35 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKoBn-0009yU-5E; Fri, 22 Aug 2014 08:43:31 -0400 Date: Fri, 22 Aug 2014 08:43:26 -0400 From: John C Klensin To: "t.petch" , apps-discuss@ietf.org Message-ID: In-Reply-To: <024801cfbdf7$b274bb00$4001a8c0@gateway.2wire.net> References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> <024801cfbdf7$b274bb00$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9udid0E7NMs8SGnkPfDkbBh-3H0 Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 12:43:37 -0000 --On Friday, August 22, 2014 11:56 +0100 "t.petch" wrote: > John > > The body of the document has references [RFC5321] and > [nullMX]. The list of references goes [1] [2] [1] [2]. (It > is amazing what you can do with submission tools:-) Sigh. See XML2RFC ticket #271 (http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/271). It is amazing what one can do with compilation tools :-( Version -01 will be compiled with the online version. A preliminary version of it does not exhibit this problem. The only change so far is to an abstract that responds to Martin's comments. Additional substantive comments welcome. thanks, john From nobody Fri Aug 22 08:43:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6568A1A0110 for ; Fri, 22 Aug 2014 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aspk9kT_aD7R for ; Fri, 22 Aug 2014 08:43:16 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0078.outbound.protection.outlook.com [213.199.154.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2501A007A for ; Fri, 22 Aug 2014 08:43:15 -0700 (PDT) Received: from pc6 (109.147.210.26) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 15:43:13 +0000 Message-ID: <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> From: t.petch To: John C Klensin , References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> Date: Fri, 22 Aug 2014 16:42:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-Originating-IP: [109.147.210.26] X-ClientProxiedBy: DB4PR03CA0037.eurprd03.prod.outlook.com (25.160.39.175) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0311124FA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(377454003)(2473001)(24454002)(51704005)(13464003)(199003)(189002)(77096002)(62236002)(46102001)(66066001)(77982001)(86362001)(92566001)(76482001)(84392001)(88136002)(85306004)(87976001)(89996001)(44716002)(15975445006)(79102001)(81542001)(80022001)(76176999)(92726001)(81816999)(77156001)(99396002)(81686999)(83072002)(50986999)(47776003)(90102001)(81342001)(87286001)(20776003)(85852003)(116806002)(93916002)(105586002)(101416001)(62966002)(230783001)(23676002)(42186005)(19580395003)(14496001)(50226001)(31966008)(61296003)(74502001)(102836001)(83322001)(107046002)(64706001)(44736004)(33646002)(21056001)(50466002)(4396001)(104166001)(106356001)(95666004)(74662001)(107886001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DRQlUPJDPI4xPodNNMrzljxFy2M Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 15:43:18 -0000 John "The SMTP specification [RFC5321] (referred to, along with its various updates, as "SMTP" below) contains a list and discussion of error codes. " Well no - error code does not appear in RFC5321, it is reply code as the rest of this I-D uses; and yes, I think that this is a source of potential confusion even among the target audience and needs changing. Tom Petch ----- Original Message ----- From: "John C Klensin" To: "Martin J. Dürst" ; Sent: Thursday, August 21, 2014 2:55 PM > > > --On Thursday, August 21, 2014 17:17 +0900 "\"Martin J. > Dürst\"" wrote: > > > I thought that 521 was quite old and widely used. So can we > > change the abstract to not say that it defines a "new" code? > > Yes, certainly. Fixed in -01, which I will issue in the next > 24 hours if there are no other comments. > > regards, > john > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Aug 22 10:13:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28C91A06A6 for ; Fri, 22 Aug 2014 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5hkMFT0KBH0 for ; Fri, 22 Aug 2014 10:13:10 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C311A06A5 for ; Fri, 22 Aug 2014 10:13:09 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKsOg-000AMR-Jo; Fri, 22 Aug 2014 13:13:06 -0400 Date: Fri, 22 Aug 2014 13:13:01 -0400 From: John C Klensin To: "t.petch" , apps-discuss@ietf.org Message-ID: In-Reply-To: <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CmpcuIxqcSeMwaVJD32Lnwtk-18 Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 17:13:14 -0000 --On Friday, August 22, 2014 16:42 +0100 "t.petch" wrote: > John > > "The SMTP specification [RFC5321] (referred to, along with its > various updates, as "SMTP" below) contains a list and > discussion of error codes. " > > Well no - error code does not appear in RFC5321, it is reply > code as the rest of this I-D uses; and yes, I think that this > is a source of potential confusion even among the target > audience and needs changing. Thanks for the careful reading. "error code" has been changed to "reply code" in -01. The term "error" does appear in other places in the document, but only in context with error status (e.g., "any attempt to send mail here is obviously a mistake somewhere") or a 5yz code, which 5321 does refer to as an error status. I'm inclined to leave those alone. If you think they would be better changed as well, please say so. john From nobody Fri Aug 22 10:59:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7DE1A06AD for ; Fri, 22 Aug 2014 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0SzDxYjym64 for ; Fri, 22 Aug 2014 10:59:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4A11A0455 for ; Fri, 22 Aug 2014 10:59:20 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKt7P-000APv-Ny for apps-discuss@ietf.org; Fri, 22 Aug 2014 13:59:19 -0400 Date: Fri, 22 Aug 2014 13:59:14 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: <561BDD4A7D6FEFD339E72B24@JcK-HP8200.jck.com> In-Reply-To: <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m1rvBHZmoGoaiwjA8jKNDgH0av4 Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Aug 2014 17:59:23 -0000 -01 has been posted, incorporating changes suggested by Tom and Martin. These changes are largely editorial (although significant in that respect). The substance of the document is unchanged. john From nobody Fri Aug 22 12:31:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8902B1A6FBB; Wed, 20 Aug 2014 18:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uWW0WdBAkEY; Wed, 20 Aug 2014 18:20:08 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31E71A6F70; Wed, 20 Aug 2014 18:20:07 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so7534716lbi.11 for ; Wed, 20 Aug 2014 18:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mG/EV9T9c2tbmy8/SZOmTfA54dR8LFId80B0hjPdXZA=; b=0BtJO7YsVZUOxxXLY0gtNPFeU1tHF19JW7A0QCbcHjFcUizSu4NzQKX6Onq5Cnybb2 vZgBR93Rd19FGKqugjg0iviVq84Pr5M0n79wCSIKTDww8bIR4cWWu1TtiuOhfogywGJa WUBkExIqDchr78R0tx7nkieAFRRRsXS1a9Vm9aNx3jx2qNSCxZnDQNDI8MIqKQybfxip 6K1bYqMT+lAEstaZwym8uuwmv4hiG1xe0sULAH6L8BFpuDvZ8kYVJcd+F9UxPld1HVhh kwcYAJTIUkjdQIxdvX0KF+CSnEoFjoFdXzGpOPWs/xWGILi97/ZJa4LpVm4d3Iu6HSAr sxYA== MIME-Version: 1.0 X-Received: by 10.112.183.162 with SMTP id en2mr42863779lbc.51.1408584005924; Wed, 20 Aug 2014 18:20:05 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Wed, 20 Aug 2014 18:20:05 -0700 (PDT) In-Reply-To: <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> Date: Wed, 20 Aug 2014 21:20:05 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11348b364f3b420501198559 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IDABEu4A_QaWKv78-COOmmXQ5G0 X-Mailman-Approved-At: Fri, 22 Aug 2014 12:31:21 -0700 Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , Apps Discuss Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 01:20:10 -0000 --001a11348b364f3b420501198559 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 9:08 PM, Paul Hoffman wrote: > On Aug 18, 2014, at 1:58 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The draft looks very good and the security considerations in RFC5789 > > cover most of the bases I would be concerned with. I do have a question > > I'd like to discuss to see if it applies or not. > > > > Normally, in other spaces patches are validated and that might be as > > simple as making sure the hash of the patch provided by the source > > matches the value you calculated (not corrupted, *should* be from the > > source you think it's from). I don't see any mention of this practice, > > is there a reason for that or should it be added? Maybe it's not > > possible because of how the patch is delivered over HTTP, but I figured > > it was worth flagging to discuss quickly. > > The patches described in this document can be delivered however the > implementers want. The document explicitly shows how to do this for any > MIME-aware transport. Some of those might come with hashes that the > recipient are expected to check, but most of the common ones today are not. > I don't think that advice about sending hashes, checking hashes, ignoring > patches that don't come with hashes, and so on are any more applicable here > than to any other formats that could cause changes in system settings. > > Sure agreed, but it's common practice to do that sort of thing with patches, so mentioning the practice would be good since you are saying it's possible. I think it could be helpful to implementers to understand that option. Can you add a couple of sentences? Thanks. > --Paul Hoffman -- Best regards, Kathleen --001a11348b364f3b420501198559 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 20, 2014 at 9:08 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On Aug 18, 2014, at 1:58 PM,= Kathleen Moriarty <= kathleen.moriarty.ietf@gmail.com> wrote:

> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> The draft looks very good and the security considerations in RFC5789 > cover most of the bases I would be concerned with.=C2=A0 I do have a q= uestion
> I'd like to discuss to see if it applies or not.
>
> Normally, in other spaces patches are validated and that might be as > simple as making sure the hash of the patch provided by the source
> matches the value you calculated (not corrupted, *should* be from the<= br> > source you think it's from).=C2=A0 I don't see any mention of = this practice,
> is there a reason for that or should it be added?=C2=A0 Maybe it's= not
> possible because of how the patch is delivered over HTTP, but I figure= d
> it was worth flagging to discuss quickly.

The patches described in this document can be delivered however the i= mplementers want. The document explicitly shows how to do this for any MIME= -aware transport. Some of those might come with hashes that the recipient a= re expected to check, but most of the common ones today are not. I don'= t think that advice about sending hashes, checking hashes, ignoring patches= that don't come with hashes, and so on are any more applicable here th= an to any other formats that could cause changes in system settings.

Sure agreed, but it's common practice to do that sort of thing = with patches, so mentioning the practice would be good since you are saying= it's possible. =C2=A0I think it could be helpful to implementers to un= derstand that option. =C2=A0Can you add a couple of sentences?

Thanks.
--Paul Hoffman


<= br>
--

Best regards,
Kathleen<= /div>
--001a11348b364f3b420501198559-- From nobody Fri Aug 22 12:31:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7321A6FF0; Wed, 20 Aug 2014 19:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ_MzN4VOcpr; Wed, 20 Aug 2014 19:14:32 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A341A6FEF; Wed, 20 Aug 2014 19:14:31 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so7458716lbi.38 for ; Wed, 20 Aug 2014 19:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T8FqlHeJRzp23HtkWul73KAsc5Fr0UL6Ioa65SaJDdo=; b=iKF4zXrjI+oG6AfT5InGflpmtacaNlNv3/6krScNq6p0+RnRy1dlpJuj88I1NCrK6c EsKtSumKSZjpA4eQFPYjXWzws9nlbhZhMFAlaJjMWNXabkklMgF3tn4o/QTve52mODiO 6D3IR39ML57psi+ljTN5aqQW6Rj/vgSXWNcxHMegLp7K9ttjJa7Fw6cIfBDu0BeSFeej TOBG1djslLxFtKrODUwXjLheegchGjBB+3uucYjlJxUTZoK/9QxGMTZ+YKkVicS1lzCD 5ggQsVNaVy5HtX206gXJ/SODUT/bYogfcO7rqjyybeLSf3/6ecHea9aFUwx7VLd3M9W2 IfZw== MIME-Version: 1.0 X-Received: by 10.112.33.74 with SMTP id p10mr43123745lbi.0.1408587270173; Wed, 20 Aug 2014 19:14:30 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Wed, 20 Aug 2014 19:14:30 -0700 (PDT) In-Reply-To: References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> Date: Wed, 20 Aug 2014 22:14:30 -0400 Message-ID: From: Kathleen Moriarty To: James M Snell Content-Type: multipart/alternative; boundary=14dae94734a3dfb9c805011a47b5 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eAYM0cKL2cjv_oDgAoupnIKnPjA X-Mailman-Approved-At: Fri, 22 Aug 2014 12:31:21 -0700 Cc: draft-ietf-appsawg-json-merge-patch@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , Paul Hoffman , Apps Discuss , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 02:14:35 -0000 --14dae94734a3dfb9c805011a47b5 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 10:00 PM, James M Snell wrote: > > On Aug 20, 2014 6:50 PM, "Paul Hoffman" wrote: > > > [Snip] > > > > > I'm not sure I can add those sentences in a useful fashion. With current > delivery mechanisms (HTTP being the most common), MIME objects don't come > with hashes for checking. So giving that advice would cause developers to > look for something that they won't have, namely hashes of the MIME object > they just got. > > > > +1 > > > I do hope you're not asking us to change the format to include an > internal hash. That would require inventing JSON canonicalization (which > the JOSE WG has flailed miserably on) and say "canonicalize, pick a hash > function, hash, and add that to the patch object". The recipient would need > to pull the hash out before processing the patch, canonicalize the result, > and check the hash. This is conceptually possible but it seems onerous, and > has not been done in any of the earlier patch formats that have been > standardized in the IETF. > > > > +1... Adding an internal hash would not work with this mechanism without > taking a major step backwards. I do not see the value. > Not to worry, I wasn't asking for anything to be added other than text in the security considerations for when it was possible, keying off of your first response, "The document explicitly shows how to do this for any MIME-aware transport. Some of those might come with hashes that the recipient are expected to check, but most of the common ones today are not." Obviously, it would not be something required since it doesn't always get delivered, but I don't see a reason to exclude mention of this practice when it provides additional integrity checking when it is available. I guess I find it odd that this has not been done before, so I'm guessing there has not been security issues yet that caused an update in practices? Thanks. > - James > > > --Paul Hoffman > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Best regards, Kathleen --14dae94734a3dfb9c805011a47b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 20, 2014 at 10:00 PM, James M Snell &= lt;jasnell@gmail.com= > wrote:


On Aug 20, 2014 6:50 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:<= br> >
[Snip]


>
> I'm not sure I can add those sentences in a useful fashion. With c= urrent delivery mechanisms (HTTP being the most common), MIME objects don&#= 39;t come with hashes for checking. So giving that advice would cause devel= opers to look for something that they won't have, namely hashes of the = MIME object they just got.
>

+1

> I do hope you're not asking us to change the format= to include an internal hash. That would require inventing JSON canonicaliz= ation (which the JOSE WG has flailed miserably on) and say "canonicali= ze, pick a hash function, hash, and add that to the patch object". The= recipient would need to pull the hash out before processing the patch, can= onicalize the result, and check the hash. This is conceptually possible but= it seems onerous, and has not been done in any of the earlier patch format= s that have been standardized in the IETF.
>

+1... Adding an internal hash would not work with this= mechanism without taking a major step backwards. I do not see the value.

Not to worry, I wasn't asking for anything to be ad= ded other than text in the security considerations for when it was possible= , keying off of your first response, "The document explicitly shows how to do this fo= r any MIME-aware transport.=C2=A0Some of those might come with hashes that the recipient ar= e expected to check, but most of the common ones today are not." =C2= =A0Obviously, it would not be something required since it doesn't alway= s get delivered, but I don't see a reason to exclude mention of this pr= actice when it provides additional integrity checking when it is available.=

I g= uess I find it odd that this has not been done before, so I'm guessing = there has not been security issues yet that caused an update in practices?<= /span>

Thanks.

- James

> --Paul Hoffman
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss




--

Best regards,
Kathleen
--14dae94734a3dfb9c805011a47b5-- From nobody Fri Aug 22 12:31:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8041A8768; Thu, 21 Aug 2014 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCw06idiG7c; Thu, 21 Aug 2014 07:20:07 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849801A035D; Thu, 21 Aug 2014 07:20:06 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id el20so8714993lab.17 for ; Thu, 21 Aug 2014 07:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FcachUFSYBDz6lz9haExv6AhGif4Yes/735rRbJukTc=; b=CNWcjLmRc2xck6C5wWNKOKt0m1qzxufR8zvD8TYFHaUM5J+3mD/ce7JyiGLUQh+dOi OPR92e7v2VdxRnOv7Q7/9fzpJ5i6PD1u53OIvK3gtVLhzKiqx/h3TDiMQ8QDT2J2WbAz WWXIOPoUP2SRgbtm1rO5BCYNeBpWKS8YvDIv51kq71tYXzCElsQxW4DFtOX8cntpH9DX hdnBTQAi34YWsXVG8Z/nvEcC5G3nUcQnQL+GHJJ4BvofzRBx+lusnnmq+28Vz8sYRtz8 dLF0uLDTe/C5qPXDDIq31InUkeGPulB+0g2p9gNG3t3e8eIm0LgRYnW0+cIr9fUFHY60 1C3Q== MIME-Version: 1.0 X-Received: by 10.112.169.35 with SMTP id ab3mr46118219lbc.41.1408630804844; Thu, 21 Aug 2014 07:20:04 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 07:20:04 -0700 (PDT) In-Reply-To: References: <20140818205813.25342.9189.idtracker@ietfa.amsl.com> <5E1CE9A7-7425-4C77-9871-3B71A1CF4CC9@vpnc.org> <4F7A88C1-52AA-4F5A-8D56-722911C9C187@vpnc.org> Date: Thu, 21 Aug 2014 10:20:04 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2696abe16720501246a24 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CHq8wefgRXV7cbhAtT27ckRWxOY X-Mailman-Approved-At: Fri, 22 Aug 2014 12:31:21 -0700 Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-json-merge-patch@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] Kathleen Moriarty's Discuss on draft-ietf-appsawg-json-merge-patch-06: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 14:20:09 -0000 --001a11c2696abe16720501246a24 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 10:11 AM, Paul Hoffman wrote: > Pete Resnick hates it when I just roll over on DISCUSSes that I think will > make the document a bit worse, so I'll do another round on this, then > probably roll over. Your call. > Just looking for a reasonable explanation and appreciate the discussion. I don't want to see a change that doesn't make sense either and am happy to see a concern is unfounded if that's the case. I'd just rather make sure we address security concerns when needed. > > On Aug 20, 2014, at 7:14 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > Not to worry, I wasn't asking for anything to be added other than text > in the security considerations for when it was possible, keying off of your > first response, "The document explicitly shows how to do this for any > MIME-aware transport. Some of those might come with hashes that the > recipient are expected to check, but most of the common ones today are > not." Obviously, it would not be something required since it doesn't > always get delivered, but I don't see a reason to exclude mention of this > practice when it provides additional integrity checking when it is > available. > > There is a very good reason not to: it will likely cause false negative > rejections much more often than catching positives. JSON is a text format, > and this merge patch format creates patches small enough to easily be sent > around in email. Email clients tend to add or strip trailing whitespace and > change line ending characters; so does FTP. Thus, a hash will likely say > "this is bad" even when it is perfectly good. Thus, encouraging the use of > hash checking at all is causing more operational security errors. > This is very helpful and a good explanation as to why this should not be done, thank you. > > > I guess I find it odd that this has not been done before, so I'm > guessing there has not been security issues yet that caused an update in > practices? > > Correct. For JSON or XML, sending a hash and expecting systems to reject > messages because of text conversions is a bad practice. The best practice > of "check the hash on this patch" is quite appropriate for .tgz .zip > tarballs, and that's where you see it in the security community. > Yes, and it's also used when downloading source code (may be in those formats) to verify the integrity and source (assuming the provided hash wasn't altered too). I don't think I've seen a mismatch where code has been replaced by an attacker for a while, but that's probably because this is commonplace to check and source providers check their servers and what they provide hasn't been altered on regular intervals. I'll drop the discuss and hopefully this won't be an issue in this area or it will get fixed in the future. Thanks, Kathleen > > --Paul Hoffman -- Best regards, Kathleen --001a11c2696abe16720501246a24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 10:11 AM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
Pete Resnick hates it when I just roll over = on DISCUSSes that I think will make the document a bit worse, so I'll d= o another round on this, then probably roll over. Your call.
Just looking for a reasonable explanation and appreciate = the discussion. =C2=A0I don't want to see a change that doesn't mak= e sense either and am happy to see a concern is unfounded if that's the= case. =C2=A0I'd just rather make sure we address security concerns whe= n needed.

On Aug 20, 2014, at 7:14 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:=

> Not to worry, I wasn't asking for anything to be added other than = text in the security considerations for when it was possible, keying off of= your first response, "The document explicitly shows how to do this fo= r any MIME-aware transport. Some of those might come with hashes that the r= ecipient are expected to check, but most of the common ones today are not.&= quot;=C2=A0 Obviously, it would not be something required since it doesn= 9;t always get delivered, but I don't see a reason to exclude mention o= f this practice when it provides additional integrity checking when it is a= vailable.

There is a very good reason not to: it will likely cause false negati= ve rejections much more often than catching positives. JSON is a text forma= t, and this merge patch format creates patches small enough to easily be se= nt around in email. Email clients tend to add or strip trailing whitespace = and change line ending characters; so does FTP. Thus, a hash will likely sa= y "this is bad" even when it is perfectly good. Thus, encouraging= the use of hash checking at all is causing more operational security error= s.

This is very helpful and a good explanatio= n as to why this should not be done, thank you.=C2=A0

> I guess I find it odd that this has not been done before, so I'm g= uessing there has not been security issues yet that caused an update in pra= ctices?

Correct. For JSON or XML, sending a hash and expecting systems to rej= ect messages because of text conversions is a bad practice. The best practi= ce of "check the hash on this patch" is quite appropriate for .tg= z .zip tarballs, and that's where you see it in the security community.=

Yes, and it's also used when downloadi= ng source code (may be in those formats) to verify the integrity and source= (assuming the provided hash wasn't altered too). =C2=A0I don't thi= nk I've seen a mismatch where code has been replaced by an attacker for= a while, but that's probably because this is commonplace to check and = source providers check their servers and what they provide hasn't been = altered on regular intervals.

I'll drop the discuss and hopefully this won't = be an issue in this area or it will get fixed in the future.

=
Thanks,
Kathleen

--Paul Hoffman


<= br>
--

Best regards,
Kathleen<= /div>
--001a11c2696abe16720501246a24-- From nobody Fri Aug 22 12:31:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146E51A035D; Thu, 21 Aug 2014 07:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dcimGg35Ta7; Thu, 21 Aug 2014 07:21:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 423891A8768; Thu, 21 Aug 2014 07:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821142121.27978.40314.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 07:21:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Lzq-9DbiknxJBXfymtW91LcF_U0 X-Mailman-Approved-At: Fri, 22 Aug 2014 12:31:21 -0700 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-json-merge-patch-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:21:25 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-appsawg-json-merge-patch-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion on checking the integrity of received patches, it was helpful. From nobody Fri Aug 22 12:32:19 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748231A8A01; Thu, 21 Aug 2014 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5VtlzagsZsk; Thu, 21 Aug 2014 13:36:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA691A89FF; Thu, 21 Aug 2014 13:36:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PBN75HA9CW001XFT@mauve.mrochek.com>; Thu, 21 Aug 2014 13:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1408653087; bh=yrvhfNGaR/3GPobPf1G//o/LZb1Lo0s5VGCN8UoTYXs=; h=Cc:Date:From:Subject:In-reply-to:To; b=gnEbvke/vL1Qc1tPRxSoNI+RrOiBKKgo7yY8QNooIhxG0S8EtK4FmyPohzxeM+6E9 KuAzPo2lte853ExlT34vPwNADF1SehZ5f6syKpE64u99+xJthp138R58X3V5xppDG9 cQo2MW59rcN1uGf4hfHwSOcsbKLVLfe6wjS7tSRY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PBEHSSJOO00000SM@mauve.mrochek.com>; Thu, 21 Aug 2014 13:31:24 -0700 (PDT) Message-id: <01PBN75FQ1CQ0000SM@mauve.mrochek.com> Date: Thu, 21 Aug 2014 13:25:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 20 Aug 2014 17:15:51 -0700" Sender: Ned Freed To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/otPcLGHLh_OgWxG-Lna671zgWWk X-Mailman-Approved-At: Fri, 22 Aug 2014 12:32:15 -0700 Cc: "dmarc@ietf.org" , Apps Discuss Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Aug 2014 20:36:31 -0000 > The list of milestones and deliverables looks good to me. Having not > participated in an IETF working group before, I have process oriented > questions. > Am I a part of the working group by being a member of the dmarc@ietf.org > list? Yes. The IETF doesn't have a concept of membership; you either participate or you don't. > How do I contribute to the working group, will the chairs ask for input at > specific times or for volunteers to write specific pieces of documents? Both of those things will probably happen, but that's in addition to general list discussions on current topics relevant to the goals of the group. > How does the working group decide that any given suggestion warrants > inclusion in a deliverable or a base spec change or some other action? When there's a rough consensus among the participants to do so. Usually it's pretty obvious whether something is supported or not, but it's up to the WG chairs to make the close calls. Ned P.S. You might want to take a look at "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", available here: http://www.ietf.org/tao.html From nobody Sat Aug 23 10:03:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65D51A04F6 for ; Sat, 23 Aug 2014 10:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWTGQqi90IoM for ; Sat, 23 Aug 2014 10:03:44 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0016.outbound.protection.outlook.com [213.199.154.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAE91A064A for ; Sat, 23 Aug 2014 10:03:43 -0700 (PDT) Received: from pc6 (109.147.210.26) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Sat, 23 Aug 2014 17:03:41 +0000 Message-ID: <00db01cfbef4$0d85bd80$4001a8c0@gateway.2wire.net> From: t.petch To: John C Klensin , References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> Date: Sat, 23 Aug 2014 17:54:43 +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-Originating-IP: [109.147.210.26] X-ClientProxiedBy: AM3PR03CA012.eurprd03.prod.outlook.com (10.141.191.140) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 031257FE13 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(2473001)(377454003)(51704005)(24454002)(51914003)(51444003)(199003)(64706001)(86362001)(77096002)(33646002)(20776003)(42186005)(14496001)(93916002)(23756003)(44716002)(50226001)(62236002)(4396001)(79102001)(85306004)(66066001)(80022001)(93886004)(47776003)(85852003)(50466002)(92566001)(74662001)(74502001)(31966008)(230783001)(77156001)(89996001)(92726001)(21056001)(83072002)(61296003)(90102001)(87976001)(101416001)(88136002)(81686999)(76176999)(50986999)(87286001)(99396002)(81816999)(84392001)(81342001)(102836001)(105586002)(81542001)(19580395003)(77982001)(83322001)(107886001)(19580405001)(106356001)(46102001)(107046002)(62966002)(95666004)(76482001)(104166001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K3vGIhNch4US36vm3-OnYKJrOnk Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Aug 2014 17:03:47 -0000 ----- Original Message ----- From: "John C Klensin" To: "t.petch" ; Sent: Friday, August 22, 2014 6:13 PM > > --On Friday, August 22, 2014 16:42 +0100 "t.petch" > wrote: > > > John > > > > "The SMTP specification [RFC5321] (referred to, along with its > > various updates, as "SMTP" below) contains a list and > > discussion of error codes. " > > > > Well no - error code does not appear in RFC5321, it is reply > > code as the rest of this I-D uses; and yes, I think that this > > is a source of potential confusion even among the target > > audience and needs changing. > > Thanks for the careful reading. "error code" has been changed > to "reply code" in -01. The term "error" does appear in other > places in the document, but only in context with error status > (e.g., "any attempt to send mail here is obviously a mistake > somewhere") or a 5yz code, which 5321 does refer to as an error > status. I'm inclined to leave those alone. If you think they > would be better changed as well, please say so. John I too would leave those other errors alone; it was just the combination of 'error' and 'code' where RFC5321 s.4.2 is all about 'reply code' which could have caused some head scratching for a punctilious but not quite expert reader (the expert would of course know that 'error code' never appears in any SMTP document and would have unconsciously emended it). Tom Petch > john > > > > > From nobody Sat Aug 23 17:28:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE361A6F04 for ; Sat, 23 Aug 2014 17:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhjR6gcHccBB for ; Sat, 23 Aug 2014 17:28:06 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C2C1A6EF6 for ; Sat, 23 Aug 2014 17:28:06 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XLLf6-000D8E-8T; Sat, 23 Aug 2014 20:28:00 -0400 Date: Sat, 23 Aug 2014 20:27:59 -0400 From: John C Klensin To: "t.petch" , apps-discuss@ietf.org Message-ID: In-Reply-To: <00db01cfbef4$0d85bd80$4001a8c0@gateway.2wire.net> References: <20140820200841.7193.84459.idtracker@ietfa.amsl.com> <53F5AB35.9080601@it.aoyama.ac.jp> <008201cfbe1f$a5d1fde0$4001a8c0@gateway.2wire.net> <00db01cfbef4$0d85bd80$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/TaKHLvMon0qO7o_AsqRXVWuJeFk Subject: Re: [apps-discuss] Fwd: I-D Action:draft-klensin-smtp-521code-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2014 00:28:08 -0000 --On Saturday, 23 August, 2014 17:54 +0100 "t.petch" wrote: > ----- Original Message ----- > From: "John C Klensin" > To: "t.petch" ; > Sent: Friday, August 22, 2014 6:13 PM >> >> --On Friday, August 22, 2014 16:42 +0100 "t.petch" >> wrote: >> >> > John >> > >> > "The SMTP specification [RFC5321] (referred to, along with >> > its various updates, as "SMTP" below) contains a list and >> > discussion of error codes. " >> > >> > Well no - error code does not appear in RFC5321, it is reply >> > code as the rest of this I-D uses; and yes, I think that >> > this is a source of potential confusion even among the >> > target audience and needs changing. >> >> Thanks for the careful reading. "error code" has been changed >> to "reply code" in -01. The term "error" does appear in >> other places in the document, but only in context with error >> status (e.g., "any attempt to send mail here is obviously a >> mistake somewhere") or a 5yz code, which 5321 does refer to >> as an error status. I'm inclined to leave those alone. If >> you think they would be better changed as well, please say so. > > John > > I too would leave those other errors alone; it was just the > combination of 'error' and 'code' where RFC5321 s.4.2 is all > about 'reply code' which could have caused some head > scratching for a punctilious but not quite expert reader (the > expert would of course know that 'error code' never appears in > any SMTP document and would have unconsciously emended it). Good. As you have probably noticed, -01 has been posted with changes consistent with the above. thanks, john From nobody Sun Aug 24 11:24:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04D11A0650; Sun, 24 Aug 2014 11:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3c7qg26mZ_Z; Sun, 24 Aug 2014 11:24:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A44701A0657; Sun, 24 Aug 2014 11:24:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140824182443.24522.31337.idtracker@ietfa.amsl.com> Date: Sun, 24 Aug 2014 11:24:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nI-QdrELJDHAD96t3tY4AUF6KSE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 18:24:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-04.txt Pages : 12 Date : 2014-08-24 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 24 11:33:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44A41A0650 for ; Sun, 24 Aug 2014 11:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te0PRNdDjCLa for ; Sun, 24 Aug 2014 11:33:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8CE1A064D for ; Sun, 24 Aug 2014 11:33:21 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Sun, 24 Aug 2014 18:33:20 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.1015.018; Sun, 24 Aug 2014 18:33:20 +0000 From: Larry Masinter To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-04.txt Thread-Index: Ac+/ydoaT/NwT+54S529yYTA5ZcfRA== Date: Sun, 24 Aug 2014 18:33:19 +0000 Message-ID: <27a643c15f1344d69309558c6134f299@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2601:9:8380:992:5883:f685:4df9:b5] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(13464003)(51704005)(377454003)(377424004)(105586002)(99396002)(2351001)(107046002)(107886001)(19580395003)(95666004)(99286002)(86362001)(31966008)(83322001)(50986999)(15975445006)(110136001)(74502001)(54356999)(2656002)(74662001)(19580405001)(106356001)(81542001)(46102001)(15202345003)(77982001)(76576001)(16601075003)(85306004)(81342001)(101416001)(33646002)(76482001)(87936001)(4396001)(230783001)(20776003)(108616004)(92566001)(64706001)(83072002)(79102001)(85852003)(90102001)(80022001)(21056001)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/apX1JYqW-Wgm2K-jcD-QlPD3S7U Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Aug 2014 18:33:25 -0000 SSBkaWRuJ3QgZ2V0IG11Y2ggZmVlZGJhY2sgb24gdGhpcywgYWZ0ZXIgYWxsLiANCkkgd2VudCBh aGVhZCBtYWRlIGFub3RoZXIgcGFzcy4NCg0KQXQgdGhpcyBwb2ludCAtLSBXR0xDIHNlZW1zIGxp a2UgdGhlIGJlc3Qgd2F5IHRvIHRyeSB0byBnZXQgc29tZSByZXZpZXcuLi4gDQpIYXZlIGF0IGl0 Lg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1 c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZw0KPiBTZW50OiBTdW5kYXksIEF1Z3VzdCAyNCwgMjAxNCAxMToyNSBBTQ0KPiBUbzogaS1k LWFubm91bmNlQGlldGYub3JnDQo+IENjOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVj dDogW2FwcHMtZGlzY3Vzc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLW11bHRpcGFy dC1mb3JtLQ0KPiBkYXRhLTA0LnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmll cy4NCj4gIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEFwcGxpY2F0aW9ucyBBcmVh IFdvcmtpbmcgR3JvdXANCj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogUmV0dXJuaW5nIFZhbHVlcyBmcm9tIEZvcm1zOiBtdWx0aXBh cnQvZm9ybS1kYXRhDQo+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogTGFycnkgTWFzaW50ZXIN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYXBwc2F3Zy1tdWx0aXBhcnQtZm9ybS1k YXRhLTA0LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTINCj4gCURhdGUgICAgICAgICAgICA6 IDIwMTQtMDgtMjQNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIHNwZWNpZmljYXRpb24gKHJl KWRlZmluZXMgdGhlIG11bHRpcGFydC9mb3JtLWRhdGEgSW50ZXJuZXQgTWVkaWENCj4gICAgVHlw ZSwgd2hpY2ggY2FuIGJlIHVzZWQgYnkgYSB3aWRlIHZhcmlldHkgb2YgYXBwbGljYXRpb25zIGFu ZA0KPiAgICB0cmFuc3BvcnRlZCBieSBhIHdpZGUgdmFyaWV0eSBvZiBwcm90b2NvbHMgYXMgYSB3 YXkgb2YgcmV0dXJuaW5nIGENCj4gICAgc2V0IG9mIHZhbHVlcyBhcyB0aGUgcmVzdWx0IG9mIGEg dXNlciBmaWxsaW5nIG91dCBhIGZvcm0uICBJdA0KPiAgICByZXBsYWNlcyBSRkMgMjM4OC4NCj4g DQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdn LW11bHRpcGFydC1mb3JtLQ0KPiBkYXRhLw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYXBwc2F3Zy1tdWx0aXBhcnQtZm9ybS1kYXRhLTA0DQo+IA0KPiBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXBwc2F3Zy1tdWx0aXBhcnQtZm9ybS0NCj4gZGF0 YS0wNA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4g DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From nobody Sun Aug 24 15:40:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0C1A8862; Sun, 24 Aug 2014 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Uia8QzsZlh; Sun, 24 Aug 2014 15:40:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016611A885E; Sun, 24 Aug 2014 15:40:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7OMeC0s031556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Aug 2014 15:40:16 -0700 Message-ID: <53FA692E.1040503@dcrocker.net> Date: Sun, 24 Aug 2014 15:37:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen , Apps Discuss , dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 24 Aug 2014 15:40:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qcgylcYggi9nEXXYoHpa5D_dBk4 Subject: Re: [apps-discuss] Start of DMARC WG + proposed milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 22:40:21 -0000 On 8/18/2014 8:31 AM, Tim Draegen wrote: > If you have comments on the milestones, please provide them by August 25th. Have fun, Mostly small, suggested wording tweaks, to improve clarity and possibly avoid some unnecessary points of controversy. There's one (???) with a change I think is correct. If it isn't the reason needs to be made explicit. > [1] http://datatracker.ietf.org/wg/dmarc/charter/ > Domain-based Message Authentication, Reporting & Conformance (DMARC) > uses existing mail authentication technologies (SPF and DKIM) to > extend validation to the RFC5322.From field. DMARC uses DNS records to extend -> and extends DKIM and SPF don't do the extending. DMARC does. DKIM and SPF are merely underpinnings. > to add policy-related requests for receivers and defines a feedback > mechanism from receivers back to domain owners. This allows a domain > owner to advertise that mail can safely receive differential > handling, such as rejection, when the use of the domain name in the > From field is not authenticated. Existing deployment of DMARC has > demonstrated utility at internet scale, in dealing with significant internet -> Internet > email abuse, and has permitted simplifying some mail handling > processes. However, DMARC is problematic for mail that does not flow for mail that does not flow -> for indirect mail flows that are not > from operators having a relationship with the domain owner, directly directly -> and directl ('direct' vs. 'indirect' is an essential issue and the terminology needs to be established here, to make the late use clear.) > to receivers operating the destination mailbox (for example, mailing mailbox ( for mailing -> mailbox. Examples include mailing > lists, publish-to-friend functionality, mailbox forwarding via > ".forward", and third-party services that send on behalf of clients). > The working group will explore possible updates and extensions to the > specifications in order to address limitations and/or add specifications -> specifications > capabilities. It will also provide technical implementation guidance > and review possible enhancements elsewhere in the mail handling > sequence that could improve DMARC compatibility. > > The existing DMARC base specification has been submitted as an > Independent Submission to become an Informational RFC. > > Specifications produced by the working group will ensure preservation > of DMARC utility for detecting unauthorized use of domain names, hmmm. on reflection, this works better as a positve: utility for detecting authorized use of domain names Use for detecting unauthorized use is far more complicated and potentially controversial. Use for detecting authorized use is straightforward. > while improving the identification of legitimate sources that do not > currently conform to DMARC requirements. Issues based on operational > experience and/or data aggregated from multiple sources will be given > priority. > > The working group will seek to preserve interoperability with the > installed base of DMARC systems, and provide detailed justification > for any non-interoperability. As the working group develops solutions > to deal with indirect mail flows, it will seek to maintain the > end-to-end nature of existing identifier fields in mail, in > particular avoiding solutions that require rewriting of originator > fields. > > Working group activities will pursue three tracks: > > 1. Addressing the issues with indirect mail flows > > The working group will specify mechanisms for reducing or eliminating > the DMARC's effects on indirect mail flows, including deployed delete [the] > behaviors of many different intermediaries, such as mailing list > managers, automated mailbox forwarding services, and MTAs that > perform enhanced message handling that results in message handling that -> handling, which (if only to reduce the number of 'that's in the sentence...) > modification. Among the choices for addressing these issues are: > > - A form of DKIM signature that is better able to survive transit > through intermediaries. > > - Collaborative or passive transitive mechanisms that enable an > intermediary to participate in the trust sequence, propagating > authentication directly or reporting its results. > > - Message modification by an intermediary, to avoid authentication > failures, such as by using specified conventions for changing > the aligned identity. > > Consideration also will be given to survivable authentication through > sequences of multiple intermediaries. > > 2. Reviewing and improving the base DMARC specification > > The working group will not develop additional mail authentication > technologies, but may document authentication requirements that are document authentication -> document additional authentication (???) > desirable. If they are 'desireable' they are not 'requirements'. If they are requirements they are not merely desirable. Perhaps: but can consider additional authentication-related issues that are desirable. > The base specification relies on the ability of an email receiver to > determine the organizational domain responsible for sending mail. An > organizational domain is the 'base' name that is allocated from a > public registry; examples of registries include ".com" or ".co.uk". > While the common practice is to use a "public suffix" list to > determine organizational domain, it is widely recognized that this > solution will not scale, and that the current list often is > inaccurate. The task of defining a standard mechanism for identifying > organizational domain is out of scope for this working group. However > the working group can consider extending the base DMARC specification > to accommodate such a standard, should it be developed during the > life of this working group. > > Improvements in DMARC features (identifier alignment, reporting, > policy preferences) will be considered, such as: > > - Enumeration of data elements required in "Failure" reports > (specifically to address privacy issues) > - Handling potential reporting abuse > - Aggregate reporting to support additional reporting scenarios > - Alternate reporting channels > - Utility of arbitrary identifier alignment > - Utility of a formalized policy exception mechanism > > 3. DMARC Usage > > The working group will document operational practices in terms of > configuration, installation, monitoring, diagnosis and reporting. It > will catalog currently prevailing guidelines as well as developing > advice on practices that are not yet well-established but which are > believed to be appropriate. > > The group will consider separating configuration and other deployment > information that needs to be in the base spec, from information that > should be in a separate guide. > > Among the topics anticipated to be included in the document are: > > - Identifier alignment configuration options > - Implementation decisions regarding "pct" > - Determining effective RUA sending frequency > - Leveraging policy caching > - Various options for integrating within an existing flow > - Defining a useful, common set of options for the addresses to > which feedback reports are to be sent > - When and how to use local policy override options > > Work Items > ---------- > > Phase I: > > Draft description of interoperability issues for indirect mail > flows and plausible methods for reducing them. > > Phase II: > > Specification of DMARC improvements to support indirect mail flows > > Draft Guide on DMARC Usage > > Phase III: > > Review and refinement of the DMARC specification > > Completion of Guide on DMARC Usage > > References > ---------- > > DMARC - http://dmarc.org DMARC -> DMARC general Add: DMARC - https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ so there is an explicit reference to the specification. > SPF - RFC7208 > Authentication-Results Header Field - RFC7001 > DKIM - RFC6376 > Internet Message Format - RFC5322 > OAR / Original Authentication Results - > draft-kucherawy-original-authres > Using DMARC - draft-crocker-dmarc-bcp-03 > Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 > DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 > [2] https://www.ietf.org/mailman/listinfo/dmarc > [3] http://trac.tools.ietf.org/wg/dmarc/trac/wiki > [4] http://trac.tools.ietf.org/wg/dmarc/trac/roadmap -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 24 17:19:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6121A88C5 for ; Sun, 24 Aug 2014 17:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDJEVAv3tp65 for ; Sun, 24 Aug 2014 17:19:34 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC51A88C7 for ; Sun, 24 Aug 2014 17:19:32 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 44FCA563E36; Sun, 24 Aug 2014 19:19:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3E087A0562; Sun, 24 Aug 2014 19:19:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYCKCmsWUpvB; Sun, 24 Aug 2014 19:19:32 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 017C3A056A; Sun, 24 Aug 2014 19:19:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D354AA0569; Sun, 24 Aug 2014 19:19:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6RkhGBnGtwR9; Sun, 24 Aug 2014 19:19:31 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 9EDBCA0562; Sun, 24 Aug 2014 19:19:31 -0500 (CDT) Date: Sun, 24 Aug 2014 19:19:30 -0500 (CDT) From: Franck Martin To: IETF Apps Discuss Message-ID: <995209307.6642.1408925970696.JavaMail.zimbra@peachymango.org> In-Reply-To: <794363704.6604.1408925563387.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6641_1501649493.1408925970696" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF31 (Mac)/8.0.5_GA_5839) Thread-Topic: Review of draft-ietf-appsawg-authres-ptypes-registry Thread-Index: F4B2Tn/qS2J1EE9wApY7mlfDT60qSQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GmEvS7P6fPVuXx31ToHRfR9FmXg Subject: [apps-discuss] Review of draft-ietf-appsawg-authres-ptypes-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2014 00:19:39 -0000 ------=_Part_6641_1501649493.1408925970696 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I reviewed in full the document draft-ietf-appsawg-authres-ptypes-registry and I have the following comments: While the document indicates the limitation of the ptype, it does not explain why it needs to be extended. I propose the following text to be used in the introduction, to replace the last paragraph (but I can live without this change): -- [RFC7001] ptypes were defined based on the current authentication methods that are in use at the time of the creation of this specification. Since then, some new authentication methods have emerged or are becoming in use. For instance more emails are encrypted or sent over encrypted sessions. While encryption provides authorization, it also provides some forms of authentication. The properties of such authentication methods are sometimes outside current electronic mail message properties. This document updates the specification to allow for additional property types ("ptypes") beyond the original set, and creates a registry where new ones can be listed and their defining documents referenced. -- I also checked that this specification would allow draft-martin-authentication-results-tls if adopted. This document provides a minimal change to RFC7001, therefore my limited comments/review. ------=_Part_6641_1501649493.1408925970696 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I reviewed in full the document draft-ietf-ap= psawg-authres-ptypes-registry and I have the following comments:
<= div>
While the document indicates the limitation of the ptype= , it does not explain why it needs to be extended.

I prop= ose the following text to be used in the introduction, to replace the last = paragraph (but I can live without this change):
--
[RFC7001] ptypes w= ere defined based on the current authentication methods that are in use at = the time of the creation of this specification. Since then, some new authen= tication methods have emerged or are becoming in use.  For instance mo= re emails are encrypted or sent over encrypted sessions. While encryption p= rovides authorization, it also provides some forms of  authentication.= The properties of such authentication methods are sometimes outside curren= t electronic mail message properties.

This document upda= tes the specification to allow for additional property types ("ptypes") bey= ond the original set, and creates a registry where new ones can be listed a= nd their defining documents referenced.
--

= I also checked that this specification would allow draft-martin-authenticat= ion-results-tls if adopted.

This document provides= a minimal change to RFC7001, therefore my limited comments/review.


------=_Part_6641_1501649493.1408925970696-- From nobody Sun Aug 24 23:13:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705B71A8A7C; Sun, 24 Aug 2014 23:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O78zW1L7Mzb7; Sun, 24 Aug 2014 23:13:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 459011A8A78; Sun, 24 Aug 2014 23:13:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825061322.10523.37274.idtracker@ietfa.amsl.com> Date: Sun, 24 Aug 2014 23:13:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PJDaTxykllzXoCq6QZF9ljk1tAE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:13:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A Property Types Registry for the Authentication-Results Header Field Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-authres-ptypes-registry-01.txt Pages : 5 Date : 2014-08-24 Abstract: [RFC7001] describes a header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, mainly Mail Transfer Agents (MTAs) or mail filters, can add or use this header field to relay that information in a convenient and meaningful way to later-stage systems, such as for sorting and filtering decisions. One portion of the definition in that document limits the types of authentication properties about a message to a small, fixed set. This document updates the specification, making it extensible to allow new property types to be declared and used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-authres-ptypes-registry-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-authres-ptypes-registry-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 24 23:26:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D71A8A8B for ; Sun, 24 Aug 2014 23:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOrUiCyP3_YI for ; Sun, 24 Aug 2014 23:26:54 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D792C1A8A89 for ; Sun, 24 Aug 2014 23:26:53 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so11428748lbi.41 for ; Sun, 24 Aug 2014 23:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7T5p3h5nu39ERV1LyNtupFkoLEixvCOD8stMe8AeJds=; b=FV5mnnpuJqPhNXDKGMwTofEqSkwoa2Ks9rusZK2gvTrZlSRC3UCFNZm4BOQiSAgXYY 6xTJdeFITG162tcseG+kiwZWrgProrM+o22HMUMNuGO0ZaWaJxtWjcTJOIi86vsC6r5z szZ8uWGRBV+eDA2kCuYmiv1BN4we0vQoQ4PhhwjufNnE4+gL4RQ/8H8Wid5kNd9IpKLt ALvpBLmIpLAZolunI4bXntJiLXJb6M6wn/Az1eR1WaXfJMAXfmytOnPDapXYWqNTev81 i4uC6oQu/pwgO05N6VqlL8lL8xvbkr8LJXJUhiZZaiTtPegLsffDgg581S47WL09AOzn eWoQ== MIME-Version: 1.0 X-Received: by 10.112.225.7 with SMTP id rg7mr18068984lbc.52.1408948012195; Sun, 24 Aug 2014 23:26:52 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Sun, 24 Aug 2014 23:26:52 -0700 (PDT) In-Reply-To: <995209307.6642.1408925970696.JavaMail.zimbra@peachymango.org> References: <794363704.6604.1408925563387.JavaMail.zimbra@peachymango.org> <995209307.6642.1408925970696.JavaMail.zimbra@peachymango.org> Date: Sun, 24 Aug 2014 23:26:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a11348d4ec6241b05016e45a2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BpmRXUHfoGcq_NTBkQWK3eJqYxc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-authres-ptypes-registry X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2014 06:26:55 -0000 --001a11348d4ec6241b05016e45a2 Content-Type: text/plain; charset=UTF-8 Hi Franck, thanks for your review. On Sun, Aug 24, 2014 at 5:19 PM, Franck Martin wrote: > While the document indicates the limitation of the ptype, it does not > explain why it needs to be extended. > > I propose the following text to be used in the introduction, to replace > the last paragraph (but I can live without this change): > [...] > Since you said you're okay with not making this change, I think I'm going to leave it out. While your proposed text is accurate, I don't think it's necessary to include. For one thing, if one looks at the contents of the registry (shortly after it's created), it'll be obvious why the extension was needed. The rest of your proposal talks about the registry creation and what will be in it, but that's already clear from IANA Considerations, and is generally why we create keyword registries anyway. -MSK --001a11348d4ec6241b05016e45a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Franck, thanks for your review.

On Sun, Aug 24, = 2014 at 5:19 PM, Franck Martin <franck@peachymango.org>= wrote:
While the document indicates the limitation of the ptype, it does not expla= in why it needs to be extended.

I propose the follow= ing text to be used in the introduction, to replace the last paragraph (but= I can live without this change):
[...]

Since you said = you're okay with not making this change, I think I'm going to leave= it out.=C2=A0 While your proposed text is accurate, I don't think it&#= 39;s necessary to include.=C2=A0 For one thing, if one looks at the content= s of the registry (shortly after it's created), it'll be obvious wh= y the extension was needed.

The rest of your proposal talks about the registry creation = and what will be in it, but that's already clear from IANA Consideratio= ns, and is generally why we create keyword registries anyway.

-MSK
--001a11348d4ec6241b05016e45a2-- From nobody Mon Aug 25 00:08:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A341A8AAD; Mon, 25 Aug 2014 00:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSdGYjJZIvFr; Mon, 25 Aug 2014 00:08:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF761A8AAE; Mon, 25 Aug 2014 00:08:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825070820.11509.43466.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 00:08:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qS9dGSN__NsszX0vsul7gbCm4UE Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:08:33 -0000 X-List-Received-Date: Mon, 25 Aug 2014 07:08:33 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Mon Aug 25 00:29:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24FE1A8AB9 for ; Mon, 25 Aug 2014 00:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.911 X-Spam-Level: * X-Spam-Status: No, score=1.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2fgbDxGDGVA for ; Mon, 25 Aug 2014 00:28:58 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE5D1A8AB7 for ; Mon, 25 Aug 2014 00:28:57 -0700 (PDT) Received: internal info suppressed Date: Mon, 25 Aug 2014 09:28:55 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1408951735; bh=r0wX2ZABeYb67vv59pYpXCYngAfGqGRJ8qUDe/WdFwM=; h=Date:From:To:Subject; b=S7KnEjzaCRa1mVSTdTVeQsfCiQiLBxa1spei9ZyIe/LF7QaZdrjSRDZyA595ZnlTa ZP97pFl68FgBj4IYxvlCqnGQRCDvIbYnwoH6ijBsgdQs8pRH5rgky4538kvkdsrRR2 TTXbSpN7fwAt2alyVCbqFMlC1NzRaS9WJ/pCUFoo= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/US5tiBJDGM9aHCG0YroJ6vTRUWA Subject: [apps-discuss] spam via the IETF Tools - was: draft-ietf-mixer-mail11 (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2014 07:29:00 -0000 ... it seems that spammers have discovered the IETF Tools set, and inserted it into their address books... This is the first case I see (from a draft which is at least 20 years old!). Maybe we should check how to protect the Tools set... ;-) ------------------------------------------------------------------------------ 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 ---------- Forwarded message ---------- Date: Mon, 25 Aug 2014 00:28:38 +0000 From: guerac87@gmail.com To: "draft-ietf-mixer-mail11@tools.ietf.org" Cc: Kennessy Irwin Tomlinson <1dlover572@gmail.com> Subject: draft-ietf-mixer-mail11 Resent-Date: Mon, 25 Aug 2014 00:29:32 +0000 (GMT) Resent-From: draft-alias-bounces@tools.ietf.org Resent-To: claudio.allocchio@elettra.eu Sent from Windows Mail From nobody Mon Aug 25 08:02:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E181A9096 for ; Mon, 25 Aug 2014 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li3CsvJkom7u; Mon, 25 Aug 2014 08:02:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDD81A909F; Mon, 25 Aug 2014 08:02:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825150224.15984.2622.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 08:02:24 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PYaes9OFf4vDQyzBvuCm4Md04Jg Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:02:28 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Mon Aug 25 11:05:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF931A01EB for ; Mon, 25 Aug 2014 11:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jESnPtQRalbh; Mon, 25 Aug 2014 11:05:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FC1A0151; Mon, 25 Aug 2014 11:05:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825180538.8998.95819.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 11:05:38 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YYXjTSn_7Rr1n5eI_pRoMj0aU9g Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:05:45 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Mon Aug 25 11:22:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8D01A0263 for ; Mon, 25 Aug 2014 11:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjAr0ryIYGjU for ; Mon, 25 Aug 2014 11:22:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 477231A0255 for ; Mon, 25 Aug 2014 11:22:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B1E72BDF7 for ; Mon, 25 Aug 2014 19:21:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jYIshfp7rKc for ; Mon, 25 Aug 2014 19:21:58 +0100 (IST) Received: from [10.87.48.7] (unknown [86.41.56.186]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09875BDD7 for ; Mon, 25 Aug 2014 19:21:58 +0100 (IST) Message-ID: <53FB7EC5.9060202@cs.tcd.ie> Date: Mon, 25 Aug 2014 19:21:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Apps Discuss References: <53FB7E79.3040608@cs.tcd.ie> In-Reply-To: <53FB7E79.3040608@cs.tcd.ie> X-Forwarded-Message-Id: <53FB7E79.3040608@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Kjx5taiH55uexdRw-yZMZj2JqSE Subject: [apps-discuss] Fwd: [saag] new list for discussion of end-to-end email security/privacy improvements X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Aug 2014 18:22:02 -0000 FYI -------- Forwarded Message -------- Subject: [saag] new list for discussion of end-to-end email security/privacy improvements Date: Mon, 25 Aug 2014 19:20:41 +0100 From: Stephen Farrell To: saag@ietf.org Hi all, Following on from discussion in Toronto in appaswg and saag, and a subsequent request, we've created a mailing list for discussing this topic. Pete Resnick and I will initially manage the list. If you're interested, please subscribe. Once Pete and I figure there's a good enough set of folks subscribed we'll fire off a starter email. That usually takes a few days, so probably Wed-Thu this week. The list [1] description is: There is significant interest in improving the privacy-related properties of Internet mail. One focus of current efforts is on the per-hop (connection-based) protections provided by TLS. However a wide range of other work has a focus on end-to-end protection, at the Internet scale of billions of end users and perhaps millions of operators. Such work typically involves new forms of mail header or body protection, new public key management (compared to S/MIME or PGP), and security mechanisms more appropriate for mobile/web user-agents. Other security-relevant approaches may be discussed if needed. Various proposals and development efforts on this topic are underway outside the IETF. This mailing list provides an IETF venue for discussion of elements that might be commonly needed by such efforts and to identify work that the IETF could do to aid in achieving better end-to-end security deployed for Internet email. Cheers, S. [1] https://www.ietf.org/mailman/listinfo/endymail _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Mon Aug 25 16:07:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6B1A0450 for ; Mon, 25 Aug 2014 16:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVVmIJ8w_PDU; Mon, 25 Aug 2014 16:07:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 432801A0465; Mon, 25 Aug 2014 16:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825230647.8318.46480.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 16:06:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/A_UNldFJ0vM1Q7a13L27BEQR8W4 Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:07:03 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Tue Aug 26 01:05:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F161A0AF7 for ; Tue, 26 Aug 2014 01:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXtq_6fw8HZd; Tue, 26 Aug 2014 01:05:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACBB1A0AFC; Tue, 26 Aug 2014 01:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826080528.18880.75471.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 01:05:28 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Ysg0zzvBXCoNdIAFeFbBvzTfbJw Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:05:29 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Tue Aug 26 13:58:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6C61A87E1; Tue, 26 Aug 2014 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWhc0BdguxHq; Tue, 26 Aug 2014 13:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA01A887E; Tue, 26 Aug 2014 13:58:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826205838.19152.1118.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 13:58:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/e65jrrK2LAqBT8enMedTDpoA-ys Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-authres-ptypes-registry-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:58:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A Property Types Registry for the Authentication-Results Header Field Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-authres-ptypes-registry-02.txt Pages : 5 Date : 2014-08-26 Abstract: [RFC7001] describes a header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, mainly Mail Transfer Agents (MTAs) or mail filters, can add or use this header field to relay that information in a convenient and meaningful way to later-stage systems, such as for sorting and filtering decisions. One portion of the definition in that document limits the types of authentication properties about a message to a small, fixed set. This document updates the specification, making it extensible to allow new property types to be declared and used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-authres-ptypes-registry-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-authres-ptypes-registry-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 27 10:07:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBB21A212A; Wed, 27 Aug 2014 10:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va-BlnSPaSaZ; Wed, 27 Aug 2014 10:07:06 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3096C1A0BEC; Wed, 27 Aug 2014 10:06:59 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so393165obc.26 for ; Wed, 27 Aug 2014 10:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=IJGcJbrj1sO9cS7jt9Cl2Aut4OtGFsQmKV3UAczu73E=; b=QGUPiZuD9LNZCBCqWI9+Qq0VIeCNorDF9WykT/PbxrRtzDQR5GwGJu7FZnaxILe0vb uH1QMnd1flI7/GDMi6k030R6pd8BLOvfNnTF1O4lcQ5pban4cuod7UgNUyQBDTkfLH1e 1e1d/80ZnLMbhA31Y1EX0Buh6D2Z1pf81Ql26lte/LJp9ochIiNe9axsCxCewoMOKV9G 4vRsvqXjGtWtx5kUPDGI8+SvBmoxPJG8bKLWyGVzQ2IlApMJfBwipW8G7zIlyfMt/ecD KFSFU6oUyn3ZLBYHbVs2NmvRL/v++SRrkiHgv6zuri+oXZRSEWIUHygfB7eNV0qAEj7J rpnA== X-Received: by 10.60.65.135 with SMTP id x7mr35790291oes.45.1409159218560; Wed, 27 Aug 2014 10:06:58 -0700 (PDT) Received: from ?IPv6:2605:6000:9005:3f00:9ca:cc81:2631:6162? ([2605:6000:9005:3f00:9ca:cc81:2631:6162]) by mx.google.com with ESMTPSA id tb3sm1329550oec.7.2014.08.27.10.06.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Aug 2014 10:06:57 -0700 (PDT) Message-ID: <53FE102E.1090006@gmail.com> Date: Wed, 27 Aug 2014 12:06:54 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, rai-discuss@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/YTXlFcMSignvWZorW0NAYYY86yI Cc: "tsv-ads@tools.ietf.org" , Aaron Falk Subject: [apps-discuss] Nominees to co-chair proposed TAPS working group? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Aug 2014 17:07:08 -0000 Martin and I have been talking about transport evolution, and we thought the proposal for a Transport Services (TAPS) BOF at IETF 90 was a great way to get started. We've completed the WG Review step of TAPS charter review, and the charter is on the next IESG telechat agenda for approval as a working group. We have selected Aaron Falk as a co-chair for the working group when it's formed, but want to consider having a co-chair from outside TSV, to make sure we get the perspective of protocol developers who make use of transport services. So, we're soliciting nominations (which can be self-nominations) from APP and from RAI, to see if we can make that happen. Aaron is an experienced WG chair, so we're able to consider folk who haven't chaired an IETF working group yet. The duties of a working group chair are described in http://tools.ietf.org/html/rfc2418#section-6.1. In addition, most TSV co-chairs serve on the TSV Directorate, described at http://trac.tools.ietf.org/area/tsv/trac/wiki/TSV-Directorate. We would expect TAPS co-chairs to attend most IETF face-to-face meetings, and to have some schedule flexibility to accommodate activities such as working group teleconferences. The current TAPS charter version is 00-02. The most up to date version of the charter is always at https://datatracker.ietf.org/doc/charter-ietf-taps/. We would expect to make a decision within the next week or two, given the right nominee. Please reply privately with nominations to tsv-ads@tools.ietf.org, and thanks for your help. Spencer and Martin, as TSV ADs From nobody Wed Aug 27 11:51:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28891A019C for ; Wed, 27 Aug 2014 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fUgC4APRFFW; Wed, 27 Aug 2014 11:51:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFD11A6F04; Wed, 27 Aug 2014 11:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-json-merge-patch@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827185137.5528.88815.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 11:51:37 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yovwJegEEXlmFqAr_AxsQd0QirY Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:51:45 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch/ From nobody Thu Aug 28 11:24:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5951A88FD for ; Thu, 28 Aug 2014 11:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZbR2ETjYaAE for ; Thu, 28 Aug 2014 11:24:52 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 04B851A88DF for ; Thu, 28 Aug 2014 11:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1409250288; d=isode.com; s=selector; i=@isode.com; bh=w+Q6x03Abq7+wuNX2ENDBh/oPZBJYUZagZUkTs4Xads=; 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=H+gpVn+Cr3opofX5r8JWmUrkcsdj6jXI1MKGne+5GDBcEbrZ+FVBihyabadY6j7zaQD5dJ 1LEeErWRoUIHnL04uXmntSm52M0wsp09vLN8MNw4am/v7GK/ujU0YnJSciUanqA+9rZgtl D3Hu1anmKyGd8ijZrf21c0+o/3JZ3I4=; Received: from [172.20.1.47] ((unknown) [217.34.220.158]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 28 Aug 2014 19:24:48 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <53FF740D.5060305@isode.com> Date: Thu, 28 Aug 2014 19:25:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UYZDRf6eXlpCJkXTmS6jbFnwTG8 Subject: [apps-discuss] WGLC on draft-ietf-appsawg-uri-scheme-reg X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Aug 2014 18:24:53 -0000 This message officially starts the APPSAWG Last Call for the following document: Guidelines and Registration Procedures for New URI Schemes http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ The Working Group Last Call for this document starts today, on Thursday, 28th of August and will end on Friday, 19th of September. This is about 3 weeks to accommodate for holiday season and impact this document can have on IETF and other SDOs. Please send any comments to the apps-discuss mailing list or directly to the chairs. Even if you reviewed this document and found no issues then please let the chairs know. Thank you, Alexey Melnikov, as an APPSAWG co-chair From nobody Thu Aug 28 11:26:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05E41A8911 for ; Thu, 28 Aug 2014 11:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBK1splqC2ki; Thu, 28 Aug 2014 11:26:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FDE1A890D; Thu, 28 Aug 2014 11:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140828182602.29957.22682.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 11:26:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oU9EppieT9gOemT1SLxGmIQRi7k Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:26:03 -0000 IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Thu Aug 28 11:42:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632571A897C for ; Thu, 28 Aug 2014 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rRtPDHy-lIj; Thu, 28 Aug 2014 11:42:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5461A897F; Thu, 28 Aug 2014 11:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140828184230.1493.65131.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 11:42:30 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WjnkWg8RFhTGnPg175eVTWcGrSw Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:42:39 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Thu Aug 28 15:06:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734651A002D for ; Thu, 28 Aug 2014 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffBHIvSrNKkt; Thu, 28 Aug 2014 15:05:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F04081A0012; Thu, 28 Aug 2014 15:05:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-nullmx@tools.ietf.org, dhc@dcrocker.net, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140828220554.29893.95600.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 15:05:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GQHIxpAv3_V3EJL94y3qZjldqqg Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 22:05:57 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ From nobody Fri Aug 29 02:48:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83B1A071D for ; Fri, 29 Aug 2014 02:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo8Xkq6FxnEu for ; Fri, 29 Aug 2014 02:47:57 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id C77801A0713 for ; Fri, 29 Aug 2014 02:47:56 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1XNImh-00024V-pl; Fri, 29 Aug 2014 10:47:55 +0100 Received: from oerc-dynamic-215.oerc.ox.ac.uk ([129.67.194.215]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1XNImg-0000rs-8c; Fri, 29 Aug 2014 10:47:54 +0100 Message-ID: <54004C58.6020406@ninebynine.org> Date: Fri, 29 Aug 2014 10:48:08 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexey Melnikov , "apps-discuss@ietf.org" References: <53FF740D.5060305@isode.com> In-Reply-To: <53FF740D.5060305@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZFE_YoFEqqKT_8WWYwF7oKsJWbU Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-uri-scheme-reg X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Aug 2014 09:48:00 -0000 On 28/08/2014 19:25, Alexey Melnikov wrote: > This message officially starts the APPSAWG Last Call for the following document: > Guidelines and Registration Procedures for New URI Schemes > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ It's been a while since I looked at this. Generally, I think it looks very good. Coming to this with relatively fresh eyes, I have some new comments. ... I have one possibly substantive comment: Section 4.1 sets out normative requirements on provisional registrations, mostly SHOULD, but some REQUIRED. Yet section 7.1 removes the requirement for any review (which I support). Thus, while I'm all for encouraging that various desiderata in section 4.1 are satisfied, I'm not sure if it works for these be be normative in a specification that may be not reviewed. My thoughts are to either: (a) tone down the normative language in section 4.1, while leaving everything strongly encouraged. E.g. Current: For a provisional registration, the following are REQUIRED: Propose: For a provisional registration, submitters are strongly encouraged to ensure their proposal satisfies the following criteria: (b) introduce some wording (e.g. in section 7.1) about the possibility of removal of a registration that is subsequently found to not conform to the normative requirements. On balance, as the purpose of provisional registration is to facilitate access to even rudimentary information about proposed and in-use schemes, I favour option (a) or similar. Related to this. It's never been a problem to date, but should there be some defined possibility for frivolous or disruptive registrations to be removed (e.g. at request of DE)? ... The following comments are mostly editorial, and don't substantively affect the spec. # 3.4. Definition of Operations Final paragraph (dereferencing). I think the spec should say something about dereferencing a URI being "safe", in the sense of http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction E.g., include something like this: The default invocation, or dereferencing, of a URI should be "safe" (in the sense described by [W3CWebArch] section 3.4); i.e. an agent performing such an interaction should not incur any additional obligations by doing so. # 3.7. Clear Security Considerations Current: The definition of an individual scheme should note which of these apply to the specified scheme. Suggest: The definition of an individual scheme should note which of these apply to the specified scheme, in addition to any more scheme-specific concerns. # 3.8. Scheme Name Considerations Para 5. The text introduces protocols and applications, then describes a requirement in terms of services. I find this reads oddly. Current: If a scheme name has a one-to-one correspondence with a service name (see section 5 of [RFC6335]), then the names SHOULD be the same. Suggest: If a scheme name has a one-to-one correspondence with a protocol or application name (see section 5 of [RFC6335]), then the names SHOULD be the same. Final para: I note there is still a problem reference [[CREF1...]] in this last-call document. ... That's all I have for you. #g From nobody Sat Aug 30 08:32:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4AC1A048A for ; Sat, 30 Aug 2014 08:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CUCQCYWGa65 for ; Sat, 30 Aug 2014 08:32:43 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E500B1A047E for ; Sat, 30 Aug 2014 08:32:42 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so4154948lab.9 for ; Sat, 30 Aug 2014 08:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uEtTHd6HIOCwa+FiGSnxjcf0CVjxHntVj3IMaZ2ipUQ=; b=s2GMBaWThGJ28t+KLDH3U2OaLujdeyrs1Ar1gi38+SvwzpYUFwNmzrTWcpWGFHSxSL IpsCXlQB0vt41hA1f0UzR74Nu8AIjzxR1FHipaQYoMFC9QPlWoUEh39FyGY8LZtVuXl3 7KkjZNrvQninx3u/vFGwNxzX0UrXIVi7jeOB5KA9RwkO4IpU5AG3vBNbJNcsZdQGPAX2 Oa8zj++WBXfjiHso0aWYbLVTevv10RzDBWq08gptkf20CZ/IrB3I7kDyVCSFeMXAXGsZ 1FqrB+micHYGXJW0cRqsPU9ACGJP3/uwHTr1dP8nm+DHiE6AbnxNZhBhSBTSx1MYKldZ ntpQ== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr2549896laj.88.1409412761127; Sat, 30 Aug 2014 08:32:41 -0700 (PDT) Received: by 10.25.211.82 with HTTP; Sat, 30 Aug 2014 08:32:41 -0700 (PDT) Date: Sat, 30 Aug 2014 08:32:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0160adf8f814250501da7a59 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-5cxMOOxymFRvQSkUcfDfk4dsM4 Subject: [apps-discuss] WGLC on draft-ietf-appsawg-authres-ptypes-registry-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Aug 2014 15:32:44 -0000 --089e0160adf8f814250501da7a59 Content-Type: text/plain; charset=UTF-8 This was sent to the wrong place. :-) ---------- Forwarded message ---------- From: Alexey Melnikov Date: Sat, Aug 30, 2014 at 5:02 AM Subject: WGLC on draft-ietf-appsawg-authres-ptypes-registry-02 To: "appsawg-chairs@tools.ietf.org" This message officially starts the APPSAWG Last Call for the following document: A Property Types Registry for the Authentication-Results Header Field The 2 weeks Working Group Last Call for this document starts today, on Saturday, 30th of August and will end on Sunday, 14th of September. Please send any comments to the apps-discuss mailing list or directly to the chairs. Even if you reviewed this document and found no issues then please let the chairs know. Thank you, Alexey Melnikov, as an APPSAWG co-chair --089e0160adf8f814250501da7a59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This was sent to the wrong place.=C2=A0 :-)

---------- Forwarded message ----------
From: <= b class=3D"gmail_sendername">Alexey Melnikov <alexey.melnikov@isode.com><= /span>
Date: Sat, Aug 30, 2014 at 5:02 AM
Subject: WGLC on draft-ietf-appsawg-a= uthres-ptypes-registry-02
To: "appsawg-chairs@tools.ietf.org" <appsawg-chairs@tools.ietf.org>


This message officially starts the APPSAWG Last Call for the follow= ing document:
=C2=A0 =C2=A0 A Property Types Registry for the Authentication-Results Head= er Field
<http://datatracker.ietf.org/doc/d= raft-ietf-appsawg-authres-ptypes-registry/>

The 2 weeks Working Group Last Call for this document starts today, on Satu= rday, 30th of August and will end on Sunday, 14th of September.

Please send any comments to the apps-discuss mailing list or directly to th= e chairs.=C2=A0 Even if you reviewed this document and found no issues then= please let the chairs know.

Thank you,
Alexey Melnikov, as an APPSAWG co-chair

--089e0160adf8f814250501da7a59-- From nobody Sun Aug 31 10:03:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1E31A89D5 for ; Sun, 31 Aug 2014 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv_LNNLodnSt for ; Sun, 31 Aug 2014 10:03:09 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F801A89C0 for ; Sun, 31 Aug 2014 10:03:08 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XO8Ww-0006Ae-1E; Sun, 31 Aug 2014 13:03:06 -0400 Date: Sun, 31 Aug 2014 13:03:05 -0400 From: John C Klensin To: S Moonesamy Message-ID: <1CF4D3316BAD53D80E72C20E@[192.168.1.128]> In-Reply-To: <6.2.5.6.2.20140830114726.0c78fd88@resistor.net> References: <47A1E127-4E2D-466A-9AF8-39990782C1A1@vigilsec.com> <9C9D9A59F858835CF6647755@JcK-HP8200.jck.com> <6.2.5.6.2.20140830114726.0c78fd88@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3W7ZE0JoOPTiaEDkSEXsGmrFx6g Cc: apps-discuss@ietf.org Subject: [apps-discuss] RFC2369 to Internet Standard) Re: The IETF should run an IMAPS server for its lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Aug 2014 17:03:12 -0000 (discussion, if more is needed, moved to Apps-Discuss from IETF list) --On Saturday, 30 August, 2014 11:49 -0700 S Moonesamy wrote: > Hi John, > At 10:03 30-08-2014, John C Klensin wrote: >> p.s. RFC 2369 is in extremely wide use by multiple independent >> implementations (including the IETF incarnation of MAILMAN). >> Can anyone think of a reason it should not be a full Standard? >> Volunteers to do the writeup and herd whatever and whomever >> need herding? > > See http://tools.ietf.org/html/draft-moonesamy-rfc2369bis-04 And so? From skimming that draft, it fails to recognize 2369 as a widely-accepted fact and widely deployed, thereby providing a reason to _not_ move it to full standard. In addition, it looks from the tracker [1] as if you and your colleagues simply ran out of steam in the first quarter of 2012, perhaps after John Levine's review of 6 January [2] (with which I do not entirely agree), and that Pete finally gave up on it at the beginning of 2013. Again from skimming, especially of Appendix B (I could have missed something) the only substantive changes to 2369 are the whitespace issues (which I'm not sure are substantive), adding a few more exemplar header fields, and updating references. And John points out, there is also some unnecessary and quite controversial material. Recommendation/Request: Unless you or others believe it would be inappropriate for some reason I haven't spotted in the draft you cite, can we just move RFC 2369 to Full Standard? The implementation report is that MAILMAN supports it and has done so for years, John's note implies that mj2 supports it. I'm pretty sure that I've seen messages from LISTSERV, Majordomo, and Oracle/Sun Messaging Server lists with those headers too, but two independent implementations is enough. The headers are widely used, including on all IETF lists (so "dogfood-eating" principles apply). There is no evidence that their presence in a message header set causes problems and some evidence that they are useful. If you then want to come back to this and produce an "updates" document that deals with references and whatever other issues you think are important (controversial or not), I think that would be a wonderful idea. You, however, should expect pushback on deployment and deployability of some of your suggestions along the lines of John L.'s review and from those of us who would be disturbed by something like it being approved without i18n considerations (EAI-related ones in particular) if nothing else. best, john [1] https://datatracker.ietf.org/doc/draft-moonesamy-rfc2369bis/history/ [2]http://www.ietf.org/mailarchive/web/appsdir/current/msg00687.html From nobody Sun Aug 31 10:38:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD841A8A54 for ; Sun, 31 Aug 2014 10:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8mUy00ooR2l for ; Sun, 31 Aug 2014 10:38:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2751C1A8A1D for ; Sun, 31 Aug 2014 10:38:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.234]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s7VHcGt0022996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2014 10:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1409506709; x=1409593109; bh=+frWIVoY6soOqjKX0wD4rMgQpJQoiIJM4fDSYggwyFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GfYG3pMaPDNYNZMiIEyA36ZArLGmKjaEktPuAkE6keNBgHJBVu75LiwBm9UXb5oPk 7I/PP2g+5DGM0BiaBeJMGbBXH+UsZsCwsCrBg01I/2rv5OQg0l5QBoA7LVlx3ol6TS PPc6WX0YbxG+ElSSsjEKKcTjFlamOu+dAT80iBn4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1409506709; x=1409593109; i=@elandsys.com; bh=+frWIVoY6soOqjKX0wD4rMgQpJQoiIJM4fDSYggwyFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YjSX8cdOCD1lY4Tkf80oaxuv+7SnMTjkv2ttMRjq3G0z8+fz3SeANCG8OnHKfb/ft bhNPiBSrSZeQT7YXkkvtriw4GVMpoBPUpsPxevZLMnRNfGOD5muGYLu1r1oVyf1o5j +X5G/40w28seuukTy4agLPpWVNtO7JNeEe8CciV0= Message-Id: <6.2.5.6.2.20140831100827.0beeb798@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 31 Aug 2014 10:30:52 -0700 To: John C Klensin From: S Moonesamy In-Reply-To: <1CF4D3316BAD53D80E72C20E@[192.168.1.128]> References: <47A1E127-4E2D-466A-9AF8-39990782C1A1@vigilsec.com> <9C9D9A59F858835CF6647755@JcK-HP8200.jck.com> <6.2.5.6.2.20140830114726.0c78fd88@resistor.net> <1CF4D3316BAD53D80E72C20E@[192.168.1.128]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wCbF4qkuzTSAf9lNHX5gzZKpl8c Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC2369 to Internet Standard) Re: The IETF should run an IMAPS server for its lists X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Aug 2014 17:38:35 -0000 Hi John, At 10:03 31-08-2014, John C Klensin wrote: >And so? From skimming that draft, it fails to recognize 2369 as >a widely-accepted fact and widely deployed, thereby providing a >reason to _not_ move it to full standard. In addition, it looks >from the tracker [1] as if you and your colleagues simply ran >out of steam in the first quarter of 2012, perhaps after John >Levine's review of 6 January [2] (with which I do not entirely >agree), and that Pete finally gave up on it at the beginning of >2013. The draft state was "External Party" in 2013. That was around the time the work in a working group took most of my time. I moved the thread to apps-discuss@ (see http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04030.html ). >Again from skimming, especially of Appendix B (I could have >missed something) the only substantive changes to 2369 are the >whitespace issues (which I'm not sure are substantive), adding a >few more exemplar header fields, and updating references. And >John points out, there is also some unnecessary and quite >controversial material. The main change is the "MUST NOT" for mailing list managers and URLs to URIs. >Recommendation/Request: Unless you or others believe it would be >inappropriate for some reason I haven't spotted in the draft you >cite, can we just move RFC 2369 to Full Standard? The >implementation report is that MAILMAN supports it and has done >so for years, John's note implies that mj2 supports it. I'm >pretty sure that I've seen messages from LISTSERV, Majordomo, >and Oracle/Sun Messaging Server lists with those headers too, >but two independent implementations is enough. The headers are >widely used, including on all IETF lists (so "dogfood-eating" >principles apply). There is no evidence that their presence in a >message header set causes problems and some evidence that they >are useful. The objective was to move RFC 2369 and RFC 2919 along the track. I asked for feedback from the Mailman developers. There are several implementations which support those header fields. Regards, S. Moonesamy